Re: [Txauth] New version of XYZ Draft

[Dick Hardt <[e-mail]>]

Justin: how about we let the chairs drive WG conversations on the
goals, and we focus on the technical discussion?

In addition to my questions and observations earlier, here is my feedback
on the new capabilities in XYZ:

2.5.2. Redirect to an Arbitrary Short URL

This looks the same as 2.5.1 except it is short. My concern with both of
these is the AS has no signal on the mode chosen by the client/user. It
could be a redirect on the same device, or decoupled, where the user is now
on a different device. In 2.5.3 you justify a new URL because the AS may
want a different URL for an app. I think that is even more significant
between an on device redirect, and a decoupled experience. By having
different URLs for the different modes in XAuth, the AS can ensure the one
in a decoupled mode is short enough to be scanned if decoupled is
supported. In other words, the mode dictates if it should be short enough
to be scanned.

2.5.3 Open an Application-specific URL

What are you intending "app" to mean? I can think of a device where the
client can open a URL, and a URL could not be associated with an
application on the device. Are you thinking the client will do some
detection if a specific app is available on the device? What if the app is
not on the device? Most platforms don't provide any probing on what other
apps are on a device, so there is no mechanism to detect if the app is
present prior to launching. Is that what you are expecting?

2.5.5. Receive an HTTP Direct Callback

What use cases require this functionality? Contrary to SecEvent, where both
push and poll are specified because a receiver may not be able to have a
public endpoint, the AS has a public endpoint for the client to call. In
GNAP, the client can poll the AS. Why have both?

/Dick



On Sat, Jul 18, 2020 at 7:55 AM Justin Richer <[e-mail]> wrote:

> I really don’t see them as shifting towards each other so much as it is
> them adapting and changing based on ongoing efforts. As such I’ve modified
> XYZ not to make it “look more like XAuth”, but rather to hopefully improve
> it in some measurable dimensions. So if you wonder why it doesn’t “look
> even more like XAuth” it’s because I don’t think that such changes would be
> improvements — in fact, even with recent improvements, I think there are a
> still a lot of issues with XAuth’s design and assumptions. XYZ can, I’m
> sure, also be improved.
>
> The goal here isn’t to take two projects and make them look the same. The
> goal here is to make one protocol, GNAP, with the best ideas and elements
> engineered into it that we, as a working group, can. It’s not about one
> input proposal winning over another, it’s about improving our understanding
> of all the use cases and possible solutions and coming up with the best
> specification possible. Making things better should always be the goal.
> Progress should always be the goal.
>
> But we aren’t here to build XYZ or XAuth. We’re here to build GNAP and
> decide what GNAP looks like. XYZ’s structure and design is the best I’ve
> been able to make it so far, and it should be our goal as a WG to move past
> either XYZ or XAuth and build GNAP even better than any of that.
>
>  — Justin
>
> On Jul 17, 2020, at 6:46 PM, Dick Hardt <[e-mail]> wrote:
>
> XYZ is looking a lot more like XAuth, similar to how XAuth has shifted
> towards XYZ.
>
> I have implemented separate URIs for grants and authorizations, and it
> worked really well.
>
> All 3 of the new capabilities are problematic. Perhaps you did not notice
> that there no longer is a short_uri in XAuth? As I recall, you were opposed
> to the short URI that was in the earlier drafts of XAuth. In my XAuth
> implementation, I show QR codes in the CLI app. Have you checked out my
> implementation? Have you implemented a QR code? I found that the string did
> not need to be nearly as short as it has in the past.
>
> I still don't understand the requirement to rotate the reference handle. I
> read over the pointer you provided last time we discussed it, and
> responded, but I have not heard back from you on that.
>
>
> ᐧ
>
> On Fri, Jul 17, 2020 at 2:36 PM Justin Richer <[e-mail]> wrote:
>
>> Most of these are changes I’ve wanted to do for quite some time and
>> finally had opportunity to make the edits. As I said below, the core
>> protocol really hasn’t changed in nature, but hopefully it’s easier to
>> understand with it laid out in this way.
>>
>> All of these are points that I’ve made previously on the list in
>> discussions, but to answer your questions directly:
>>
>> - Mapping items to separate URLs has been on XYZ’s radar since well
>> before it was proposed in Xauth, so this is bringing some of that into the
>> concrete system. I still need to implement it to see how well it works in
>> practice.
>>
>> - The need to rotate the reference handle as well as use it externally
>> (the “extend a request” method) both call for having an identifier separate
>> from the access URL. It also allows an AS more freedom in how it manages
>> its endpoints, and aligns with the desire to push more information into the
>> ongoing request after the initial phase. I’d actually rather the access
>> token management move in that direction, using the token itself as the
>> artifact, but I couldn’t do that and still use the DELETE method for
>> revocation. So that’s an engineering challenge that I think the group
>> should discuss, and decide whether it’s worth having the “DELETE” verb
>> semantics and having that restriction placed on the AS as a consequence.
>>
>> - The DID work is likely better suited for an extension, and always has
>> been. But it was worth having in previous revisions for discussion
>> purposes, especially as a point around how a non-HTTP interaction method
>> would work. I expect to see DIDCOMM, CHAPI, WebAuthN, and other interaction
>> methods in the extensions landscape of GNAP, usable alongside the others.
>>
>> And a final point, the interaction setup hasn’t really changed, so I’m
>> curious to hear what you think *has* changed there. Even with a couple
>> new capabilities on the way there (short_uri and app) and back (pushback),
>> It’s structurally and conceptually identical to previous revisions.
>>
>>  — Justin
>>
>> On Jul 17, 2020, at 1:10 PM, Dick Hardt <[e-mail]> wrote:
>>
>> Hey Justin,
>>
>> Glad to see that you are aligning on having URIs for the access tokens
>> and the "grant".
>>
>> While the token URI is unique to the token, you have not done the same
>> for a "grant", but have a handle and a non-unique URI.
>>
>> Why not have a unique grant URI similar to the token URI? (a combination
>> of the handle and a non-unique URI) -- this is then both the identifier,
>> and the URL for "management"?
>>
>> Glad to see you have excised the DID references. I don't think the common
>> use cases are well established there currently.
>>
>> I have LOTS of feedback on your interaction changes, that I'll post later
>> on, and hope that others have feedback on those as well.
>>
>> /Dick
>>
>>
>>
>>
>>
>> On Thu, Jul 16, 2020 at 2:52 PM Justin Richer <[e-mail]> wrote:
>>
>>> Hi all,
>>>
>>> I’ve updated the XYZ draft specification. Since the publication tools
>>> are currently locked prior to the upcoming virtual meeting, I have
>>> published it online here:
>>>
>>> https://oauth.xyz/draft-richer-transactional-authz
>>>
>>> This represents a pretty significant refactoring of the specification,
>>> hopefully to make the concepts and capabilities easier to understand. The
>>> core protocol is largely the same as before, but there are a number of
>>> serious updates:
>>>
>>>  - Continuation requests happen at a URL returned in the TX response.
>>> The “handle” is still sent as one of the input values here, since the
>>> handle can also be used it other contexts.
>>>  - Tokens now can include the resources they are issued for
>>>  - Tokens can have an optional management URI for rotation and
>>> revocation.
>>>  - “claims” has been removed in favor of “subject” dealing directly with
>>> identifiers and assertions
>>>  - the “user” request and response now align with identifiers and
>>> assertions
>>>  - Extensions and registries are more clearly enumerated throughout the
>>> document
>>>  - DID-related items have been excised in deference to a future possible
>>> extension
>>>  - Added a “pushback” mechanism to complement the “callback” mechanism
>>>  - Simplified dynamic handle returns and access tokens based on
>>> developer feedback (basically we dropped a bunch of “what if” stuff that
>>> nobody used or liked, like SHA3 hashes for bearer tokens)
>>>
>>> I’ve also updated the interactive examples on https://oauth.xyz/ to
>>> match this new draft. Hopefully it’s consistent with the draft text.
>>>
>>> I have not yet, however, updated any of the implementations of XYZ to
>>> take the elements of new syntax into account, so there might be some more
>>> changes prior to the IETF meeting as I realize what terrible mistakes I’ve
>>> made when doing that. :)
>>>
>>> Feedback, as always, is welcomed, and thanks to everyone who’s provided
>>> input to the project to date.
>>>
>>>  — Justin
>>> --
>>> Txauth mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/txauth
>>>
>>
>>
>