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

[Justin Richer <[e-mail]>]

Comments inline, again.

> On Jun 7, 2020, at 6:32 PM, Dick Hardt <[e-mail]> wrote:
> 
> comments inline ...
> 
> On Sun, Jun 7, 2020 at 1:41 PM Justin Richer <[e-mail] <mailto:[e-mail]>> wrote:
> Hi Dick, responses inline.
> 
>> On Jun 7, 2020, at 3:27 PM, Dick Hardt <[e-mail] <mailto:[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.
> 
> My intent was to remove confusion, not create confusion. Per my comments below, I refer to my draft as XAuth, and your draft as XYZ. The filename still has -xauth- and not -gnap-. 
> 
> I have pushed a -09 that has additional text in the introduction to clarify it should be referred to as XAuth. 
> 
> https://www.ietf.org/id/draft-hardt-xauth-protocol-09.html
>  <https://www.ietf.org/id/draft-hardt-xauth-protocol-09.html>
> 
> I named the other files with draft-hardt-gnap to make it clear the document is related to the proposed GNAP WG. 
> 

Thank you for adding the disclaimer, but by naming the draft set "The Grant Negotiation and Authorization Protocol” it still gives a different impression, intended or otherwise.

>  
> 
>> 
>> 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. 
> 
> I'm comparing the two drafts we have today, not what the drafts could be. You have consistently stated that there is just one end point in the XYZ model, and that handles represent the transaction rather than URIs -- as you state again below in your response to point 4.
> 
> I find it is much easier for people to understand a proposal to write it up. I could not see how to easily modify XYZ to support the models I envisioned, which is why I wrote XAuth.

You and I both agree that things are easier to understand when written up, and that’s why I have produced significant write-ups of both the current state and the potential future state of XYZ during its lifetime, and continue to do so. The ID is only one of these artifacts, and I find it problematic that you dismiss any and all additional material.

As both drafts are inputs to a proposed working group, and not final systems, they should be compared not only for what’s there but for what direction they could go. To do otherwise is to ignore the changes that a working group can and will make on its inputs in pursuit of a general solution. It is not my intent that XYZ, as currently proposed, be simple accepted as-is. In fact, I hope it’s not, as the entire point of me trying to start this working group was to bring a community together to build something new, useful, and powerful. My contention with your statement, if you read what I said, is not that XYZ doesn’t do something today, but that in your view it cannot do something. The entire purpose of this exercise is to compare possibility.

So then: let’s unpack that possibility. Checking my notes on this topic, I see a pretty straightforward way to do this kind of thing. Note that herein I’ll be using the native terminology of XYZ, including “transaction” and “handle”, for consistency and to avoid confusion. Currently, the spec has the Tx endpoint return a reference to the ongoing transaction, known as a handle. This credential has a value and a presentation method, and it’s returned at the top level of the response:

    "handle": {
	"value": "80UPRY5NM33OMUKMKSKU",
	"type": "bearer"
    }

It would be very simple for this credential to also include a URI for it to be used at:

    "handle": {
        "value": "80UPRY5NM33OMUKMKSKU",
        "type": “bearer”,
        “uri": “https://server.example/tx/foo-123 <https://server.example/tx/foo-123>"
    }

Or if we wanted to, we could even break it out into a multi part structure:

    “transaction": {
        "handle": {
             "value": "80UPRY5NM33OMUKMKSKU",
             "type": “bearer”
        }
        “uri": “https://server.example/tx/foo-123 <https://server.example/tx/foo-123>"
    }


This pattern of supplying both a credential and a URL for the client to use in a tightly-coupled fashion is one that has been used before and we know works. It’s the basis of RFC7592 and ODIC’s Dynamic Registration, for example. What’s important here is that the client is told exactly where to go. This URL could be the transaction endpoint itself, it could be a RESTful style API, it could be a graph API node, it could be a management service on another cluster. The protocol quite frankly shouldn’t care about this, and shouldn’t dictate to the AS how to deploy its parts. Instead, the protocol should concern itself only with the interconnection of well-defined components. By providing both a handle and a target URL we allow the AS to decide whether it wants to dispatch based on URL, handle, or something else that it gets to decide. 

Note that this credential, the handle, still needs to be presented in the context of the client’s key proofing that was used to start things off, so it isn’t fully a bearer access token. This makes it significantly harder for an attacker to do a man-in-the-middle attack with a fake AS, since they can’t get a client to use the attacker’s keys or vice versa. But this also means that I don’t think we can use an access token here, because the client needs to be able to present its keys in a consistent manner and that might include its own use of an Authorization header, depending on the key proofing method. We shouldn’t step on that space. Additionally, the client is going to be providing additional information in the follow-up requests anyway, such as a reference from the front-channel callback, the signed response to a cryptographic challenge, an identifier for a push endpoint, etc. Since we’re in the back channel we’re not limited to just stuffing things into URLs, and these can all be presented as part of the protocol request. 

Furthermore, this handle should be independent from its use in any follow-up requests because it should also be able to be used to start a new transaction in a new context. This kind of step-up authorization is something that people have long desired in OAuth 2 and have hacked together in a  few different ways in the wild, but we can do it here. Now of course we could hack around this by providing the grant URL in a new transaction request, but that unnecessarily conflates the identifier (the URL) with the access method. 

Additionally, the handle in my implementations of XYZ have all been random values, but that doesn’t need to be the case at all. For a distributed system, the AS might want to pack information about the transaction into an encrypted bundle and pass it to the handle in a more stateless/serverless fashion. If we force the AS to put that information into the URL itself, then we’re going to run into many of the same problems that we do in the front channel of OAuth 2 today and end up with some of the same workarounds and patches. This is the back channel, and we should make use of the fact that the client can send more than just a plain GET to a URL.

As an aside, this approach of bundling a target with the handle is something that’s been brought up on this list already, and I know there’s appetite for addressing it with regard to access tokens. Namely, there are a few different groups that want to be able to indicate to the client where it should use an access token. This has implications for multiple access tokens and resource set descriptions, among other key aspects of the protocol. This is a difficult and complex problem that fans out quickly, but thanks to previous indication of interest from the members of this list, it is within our proposed charter and I look forward to discussing this issue as the group gets going.

Now with that said, there are still some good reasons to define it as a single endpoint. Namely, the kinds of responses you get from starting a transaction are the same as those returned from continuing a transaction in progress. For example, with the functionality split, you now have two places in your architecture that could return an access token, depending on if the policies allow for the token to be issued without user interaction (the client credentials equivalent) or not (the auth code equivalent). Furthermore, the inputs to the request on both sides are largely the same — much of the information that you might present in a follow-up could be presented in an initial request. As such, this is not a purely restful process unless you jump through some additional hoops to force it to be, like making the client do a “GET” on the results of the request in order to get its access token instead of returning it directly. However, not even XAuth requires this, for what I hope are obvious reasons. This is the kind of thing that needs to be balanced against the benefits of splitting the endpoints, and something the group needs to debate and come to terms with. 

Using a different URI, optionally, isn’t the problem, and that could easily be added to the. Removal of the separate handle is the problem I have with the XAuth approach.

>  
> 
> 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?
> 
> Requiring the Grant URI to start with the GS URI is open to discussion. It is not clear to me why a deployment would need to have a redirector. Large scale deployments I have worked on have a router / proxy that routes requests to internal services. Having all the URIs start with the GS URI enables all GNAP operations to be routed in the same place.

You still haven’t addressed why you think that this is a reasonable requirement or assumption here but not when dealing with long/short URLs for QR codes. What is the difference?

> 
> An advantage of starting with the GS URI is that any software on the Client side knows which GS it belongs to. A Grant URI passed to a Client in a GS initiated login allows the Client to know if it trusts the GS before operating on the Grant URI. 

Is the client then required to make this check for security purposes? Or can we protect against this kind of confusion by building the system to be resilient to it in a different way? I have opted for the latter in XYZ’s design.

> 
> If the Grant URI can be any URI, then a Client could be tricked into operating on a Grant URI it should not be operating on. 

This is not true if the client also needs to present its keys with the request, is it? Am I missing an attack here?

>  
> 
>> 
>> 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?
> 
> A GS implementation is free to use the same identifiers and storage system for Client IDs and Client Handles. 
>  
> 
> 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. 
> 
> In XYZ a client handle refers to both registered clients, and dynamic clients. That seems to continue to be haphazard. 
> 
> Dynamic Registration needed to use Client ID as the rest of OAuth only understood that identifier for a client.
> 
> XAuth allows each type of client to have their own identifier.

The key handle represents a set of keying material that is passed by reference instead of by value. That keying material is something that the server has seen before. It can be associated with a piece of software that has either been statically registered, or it could be a key that showed up dynamically and the server is providing a shortcut to reference it.

In both cases, static and dynamic clients can present their keys by value and get expected behavior. Instead of a fuzzy definition where “client” could mean an instance, a class, or a concept, we 

This is why I want to get away from a “client identifier” because there is not a concrete and consistent definition of what a “client” means across the wide variety of use cases we already know we have.

>  
> 
> 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?
> 
> Nope. 

>  
> 
>> 
>> 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.
> 
> The XAuth proposal is to use a URI to represent the authorization. 

I know what XAuth does, and it does not help that kind of attack. Automatic credential rotation on use is a well established mitigation mechanism that is impossible if the only item you have is a URI that is given exactly once within the protocol. This is in addition to the discussion above regarding issuing the credential alongside the URI.

>  
> 
>> 
>> 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.
> 
> My statement is that it was unclear why it was needed. Perhaps you can add a Rationale section to XYZ?
>  
> 
> 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.
> 
> This is why I state that it seems hard to change (1) above. 
>  
> 
>> 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? 
> 
> I did not say it could not be done, I'm saying it is more difficult in XYZ than in XAuth

Can you explain to me how it’s more difficult in XYZ? I have explained how it can be done and I am failing to see why you think it’s harder.

>  
> 
> 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. 
> 
> Have you read the revised draft? As I noted above, I have added negotiation. The Client can state all the modes it wants, the GS can respond with the modes it will support, and the Client can offer the User any modes returned from the GS.

Yes, did you read what I wrote? I think we’re talking past each other.

>  
> 
> 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.
> 
> Yes, we need flexibility. We also need the GS to be able to easily enforce what can happen.
>  
> 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? 
> 
> Yes, XYZ is extensible. It is not namespaced as XAuth is.

It is, though, as I said above.

>  
> 
> 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.
> 
> All I am doing is comparing what is written. I'm not trying to paint XYZ anything. 

Except that you are doing that — when I raise a concern on something in XAuth you often respond with “oh but that’s up for debate!” while dismissing the same counter-argument with “I’m comparing what’s written”. 

These are input proposals, everything is up for debate. That’s why we’re debating.

>  
> 
>> 
>> 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. 
> 
> Once again it does not seem that you have read the latest draft. XAuth allows existing OAuth 2 scopes, OR OAuth 2 scopes with RAR, OR a new type authorization type that works differently.

I don’t think you read what I wrote here. I did read the new XAuth draft before replying, and my complaint is that it is still an OR. 

> 
>  
> 
>> 
>> 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 meant to include [2] as another claim schema in point (6) above. In XAuth, you will see that "vc" is another object in the "claims" Object.
>  
> 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.
> 
> We agree on the flexibility. The XAuth proposal is to namespace the schemas so that adopting existing schemas, or using a new one is straightforward.

The XYZ proposal is to have a core namespace for common elements and additionally to allow other namespaces to be added in as needed.

 — Justin

> 
> 
> 
> Thanks,
>  — Justin
> 
>> 
>> ᐧ
>> -- 
>> Txauth mailing list
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/txauth <https://www.ietf.org/mailman/listinfo/txauth>
> 
> ᐧ