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

From: Dick Hardt <[email-masked]>
Date: Sun, 7 Jun 2020 12:27:39 -0700

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-gnap-advanced-00.html
https://www.ietf.org/id/draft-hardt-gnap-jose-00.html

IMHO, the main doc is much more readable. :)

*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.

*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.

*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.

*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.

*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.

*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.

*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.

*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

[2] https://w3c.github.io/vc-data-model/

ᐧ

---

From: Justin Richer <[email-masked]>
Date: Sun, 7 Jun 2020 16:41:00 -0400

Hi Dick, responses inline.

> On Jun 7, 2020, at 3:27 PM, Dick Hardt <[email-masked]> wrote:
> 
> Hello
> 
> 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>
> 

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

---

From: Dick Hardt <[email-masked]>
Date: Sun, 7 Jun 2020 15:32:55 -0700

comments inline ...

On Sun, Jun 7, 2020 at 1:41 PM Justin Richer <[email-masked]> wrote:

> 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

I named the other files with draft-hardt-gnap to make it clear the document
is related to the proposed GNAP WG.

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

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

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.

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.

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

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

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

>
>
> *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.

> 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

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

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

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

> 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’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.

---

From: Dick Hardt <[email-masked]>
Date: Sun, 7 Jun 2020 18:08:54 -0700

I'd be interested to see how you address any of the concerns you think have
merit with an update to XYZ. I think it would also be useful for the group
to adopt the terms Grant and Negotiation rather than Transaction in your
doc to reflect the terms the WG has settled on.

/Dick
ᐧ

On Sun, Jun 7, 2020 at 3:32 PM Dick Hardt <[email-masked]> wrote:

> I have pushed a -09 that has additional text in the introduction to
> clarify it should be referred to as XAuth.
>
> I named the other files with draft-hardt-gnap to make it clear the
> document is related to the proposed GNAP WG.
>
>
>
>>
>>
>> *XYZ vs XAuth*
>>
>> 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.
>>
> 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
> My statement is that it was unclear why it was needed. Perhaps you can
> add a Rationale section to XYZ?
>
>
>>
>> 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.
>>
>> 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?
>>
>
> 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.
>
>
>>
>> Thanks,
>>  — Justin
>>
>>
>> ᐧ
>> --
>> Txauth mailing list
>> [email-masked]

---

From: Justin Richer <[email-masked]>
Date: Mon, 8 Jun 2020 08:29:23 -0400

Comments inline, again.

> On Jun 7, 2020, at 6:32 PM, Dick Hardt <[email-masked]> wrote:
> 
> comments inline ...
> 
> On Sun, Jun 7, 2020 at 1:41 PM Justin Richer <[email-masked] <mailto:[email-masked]>> wrote:
>> On Jun 7, 2020, at 3:27 PM, Dick Hardt <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Hello
>> 
> 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>
> 
> 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.

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

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

> A GS implementation is free to use the same identifiers and storage system for Client IDs and Client Handles. 
>  
> 
> 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.
> 

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.

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

> My statement is that it was unclear why it was needed. Perhaps you can add a Rationale section to 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.

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

It is, though, as I said above.

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

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

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

---

From: Dick Hardt <[email-masked]>
Date: Mon, 8 Jun 2020 11:58:03 -0700

On Mon, Jun 8, 2020 at 5:29 AM Justin Richer <[email-masked]> wrote:
<snip>

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

>
> 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": {
>         “uri": “https://server.example/tx/foo-123"
>     }
>
>         “uri": “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.

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

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

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

> 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

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

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

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

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

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

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?

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      |           |        |                             |
    +--------------+-----------+--------+-----------------------------+

>> 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

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

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

More modes may defined in extensions, or in this document.

> It is, though, as I said above.

Where?

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

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

Yes, we are debating the pros and cons of each proposal.

> 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

and example 2 now is of type "oauth_rich"

https://tools.ietf.org/html/draft-hardt-xauth-protocol-10#section-3.2

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

/Dick
ᐧ

---

From: Justin Richer <[email-masked]>
Date: Mon, 8 Jun 2020 16:02:21 -0400

> On Jun 8, 2020, at 2:58 PM, Dick Hardt <[email-masked]> wrote:
> 
> 
> 
> On Mon, Jun 8, 2020 at 5:29 AM Justin Richer <[email-masked] <mailto:[email-masked]>> wrote:
> <snip>
>>  
>> 
>>> 
>>> XYZ vs XAuth
>>> 
> An ID is submitted under the IETF IPR regime. While you have written much about XYZ, what is before the group are the IDs.
>  
> 
> 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.

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

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

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

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.

> 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”.

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

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.

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

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.

> 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
> 
> https://tools.ietf.org/html/draft-hardt-xauth-protocol-10#section-5 <https://tools.ietf.org/html/draft-hardt-xauth-protocol-10#section-5>
> 

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. 

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

> 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"
>  
> 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>
> 
> 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.

> 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

---

From: Dick Hardt <[email-masked]>
Date: Mon, 8 Jun 2020 14:33:37 -0700

On Mon, Jun 8, 2020 at 1:02 PM Justin Richer <[email-masked]> wrote:

<snip>

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

I don't see it being complex. The data either moves by reference or by
value. Both parties will have to enable support by reference. Passing by
value is an optimization so that the client does not have to make an
additional call.

 <snip>

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

I don't understand this.

How is the Client authenticating that it is a specific pre-registered
client?

<snip>

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

My bad. I got confused which topic we were on.

In XAuth, if the server wants to protect itself from a session fixation
attack in a given request, and it wants to support both "redirect" and
"user_code" modes,
the server will return only those two modes and not "indirect". The

In XAuth, if the server wants to protect itself from a session fixation
attack in a given request, and it wants to support both "redirect" and
"user_code" modes,
the server MUST return callback, redirect, and user_code. The client does
not know that the "indirect" mode is not supported, and may try that.

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

No. I'm saying that stating it could be done is different than writing it
up. I would expect your draft to be the culmination of your convictions.

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

Agreed.

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

Agreed that RESTful does not work for everything. It does look like it maps
well here.

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

I think how the user gets to and from the server is CRITICAL to the server
if it wants to protect itself from a session fixation attack.
See above where the client does not know what it can actually do that the
server will allow.

<snip>

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

This group can define a new syntax if it wants, and it will be unencumbered
by the OAuth 2 and RAR legacy if deployments that want to use the OAuth 2
and RAR syntax can use them directly. Ie, there can be a type "gnap" or
some such.

 <snip>

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

One of the objectives of this work is to have extension points. My point
was that XAuth had a clear extension point for adding schemas. How to
extend XYZ was not clear in your proposal.

I think the XAuth proposal is better than the two examples you proposed. In
your first example, the schema is a second class schema, and in your second
example, claims are spread across to top level options. Both of these
pollute other schemas.

/Dick

ᐧ

---

From: Justin Richer <[email-masked]>
Date: Tue, 9 Jun 2020 12:10:40 -0400

> On Jun 8, 2020, at 5:33 PM, Dick Hardt <[email-masked]> wrote:
> 
> 
> 
> On Mon, Jun 8, 2020 at 1:02 PM Justin Richer <[email-masked] <mailto:[email-masked]>> wrote:
> 
> <snip>
> I don't see it being complex. The data either moves by reference or by value. Both parties will have to enable support by reference. Passing by value is an optimization so that the client does not have to make an additional call.

“Both parties will have to enable” is where the complexity comes into play. It’s putting a requirement on the client to anticipate several different ways to get the same information.

> How is the Client authenticating that it is a specific pre-registered client?

The client is identified by its key. There is no external client identifier. I think you’re confused because you’re still thinking in terms of OAuth 2’s client ID based model and I am trying to move us past that. It took me time to realize that we really can let it go, so hopefully this is helpful in explaining why.

When a credential is cryptographically random enough to be unique, it can be used as its own identifier, particularly when you don’t need to identify the entity outside of the context that it can present and prove its credential. To stretch a metaphor, passwords don’t always need usernames. This is, after all, the driving design pattern behind OAuth access tokens. An access token doesn’t have a “username” portion to it, even though it would have been trivial to require the client to send its client ID alongside the access token. Why does that work? Because our model of what the RS does with the access token is built around it answering the questions: is this token valid and does it allow what’s being requested? If the RS needs to know which client was issued the token, it can discover that information without being told separately from the token -- perhaps it’s in the token itself or it’s in an introspection response. And in a lot of cases, the RS doesn’t care about the client software, it just wants to know if the token’s any good. Even in constrained tokens such as MTLS, PoP, and DPoP, we aren’t really authenticating the client at the RS so much as making sure the right key is presented alongside the right token. 

XYZ takes that same approach with the client talking to the AS and uses the credential (key) to identify the client as well as authenticate and protect the request. We can’t just say “OAuth 2 had client IDs and people are used to it so it must be good and we have to keep using it”. We need to ask WHY OAuth 2 needs client IDs and if that still makes sense. I argue that it doesn’t make sense anymore and we need to step back and look at a better model. OAuth 2 needs a client ID because it gets passed in the front channel and the client’s credentials can’t be used there. The access token doesn’t need an equivalent because it’s passed in the back channel and can be used directly. Now that the client no longer needs to be identified, but not authenticated, through untrusted third parties (such as the browser), we don’t need to have a separate identifier as part of the protocol. With an intent-based protocol, that starts in the back channel, you don’t need a client identifier anymore. Once the AS finds that key, the AS can then figure out what policies, rights, and restrictions are attached to that key. In many implementations, there’s going to be some kind of “registered client” object in a database somewhere that drives those policies. That’s the classical OAuth model, and it works in many cases. But in other cases, the key is going to just be a value used to protect the request chain (and possibly the token itself), and the policy is going to be built up by other things like a device posture or signature on the calling software or verified user information. It’s not just about client authentication, even though it can be used for it. DPoP, PKCE, and DynReg have shown us the value in dynamic systems, in different ways. 

On top of that, PAR is showing us that a lot of the constraints that we have in OAuth 2 don’t really apply anymore. For instance, Redirect URI restrictions can be relaxed because now you CAN identify and authenticate the software sending it, which isn’t true with a front-channel-first approach. All of the things that are required in OAuth 2 start to become redundant, and it leads to things like requiring that “client_id” still always be passed in the front channel even though the information could be looked up from an internal request_uri reference using PAR and JAR together.

That’s why a key handle isn’t exactly the same as a client ID and I did not call it a client ID in the XYZ protocol. It’s a shortcut to refer to the key material for certain optimized cases, but ultimately it’s pointing to a key. This has an interesting and beneficial side effect — if you HAVE a client ID as part of your internal data model, it can FUNCTION as a key handle because it’s a unique value the AS can use to look up key information. It’s not “authenticating the client”, it’s pointing to a key which in turn identifies and authenticates the software making the call. The fact that it’s a “client ID” is an artifact of the implementation, which in this case has an OAuth 2 legacy to work with. 

If we’re going to move past the constraints of OAuth 2 we need to stop thinking so strictly in its terms and models. There are better ways to approach this now and client IDs are not required by this protocol model.

> In XAuth, if the server wants to protect itself from a session fixation attack in a given request, and it wants to support both "redirect" and "user_code" modes, 
> In XAuth, if the server wants to protect itself from a session fixation attack in a given request, and it wants to support both "redirect" and "user_code" modes, 
> the server MUST return callback, redirect, and user_code. The client does not know that the "indirect" mode is not supported, and may try that.
> 

In XYZ, if the server wants to protect against a session fixation attack, it will reject a request that doesn’t have a “callback” field in it. The AS always gets to choose which things it supports for any given request. If the client wants to support both “redirect” and “user_code’ modes AND has the ability to handle session fixation issues, it sends the “redirect”, “user_code’, and “callback” fields in its interaction request. 

> 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?
> 
> No. I'm saying that stating it could be done is different than writing it up. I would expect your draft to be the culmination of your convictions.

My draft is exactly that, and as you can see I’m open to having more discussions beyond it.

>  
> 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.
> 
> Agreed. 
> 
>  
> 
>> 
>> For example: 
>> 
> Agreed that RESTful does not work for everything. It does look like it maps well here.

I disagree that it maps well. I think this is an over-application of a design pattern and the details will be problematic in implementation.

> I think how the user gets to and from the server is CRITICAL to the server if it wants to protect itself from a session fixation attack.
> See above where the client does not know what it can actually do that the server will allow.

It is critical that the server knows how to protect itself, yes. It’s not critical that the way there and the way back are tightly bound to each other in this way. I think that model is limiting.

> This group can define a new syntax if it wants, and it will be unencumbered by the OAuth 2 and RAR legacy if deployments that want to use the OAuth 2 and RAR syntax can use them directly. Ie, there can be a type "gnap" or some such.
> 
>  <snip>
>          "http://example.info/claims/groups <http://example.info/claims/groups>": null
>         },
>        "id_token":
>         {
>          "http://example.info/claims/groups <http://example.info/claims/groups>": null
>         },
>        "id_token":
>         {
> One of the objectives of this work is to have extension points. My point was that XAuth had a clear extension point for adding schemas. How to extend XYZ was not clear in your proposal.
> 

I am sorry that the extensibility of the protocol was not clear. It is stated in each section that additional items can be added, and I have stated repeatedly that it’s extensible and demonstrated how, here on this list. 

> I think the XAuth proposal is better than the two examples you proposed. In your first example, the schema is a second class schema, and in your second example, claims are spread across to top level options. Both of these pollute other schemas.
> 

Not surprisingly, I disagree about the cleanliness of XAuth’s proposed approach. The proposal here adds external schemas as extensions instead of relying on them internally. 

If anything, I think that the OpenID Foundation would be the ones to define how to make an OIDC claims request using this protocol, not us, since they own and control that query syntax and everything it implies. We can provide a means of extension.

I also think there’s value in defining a set of core interoperable identity fields, which themselves could also be extended. 

All of these mechanisms should be controlled by some combination of registries and collision-resistant namespaces, which is the approach I’ve taken for extensibility throughout XYZ.

 — Justin

---

From: Dick Hardt <[email-masked]>
Date: Tue, 9 Jun 2020 13:11:08 -0700

Comments inline

Last item will be broken out to new thread.

On Tue, Jun 9, 2020 at 9:10 AM Justin Richer <[email-masked]> wrote:

> “Both parties will have to enable” is where the complexity comes into
> play. It’s putting a requirement on the client to anticipate several
> different ways to get the same information.
>

As I understand it, XYZ works the same way. The client may get a handle to
the transaction in an Interaction Response or a Wait Response, or the
client receives a transaction response.

There could be only one way in XAuth (pass by reference), but I expect that
people will prefer an optimization of pass by value when it can be done and
deal with the complexity that they may get the data in two different ways,
just as in XYZ.

>> 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.
>>
>
> I don't understand this.
>
> *The client is identified by its key.*
>

And you think that will be an easy concept for developers to migrate to
from the mental model they have now? And what is the value? I believe your
proposal for other pre-registered clients to migrate was to use the Client
ID as the Key Handle. So the Key Handle may represent any of the
pre-registered clients, but represents each instance of a dynamic client.
Does not seem like it is any different than how a Client ID is used today.

Tom has started a new thread on other aspects of this section.
 <snip>

> In XYZ, if the server wants to protect against a session fixation attack,
> it will reject a request that doesn’t have a “callback” field in it. The AS
> always gets to choose which things it supports for any given request. If
> the client wants to support both “redirect” and “user_code’ modes AND has
> the ability to handle session fixation issues, it sends the “redirect”,
> “user_code’, and “callback” fields in its interaction request.
>

If the client chooses to present the interaction_url as a scannable
barcode, which is an option if it receives one, it will then get an error
when it tries to do a transaction continue request as the AS protects
itself. Unfortunately the user has scanned the barcode and is now at the
AS. I don't see how the client learns it is not able to do what I call an
"indirect" mode interaction. Would you explain how this situation is
prevented in XYZ?

<snip>

>> Would you address these questions?

>> 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.
>>
>
> I disagree that it maps well. I think this is an over-application of a
> design pattern and the details will be problematic in implementation.
>

What aspect does not map well?

What do you think will be problematic?

It seems much simpler to route a request based on URI and verb(XAuth), then
parse and inspect a JSON payload (XYZ)

> It is critical that the server knows how to protect itself, yes. It’s not
> critical that the way there and the way back are tightly bound to each
> other in this way. I think that model is limiting.
>

What other way back are you envisioning there could be besides a URI
redirect?

Rolling between mobile apps is a URI redirect. What else could happen?

I expect there will be new ways of transferring control to a GS, or that
the GS will reach out to the user directly.

> This group can define a new syntax if it wants, and it will be
> unencumbered by the OAuth 2 and RAR legacy if deployments that want to use
> the OAuth 2 and RAR syntax can use them directly. Ie, there can be a type
> "gnap" or some such.
>
>
You did not respond to this response.

The next section I have put into a separate email.

/Dick

ᐧ

---

From: Dick Hardt <[email-masked]>
Date: Tue, 9 Jun 2020 13:14:43 -0700

Forking this topic to a new thread

+Mike as he has expressed concern about creating new identity claims

>> 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":
>>         {
> I am sorry that the extensibility of the protocol was not clear. It is
> stated in each section that additional items can be added, and I have
> stated repeatedly that it’s extensible and demonstrated how, here on this
> list.
>
> I think the XAuth proposal is better than the two examples you proposed.
> In your first example, the schema is a second class schema, and in your
> second example, claims are spread across to top level options. Both of
> these pollute other schemas.
>
>
> Not surprisingly, I disagree about the cleanliness of XAuth’s proposed
> approach. The proposal here adds external schemas as extensions instead of
> relying on them internally.
>
> If anything, I think that the OpenID Foundation would be the ones to
> define how to make an OIDC claims request using this protocol, not us,
> since they own and control that query syntax and everything it implies. We
> can provide a means of extension.
>
> I also think there’s value in defining a set of core interoperable
> identity fields, which themselves could also be extended.
>
> All of these mechanisms should be controlled by some combination of
> registries and collision-resistant namespaces, which is the approach I’ve
> taken for extensibility throughout XYZ.
>

JSON by its nature is extensible. Adding new members to an object is
straight forward. XYZ is not unique here. It sounds like your idea of
extensibility is telling people that they can add new members to JSON. Of
course they can. That is like saying you can add new query parameters to a
front channel OAuth 2 request.

My concern was that XYZ does not have a clear way to add new identity claim
schemas. You have two examples, add a schema as a member of the claims
object, which is mixing claims with schema extensions, or adding a root
member, which is then putting claims into more than one place. It is not
clear where to add a new schema, so we could easily end up with new schemas
in both places. That sounds confusing.

In XAuth, the members of the claims object are the schema. Adding a new
schema is done one, consistent way.

wrt. "defining a set of core interoperable identity fields", the charter
says we should be NOT develop a new schema:

The group is chartered to develop mechanisms for conveying identity
information within the protocol including identifiers (such as email
addresses, phone numbers, usernames, and subject identifiers) and
assertions (such as OpenID Connect ID Tokens, SAML Assertions, and
Verifiable Credentials). The group is not chartered to develop new formats
for identifiers or assertions, nor is the group chartered to develop
schemas for user information, profiles, or other identity attributes,
unless a viable existing format is not available.

wrt. OIDC claims, the charter explicitly calls out developing mechanisms
for conveying ... OIDC ID Tokens.

ᐧ

---

From: Justin Richer <[email-masked]>
Date: Wed, 10 Jun 2020 10:54:25 -0400

> On Jun 9, 2020, at 4:11 PM, Dick Hardt <[email-masked]> wrote:
> 
> Comments inline
> 
> On Tue, Jun 9, 2020 at 9:10 AM Justin Richer <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
>> On Jun 8, 2020, at 5:33 PM, Dick Hardt <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> 
>> 
> As I understand it, XYZ works the same way. The client may get a handle to the transaction in an Interaction Response or a Wait Response, or the client receives a transaction response.
> 
> There could be only one way in XAuth (pass by reference), but I expect that people will prefer an optimization of pass by value when it can be done and deal with the complexity that they may get the data in two different ways, just as in XYZ.

It’s not the same. What you’re missing, I believe, is that this is one of the benefits of having a single endpoint, as XYZ is defined today. The “grant response” comes from exactly one place regardless of where in the transaction it happens. This is why I think this is something the working group as a whole needs to weigh in on, to figure out the pros and cons of different designs. I personally don’t like the complexity, and a definitely don’t like the restrictions imposed by XAuth today, but there are benefits that might outweigh and justify that move. 

> The client is identified by its key.
> 
> And you think that will be an easy concept for developers to migrate to from the mental model they have now? And what is the value? I believe your proposal for other pre-registered clients to migrate was to use the Client ID as the Key Handle. So the Key Handle may represent any of the pre-registered clients, but represents each instance of a dynamic client. Does not seem like it is any different than how a Client ID is used today.
> 

Not only do I think OAuth developers can migrate, I think it’s essential that we do in order to make this useful to non-OAuth developers. Vast swaths of the internet are already building out key-based systems, not using OAuth. In my own experience, I can say for a fact that the awkwardness of needing a client identifier ahead of time is one of the problems. The fact that there’s a place to use a legacy client ID within the protocol is a bonus feature, and important for migration. But it’s even more important that it’s not 

And we should look at history before we declare something impossible. We managed to get web developers away from thinking about accessing an API with a username and password and toward thinking in terms of accessing it with a token. This is a shift of the same kind, and an important one at that.

To me, this is one of the important fundamental shifts of this work away from the limits of OAuth’s models and assumptions, and one of the ones that will make this work applicable far outside of the space that OAuth 2 has already carved. I don’t see a compelling reason to limit ourselves.

If your primary goal is to keep OAuth 2 developers safe and happy, then in all honesty, just keep using OAuth 2. Why wouldn’t you? Use PAR and RAR and DPoP for advanced functionality. It’s a combination that, if a bit patched-together, does work. Move to a new protocol when it does something you can’t do, or it’s otherwise a better fit for what you’re trying to solve. And when you’re in a position to move, there’s a migration path. That doesn’t mean it’s a direct re-use, it means you can migrate — move, change — without tearing absolutely everything out. But you still need to move, and that’s expected. 

In all honesty, I think the gap between OAuth 2 and XYZ is less than the gap between OAuth 1 and OAuth 2, especially if you’re looking at using OAuth 2 with PAR, RAR, etc. I don’t see a compelling reason to artificially limit the new protocol with the constraints of the old, particularly when there’s a migration path between them. XYZ can make use of some of the familiar pieces of OAuth 2 without causing all clients to depend on them. That’s the difference between migration and straight re-use.

> If the client chooses to present the interaction_url as a scannable barcode, which is an option if it receives one, it will then get an error when it tries to do a transaction continue request as the AS protects itself. Unfortunately the user has scanned the barcode and is now at the AS. I don't see how the client learns it is not able to do what I call an "indirect" mode interaction. Would you explain how this situation is prevented in XYZ?

If the client has made a request with “redirect” and “callback” in its request, and then decides to display the interaction URL as a scannable code, then the AS will just redirect to the client’s callback URL when it’s done, whatever that URL was. If the client sends a “callback” URL that it can’t get information from, then that’s a poorly-written client, isn’t it?

If the client can’t get to the information in the callback URL unless it’s on the same device, then the client isn’t going to show the user a scannable code to be read by a secondary device. Why would it?

> Would you address these questions?

Transactions are updated by sending the transaction handle back with additional information. This is no different from the request made after a front channel callback, or what would be made in a challenge-response format. I haven’t written up a way to create a new transaction building on an old one (which I think is an important advanced use case), but it would amount to having a separate field in the initial transaction request to have the transaction handle of the old transaction in it. 

Multiple access tokens cannot be refreshed separately in the current implementation of XYZ. This is a noted gap in the spec, and I’m open to ideas on how it would be handled.

> It seems much simpler to route a request based on URI and verb(XAuth), then parse and inspect a JSON payload (XYZ)

See above.

> What other way back are you envisioning there could be besides a URI redirect?
> 
> I expect there will be new ways of transferring control to a GS, or that the GS will reach out to the user directly.
> 

Push notifications on a mobile platform, COAP-style subscriptions at the HTTP layer, messages coming in over a blockchain fabric through a separate entity…

I think your view of what a client is and how it could communicate and interact is limited, and that’s informing XAuth’s design.

> You did not respond to this response. 

What I’m proposing in XYZ is exactly the new syntax that incorporates both RAR and scope natively by using handles and polymorphic JSON. Other resource request syntaxes could also be defined and added.

---

From: Justin Richer <[email-masked]>
Date: Wed, 10 Jun 2020 11:07:00 -0400

> On Jun 9, 2020, at 4:14 PM, Dick Hardt <[email-masked]> wrote:
> 
> JSON by its nature is extensible. Adding new members to an object is straight forward. XYZ is not unique here. It sounds like your idea of extensibility is telling people that they can add new members to JSON. Of course they can. That is like saying you can add new query parameters to a front channel OAuth 2 request.
> 

Yes, exactly. And that’s exactly how OAuth 2 has been extended. I’m glad you see that now.

> My concern was that XYZ does not have a clear way to add new identity claim schemas. You have two examples, add a schema as a member of the claims object, which is mixing claims with schema extensions, or adding a root member, which is then putting claims into more than one place. It is not clear where to add a new schema, so we could easily end up with new schemas in both places. That sounds confusing.
> 
> In XAuth, the members of the claims object are the schema. Adding a new schema is done one, consistent way.

I provided a couple examples off the cuff of possible ways to extend something, as your base claim was that XYZ could not be extended with new or external query schemas. Of the two, I think that it makes more sense for it to be a separate top-level object. Why? Because the OIDC “claims” request syntax not only dictates claims within the OIDC schema, it also specifies how the information comes back. The XYZ claims request talks about information that comes back in the XYZ claims section of the response. Since the OIDC request allows for targeting specifically to the ID token and UserInfo Endpoint, I think it is much cleaner to be at the top level as its own thing. 

> 
> wrt. "defining a set of core interoperable identity fields", the charter says we should be NOT develop a new schema:
> 
> The group is chartered to develop mechanisms for conveying identity information within the protocol including identifiers (such as email addresses, phone numbers, usernames, and subject identifiers) and assertions (such as OpenID Connect ID Tokens, SAML Assertions, and Verifiable Credentials). The group is not chartered to develop new formats for identifiers or assertions, nor is the group chartered to develop schemas for user information, profiles, or other identity attributes, unless a viable existing format is not available.
> 
> wrt. OIDC claims, the charter explicitly calls out developing mechanisms for conveying ... OIDC ID Tokens.
> 
> ᐧ

Precisely: the charter says we will have a way to convey identifiers and assertions. The XYZ “claims” section lists identifiers that can come back, in plain text, and assertions, that can also come back along side them. It’s not a full query language and isn’t intended to be, and I think that it would actually be dangerous for this to be a full identity schema, but it is itself extensible internally if someone wants to do that. Claiming that a list of identifiers is “developing a new schema” is an argument several bridges too far from reality. I picked a couple examples out of thin air, with the idea that we’d bikeshed them eventually and tie them to a registry. We might want to re-use a set of identifiers here, and for that I actually like Annabelle Backman’s proposal to the SECEVENT group better than most that I’ve seen in the space:

https://tools.ietf.org/html/draft-ietf-secevent-subject-identifiers <https://tools.ietf.org/html/draft-ietf-secevent-subject-identifiers>

As many of you know, I kept all identity stuff out of XYZ initially, but there was enough interest within the group here for me to give it a shot to see what it would look like. In designing the “claims” capability of XYZ, I took several pages from Aaron Parecki’s blog post on the topic from last year, which I still think is a valuable read if you haven’t yet:

https://aaronparecki.com/2019/07/18/17/adding-identity-to-xyz <https://aaronparecki.com/2019/07/18/17/adding-identity-to-xyz>

 — Justin

---

From: Benjamin Kaduk <[email-masked]>
Date: Sat, 13 Jun 2020 21:43:15 -0700

Hi all,

Sorry for jumping in so late (and with so little to say).  But,

> Yes, we are debating the pros and cons of each proposal.

maybe it's just me, but the phrasing of "debating the pros and cons of each
proposal" makes it sound like a fixed evaluation, where we have two inputs,
tally the plusses and minuses in each's column, and at the end decide what
is "better".  I'd much rather describe what we're doing now as exploring
what properties we could have in GNAP and considering which of those
properties we believe will make for a successful protocol.
Hopefully everyone is already doing this, and I will happily apologize for
wasting your time to read this message.  But I do want to avoid this as a
question of "is X or Z a better protocol?", and ensure that we feel that we
have the freedom to do the right thing.

Thanks,

Ben

---

From: Benjamin Kaduk <[email-masked]>
Date: Sat, 13 Jun 2020 21:49:40 -0700

One more point, while I'm catching up on the thread...

> If we’re going to move past the constraints of OAuth 2 we need to stop thinking so strictly in its terms and models. There are better ways to approach this now and client IDs are not required by th…

The idea of a client (or other entity) being identified precisely by its
public key is very reminiscent of HIP (RFC 7401, 7402) that has a similar
stance.  (There, it's billed as a security feature, since you are literally
guaranteed by the protocol to be talking to the entity you think you are.)
One of the difficulties with using HIP, though, is that just the pubkey is
not always a terribly useful identifier, and we tend to want to tie into
other naming systems (e.g., the DNS in the case of HIP) so that we know
that the party we're talking to at the HIP layer is also the
person/organization we want to be talking to.  In the case of HIP, the need
to bind a different type of name to the public key brings back a lot of the
issues that using the key as the identifier was supposed to solve (and in
my opinion is part of why HIP is not more broadly deployed).  I don't see
this need for a binding of external name/identity to an XYZ public key as a
fatal flaw, though -- the way in which introduction are done combined with
the AS's database seems to allow things to work reasonably.  I just want to
make sure that we're thinking about how the public key will be bound to
external identities, and make sure that our story for doing so is sound.

Thanks,

Ben

---

From: Justin Richer <[email-masked]>
Date: Sun, 14 Jun 2020 13:21:18 -0400

Hi, Ben --

> On Jun 14, 2020, at 12:49 AM, Benjamin Kaduk <[email-masked]> wrote:
> 

Yes, I feel the same way. The idea behind XYZ’s ability to introduce the key either by value leads to a model where the key is always what points to the policy of what’s allowed, but the way that the AS discovers which key it’s supposed to be proving against is separate. So it goes handle -> key -> client. In OAuth 2, the model is you identify the client and then figure out what key is attached to that client. The relationship is inverted as handle -> client -> key, and that’s where the problems start to come in for other communities. 

It’s really important for a lot of use cases that we let clients have an identifier separate from the key value itself, which is why XYZ doesn’t define the key handle as the fingerprint of the key, or the key ID (which could be internal to the JWK), or anything else. All it means is “when the AS sees this value, it knows what key or keys it is referring to”. And from there, the AS can figure out the rest of its policy. As you say, this relationship can get set up with an AS database, or the AS could know how to look up the key in a DNS store or distributed ledger — it doesn’t matter, as long as the AS can find the key. This allows us to also have use cases where we don’t have a separate identifier that the AS knows about and we can just send the key as-is, like for ephemeral clients in SPAs, or mobile applications that would need to be registered in OAuth 2 in order to get a client ID. And you don’t even need to look that far from OAuth to find use cases for key-based identity, as that’s at the core of the self-issued OP functions in OIDC, which is in the core spec. There, we have the spec saying to use the redirect URI as the client ID — even though the client already is sending the Redirect URI, OAuth 2 (and the associated assumptions and model of the protocol underneath) need this explicit client ID field for all use cases. 

Something that I think is interesting is that we have an opportunity to potentially define ways to process these kinds of things cross domain, much the way JWTs and introspection allow for cross-domain access tokens to be processed. But I think there’s still a lot of discussion and debate to figure out all the avenues that people care about here. XYZ’s model is probably not exactly right for every case, but I’ve already seen the ability to do key by value or by reference be useful in a lot of places that OAuth 2 doesn’t really work well.

And that’s really where GNAP is going to shine — in the gaps that OAuth 2 has left.

Thanks, 
 — Justin

---

From: Dick Hardt <[email-masked]>
Date: Mon, 15 Jun 2020 16:42:43 -0700

inline ...

On Sat, Jun 13, 2020 at 9:43 PM Benjamin Kaduk <[email-masked]> wrote:

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

Hey Ben, thanks for pointing out my sloppy language, and the possible
misinterpretation.

I think we are debating the pros and cons of each of the proposal's *to
provide a feature* in the protocol, specifically the 4 areas I had concerns
in XYZ, and my proposals to address each of those.

/Dick

ᐧ

---

From: Dick Hardt <[email-masked]>
Date: Mon, 15 Jun 2020 17:19:19 -0700

On Wed, Jun 10, 2020 at 7:54 AM Justin Richer <[email-masked]> wrote:

>>> 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.
>>> 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.
>>>
>>
> There could be only one way in XAuth (pass by reference), but I expect
> that people will prefer an optimization of pass by value when it can be
> done and deal with the complexity that they may get the data in two
> different ways, just as in XYZ.
>
>
> It’s not the same. What you’re missing, I believe, is that this is one of
> the benefits of having a single endpoint, as XYZ is defined today. The
> “grant response” comes from exactly one place regardless of where in the
> transaction it happens. This is why I think this is something the working
> group as a whole needs to weigh in on, to figure out the pros and cons of
> different designs. I personally don’t like the complexity, and a definitely
> don’t like the restrictions imposed by XAuth today, but there are benefits
> that might outweigh and justify that move.
>

I think having a single endpoint is a disadvantage. The client (and server)
have to parse the JSON to understand what happened.

When the client wants to get a grant, it fetches the URL, as there is only
one way for the client to ask for the grant. In XYZ, the client creates
some JSON that signals to the AS that it wants a grant. Seems similar
complexity on the client.

But on the server, the server has to parse the JSON to understand what the
client wants to do.

I agree that the different published endpoints in OAuth 2 created
additional complexity, but in XAuth, there is only one published endpoints.
All other URIs are that endpoint with what could be considered parameters
added for context.

>>>>> 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?
>>>>>
>>>>
>>> That is not entirely correct. A pre-registered client can still pass
>>> its key by value, and a dynamic client can still use a
> Not only do I think OAuth developers can migrate, *I think it’s essential
> that we do* in order to make this useful to non-OAuth developers. Vast
> swaths of the internet are already building out key-based systems, not
> using OAuth. In my own experience, I can say for a fact that the
> awkwardness of needing a client identifier ahead of time is one of the
> problems. The fact that there’s a place to use a legacy client ID within
> the protocol is a bonus feature, and important for migration. But it’s even
> more important that it’s not
>
> And we should look at history before we declare something impossible. We
> managed to get web developers away from thinking about accessing an API
> with a username and password and toward thinking in terms of accessing it
> with a token. This is a shift of the same kind, and an important one at
> that.
>
> To me, this is one of the important fundamental shifts of this work away
> from the limits of OAuth’s models and assumptions, and one of the ones that
> will make this work applicable far outside of the space that OAuth 2 has
> already carved. I don’t see a compelling reason to limit ourselves.
>
> If your primary goal is to keep OAuth 2 developers safe and happy, then in
> all honesty, just keep using OAuth 2. Why wouldn’t you? Use PAR and RAR and
> DPoP for advanced functionality. It’s a combination that, if a bit
> patched-together, does work. Move to a new protocol when it does something
> you can’t do, or it’s otherwise a better fit for what you’re trying to
> solve. And when you’re in a position to move, there’s a migration path.
> That doesn’t mean it’s a direct re-use, it means you can migrate — move,
> change — without tearing absolutely everything out. But you still need to
> move, and that’s expected.
>
> In all honesty, I think the gap between OAuth 2 and XYZ is less than the
> gap between OAuth 1 and OAuth 2, especially if you’re looking at using
> OAuth 2 with PAR, RAR, etc. I don’t see a compelling reason to artificially
> limit the new protocol with the constraints of the old, particularly when
> there’s a migration path between them. XYZ can make use of some of the
> familiar pieces of OAuth 2 without causing all clients to depend on them.
> That’s the difference between migration and straight re-use.
>

Of course you think it is straightforward. It is the mental model you made
up!

I agree we should not artificially limit the new protocol, but there is
also no need to burn everything down because we can.

> If the client has made a request with “redirect” and “callback” in its
> request, and then decides to display the interaction URL as a scannable
> code, then the AS will just redirect to the client’s callback URL when it’s
> done, whatever that URL was. If the client sends a “callback” URL that it
> can’t get information from, then that’s a poorly-written client, isn’t it?
>

Let me provide more clarity on the scenario.

The client is a web app that can redirect the user to the AS, and receive a
callback, it can display a code and URI to enter the code, or it can show a
scannable code for the user to scan on their mobile phone. The user may be
using the web app on a PC, and the AS is on their phone. The user chooses
to scan the barcode with their phone. After authenticating with the AS, the
AS redirects back to the callback URL. But the webpage is now on the user's
mobile device, not the web app on the PC.

>
> If the client can’t get to the information in the callback URL unless it’s
> on the same device, then the client isn’t going to show the user a
> scannable code to be read by a secondary device. Why would it?
>

Because it is a better experience for the user per above.

The AS parameters don't differentiate between a scannable URL and a URL
that can only be redirected, so the client will think it can do anything.

Additionally, in XAuth, the client can provide an informational URI for the
AS to redirect after a scannable code or a user code flow.

>>> Refreshing an access token in XYZ returns a full transaction response
>>> per Section 9.3 which refers to Section 8.
>>>
> Transactions are updated by sending the transaction handle back with
> additional information. This is no different from the request made after a
> front channel callback, or what would be made in a challenge-response
> format. I haven’t written up a way to create a new transaction building on
> an old one (which I think is an important advanced use case), but it would
> amount to having a separate field in the initial transaction request to
> have the transaction handle of the old transaction in it.
>

So the AS needs to understand that various combinations of fields to know
if it is updating or creating a transaction. Seems like complicated logic
at the AS to understand what the Client wants to do compared to a URI and
HTTP method.

>
> Multiple access tokens cannot be refreshed separately in the current
> implementation of XYZ. This is a noted gap in the spec, and I’m open to
> ideas on how it would be handled.
>

URIs for each authorization. :)

> It seems much simpler to route a request based on URI and verb(XAuth),
> then parse and inspect a JSON payload (XYZ)
>
>
> See above.
>

I don't see what is problematic from above. Would you elaborate?

>> I think how the user gets to and from the server is CRITICAL to the
>> server if it wants to protect itself from a session fixation attack.
> Push notifications on a mobile platform,
>

Push notifications between the AS and a third party Client? How would that
work?

> COAP-style subscriptions at the HTTP layer, messages coming in over a
> blockchain fabric through a separate entity…
>

I think you are mixing up how the client and AS communicate, with how the
AS redirects the user back to the client. We already have a channel for the
client and AS to communicate. The only reasons we need to get the user back
is to protect from sessions fixation, and to provide a better experience.

>
> I think your view of what a client is and how it could communicate and
> interact is limited, and that’s informing XAuth’s design.
>

I think your view of my view is limited. :)

> What I’m proposing in XYZ is exactly the new syntax that incorporates both
> RAR and scope natively by using handles and polymorphic JSON. Other
> resource request syntaxes could also be defined and added.
>

Unclear how polymorphic JSON helps with RAR and scope. My impression was
that it signalled the difference between an array of resources vs a single
resource.

Your extension mechanism would be to add a JSON object at the top level, or
inject it within the schema you are defining? IE, just use the
extensibility of JSON?

I think having the client clearly indicate the schema it is using is
crisper and less likely to get wrong.

Also, I think that the AS may want to know if the client is intending to be
using only oauth_scopes, or has been updated to use RAR.

ᐧ

---

From: Dick Hardt <[email-masked]>
Date: Mon, 15 Jun 2020 17:38:42 -0700

comments inline ...

On Wed, Jun 10, 2020 at 8:07 AM Justin Richer <[email-masked]> wrote:

>>> 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":
>>>         {

I think you are missing my point. Adding query parameters to OAuth 2 was
not a defined extension point. It was inherent in how query parameters
work. OAuth 2 did define the type of grant as an extension point.

>
> My concern was that XYZ does not have a clear way to add new identity
> claim schemas. You have two examples, add a schema as a member of the
> claims object, which is mixing claims with schema extensions, or adding a
> root member, which is then putting claims into more than one place. It is
> not clear where to add a new schema, so we could easily end up with new
> schemas in both places. That sounds confusing.
>
>
> I provided a couple examples off the cuff of possible ways to extend
> something, as your base claim was that XYZ could not be extended with new
> or external query schemas. Of the two, I think that it makes more sense for
> it to be a separate top-level object. Why? Because the OIDC “claims”
> request syntax not only dictates claims within the OIDC schema, it also
> specifies how the information comes back. The XYZ claims request talks
> about information that comes back in the XYZ claims section of the
> response.
>

I would put the OIDC request to acquire claims from a user_info endpoint
into the authorization request so that there is a consistent way to get
back an access token, as opposed to a new top level object that could
return claims and/or an access token.

> Since the OIDC request allows for targeting specifically to the ID token
> and UserInfo Endpoint, I think it is much cleaner to be at the top level as
> its own thing.
>

My point is that XYZ does not *define* how to add new schemas. An extension
can add anything it wants to the JSON, and as you have shown there is more
than one way to do it, and I think long term when there are divergent
mechanisms, the code is going to get ugly in detecting what claims are
being asked for.

> Verifiable Credentials). The group is not chartered to develop new
> formats for identifiers or assertions, nor is the group chartered to
> develop schemas for user information, profiles, or other identity
> attributes, unless a viable existing format is not available.
>
>
> Precisely: the charter says we will have a way to convey identifiers and
> assertions. The XYZ “claims” section lists identifiers that can come back,
> in plain text, and assertions, that can also come back along side them.
>

These claims are a schema. We will have an IANA entry for what claims are
allowed inside of the claims object. This is defining a new schema.

> It’s not a full query language and isn’t intended to be, and I think that
> it would actually be dangerous for this to be a full identity schema, but
> it is itself extensible internally if someone wants to do that. Claiming
> that a list of identifiers is “developing a new schema” is an argument
> several bridges too far from reality.
>

You are not inventing new identifiers, but you will be defining which
strings are being used to represent which concepts. FOr example you have
"email" vs "email_address", or any other string combination that a human
would likely interpret as an email like object.  Then there is specifying
what can be in the field.

> I picked a couple examples out of thin air, with the idea that we’d
> bikeshed them eventually and tie them to a registry. We might want to
> re-use a set of identifiers here, and for that I actually like Annabelle
> Backman’s proposal to the SECEVENT group better than most that I’ve seen in
> the space:
>
> https://tools.ietf.org/html/draft-ietf-secevent-subject-identifiers
>

That is one schema. And it has advantages for the subject identifiers, but
obviously does not cover the wide array of other identity attributes.

Why would we not want to reuse existing schemas? And support all of them?

ᐧ

---

From: Dick Hardt <[email-masked]>
Date: Mon, 15 Jun 2020 17:47:53 -0700

comments inline ...

On Sun, Jun 14, 2020 at 10:21 AM Justin Richer <[email-masked]> wrote:

> >> The client is identified by its key. There is no external client
> identifier. I think you’re confused because you’re still thinking in terms
> of OAuth 2’s client ID based model and I am trying to move us past that. It
> took me time to realize that we really can let it go, so hopefully this is
> helpful in explaining why.
> >>
> >> When a credential is cryptographically random enough to be unique, it
> can be used as its own identifier, particularly when you don’t need to
> identify the entity outside of the context that it can present and prove
> its credential. To stretch a metaphor, passwords don’t always need
> usernames. This is, after all, the driving design pattern behind OAuth
> access tokens. An access token doesn’t have a “username” portion to it,
> even though it would have been trivial to require the client to send its
> client ID alongside the access token. Why does that work? Because our model
> of what the RS does with the access token is built around it answering the
> questions: is this token valid and does it allow what’s being requested? If
> the RS needs to know which client was issued the token, it can discover
> that information without being told separately from the token -- perhaps
> it’s in the token itself or it’s in an introspection response. And in a lot
> of cases, the RS doesn’t care about the client software, it just wants to
> know if the token’s any good. Even in constrained tokens such as MTLS, PoP,
> and DPoP, we aren’t really authenticating the client at the RS so much as
> making sure the right key is presented alongside the right token.
> >>
> >> XYZ takes that same approach with the client talking to the AS and uses
> the credential (key) to identify the client as well as authenticate and
> protect the request. We can’t just say “OAuth 2 had client IDs and people
> are used to it so it must be good and we have to keep using it”. We need to
> ask WHY OAuth 2 needs client IDs and if that still makes sense. I argue
> that it doesn’t make sense anymore and we need to step back and look at a
> better model. OAuth 2 needs a client ID because it gets passed in the front
> channel and the client’s credentials can’t be used there. The access token
> doesn’t need an equivalent because it’s passed in the back channel and can
> be used directly. Now that the client no longer needs to be identified, but
> not authenticated, through untrusted third parties (such as the browser),
> we don’t need to have a separate identifier as part of the protocol. With
> an intent-based protocol, that starts in the back channel, you don’t need a
> client identifier anymore. Once the AS finds that key, the AS can then
> figure out what policies, rights, and restrictions are attached to that
> key. In many implementations, there’s going to be some kind of “registered
> client” object in a database somewhere that drives those policies. That’s
> the classical OAuth model, and it works in many cases. But in other cases,
> the key is going to just be a value used to protect the request chain (and
> possibly the token itself), and the policy is going to be built up by other
> things like a device posture or signature on the calling software or
> verified user information. It’s not just about client authentication, even
> though it can be used for it. DPoP, PKCE, and DynReg have shown us the
> value in dynamic systems, in different ways.
> >>
> >> On top of that, PAR is showing us that a lot of the constraints that we
> have in OAuth 2 don’t really apply anymore. For instance, Redirect URI
> restrictions can be relaxed because now you CAN identify and authenticate
> the software sending it, which isn’t true with a front-channel-first
> approach. All of the things that are required in OAuth 2 start to become
> redundant, and it leads to things like requiring that “client_id” still
> always be passed in the front channel even though the information could be
> looked up from an internal request_uri reference using PAR and JAR together.
> >>
> >> That’s why a key handle isn’t exactly the same as a client ID and I did
> not call it a client ID in the XYZ protocol. It’s a shortcut to refer to
> the key material for certain optimized cases, but ultimately it’s pointing
> to a key. This has an interesting and beneficial side effect — if you HAVE
> a client ID as part of your internal data model, it can FUNCTION as a key
> handle because it’s a unique value the AS can use to look up key
> information. It’s not “authenticating the client”, it’s pointing to a key
> which in turn identifies and authenticates the software making the call.
> The fact that it’s a “client ID” is an artifact of the implementation,
> which in this case has an OAuth 2 legacy to work with.
> >>
> >> If we’re going to move past the constraints of OAuth 2 we need to stop
> thinking so strictly in its terms and models. There are better ways to
> approach this now and client IDs are not required by this protocol model.
> >
> Yes, I feel the same way. The idea behind XYZ’s ability to introduce the
> key either by value leads to a model where the key is always what points to
> the policy of what’s allowed, but the way that the AS discovers which key
> it’s supposed to be proving against is separate. So it goes handle -> key
> -> client. In OAuth 2, the model is you identify the client and then figure
> out what key is attached to that client. The relationship is inverted as
> handle -> client -> key, and that’s where the problems start to come in for
> other communities.
>

I'm finding the following confusing:

handle -> key -> client
handle -> client -> key

We have some identifier, and it is used by the AS to get an object /
collection of attributes about the client

handle -> {
    name
    URI
    image
    key
    ....
}

What is "client" above"? Is the client not a collection of attributes, and
one of those is the key?

> It’s really important for a lot of use cases that we let clients have an
> identifier separate from the key value itself, which is why XYZ doesn’t
> define the key handle as the fingerprint of the key, or the key ID (which
> could be internal to the JWK), or anything else. All it means is “when the
> AS sees this value, it knows what key or keys it is referring to”. And from
> there, the AS can figure out the rest of its policy. As you say, this
> relationship can get set up with an AS database, or the AS could know how
> to look up the key in a DNS store or distributed ledger — it doesn’t
> matter, as long as the AS can find the key. This allows us to also have use
> cases where we don’t have a separate identifier that the AS knows about and
> we can just send the key as-is, like for ephemeral clients in SPAs, or
> mobile applications that would need to be registered in OAuth 2 in order to
> get a client ID. And you don’t even need to look that far from OAuth to
> find use cases for key-based identity, as that’s at the core of the
> self-issued OP functions in OIDC, which is in the core spec. There, we have
> the spec saying to use the redirect URI as the client ID — even though the
> client already is sending the Redirect URI, OAuth 2 (and the associated
> assumptions and model of the protocol underneath) need this explicit client
> ID field for all use cases.
>
> Something that I think is interesting is that we have an opportunity to
> potentially define ways to process these kinds of things cross domain, much
> the way JWTs and introspection allow for cross-domain access tokens to be
> processed. But I think there’s still a lot of discussion and debate to
> figure out all the avenues that people care about here. XYZ’s model is
> probably not exactly right for every case, but I’ve already seen the
> ability to do key by value or by reference be useful in a lot of places
> that OAuth 2 doesn’t really work well.
>

 Are you able to provide examples so the rest of us can fully appreciate
what the gaps are?
ᐧ