Re: [Txauth] WG Review: Grant Negotiation and Authorization Protocol (gnap)
Dick Hardt <dick.hardt@gmail.com> Mon, 06 July 2020 16:59 UTC
Return-Path: <dick.hardt@gmail.com>
X-Original-To: txauth@ietfa.amsl.com
Delivered-To: txauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DA993A17E8; Mon, 6 Jul 2020 09:59:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oFfsc17XxSA2; Mon, 6 Jul 2020 09:58:59 -0700 (PDT)
Received: from mail-lj1-x243.google.com (mail-lj1-x243.google.com [IPv6:2a00:1450:4864:20::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CAFDE3A1809; Mon, 6 Jul 2020 09:58:58 -0700 (PDT)
Received: by mail-lj1-x243.google.com with SMTP id q4so10548872lji.2; Mon, 06 Jul 2020 09:58:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=OeyxxEsbbBTtRX7fNeYuixV4JY4+4XZLSMvVf9QGyNU=; b=WFSp9/y6PZuLsIVj3BhitEK6AvUo3GpDDivSpqgZkj9LKk+uNpLYL2k1JitV75p5tR uAwB/uD6nfIFYY7FQWXTTURveE6AaBcJ5Ji18n6GKIEAWL5caw1Vam1aGuA7BumrQZWW 3RHgb1ZOLK7JnBSOEAXkr13Otz4V0ak+25YFS3kig3I3ZrQNuClSgC1+RH4Xxz83xNsj 2Uhu2YdJmbXLHfpyb1db/N4PnNVmd/9VVMk/p4zFliWNPU+dx4sDI070N2aGDEGsOSXV s15vWYrnJ1ZCmgz4mLYax6AX5N7hN1AGx5q70EMOhq3EcVGAEA69lsuo1Qbq5vvKmdHV UktA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=OeyxxEsbbBTtRX7fNeYuixV4JY4+4XZLSMvVf9QGyNU=; b=Uj2bjHQnZNRJOhidOSGIYm+bfo9G5y/hQUO5xsdbW75hOrpremUfimUgIuEqb1jJCl w1TTTDTmwxwDpHs/Wpcl/5J0LtuNbpqLAdL7NNiRcJhgczcUXmQaXYQ/pLx/iXBpfKS0 +hqESsmdIz8a49kxWRrNPu3TOwPKRaQeqzh2aI9+/SfQ9GeCou6NBPVyx2cH9GiTaFgw HazIrA16IcTt6voqqo1USWXBeNDIGqelcIGvXkGLJBAPCxoEReDiLh1v01WSEgScIWxv Rl31XZKghGh/tOQ5QoEB57D+v2wi2X/TgSk7YpI682+PpQczx1wFEOMMFkYmznYFAaI3 502Q==
X-Gm-Message-State: AOAM5324VsxFKcpFQ9tW2NMtQeBJggWhHDp8ablfeiQXag5yl0qE8NLu Gj/0mUQayAXiZOgcTlHnpm5FbA2LDAxPmhE/k1co8Pqf
X-Google-Smtp-Source: ABdhPJyPJSV3fRLVk4XDsSZxFBRmExHyyM0V4r0S/s2kL4nTGgJvu1dofMwQhAoBAZs9r4iyVeMtAegc4GF2QN6yxDw=
X-Received: by 2002:a2e:900a:: with SMTP id h10mr29375886ljg.242.1594054736725; Mon, 06 Jul 2020 09:58:56 -0700 (PDT)
MIME-Version: 1.0
References: <159318778098.29096.6482921706088845432@ietfa.amsl.com> <cdbb228a-1412-e2e2-fe15-852fdd4649ac@free.fr> <CAD9ie-vrMk_D8WSz7h5aAw_FmnBJDkRJyWQeXTTsAP3ofH0iNg@mail.gmail.com> <a21d84cc-02d2-8140-bb4c-e4d6a05d737f@free.fr> <CAD9ie-tswzXQPgn13SMdQYQFfSxiuVu1hCuwsuUT5XbzbhmsKw@mail.gmail.com> <3c21e0fa-5636-54fe-675f-abc5b41ab09e@free.fr> <CAD9ie-tbuykhJAMFao+4wJU51GgCKPXCPZB-P+q+doMBFezarg@mail.gmail.com> <731a364a19a74e1d982d59d9c441dc0a@cert.org> <ef68863a-d97f-7632-7902-cc31136759eb@free.fr> <CAD9ie-saCvan0UPDOy=ccy11F7sQcmXOQjzBvDR=FUJrH1g9ow@mail.gmail.com> <354edabf-d9d5-1318-403f-866043e8d0a6@free.fr>
In-Reply-To: <354edabf-d9d5-1318-403f-866043e8d0a6@free.fr>
From: Dick Hardt <dick.hardt@gmail.com>
Date: Mon, 06 Jul 2020 09:58:20 -0700
Message-ID: <CAD9ie-uc+4k1wJpt=wBKn8yRDha_0W00WqW+t57fEVqq9xrirQ@mail.gmail.com>
To: Denis <denis.ietf@free.fr>
Cc: Roman Danyliw <rdd@cert.org>, Nat Sakimura <sakimura@gmail.com>, "txauth@ietf.org" <txauth@ietf.org>, The IESG <iesg@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000055cc4205a9c8cabc"
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/nByUfQpU-HG9OG7-zRzmtpM9Ocs>
Subject: Re: [Txauth] WG Review: Grant Negotiation and Authorization Protocol (gnap)
X-BeenThere: txauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <txauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/txauth>, <mailto:txauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/txauth/>
List-Post: <mailto:txauth@ietf.org>
List-Help: <mailto:txauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/txauth>, <mailto:txauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 06 Jul 2020 16:59:10 -0000
Security is not called out as a goal, but is a goal for ALL implementations/deployments. While privacy will be a goal for some implementations/deployments, it will NOT be a goal for all. I think your suggested additions will constrain the work. On Mon, Jul 6, 2020 at 9:38 AM Denis <denis.ietf@free.fr> wrote: > Hi Dick, > > Hi Denis > > Just like "privacy", "security" is not called out as a goal. (it is > mentioned as an issue with OAuth 2.0). > > The word "security" appears once in the charter, but the word "privacy" > does not appear. > > What goes well without saying, goes even better when you say it. > > Many features announced in the charter *prevent *to apply privacy > principles. > So it is easy to get the impression that the charter is considering that > privacy is a non-goal. > > "Privacy by design" should be mentioned as well as "privacy by default". > These two magic sentences are of utmost importance. > > Denis > > > On Mon, Jul 6, 2020 at 8:49 AM Denis <denis.ietf@free.fr> wrote: > >> One single comment. >> >> Dick wrote on the last line: >> >> I think pretty much everyone is onboard supporting privacy, but not all >> use cases have the same privacy considerations. >> >> I hope that this is true, but in such a case I can't understand why the >> word "*privacy*" is missing in the charter. >> >> Denis >> >> Note: IESG added >> >> Hello! >> >> >> >> I’m top-posting here because there is no easy way for me to cleaning >> insert my process comment. I think we are having a necessary conversation >> below and in no way should it stop because of this note. >> >> >> >> As a process check, this thread started with a request for community >> review on the charter text [1]. Among other things, this charter review is >> trying to ensure the problem is clear, defines the bounds of the desired >> solutions and identifies critical objections from the consensus-derived >> text. The text is not intended to define detailed >> requirements/architecture, resolve tradeoffs, or to specify a solution, >> unless they are critical to bounding the solution. These details should be >> left to future discussions of a chartered WG (not that they can’t start now >> in parallel). Additionally, as a reminder, while there are multiple >> individual drafts with proposed solutions in the datatracker, the design >> decisions they make are not part of the charter and their adoption is not >> assumed by the charter. If there are key design elements in those or any >> other documents that is felt to be crucial to scoping the WG, we need to >> capture the thinking, generalize it (as appropriate), and add it to the >> charter text explicitly or by reference. >> >> >> >> Let’s continue to talk about the technical details of the use cases, >> design properties, constraints and candidate solutions. Additionally, >> given the -05 charter text and milestones [2], it would be helpful to >> understand what outstanding concerns remain with the charter text in >> preparation for the Thursday, July 9th telechat where the IESG will use >> community feedback to help decide the way ahead for this proposed WG. >> >> >> >> Roman >> >> >> >> [1] >> https://mailarchive.ietf.org/arch/msg/txauth/4nE8rtyRPtdk0FrclQ1c-FWMO8w/ >> >> [2] https://datatracker.ietf.org/doc/charter-ietf-gnap/ >> >> >> >> >> >> >> >> *From:* Txauth <txauth-bounces@ietf.org> <txauth-bounces@ietf.org> *On >> Behalf Of *Dick Hardt >> *Sent:* Friday, July 3, 2020 9:41 PM >> *To:* Denis <denis.ietf@free.fr> <denis.ietf@free.fr> >> *Cc:* Nat Sakimura <sakimura@gmail.com> <sakimura@gmail.com>; >> txauth@ietf.org >> *Subject:* Re: [Txauth] WG Review: Grant Negotiation and Authorization >> Protocol (gnap) >> >> >> >> + Nat as he is mentioned >> >> - IESG >> >> >> >> On Fri, Jul 3, 2020 at 2:16 AM Denis <denis.ietf@free.fr> wrote: >> >> Hello Dick, >> >> >> >> Catching up on this email ... comments inserted ... >> >> >> >> On Mon, Jun 29, 2020 at 12:06 AM Denis <denis.ietf@free.fr> wrote: >> >> Hello Dick, >> >> >> >> Denis, thanks for sharing your thoughts, some clarifications on your >> statements inserted: >> >> >> >> On Fri, Jun 26, 2020 at 9:42 AM Denis <denis.ietf@free.fr> wrote: >> >> <snip> >> >> *New proposed charter* >> >> <snip> >> >> >> Resource servers inform their clients about which access token formats >> are acceptable and depending upon the king of operation >> that is requested, which kind of attributes are needed and from which ASs >> that my be obtained. >> >> While at times this may be appropriate, at other times disclosing the >> attributes the RS requires is not needed by the client. >> For example, an enterprise client accessing a resource does not need to >> know which groups a user belongs to, >> but the RS may require that to determine if the user running the client >> has access. >> >> As soon as there is a desire to implement privacy by default, the client >> should not provide more attributes than strictly necessary. >> Even after three readings of your example, I failed to understand it. >> >> >> A major difference with OAuth 2.0 is that there is no bilateral trust >> relationship between an authorization server and a resource server: >> for a given category of attributes, a resource server may trust one or >> more authorization servers. Another major difference with OAuth 2.0. >> is that the content of an attributes token is meant to be accessible to >> the client. >> >> This is not how OAuth 2.0 works. See slides 7 and 8 from my original IETF >> presentation on what became OAuth 2.0 >> >> >> >> https://www.slideshare.net/gueste648b/ietf-77-oauth-wrap-presentation >> >> I looked at the two slides. >> >> Unfortunately slide 7 has just one arrow with the word "trust". This is >> insufficient to understand what is meant unless being present >> at the presentation. Does it mean that the PR (RS) trusts one AS or that >> it may trust multiple ASs ? >> >> Unfortunately slide 8 has just one arrow between the PR and the AS which >> is red-crossed but no text at all. This is insufficient to understand >> what is meant unless being present at the presentation. Does it mean that >> the PR and the AS never communicate directly ? >> Does it mean that they have no relationships at all, besides the one way >> trust relationship mentioned in slide 7 ? >> >> So it hard to say whether these two slides are indeed meaning that there >> is no bilateral relationship between an authorization server and a resource >> server. >> >> Apologies for not providing an explanation on the slides. >> >> >> >> Slide 7 shows that trust between the AS and PR (now RS) was >> unidirectional, from the RS to the AS. >> >> Slide 8 indicates that trust is not bidirectional. >> >> [Denis] ... which means that slide 8 contradicts slide 7. :-) >> >> >> >> Slide 8 says it does not go both ways. Slide 7 says it goes one way. I >> don't see the contradiction. >> >> I would have preferred that you meant: the RS and the AS never >> communicate directly, which is indeed a nice property to follow >> to ensure the user's privacy. >> >> That is one model. Other models are appropriate in other circumstances.. >> >> >> >> >> >> There is no limit on how many ASs an RS may trust. >> >> [Denis] This is fine. >> >> On June 12, Nat Sakimura recently answered to an email with the >> following topic: >> >> Re: [OAUTH-WG] Comments on draft-ietf-oauth-jwsreq-22 (The OAuth 2.0 >> Authorization Framework: JWT Secured Authorization Request)) >> >> My arguments were: >> >> The original model for OAuth was making the assumption that the AS >> and the RS had a strong bilateral relationship. >> >> *A key question is whether such strong relationship will be >> maintained for ever *or >> whether it will be allowed to perform some evolutions of this >> relationship. >> >> In order to respect the privacy of the users, there is the need to >> encompass other scenarios. One of these scenarios is that the AS and the RS >> do not need any longer to have such a strong relationship. In terms >> of trust relationships, a RS simply needs to trust the access tokens issued >> by an AS. >> The AS does have any more a "need to know" of all the RSs that are >> accepting its access tokens. This would be a major simplification of the >> current global architecture. >> >> Nat's position was: >> >> "My take is that the basic assumption of OAuth 2.0 Framework is that >> there is a strong relationship between AS and RS. >> I feel that it is quite unrealistic that an RS would trust the access >> token issued by an AS that it has no strong relationship with". >> >> There are indeed different positions on this topic. >> >> >> >> I don't think Nat and I have different opinions, but I will let Nat >> clarify. >> >> Just because there is a strong relationship between the AS and RS, does >> not mean it is bidirectional. I would understand >> >> >> >> "I feel that it is quite unrealistic that an RS would trust the access >> token issued by an AS that it has no strong relationship with" >> >> >> >> to indicate Nat is expecting the trust to be from the RS to the AS. >> >> [Denis] Speaking of a "strong relationship" is ambiguous. The key point >> being whether the relationship is unilateral or bilateral. >> There is no need to use the wording "strong relationship" when the >> relationship is only unilateral: a RS simply trusts an AS for the access >> tokens it issues. >> In such a case, this does not mean that an AS is knowing all the RSs that >> are trusting it. >> >> On the contrary, a strong (bi-)relationship is when a RS and an AS both >> agree between them about the meaning of scope parameters. >> This is a typical case for OAuth 2.0. >> >> You can ask Nat what he meant by "strong relationship" >> >> >> >> The AS is stating what a scope means to it and the user.. The RS can do >> whatever it wants. I don't see that as requiring a bidirectional >> relationship. >> >> >> >> >> >> >> >> >> >> >> >> The AS may not even know who the RS (or PR in the slides) is. >> >> >> >> <snip> >> >> >> I got rid of the word "delegation": the client does not delegate anything >> to an authorization server. If it would, this would mean that the >> authorization server >> would be able to act as the client and could know everything that the >> client will do, which comes into contradiction with the user's privacy. >> >> >> >> The above is not true. >> >> >> >> The Resource Owner is delegating access control to the AS in >> authorization use cases. >> >> The OAuth 2.0 model does not mandate any more the presence of a Resource >> Owner. >> >> >> >> Why do you say that? The RO is who owns the RS. Your statement does not >> make sense. >> >> [Denis] I mean that there is not necessarily a protocol defined so that >> the RO can interact with the requests from the clients. >> >> Is the RO the User? In consumer use cases it usually is, and the RO is >> using the client. I'm not sure what you scenario you are describing >> >> >> >> >> >> >> >> >> >> The client is may be delegating user authentication to the AS in identity >> claim use cases. >> >> Delegating user authentication to the AS is different from delegating >> access control to the AS. >> >> >> >> Agreed. Your statement was there was no delegation. I'm explaining there >> are potentially two delegations. >> >> >> >> The AS can act as the client in many OAuth deployments, as the access >> token is a bearer token. >> >> A bearer token is rather insecure. >> >> Cookies are also bearer tokens. But we use them all the time in web apps >> for storing session state and prior authentication! :) >> >> >> >> >> >> That does not mean the AS knows what the client is doing. >> >> There are currently two attempts in the OAuth WG to let know to the AS >> what the client is doing: >> >> - draft-ietf-oauth-jwsreq-22 (The OAuth 2.0 Authorization >> Framework: JWT Secured Authorization Request) >> - draft-ietf-oauth-rar-01 (OAuth 2.0 Rich Authorization >> Requests) >> >> Those are optional, and in some situations are a desired property. >> >> [Denis] However, in these two drafts, the privacy considerations >> sections are silent on this point. >> >> There are lots of missing details in both drafts! Security >> considerations, error messages etc. >> >> >> >> I think pretty much everyone is onboard supporting privacy, but not all >> use cases have the same privacy considerations. >> >> >> >> /Dick >> >> >> > -- > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth >
- [Txauth] WG Review: Grant Negotiation and Authori… The IESG
- Re: [Txauth] WG Review: Grant Negotiation and Aut… Denis
- Re: [Txauth] WG Review: Grant Negotiation and Aut… Dick Hardt
- Re: [Txauth] WG Review: Grant Negotiation and Aut… Dick Hardt
- Re: [Txauth] WG Review: Grant Negotiation and Aut… Justin Richer
- Re: [Txauth] WG Review: Grant Negotiation and Aut… Tom Jones
- Re: [Txauth] WG Review: Grant Negotiation and Aut… Justin Richer
- Re: [Txauth] WG Review: Grant Negotiation and Aut… Dick Hardt
- Re: [Txauth] WG Review: Grant Negotiation and Aut… Tom Jones
- Re: [Txauth] WG Review: Grant Negotiation and Aut… Justin Richer
- Re: [Txauth] WG Review: Grant Negotiation and Aut… Dick Hardt
- Re: [Txauth] WG Review: Grant Negotiation and Aut… Denis
- Re: [Txauth] WG Review: Grant Negotiation and Aut… Denis
- Re: [Txauth] WG Review: Grant Negotiation and Aut… Justin Richer
- Re: [Txauth] WG Review: Grant Negotiation and Aut… Mike Varley
- Re: [Txauth] WG Review: Grant Negotiation and Aut… Tom Jones
- Re: [Txauth] WG Review: Grant Negotiation and Aut… Denis
- Re: [Txauth] WG Review: Grant Negotiation and Aut… Denis
- Re: [Txauth] WG Review: Grant Negotiation and Aut… Dick Hardt
- Re: [Txauth] WG Review: Grant Negotiation and Aut… Dick Hardt
- Re: [Txauth] WG Review: Grant Negotiation and Aut… Denis
- Re: [Txauth] WG Review: Grant Negotiation and Aut… Dick Hardt
- Re: [Txauth] WG Review: Grant Negotiation and Aut… Roman Danyliw
- Re: [Txauth] WG Review: Grant Negotiation and Aut… Roman Danyliw
- Re: [Txauth] WG Review: Grant Negotiation and Aut… Denis
- Re: [Txauth] WG Review: Grant Negotiation and Aut… Denis
- Re: [Txauth] WG Review: Grant Negotiation and Aut… Dick Hardt
- Re: [Txauth] WG Review: Grant Negotiation and Aut… Dick Hardt
- Re: [Txauth] WG Review: Grant Negotiation and Aut… Denis
- Re: [Txauth] WG Review: Grant Negotiation and Aut… Dick Hardt
- Re: [Txauth] WG Review: Grant Negotiation and Aut… Roman Danyliw
- Re: [Txauth] WG Review: Grant Negotiation and Aut… Tom Jones
- Re: [Txauth] WG Review: Grant Negotiation and Aut… Denis
- Re: [Txauth] WG Review: Grant Negotiation and Aut… Tom Jones
- Re: [Txauth] WG Review: Grant Negotiation and Aut… Justin Richer
- Re: [Txauth] WG Review: Grant Negotiation and Aut… Denis
- Re: [Txauth] WG Review: Grant Negotiation and Aut… Tom Jones
- Re: [Txauth] WG Review: Grant Negotiation and Aut… Justin Richer