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

[Dick Hardt <[e-mail]>]

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