Re: [Txauth] XYZ-08 vs XAuth-08

[Justin Richer <[e-mail]>]

Hi Dick, responses inline.

> On Jun 7, 2020, at 3:27 PM, Dick Hardt <[e-mail]> wrote:
> 
> Hello
> 
> I have just posed some updates on the XAuth draft:
> 
> In -07 I added the XYZ features of interaction negotiation, and a Client Handle for dynamic clients. I also updated the name to GNAP, but preserved the draft-hardt-xauth-protocol filename for ease of tracking changes. 
> 
> In -08 I split the doc into: core protocol, advanced features, and JOSE authentication. 
> 
> https://www.ietf.org/id/draft-hardt-xauth-protocol-08.html <https://www.ietf.org/id/draft-hardt-xauth-protocol-08.html>
> https://www.ietf.org/id/draft-hardt-gnap-advanced-00.html <https://www.ietf.org/id/draft-hardt-gnap-advanced-00.html>
> https://www.ietf.org/id/draft-hardt-gnap-jose-00.html <https://www.ietf.org/id/draft-hardt-gnap-jose-00.html>
> 
> IMHO, the main doc is much more readable. :)
> 

I think that renaming your individual draft is premature and presumptive, as the WG has not yet decided on an approach for the WG base draft and renaming one of the input drafts like this is going to simply add to confusion when trying to discuss and compare different approaches. I would recommend undoing this name change in order to facilitate discussion going forward, to allow people to refer to one project with a single name and know what it means.

As you and I have discussed offline, and as you yourself suggested, it might be beneficial for the working group to start from a new draft document incorporating the most important features. Until we reach that point, renaming any of the input drafts into what the group’s target draft will be is going to cause problems.

> 
> XYZ vs XAuth
> 
> The remaining major differences between XYZ and XAuth are areas I have concerns about. (I will continue to use XYZ and XAuth refer to each draft). The concerns are:
> 
> 1) API in JSON vs URI and HTTP Verb
> 
> In XYZ, all calls are to the same endpoint as an HTTP POST. The AS must parse the JSON to determine what to do. 
> 
> XAuth has a RESTful interface. A Grant Request starts at the GS URI, and Grants and Authorizations are returned as URI resources. Creating a Grant is done with a POST, reading a Grant is done with a GET. 
> 
> With URIs and HTTP verbs, A large scale GS can easily implement independent services for each  functionality as routing of requests can be done at the HTTP layer based on the URI and HTTP verb. This allows a separation of concerns, independent deployment, and resiliency.

As I have said many, many times, both on the list and in the documentation for XYZ, this is an area that is worth discussing within the working group. It’s been tagged a potential direction in XYZ from early days, but not something that we’ve pursued because it hasn’t been needed in the spaces we’ve used it.

So saying this is a fundamental aspect of XYZ and implying that it’s a non-starter for it to not be built that way is misdirection. I hope that the conversation here in this group can continue without you ignoring or dismissing previous statements like this as we discuss things. 

Additionally, I find XAuth’s restrictions on the structure of the Grant URI potentially problematic, namely that it has to start with the server’s URL. This will lead to deployments needing to bend their setups with proxies or redirectors to make things fit, which you yourself have said is going to be an issue for things like supporting a short redirect URL vs. a long redirect URL. Your complaint there was one of latency and complexity, why does that not apply here? But most fundamentally, I do not see what value this restriction brings to the system. If the value is coming back from the GS endpoint, and the client is getting all of its pointers from there, what’s the point of dictating how that has to look?

> 
> 2) Handles for all Clients vs Client ID and Client Handle
> 
> In XYZ, both pre-registered clients and dynamic clients use a handle. 
> 
> In XAuth, the Client ID refers to a pre-registered client, and the Client Handle is specific to an instance of a dynamic client. Using separate terms clearly differentiates which identifier is being presented to the GS. 
> 
> This allows a GS to use separate mechanisms for managing pre-registered clients and dynamic clients, an important consideration as there can easily be millions of instances of a single dynamic client.
> 
> Additionally, developers are already familiar with what a Client ID is for pre-registered clients.

I see the inconsistency in the XAuth draft to be problematic. Under this proposed model, I now need to be able to track clients using different kinds of identifiers depending on what kind of registration they used? Why build in this dichotomy?

One of the design goals of XYZ was to bring consistency to the haphazard world of OAuth 2, where a client ID could mean a class of client software or an individual client or a cluster of servers or any number of other things. 

And as I’ve demonstrated with an implementation on top of the MITREid Connect OAuth 2 server, it’s completely possible and well within-protocol to pass in a static client ID within the XYZ’s “key handle” field and have things work as expected. Yes, it’s called something different — but if that’s a problem, then XAuth’s renaming of the Authorization Server to a Grant Server is going to be significantly more confusing for developers, don’t you think?

> 
> 3) Transaction Handles are One Time Use
> 
> In XYZ, transaction handles are one time use [1]. In the OAuth WG discussion on one time use refresh tokens, clients are often distributed across components, which complicates one time use references. 
> 
> One time use transaction handles also makes them inconsistent with the display, resource, user, and key handles.

Transaction handles being one-time-use is based on experience with a session fixation attack against UMA (now patched):

https://kantarainitiative.org/confluence/display/uma/Understanding+the+Session+Fixation+Attack+on+UMA+Claims-Gathering+and+the+Provided+Mitigation <https://kantarainitiative.org/confluence/display/uma/Understanding+the+Session+Fixation+Attack+on+UMA+Claims-Gathering+and+the+Provided+Mitigation>

Clients with distributed components are going to have to be considered in our core model, and so there are considerations and tradeoffs in terms of security and deployability that we need to address here. These are the same kinds of discussions that we’re having in OAuth 2, as you point out, and so we can not only apply that experience and knowledge to this, but we can build something that behaves better than a refresh token for this purpose.

> 
> 4) New User Identifier
> 
> XYZ introduces a new identifier for the user, a User Handle. Unclear why a new type of user identifier is needed, except for the desire to have a handle for everything.
> 

This is based directly on the Persisted Claims Token concept from UMA2, where a client (that is trusted to make such a statement) can say that it reasonably believes that the current user interacting with this client is the same user that it’s been interacting with before, for use with a future request. An AS can take this signal into consideration when processing the request, potentially avoiding unnecessary interaction and friction.

I’m not surprised that you see this as “just applying a handle for everything” considering you’ve previously objected to the use of the pass-by-reference construct for other aspects of the protocol in the past as well. Each component in XYZ that has a separate handle has one for specific and documented reasons, and it’s a core feature that these are handled (pun intended) in a consistent and predictable manner.

> 5) Interaction Capabilities vs Modes
> 
> In XYZ, the capabilities are expressed by the client, and the GS states which capabilities it will accept. This can make it difficult for the GS to enforce the interaction choices as the client can mix and match which capabilities are returned. For example, a GS may not want to support a redirect without a callback to protect itself from session fixation attacks. In XAuth, the interaction modes provide clarity on the mode of interaction and the security properties. For example the GS may support both user_code and redirect modes, but not the indirect mode which is subject to session fixation attacks.
> 

If the GS doesn’t want to accept a redirect without a callback, it can because the request will have a redirect, but not a callback, and it can reject the request. What makes you believe that this is not detectable or not possible in XYZ? 

The modes in XAuth are much more limiting, as the mixing of different interaction methods is already something that we need to start figuring out. Let’s say, for example, a client can do a redirect, accept a CIBA-style ping, or do a direct app2app communication. There’s a natural preference the client will have here: if it can talk to another app directly, it’ll try that first. If that doesn’t work, it can get a push notification sent, and if all that fails, it can pop open a browser. If I have to pick just one of those modes when I make the request, then the client needs to make three different requests to the AS before I get anything that works. 

This kind of mixing is important to allow for different modalities of client. In fact, the return callback could be tied to the entry of a user code, not just an outbound redirect. How the client gets the user to the AS and how the user gets back are separate questions, and we need flexibility in both. XAuth ties them together in the same way that OAuth 2 does, and this is an unnecessary restriction that does not add security or simplicity.

> 6) Claims at Top Level vs Namespaced 
> 
> In XYZ, there is one schema for claims, and they are requested as:
> 
>    "claims": {
>        "subject": true,
>        "email": true
>    }
> 
> Whereas in XAuth, claims are in their own namespace:
> 
>     "claims": {
>         "oidc": {
>             "id_token" : {
>                 "email"          : { "essential" : true },
>                 "email_verified" : { "essential" : true }
>             },
>             "userinfo" : {
>                 "name"           : { "essential" : true },
>                 "picture"        : null
>             }
>         }
> 
> In this example, the client is requesting OIDC defined claims, the email to be in an ID Token, and the name and picture to be as text. While the XYZ schema may be extended, there are already numerous schemas being used. The XAuth approach is to support existing and new schemas, rather than pick one and/or create another one, and allows a Grant Request to contain claims from multiple schemas at the same time.

Again, as I have said many times, this part of the request (as is the rest of the request) is extensible. The goal of the “claims” object in XYZ was to propose a simple, common core. Is this the best set? Probably not, but that’s why nothing is final yet, right? 

If we wanted to allow for OIDC style claims objects, we have space to do exactly that, either as a sub-component of the existing claims object or as a new top-level object in the request. This flexibility is important, as there are other schemas and other query languages that people might want to support, including things like JWM:

https://tools.ietf.org/id/draft-looker-jwm-01.html <https://tools.ietf.org/id/draft-looker-jwm-01.html>

And at Mike Jones’s request, I’ve added notes in the current draft of XYZ to the places that will be extensible via registry or some other mechanism — but the goal was to have everything in there be extensible by reasonable mechanisms in ways that will allow innovation to flourish without breaking core and common functionality. 

I do not understand why you insist on painting XYZ as a static, inflexible, and unbending model when it is exactly the opposite. You don’t have to externalize every piece of flexibility in order to have it, and I really hope that these myths don’t keep getting repeated in the group.

> 
> 7) No Authorization Type
> 
> Similar to (6), XYZ has a single schema for how to request access to a resource. While that schema is extensible, it requires adaption from any system with an existing schema. XAuth has a type for each authorization request (oauth2, rar), allowing existing schemas and new schemas to be supported.

This is a ridiculous claim because the RAR format is a back port of the XYZ format to an OAuth 2 architecture. If you consider that RAR is extensible, then XYZ is extensible by your same definitions. In addition, if there are other resource query languages out there beyond these, and we can support them just like we would support additional claims query languages. 

Furthermore, as I’ve said before, XAuth doesn’t allow a clean way to define the use of both OAuth 2 scopes and rich requests. XYZ does this by allowing scope-style strings and full JSON objects to be specified at the same level in the same data structure, so there’s no confusion over how they’re grouped or applied. XAuth makes me choose ahead of time to use one or the other, effectively at the API level. So I can no longer easily call for, say, “login information” (a general scope) along with “transaction history for a specific bank account” (a rich data object) in the same request. Even RAR handles this better than XAuth by simply letting the “scope” parameter also be passed along side the authorization_details object, but there are significant complexity issues with this as there isn’t a clear way to combine these concepts in the OAuth 2 world. I think we can do so much better here, and XYZ proposes one such consistent way to do that by defining the scope-equivalent to be a pass-by-reference version of the rich object that is passed-by-value. If clients have a shortcut (a scope), they can use that; if they need the expressiveness of the resources structure, they can do that. 

> 
> Summary
> 
> While concerns (3-7) can be addressed in XYZ, (1-2) look fundamental to the XYZ architecture.
> 
> [1] https://tools.ietf.org/html/draft-richer-transactional-authz-08#section-7 <https://tools.ietf.org/html/draft-richer-transactional-authz-08#section-7>
> 
> [2] https://w3c.github.io/vc-data-model/ <https://w3c.github.io/vc-data-model/>
I’m not sure what you intended to bring up about VC’s in your email, because I didn’t see a back-reference to this, but I’m glad you did mention it. This is an example of a query, assertion, and proofing data model for users that uses a structure and language that is outside of the OIDC world, but existing parallel to it. I believe our protocol needs to be flexible enough to allow this kind of thing on input (the client presenting information about who the user is, as well as requesting specific information about the user) and output (the AS claiming information about the user), in addition to the client being given something that it can then in turn use with another service down the line to present user information. The world is moving away from an IdP-driven identity model, and we need to keep moving with it and enable it here.


Thanks,
 — Justin

> 
> ᐧ
> -- 
> Txauth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/txauth