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

[Justin Richer <[e-mail]>]

I’m also worried about feature creep, but it’s something that the group can guard against in very practical ways. It’s dangerous to dismiss someone else’s work as “only theoretical”, especially because GNAP is going to draw from a different sent of circumstances that are going to be outside the experience of the core OAuth community, and that’s a really good thing. 

But I believe that we can apply a set of sensible criteria to things:

 - Is there an implementation (even a proof of concept)? Running code makes bad assumptions come out in sharp relief, and we need to test these assumptions constantly. But also keep in mind that running code can be changed.
 - Is there an existing, perhaps more convoluted, solution out there? Pulling disparate systems under a common structure should be a way of working here. But this only works if it can come “in common” and we aren’t stretching the abstractions so much that they’re meaningless.
 - Does it fit in the GNAP model along with other work? This might mean we have to adjust the model, but such adjustments shouldn’t be at the expense of all other use cases. Sometimes, things don’t fit, and that’s ok.

Cohesiveness of the GNAP solution will come from applying good engineering and questioning assumptions about our existing and proposed solutions. It’s important that we know the :why: of things and not just the :what:. The last thing I think we want is a protocol that is actually a bunch of completely different protocols with switched behavior. This is one of the biggest complaints that I see about OAuth 2’s “framework” approach and I think we have an opportunity to do much better here if we get the model right. That’s going to take time and effort, but I believe it’s possible, and I look forward to building that with everyone here.

Right now, our best focus is going to be use cases — what do people want to :do: with GNAP — and what those use cases say about our model and assumptions going in to the solution space. There are a number of valuable points in both Tom and Denis’s discussion below. Some of it fits, some of it doesn’t. Some of it might be better for an extension. Some of it might be counter to what we’re after. 

Discussing all of that is why we’re all in a standards working group and not just building a commercial product.

 — Justin

> On Jun 27, 2020, at 4:45 PM, Tom Jones <[e-mail]> wrote:
> 
> +1 - Right on Justin.
> Peace ..tom
> 
> 
> On Sat, Jun 27, 2020 at 1:15 PM Dick Hardt <[e-mail] <mailto:[e-mail]>> wrote:
> +1 to 'We shouldn’t let “OAuth 2 doesn’t do it that way” be the limiting factor here.'
> 
> Conversely, I worry about scope creep if we are forced to complicate the protocol to cover use cases that are only theoretical. (I'm not implying that any of the use cases discussed in this thread are in that category).
> 
> /Dick
> 
> On Sat, Jun 27, 2020 at 12:56 PM Justin Richer <[e-mail] <mailto:[e-mail]>> wrote:
> 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. It’s not unheard of today for a single OAuth 2 RS to accept tokens from multiple AS’s. 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.
> 
> 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 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. 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.
> 
> 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>
> 
> -- 
> Txauth mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/txauth <https://www.ietf.org/mailman/listinfo/txauth>
> -- 
> Txauth mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/txauth <https://www.ietf.org/mailman/listinfo/txauth>