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

[Justin Richer <[e-mail]>]

Hi Denis,

> On Jun 29, 2020, at 3:13 AM, Denis <[e-mail]> wrote:
> 
> 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.
> 
This is a great example — each university is definitely in place to produce the attributes bound to the user, and therefore to host the “graduation proof” API. But the question is, who will produce the access tokens that can be used for each copy of that API?

In the OAuth 2 trust model, each university would have its own AS protecting its own API. That model still makes sense for a lot of things, and maybe even this case as well. But each university could also accept, say, access tokens from other universities within a consortium, or from a trusted third-party agency, or even an arbitrary AS as long as the access token can prove it’s bound to a user credential the university can trust as being that former student. There are a lot of possibilities, and the details of most of these other scenarios are going to rely on additional pieces that will be defined outside of GNAP.

>> 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 ?
> 
Correct, we shouldn’t assume it, but we should also not preclude it. I think a lot of the internet is going keep with that model for some time to come, even if it’s not universal.

>> 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" ?
> 
This means that a user has their own AS that’s under their personal control. Maybe it’s something they host on the web somewhere, or maybe it’s an app on their personal device, or any number of things. As below, this is the idealized UMA model below, where the user gets to decide which AS to use to protect their data API.
>> 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 ?
> 
The difference isn’t on what “trust” means, the difference is on which parties are A, B, and C in your equation above, and more importantly, *why* they trust. There are scenarios where the RS would trust the user because the RS knows the user, not because of which AS the user is using. 
>> 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.
> 
The scope doesn’t have to be RS dependent, you can have many RS’s implementing the same API with the same scopes. There are of course plenty of instances where the scope does identify the RS, but there’s also been other work in the OAuth WG like the “resource” parameter [RFC8707] to provide explicit direction as well. Honestly that aspect of the request is a bit of a mess in OAuth right now, and it’s one of the main things I think we need to clean up here in GNAP. Incidentally, this is why I’m so against simply importing “scope” and RAR directly into GNAP, we need to move past the intrinsic limitations in those systems.
> 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.
> 

In GNAP, we will be defining ways to do fine-grained access control. This will let the client specify what it wants across a wide range of dimensions, and that’s a really powerful pattern. One of the dimensions that the client :could: specify to the AS is which RS it wants to talk to. In some deployments, this will let the AS draft a token that is limited to just that single RS, perhaps by encrypting it against the RS’s key or setting an audience-restriction field. So using the syntax from XYX and RAR (which is a back-port of part of XYZ to OAuth 2), you get something like this:

	{
		resources: {
			location: [“https://rs.example.com/resource <https://rs.example.com/resource>”],
			action: [“read”]
		}
	}

But there are other cases, like what you’re talking about in this thread, where you don’t want the AS to know which RS the client is going to talk to. The client knows, and it just needs to get a token that the RS will trust for the action it wants to take. Using the same syntax, that would look something like this:

	{
		resources: {
			action: [“read”]
			type: “proof_of_graduation”
		}
	}

Which one of these do you use? That’s up to your API deployment. What will your RS want or need to know in order to fulfill the request? What will your AS need in order to create a token that will work for the deployed system? That’s not something the protocol should dictate, but it should allow that choice. The client needs to know what to ask for, the AS needs to know what to expect and issue, and the RS needs to know what to look for in (or about) the token.

This is one of the places where I think we can really start to innovate and bring these worlds together. There’s kind of an artificial split right now and we can do better. OAuth 2 moved us past the concept of the AS and RS being the same system (just called the “server” in OAuth 1), and UMA pushed the conversation further into the AS and RS being introduced to each other during the protocol flow. GNAP can keep this going, and do so without giving up the ability for the RS to be tightly bound to the AS, if the deployment desires or requires it. I think we can do these advanced distributed trust models without getting in the way of the classical AS-as-the-hub trust model form OAuth 2, and both become options that (importantly) work pretty similarly within the GNAP protocol itself.

 — Justin

> 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 <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 <https://www.ietf.org/mailman/listinfo/txauth>
>> 
>