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

[Denis <[e-mail]>]

Justin,

> Removing the IESG as this is really a more internal-to-the-group 
> discussion, as it comes down to the scope of use cases that we want to 
> address here in GNAP.
>
> While it is definitely important to understand how and why OAuth 2 
> does things, we do need to keep use cases like Denis’s in mind.
Thanks.
> It’s not unheard of today for a single OAuth 2 RS to accept tokens 
> from multiple AS’s.

We are preparing the future. A simple case is to prove "who you are" and 
since banks "need to know their customers"
they would be well placed to provide an access token containing some 
verified personal attributes.

For example, a student would like to change university and would need to 
present his prior graduations.
In such a case, each university or school would be well placed to 
produce such a proof by issuing an access token.

> In fact, we’ve even got cases with things like the Solid project where 
> the RS will take a token from :any: AS so long as it can verify that 
> it’s approved by the resource owner. While the Solid platform has its 
> own special layering in place to allow this, our model should not 
> assume a closely-tied connection between an RS and any single AS. The 
> question of :how: we solve that is, of course, up to the WG to figure 
> out over time.

Would this mean that we strongly agree together that the model should 
not assume a closely-tied connection between an RS and any single AS ?

> Taking that even further, I think the idea of an AS that’s personal to 
> the user, to promote privacy and control, is a very good one.

In a previous message, I indicated that I have been able to understand 
what you mean by: an "AS that’s personal to the user" ?

> In fact, this is one of the main selling points of UMA2 and its 
> federated authorization mechanisms. With GNAP, we might be able to 
> deliver
> on this promise even more than UMA has been able to, and it’s my hope 
> that we can have a cohesive protocol that allows both user-to-self
> and user-to-another delegation sharing without needing to use 
> different mechanisms.
>
> Additionally, the RS-first method is also something from the UMA2 work 
> that we should be working on, as it touches on AS discovery, AS/RS 
> communication, and a few other aspects of the protocol design. It’s 
> not a trivial problem by any stretch, and there are huge privacy and 
> security implications, but there’s both need for it and some good 
> prior art to pull from. In fact, XYZ’s whole notion of a “transaction 
> handle” is an adaptation of UMA2’s “permission ticket”. In UMA, this 
> ticket is first issued to the RS by the AS, and the RS then hands it 
> to the client, which starts the negotiation for access. I envision 
> something very similar happening here with GNAP, where a client can 
> get something to bootstrap the process at the AS. The important thing, 
> to me, is that we don’t have to jump through a bunch of weird hoops 
> such that the AS-first and RS-first cases look completely different, 
> as they do in UMA2 and OAuth 2 respectively today. We’ve got the 
> chance to have a clean and cohesive protocol here, let’s not miss that 
> opportunity.
>
> So in sum, the trust model of OAuth 2 is not sufficient to cover 
> everything, and the model that Denis is proposing is something we 
> should at least look at as a use case.
> Where Denis and I seem to disagree is whether this trust model should 
> be the :only: one that we address with the protocol.

Any trust relationship may be described using the following 
construction:  entity A trusts entity B for some action C.
If you have in mind additional trust relationships, would you be able to 
express them using this construction ?
Maybe you also have in mind some relationships that do not imply a form 
of trust ?

> I strongly believe, as I believe much of this group does, that we 
> can’t discount or ignore (or make things overly difficult for)
> the tightly bound AS/RS combos, or any type of static setup where the 
> RS offloads its trust fully to the AS.
> But it’s my belief that we should be able to do so without needlessly 
> throwing out all of the OAuth 2 use cases.

Reading these sentences confuses me again since they seem to mean that 
the model should assume a closely-tied connection between RSs and ASs.

In OAuth 2.0, the scope parameter allows the client to specify the 
desired scope of the requested security token in the context of the 
service or resource
where the token will be used. The values and associated semantics of 
scope are service specific and and expected to be described in the 
relevant service
documentation [RFC 8693]. Since the scope is RS dependent, the client 
MUST inform the AS about the identity of the RS, but this should be 
avoided for
privacy reasons.

Currently in OAuth 2.0, there is no protocol being defined to be able to 
know which attributes correspond to a given scope for a given RS.
IMHO, the main idea is the following:  rather than using the scope 
parameter, the client should be able to inform directly the AS about
which attributes it needs. In this way, the client would not need to 
inform the AS for which RS these attributes are needed.

A major difference with OAuth 2.0 would be that attributes could be 
requested directly to an AS without using the pair scope/RS.
Such an approach would make the architecture scalable.

Denis

>
> We shouldn’t let “OAuth 2 doesn’t do it that way” be the limiting 
> factor here. We need to understand the what and wherefore of things 
> that OAuth 2 is bad at, otherwise we’re just going to re-invent OAuth 
> 2 and inherit its problems.
>
>  — Justin
>
>> On Jun 26, 2020, at 1:39 PM, Dick Hardt <[e-mail] 
>> <mailto:[e-mail]>> wrote:
>>
>> 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..
>>
>>
>>         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
>>
>> 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 client is may be delegating user authentication to the AS in 
>> identity claim use cases.
>>
>> The AS can act as the client in many OAuth deployments, as the access 
>> token is a bearer token. That does not mean the AS knows what the 
>> client is doing.
>>
>> /Dick
>> ᐧ
>> -- 
>> Txauth mailing list
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/txauth
>