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

[Denis <[e-mail]>]

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]> *On Behalf Of *Dick Hardt
> *Sent:* Friday, July 3, 2020 9:41 PM
> *To:* Denis <[e-mail]>
> *Cc:* Nat Sakimura <[e-mail]>; [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
>