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

[Dick Hardt <[e-mail]>]

(dropping IESG, adding Nat as Denis is quoting him)

On Thu, Jul 2, 2020 at 10:59 AM Dick Hardt <[e-mail]> wrote:

> Catching up on this email ... comments inserted ...
>
> On Mon, Jun 29, 2020 at 12:06 AM Denis <[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]> 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.
>
> There is no limit on how many ASs an RS may trust.
>
>
>> 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.
>
>
>
>>
>> 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.
>
>
>>
>> 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.
>
> /Dick
>
>