Re: [Txauth] WG Review: Grant Negotiation and Authorization Protocol (gnap)

[Denis <[e-mail]>]

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 wellwithout saying, goes even better whenyou sayit.

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 <[e-mail] 
> <mailto:[e-mail]>> 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 9^th
>>     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/
>>     <https://datatracker.ietf.org/doc/charter-ietf-gnap/>
>>
>>     *From:* Txauth <[e-mail]>
>>     <mailto:[e-mail]> *On Behalf Of *Dick Hardt
>>     *Sent:* Friday, July 3, 2020 9:41 PM
>>     *To:* Denis <[e-mail]> <mailto:[e-mail]>
>>     *Cc:* Nat Sakimura <[e-mail]>
>>     <mailto:[e-mail]>; [e-mail] <mailto:[e-mail]>
>>     *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 <[e-mail]
>>     <mailto:[e-mail]>> wrote:
>>
>>         Hello Dick,
>>
>>             Catching up on this email ... comments inserted ...
>>
>>             On Mon, Jun 29, 2020 at 12:06 AM Denis
>>             <[e-mail] <mailto:[e-mail]>> 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
>>                     <[e-mail] <mailto:[e-mail]>>
>>                     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
>>
>