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

[Denis <[e-mail]>]

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.  :-)

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.

> 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.

>
>>     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.

>>
>>     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.

Denis

> /Dick
>