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

[Dick Hardt <[e-mail]>]

In case it was not clear from my email, I was not dismissing anybody's work
as "theoretical".

On Sun, Jun 28, 2020 at 10:50 AM Justin Richer <[e-mail]> wrote:

> 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]> 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
>>
>
>