Re: [Txauth] New version of XYZ Draft

[Justin Richer <[e-mail]>]

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] <mailto:[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] <mailto:[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] <mailto:[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 <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/ <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] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/txauth <https://www.ietf.org/mailman/listinfo/txauth>
>