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

[Tom Jones <[e-mail]>]

+1 - Right on Justin.
Peace ..tom


On Sat, Jun 27, 2020 at 1:15 PM Dick Hardt <[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]> 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]> 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]> 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]
>> https://www.ietf.org/mailman/listinfo/txauth
>>
>>
>> --
>> Txauth mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/txauth
>>
> --
> Txauth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/txauth
>