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

[Justin Richer <[e-mail]>]

> On Jun 8, 2020, at 2:58 PM, Dick Hardt <[e-mail]> wrote:
> 
> 
> 
> On Mon, Jun 8, 2020 at 5:29 AM Justin Richer <[e-mail] <mailto:[e-mail]>> wrote:
> <snip>
>>  
>> 
>>> 
>>> 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.
> 
> An ID is submitted under the IETF IPR regime. While you have written much about XYZ, what is before the group are the IDs.
>  
> 
> 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.
> 
> The documents are text and obviously can be edited to be anything. What we are debating are the proposed approaches. 

Then please stop presenting things in XYZ as if it cannot be changed. Thanks.

>  
> 
> 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.
> 
> The front channel is problematic as the Client is not communicating directly to an AS. I don't see how those issues would apply to a Client doing a GET of 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. 
> 
> A GS implementation can decide to only return an authorization from doing a GET on the AZ URL. Returning only an AZ URL is an option in XAuth. Similarly, we could do the same for a Grant URI. 

And that’s a lot of complex code paths for both the GS and client to deal with. With more ways that it might happen, the client has to be prepared for any of them — and get them all right. 

>  
> 
> 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.
> 
> In XAuth, the Grant URI is the GS URI + TBD + handle
> 
> Given we have asymmetric crypto as a requirement, it is unclear what having two pieces of random signal provide.

Asymmetric crypto is an implementation requirement in both the input drafts but it isn’t a requirement in the charter, and there are likely symmetric use cases and key proofing mechanisms that are going to be desirable for a lot of people.

>  
> 
>>  
>> 
>> 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?
> 
> Short URLs generally use a short host name as well as a short path. 
> 
> Most REST interfaces have the pattern I am proposing. A mental model many developers are familiar with. 

This is assuming a lot on the part of the GS implementation, still, and all of my arguments stand. 

>  
> 
>> 
>> 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?
> 
> An attacker being able to trick a Client to authenticate somewhere it is not intending to go seems like something worth preventing. 
> 
> The GS initiated login is easily supported with the URI representing the Grant.
> 
> See https://tools.ietf.org/html/draft-hardt-gnap-advanced-00#section-5 <https://tools.ietf.org/html/draft-hardt-gnap-advanced-00#section-5>
> 
> 
>  
> 
>>  
>> 
>>> 
>>> 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.
> 
> At the start of the protocol, the server is either looking up the key from a handle / Client ID if it is a pre-registered client. Correct?
> 
> Once the server has done that, it can associate the key with the Grant.

That is not entirely correct. A pre-registered client can still pass its key by value, and a dynamic client can still use a (dynamically-acquired) handle. In all cases, the client is identifying itself by its key. The difference is how the server looks up that key — it’s either from the handle, or it’s from the key value itself. 

There’s a parallelism between dynamic, ephemeral, and static clients in XYZ that I think is very valuable and it’s enabled by this feature. The ability to use a “client_id” as a key handle still makes sense semantically, because it’s a value that the AS can use to look up the key material. But fundamentally in XYZ, the client is known by its key not by a separate identifier. You can have internal identifiers for developer-facing things, of course, but the protocol does not need them.

>  
> 
> 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 
> 
> You did not complete this sentence.
> 
> I'm confused by this 
> 
> I would think that the server would require a pre-registered client to have a private key tied to the public key the server has for the Client. No?


My apologies for missing that sentence. All it was going to say was “we have a chance to define more clearly what a client is and each part of the request separate from that”.

>  
> 
> 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.
> 
> I would take a different approach. Let's clarify what a Client is. We are using the term. Having it be fuzzy and avoiding what a Client is seems the wrong approach. 
>  
> 
>>  
>> 
>> 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.
> 
> I don't see how that attack is possible. The Grant URI has a random element in it that the GS uses to retrieve information about the Grant, including the Client that created it.
>  
> 
>>  
>> 
>>> 
>>> 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.
> 
> Having both a handle and a URI seems more complicated than just a URI.

You’re conflating things: This is a separate discussion. Here we are talking about how it’s more difficult for an AS to determine the presence or absence of the “callback” field vs. detecting the presence or absence of the “direct” and/or “indirect” fields.

> 
> If you think that having a URI in addition to a handle makes sense, how about you put that into your draft and see how it works?

Because I haven’t had an opportunity to implement it in this way yet, and I’m not yet convinced the extra complexity is worth it. I said it MIGHT make sense and it’s worth talking about, which has been my public stance since before you proposed XAuth. That’s still the case, and I’ve gone to length here on the list (which is under the IETF IPR rules) to discuss it. Are you suggesting that I need to prove this to you in a particular way, instead? As this is an individual draft, it should represent what I, personally, think is the best approach. Part of my criteria for adding things to my individual draft is making sure it at least makes some amount of sense with real code. Your draft should likewise follow your own convictions.

This is of course a very different thing from being a working group editor, where the editor’s role is to capture, express, and refine what the desires of the WG are. I know the difference between these roles well, and they serve different purposes in the process.

> 
> For example: 
> 
> How is a transaction updated? 
> How are separate access tokens refreshed? 
> Refreshing an access token in XYZ returns a full transaction response per Section 9.3 which refers to Section 8.
> 
> 
> By using URIs and methods, XAuth has an easy to understand API for CRUD operations on Grants and Authorizations.
> 
>     +--------------+-----------+--------+-----------------------------+
>     | request      | http verb | uri    | response                    |
>     +==============+===========+========+=============================+
>     | Create Grant | POST      | GS URI | interaction, wait, or grant |
>     +--------------+-----------+--------+-----------------------------+
>     | List Grants  | GET       | GS URI | grant list                  |
>     +--------------+-----------+--------+-----------------------------+
>     | Verify Grant | PATCH     | Grant  | grant                       |
>     |              |           | URI    |                             |
>     +--------------+-----------+--------+-----------------------------+
>     | Read Grant   | GET       | Grant  | wait, or grant              |
>     |              |           | URI    |                             |
>     +--------------+-----------+--------+-----------------------------+
>     | Update Grant | PUT       | Grant  | interaction, wait, or grant |
>     |              |           | URI    |                             |
>     +--------------+-----------+--------+-----------------------------+
>     | Delete Grant | DELETE    | Grant  | success                     |
>     |              |           | URI    |                             |
>     +--------------+-----------+--------+-----------------------------+
>     | Read AuthZ   | GET       | AZ URI | authorization               |
>     +--------------+-----------+--------+-----------------------------+
>     | Update AuthZ | PUT       | AZ URI | authorization               |
>     +--------------+-----------+--------+-----------------------------+
>     | Delete AuthZ | DELETE    | AZ URI | success                     |
>     +--------------+-----------+--------+-----------------------------+
>     | GS Options   | OPTIONS   | GS URI | metadata                    |
>     +--------------+-----------+--------+-----------------------------+
>     | Grant        | OPTIONS   | Grant  | metadata                    |
>     | Options      |           | URI    |                             |
>     +--------------+-----------+--------+-----------------------------+
>     | AuthZ        | OPTIONS   | AZ URI | metadata                    |
>     | Options      |           |        |                             |
>     +--------------+-----------+--------+-----------------------------+
>  

While this looks good on paper, there are very pragmatic reasons that many APIs have moved away from purely RESTful patterns over the last decade, including limitations on what can be sent with GET and DELETE requests, for example. I don’t think it’s as clean a win as you’re presenting it, but I think it’s worth checking out.

> 
>>  
>> 
>> 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 is not how XAuth is written currently. The Client can list all of the modes it wants to use. The Server will return all the modes that fit in its policy for the Grant Request. Why would the Client need to make different requests?
> 
> per
> 
> https://tools.ietf.org/html/draft-hardt-xauth-protocol-10#section-3.4.2 <https://tools.ietf.org/html/draft-hardt-xauth-protocol-10#section-3.4.2>  
> 
> The interaction object contains one or more interaction mode objects per Section 5
> 
> Three modes are defined here:
> 
> https://tools.ietf.org/html/draft-hardt-xauth-protocol-10#section-5 <https://tools.ietf.org/html/draft-hardt-xauth-protocol-10#section-5>
> 
> More modes may defined in extensions, or in this document.

Yes, this is an improvement, and I’m glad you’re moving your thinking in this direction. However, it’s still not as clear how things combine to solve different use cases, and it conflates the means of getting the user TO the interaction page with the way of getting them BACK from it. It’s these flexible combinations that I think are important, and I don’t think XAuth gets this quite right yet. 

> 
> 
>>  
>> 
>> 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.
> 
> Where? 
>  
> 
>>  
>> 
>> 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”. 
> 
> Your comment was that I was "insisting" on a specific feature (the Grant URI MUST start with the GS URI). I think the requirement has many advantages, but I don't have a strong conviction about it, and am open to debating it. 

I open to debating everything in XYZ, including things I have strong convictions about. This is why I’m bringing it to a standards body and trying to start a standards process instead of just launching it as a commercial solution.

>  
> 
> These are input proposals, everything is up for debate. That’s why we’re debating.
> 
> Yes, we are debating the pros and cons of each proposal. 
>  
> 
>>  
>> 
>>> 
>>> 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. 
> 
> It is an OR in that if the client is using the type "oauth_scope", they cannot have an "authorization_details" attribute, they can only have "scope"
> 
> If the client is using the type "oauth_rich", the client MUST include "authorization_details", and MAY include "scope"
>  
> I have updated the the doc to better capture that:
> 
> https://tools.ietf.org/html/draft-hardt-xauth-protocol-10#section-3.4.4 <https://tools.ietf.org/html/draft-hardt-xauth-protocol-10#section-3.4.4>
> 
> and example 2 now is of type "oauth_rich"
> 
> https://tools.ietf.org/html/draft-hardt-xauth-protocol-10#section-3.2 <https://tools.ietf.org/html/draft-hardt-xauth-protocol-10#section-3.2>
> 

It was not clear to me that both could be sent with that mode, so thank you for updating that. But the client still has to choose one or the other up front. Why not have a mechanism that it can send both at all times? Why have a “mode” type switch at all? XYZ allows clients to make these combined requests with a single consistent syntax.

And by completely externalizing this to OAuth 2, I would argue that we lose an opportunity to more clearly define how resources are described and used, and we inherit the same combination issues that are facing RAR today. We can do better because we get to define the context.

> 
>> 
>>  
>> 
>>> 
>>> 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.
> 
> I don't follow how this would work. Perhaps you could provide an example in JSON?

One method is defining a new value inside the XYZ “claims” request object that maps to a specific sub-schema:

claims: {
   “subject”: true,
   “email”: true,
   “oidc”: {
       "userinfo":
        {
         "given_name": {"essential": true},
         "nickname": null,
         "email": {"essential": true},
         "email_verified": {"essential": true},
         "picture": null,
         "http://example.info/claims/groups": null
        },
       "id_token":
        {
         "auth_time": {"essential": true},
         "acr": {"values": ["urn:mace:incommon:iap:silver"] }
        }
      }
}

That should look pretty familiar. Alternatively, this could be done with a separate top-level request object field:


claims: {
   “subject”: true,
   “email”: true
},
“oidc_claims_request”: {
       "userinfo":
        {
         "given_name": {"essential": true},
         "nickname": null,
         "email": {"essential": true},
         "email_verified": {"essential": true},
         "picture": null,
         "http://example.info/claims/groups": null
        },
       "id_token":
        {
         "auth_time": {"essential": true},
         "acr": {"values": ["urn:mace:incommon:iap:silver"] }
        }
}

In both cases the AS is going to need to knit them together into a sensible request policy, especially since the OIDC claims query language has overlapping implications to one particular resource, the UserInfo endpoint. My contention wasn’t with your proposed solution, my contention was you claiming that XYZ has a fixed schema and is therefore limited in extensibility.

 — Justin