Subject: Re: [Txauth] XAuth - a revision of TxAuth

From: Matthew De Haast <[email-masked]>
Date: Tue, 28 Jan 2020 20:58:26 +0200

Hi Dick,

Can you clarify the relation between this and the TxAuth Charter. Are you
proposing not to charter TXAuth and rather propose xauth as an
extension of Oauth2? Is it an and/or scenario or do you see this being
worked on in conjunction with TxAuth?

Matt

On Tue, Jan 28, 2020 at 12:05 AM Dick Hardt <[email-masked]> wrote:

> Hello!
>
> I riffed on Justin's draft and have created an alternative that has the
> same core concept of secure communication of all parameters between the
> Client and the AS.
>
> https://tools.ietf.org/html/draft-hardt-xauth-protocol-00
>
> A goal of this document was to be as self contained as possible.
> Everything needed to implement is included if an implementor is are
> already familiar with OAuth 2.0 or OpenID Connect, and wants to migrate to
> XAuth.
>
> To meet that goal, JOSE was chosen as the default mechanism for the Client
> to authenticate to the AS, and to perform PoP access to a resource. The
> JOSE specific aspects are in one section, so that an extension can easily
> specify other Client authentication mechanisms.
>
> There are likely numerous editorial and syntactical errors, and as we all
> know -- naming is hard -- so feel free to suggest better names.
>
> There are lots of issues with normative language, many of which I am not
> aware of yet!
>
> I've revised the document a number of times, and may have old terms
> dangling around. Please let me know if there is something confusing, or
> contradictory!
>
> /Dick
>
>
>
>
>
>
> --
> Txauth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/txauth
>

---

From: Dick Hardt <[email-masked]>
Date: Tue, 28 Jan 2020 11:01:44 -0800

I intended XAuth to meet the TxAuth Charter.

The sequence is pretty much the same as the TxAuth ID that Justin proposed.

On Tue, Jan 28, 2020 at 10:58 AM Matthew De Haast <[email-masked]> wrote:

>> To meet that goal, JOSE was chosen as the default mechanism for the
>> Client to authenticate to the AS, and to perform PoP access to a resource.
>> The JOSE specific aspects are in one section, so that an extension can
>> easily specify other Client authentication mechanisms.
>>

---

From: Justin Richer <[email-masked]>
Date: Tue, 28 Jan 2020 23:46:08 +0100

I would not go so far as to call it “pretty much the same” as there are a number of key differences. 

But that said, while I disagree with a lot of the details of Dick’s proposal, I think it’s worthy input to what the group decides to work on.

 — Justin

> On Jan 28, 2020, at 8:01 PM, Dick Hardt <[email-masked]> wrote:
> 
> On Tue, Jan 28, 2020 at 10:58 AM Matthew De Haast <[email-masked] <mailto:[email-masked]>> wrote:
> Hi Dick,
> 
> Can you clarify the relation between this and the TxAuth Charter. Are you proposing not to charter TXAuth and rather propose xauth as an extension of Oauth2? Is it an and/or scenario or do you see this being worked on in conjunction with TxAuth?
> 
> Matt
> 
> On Tue, Jan 28, 2020 at 12:05 AM Dick Hardt <[email-masked] <mailto:[email-masked]>> wrote:
> Hello!
> 
> I riffed on Justin's draft and have created an alternative that has the same core concept of secure communication of all parameters between the Client and the AS.
> 
> https://tools.ietf.org/html/draft-hardt-xauth-protocol-00 <https://tools.ietf.org/html/draft-hardt-xauth-protocol-00>
> 
> Everything needed to implement is included if an implementor is are already familiar with OAuth 2.0 or OpenID Connect, and wants to migrate to XAuth. 
> 
> To meet that goal, JOSE was chosen as the default mechanism for the Client to authenticate to the AS, and to perform PoP access to a resource. The JOSE specific aspects are in one section, so that an extension can easily specify other Client authentication mechanisms.
> 
> There are likely numerous editorial and syntactical errors, and as we all know -- naming is hard -- so feel free to suggest better names.
> 
> There are lots of issues with normative language, many of which I am not aware of yet!
> 
> I've revised the document a number of times, and may have old terms dangling around. Please let me know if there is something confusing, or contradictory!
> 
> /Dick
> 
> 
> 
> 
> 
> 
> -- 
> Txauth mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/txauth <https://www.ietf.org/mailman/listinfo/txauth>

---

From: Justin Richer <[email-masked]>
Date: Wed, 29 Jan 2020 17:26:15 +0100

As Dick has mentioned, I gave him some early feedback on this draft before publication, and he’s asked me to write up my thoughts and responses on the current XAuth proposal that’s published here.

To disambiguate between different efforts, I’ll refer to Dick’s draft as XAuth, my own draft as XYZ, and the proposed working group work here (as in our eventual output) as TxAuth. 

The short version is that I think that both XYZ and XAuth should be seen as inputs to TxAuth, but I prefer and recommend XYZ for a number of specific reasons and differences. I also do not see XAuth and XYZ as the same, as stated in a previous email on this thread.

I think XAuth has an interesting take on the problem space that TxAuth is looking to solve, but in my opinion it generally veers too closely to OAuth2/OIDC/JWT in its solution approach. It’s got some good ideas, though, and things that we should consider, as well as a lot of things that I don’t think are good ideas, or are regressions to old ideas that I specifically think we should move beyond. 

I’ll start with things that I like and that we should look at:

1. XAuth returns a follow-up URL (actually two) with a transaction. This is something I considered with XYZ specifically to deal with revocation. This is something that I think is tractable if we do it right, and we’ll have to be careful about the privacy and security implications of this. Also, just like XYZ, calling this endpoint has to require the client to authenticate in the same way (ie, with the same key and method) that it used to start the request with.

2. XAuth has a separate request mechanism for user claims. I have been struggling with a way to have a request that results in an access token (the classical OAuth 2 model) and something that extends the request and response in a parallel way is a good thing. I like this more than what OIDC does, which is extend the “scope” field. 

But there are a lot more things that I think it doesn’t get quite right. These aren’t just syntactical or normative-reference issues, as I believe they speak to a very different underlying model and set of assumptions. 

1. XAuth removes “handles” as stand-ins for various elements. In XYZ, the “handle” concept is a key abstraction point with specific semantics. A “handle” is an identifier to a specific instantiation of a JSON object structure. Using the “handle” for Keys, for Resources, and even the whole Transaction lets you do a lot of core things in a parallel and reusable way. XAuth re-invents a few of these as separate items, listed below, and I see this as a regression.

2. XAuth uses a Client ID from OAuth 2. I removed Client IDs from XYZ because I realized that you don’t need them anymore. The client ID tells the AS which client is talking in the front channel because the client can’t authenticate. In the back channel, the key (or secret) identifier is enough to identify the client — that’s the Key Handle in XYZ that can be passed in lieu of the key itself. The argument that it’s helpful to have an identifier for doing developer support and managing registrations is spurious, since this is an internal identifier that never needs to be exposed by the protocol. Additionally, a client ID assumes a registration-based model. There are ephemeral and per-device client instances like SPA’s and mobile apps that don’t really fit the client ID model very well. Pushing this requirement on all clients is bad, as we’ve seen in OAuth 1 and OAuth 2. XAuth tries to manage this by splitting clients into two camps, but I’m saying that no client needs and external client ID.

3. XAuth uses a “type” field for interaction. This means the client can only do one type of interaction for any given transaction. XYZ started like this, but we moved away from it because we realized we could have a client app that could handle multiple types without that kind of dispatch. In XYZ the client sends over flags for each kind of interaction it can do: send the user to an arbitrary URL, give the user a code, get a callback from a browser, etc. Combining these in specific ways addresses all of the different methods that XAuth identifies as its types while also allowing additional things. The AS picks from the client’s list based on what the AS can support as well as what makes sense for the policies governing the requested access.

4. XAuth allows OAuth-style scopes next to RAR-style data structures (and next to OIDC claims structures). They are treated as completely separate from each other. In OAuth 2, RAR is defined in the context of scope (and resource and audience and other parameters), and this combination is a matter of some debate still that needs to be solved. However, it’s clear that they’re combined. In XYZ, the only resource request defined is the object inside the resource request. You can mimic “scope” behavior by using a Resource Handle, which again is defined as a single string that stands in for the whole object and could be defined by the AS (or the API it’s protecting). 

5. The different kinds of authz requests in (4) create separate tokens.This is very different from both OAuth 2 and XYZ, where you get back a single access token. And in XAuth there is no way to get, for example, two access tokens that are both described by RAR requests, so this seems like a very arbitrary and syntactically-driven separation. 

6. The assumption that JOSE will always be in the toolkit of the client developer is not true. You can do an XYZ transaction without any JOSE — for example, using HTTP Sig or MTLS for key presentation. 

7. The statement that “there is no HTTP signing” is false, as this is being brought up to the HTTP WG right now (I’m one of the co-authors). Yes, it’s not an RFC, but neither is this. And if we’re doing agile signature methods, which I contend is a required extension point, then we don’t have a dependency requirement for it. 

8. XAuth adds back in an explicit “refresh token”. In XYZ, we don’t have a refresh token because we can use the transaction handle to continue the transaction after a token has been issued. This has explicit and clear semantics that follows from what the transaction handle is used for elsewhere in the protocol — continue this request that’s in some authorization state and give me the results. 

9. XAuth uses OIDC’s ID Token. As I’ve said on the other thread, I don’t think we actually need a separately signed assertion. I’d rather see a way to sign the entire response which includes the user claims, if we want signature protection.

10. XAuth sends all the user’s claims on the login request — or more precisely, this is the only mechanism specified and the Rationale section claims this is a feature. This violates minimal disclosure and privacy design guidelines, and this type of protocol has been developed before with OpenID 1.x/2.x and SAML. The problem here unfolds when you think about how it works: The RP needs to log in. If this is the first time it’s seen this user, then it needs the user’s profile info. If not, and the profile info hasn’t changed, there’s no need for it and the AS shouldn’t send it. So the RP can signal this, right? Except that the RP doesn’t know who the user is yet (that’s why they’re making this call!). Can the AS make this call? They won’t know if the RP has cached the user’s info or not. And if we’re using Client ID, then the AS can’t even be sure that this copy of the client is the same as another copy of the client. I think TxAuth needs to minimize the user claims sent back to being an identifier, information about the authentication event that could change each time anyway, and anything that would be needed to control a cache. Additional fields can be pulled from the equivalent of a UserInfo Endpoint in a two-stage process that both preserves privacy and optimizes for what’s available from each party.

11. XAuth defines an explicit discovery step because the client now needs to know several things about the server. The mix-up attack and a few other attacks in OAuth 2 stem from this kind of process. In XYZ, the client really only needs to know the transaction endpoint URL and it learns everything else from that point. Yes, the client needs to discover that someplace — but it was a deliberate decision in limiting the amount of upfront information that the client needs to get started. I’ve played with the concept of a “capabilities” list in XYZ, where the client would present a list of things it can do and the AS trims that list to what it can also do. This type of one-stage negotiation is really powerful and I think we can get a lot from it here.

All in all, thanks for the draft. I think it raises important questions and the discussion of these questions will help us build the best system we can.

 — Justin

> On Jan 27, 2020, at 11:04 PM, Dick Hardt <[email-masked]> wrote:
> 
> Hello!
>

---

From: Dick Hardt <[email-masked]>
Date: Wed, 29 Jan 2020 15:25:06 -0800

On Wed, Jan 29, 2020 at 8:26 AM Justin Richer <[email-masked]> wrote:

> As Dick has mentioned, I gave him some early feedback on this draft before
> publication, and he’s asked me to write up my thoughts and responses on the
> current XAuth proposal that’s published here.
>

Thanks again for that feedback Justin. I was hoping to see your responses
before you posted so that I could clarify misconceptions, but I'll do that
now on the list. =)

Thanks for writing this up -- I believe it helps us identify the areas for
deeper discussion to reach rough consensus!

>
> To disambiguate between different efforts, I’ll refer to Dick’s draft as
> XAuth, my own draft as XYZ, and the proposed working group work here (as in
> our eventual output) as TxAuth.
>
> <snip>

>
> I think XAuth has an interesting take on the problem space that TxAuth is
> looking to solve, but in my opinion it generally veers too closely to
> OAuth2/OIDC/JWT in its solution approach.
>

Reusing aspects of OAuth2/OIDC/JWT that are working fine for deployments
will minimize the migration effort for them to take advantage of the
security features of this work such as not using the redirect for passing
parameters. I think XAuth supports the following clause of the current
draft charter: "the group will attempt to simplify porting from OAuth 2.0
and OpenID Connect to the new protocol where possible."

<snip>

> 1. XAuth removes “handles” as stand-ins for various elements. In XYZ, the
> “handle” concept is a key abstraction point with specific semantics. A
> “handle” is an identifier to a specific instantiation of a JSON object
> structure. Using the “handle” for Keys, for Resources, and even the whole
> Transaction lets you do a lot of core things in a parallel and reusable
> way. XAuth re-invents a few of these as separate items, listed below, and I
> see this as a regression.
>

XAuth took the transaction handle and forked it into a completion handle
and a refresh handle so that it is clear what the Client is wanting to
happen.

It was not clear the value of the other handles that were listed in XYZ.

>
> 2. XAuth uses a Client ID from OAuth 2. I removed Client IDs from XYZ
> because I realized that you don’t need them anymore. The client ID tells
> the AS which client is talking in the front channel because the client
> can’t authenticate. In the back channel, the key (or secret) identifier is
> enough to identify the client — that’s the Key Handle in XYZ that can be
> passed in lieu of the key itself. The argument that it’s helpful to have an
> identifier for doing developer support and managing registrations is
> spurious, since this is an internal identifier that never needs to be
> exposed by the protocol. Additionally, a client ID assumes a
> registration-based model. There are ephemeral and per-device client
> instances like SPA’s and mobile apps that don’t really fit the client ID
> model very well. Pushing this requirement on all clients is bad, as we’ve
> seen in OAuth 1 and OAuth 2. XAuth tries to manage this by splitting
> clients into two camps, but I’m saying that no client needs and external
> client ID.
>

I addressed this in
https://tools.ietf.org/html/draft-hardt-xauth-protocol-00#section-12 # 7

 7.   *Why is there still a Client ID?  Could we not use a fingerprint
        of the public key to identify the Client?*

        Some AS deployments do not allow calls from Registered Clients,
        and provide different functionality to different Clients.  A
        permanent identifier for the Client is needed for the Client
        developer and the AS admin to ensure they are referring to the
        same Client.  The Client ID was used in OAuth 2.0, and it served
        the same purpose

Perhaps you did not see that?

I agree that dynamic client IDs in OAuth 2 were problematic. In XAuth, a
Dynamic Client is identified by its key.

Would you clarify what is broken with Client IDs for Registered Clients? It
seems to working fine for registered clients in OAuth 2 / OpenID Connect,
and migrating those deployments will be simpler if we keep the same concept.

The key handle seems problematic as it will change when keys are rotated.

>
> 3. XAuth uses a “type” field for interaction. This means the client can
> only do one type of interaction for any given transaction. XYZ started like
> this, but we moved away from it because we realized we could have a client
> app that could handle multiple types without that kind of dispatch. In XYZ
> the client sends over flags for each kind of interaction it can do: send
> the user to an arbitrary URL, give the user a code, get a callback from a
> browser, etc. Combining these in specific ways addresses all of the
> different methods that XAuth identifies as its types while also allowing
> additional things. The AS picks from the client’s list based on what the AS
> can support as well as what makes sense for the policies governing the
> requested access.
>

Do you have a use case where the AS will want to pick from a list, rather
than supporting the one that the Client wants to use?

In the case where the AS interacts with an RO that is not the User, there
would be nothing the Client would need to do. Perhaps there is a use case
for something different? If so, please elaborate.

>
> 4. XAuth allows OAuth-style scopes next to RAR-style data structures (and
> next to OIDC claims structures). They are treated as completely separate
> from each other. In OAuth 2, RAR is defined in the context of scope (and
> resource and audience and other parameters), and this combination is a
> matter of some debate still that needs to be solved. However, it’s clear
> that they’re combined. In XYZ, the only resource request defined is the
> object inside the resource request. You can mimic “scope” behavior by using
> a Resource Handle, which again is defined as a single string that stands in
> for the whole object and could be defined by the AS (or the API it’s
> protecting).
>

I think you need to reread the 00 draft. Only one type of authorization
request is allowed.

- OAuth style for deployments where that works fine.
- RAR style for deployments that need the extra granularity of RAR
- list of RAR style for deployments that support multiple resource servers
that require independent access tokens.

>
> 5. The different kinds of authz requests in (4) create separate
> tokens.This is very different from both OAuth 2 and XYZ, where you get back
> a single access token. And in XAuth there is no way to get, for example,
> two access tokens that are both described by RAR requests, so this seems
> like a very arbitrary and syntactically-driven separation.
>

I don't think you understood what is in the draft. See above.

>
> 6. The assumption that JOSE will always be in the toolkit of the client
> developer is not true. You can do an XYZ transaction without any JOSE — for
> example, using HTTP Sig or MTLS for key presentation.
>

Per earlier feedback from you, I have strived to separate JOSE out into
Section 8, so that an extension could use HTTP signing or MTLS. Let me know
where JOSE is still an assumption.

>
> 7. The statement that “there is no HTTP signing” is false, as this is
> being brought up to the HTTP WG right now (I’m one of the co-authors). Yes,
> it’s not an RFC, but neither is this. And if we’re doing agile signature
> methods, which I contend is a required extension point, then we don’t have
> a dependency requirement for it.
>

XAuth says from
https://tools.ietf.org/html/draft-hardt-xauth-protocol-00#section-12 # 3

There is currently no widely deployed open standard for HTTP signing.

Yes, there is working going on. But security it is not a published RFC,
there are no libraries for it, and it has not been tested on the open
internet.

While I wish the HTTP WG luck in this work, and I support it happening, it
will be hard.

OAuth 1.0 core issue was that it was signing a request (in my opinion)

The widely deployed HTTP Signing is AWS SIGv4 -- which AWS supplies
libraries for every API in all popular languages so that developers don't
have to do the HTTP signing themselves.

I could imagine AWS adopting XAuth and using SIGv4 instead of JOSE if they
wanted.

> 8. XAuth adds back in an explicit “refresh token”. In XYZ, we don’t have a
> refresh token because we can use the transaction handle to continue the
> transaction after a token has been issued. This has explicit and clear
> semantics that follows from what the transaction handle is used for
> elsewhere in the protocol — continue this request that’s in some
> authorization state and give me the results.
>

I think we agree that refresh is a required feature.

I think a transaction handle is to course grained. I don't think that the
AS should be returning all the claims in a refresh. And if there are
multiple access tokens returned from the AS, then each has their own
refresh handle.

>
> 9. XAuth uses OIDC’s ID Token. As I’ve said on the other thread, I don’t
> think we actually need a separately signed assertion. I’d rather see a way
> to sign the entire response which includes the user claims, if we want
> signature protection.
>

I responded in a separate thread.

>
> 10. XAuth sends all the user’s claims on the login request — or more
> precisely, this is the only mechanism specified and the Rationale section
> claims this is a feature. This violates minimal disclosure and privacy
> design guidelines, and this type of protocol has been developed before with
> OpenID 1.x/2.x and SAML. The problem here unfolds when you think about how
> it works: The RP needs to log in. If this is the first time it’s seen this
> user, then it needs the user’s profile info. If not, and the profile info
> hasn’t changed, there’s no need for it and the AS shouldn’t send it. So the
> RP can signal this, right? Except that the RP doesn’t know who the user is
> yet (that’s why they’re making this call!). Can the AS make this call? They
> won’t know if the RP has cached the user’s info or not. And if we’re using
> Client ID, then the AS can’t even be sure that this copy of the client is
> the same as another copy of the client. I think TxAuth needs to minimize
> the user claims sent back to being an identifier, information about the
> authentication event that could change each time anyway, and anything that
> would be needed to control a cache. Additional fields can be pulled from
> the equivalent of a UserInfo Endpoint in a two-stage process that both
> preserves privacy and optimizes for what’s available from each party.
>

Not clear how XYZ improves on this.

The UserInfo Endpoint solves the Client getting more info than it needs,
but the User still needs to give consent each time unless the AS tracks it.
So it is unclear to me what value the UserInfo Endpoint brings.

Your comments have inspired me on a solution that can be done with XAuth
(or XYZ) that can't be done with OAuth 2.0/OIDC.

I'll add that to the XAuth draft and publish it.

>
> 11. XAuth defines an explicit discovery step because the client now needs
> to know several things about the server. The mix-up attack and a few other
> attacks in OAuth 2 stem from this kind of process. In XYZ, the client
> really only needs to know the transaction endpoint URL and it learns
> everything else from that point. Yes, the client needs to discover that
> someplace — but it was a deliberate decision in limiting the amount of
> upfront information that the client needs to get started.
>

That is still discovery, is it not?

Would the Client not need to know the message signing methods supported?
JOSE, HTTP Signing, and/or MTLS?

> I’ve played with the concept of a “capabilities” list in XYZ, where the
> client would present a list of things it can do and the AS trims that list
> to what it can also do.
>

So ... programatic discovery? =)

Are you suggesting that discovery of everything but the endpoint has to be
programatic?

> This type of one-stage negotiation is really powerful and I think we can
> get a lot from it here.
>

Sure ... but for many people what works today is documentation that someone
reads to understand what to do. Are you suggesting we not enable that?

>
>
> All in all, thanks for the draft. I think it raises important questions
> and the discussion of these questions will help us build the best system we
> can.
>

Thanks again for writing up your feedback!

/Dick

---

From: Justin Richer <[email-masked]>
Date: Thu, 30 Jan 2020 10:05:06 +0100

On Jan 30, 2020, at 12:25 AM, Dick Hardt <[email-masked]> wrote:
> 
> 
> 
> On Wed, Jan 29, 2020 at 8:26 AM Justin Richer <[email-masked] <mailto:[email-masked]>> wrote:
> Thanks again for that feedback Justin. I was hoping to see your responses before you posted so that I could clarify misconceptions, but I'll do that now on the list. =)
> 
> Thanks for writing this up -- I believe it helps us identify the areas for deeper discussion to reach rough consensus!
>  
> 
> I think XAuth has an interesting take on the problem space that TxAuth is looking to solve, but in my opinion it generally veers too closely to OAuth2/OIDC/JWT in its solution approach.
> 
> Reusing aspects of OAuth2/OIDC/JWT that are working fine for deployments will minimize the migration effort for them to take advantage of the security features of this work such as not using the redirect for passing parameters. I think XAuth supports the following clause of the current draft charter: "the group will attempt to simplify porting from OAuth 2.0 and OpenID Connect to the new protocol where possible.”

I understand the goals here, but I disagree that using the constructs as directly as they have been here is the most appropriate approach.

> XAuth took the transaction handle and forked it into a completion handle and a refresh handle so that it is clear what the Client is wanting to happen.
> 

I think this may be that you misunderstood the purposes of the handles, as you’ve reinvented nearly all of them with different labels in XAuth. :)

> I addressed this in https://tools.ietf.org/html/draft-hardt-xauth-protocol-00#section-12 <https://tools.ietf.org/html/draft-hardt-xauth-protocol-00#section-12> # 7
> 

I did see that and I addressed it in my comment. The AS admin and developer can still refer to an internal identifier without it being exposed in the protocol. 

> 
> I agree that dynamic client IDs in OAuth 2 were problematic. In XAuth, a Dynamic Client is identified by its key.
> 
> Would you clarify what is broken with Client IDs for Registered Clients? It seems to working fine for registered clients in OAuth 2 / OpenID Connect, and migrating those deployments will be simpler if we keep the same concept.
> 

Why would the key handle change when the key is rotated? Nothing in XYZ dictates how the key handle is generated by the AS or how the key handle is mapped to a specific key. It’s not a key identifier, which is why I haven’t called it a “key id”. 

I don’t see why a registered client can’t be identified by its key just like a dynamic client would be. What is the value in this split? I think there’s value in treating all clients the same and driving the differences in policy on the AS. Either I recognize a key handle, or I am being given a public key (which I also might recognize). In all of these cases the AS gets to run its policy against the party identified by the key.

> Do you have a use case where the AS will want to pick from a list, rather than supporting the one that the Client wants to use?

The AS would return interaction responses that are the intersection of:

 - methods the client indicates it can do in the request
 - methods the AS knows it can support
 - methods allowed by the policy governing the request

I don’t understand the second part of this question, because the AS still “supports the one the client wants to use” in the XYZ model.

As for a concrete example, look at how we handle the “qrcode” interaction case, based on OAuth 2’s device flow. In this, you want to send a URI to the client that it can render as a QR code as well as a code that the user can type into a page, in case they can’t scan the QR code. OAuth 2 manages this by having a user code as well as a pre-composed URL containing the code to be used for rendering. XYZ used to have a mode for this similar to XAuth, but we realized that we could describe this using two separate flags: 

 - I can communicate a short code that the user can type in at a static URL
 - I can get the user to go to an arbitrary URL

The second one is the same mechanism we can use for redirect-based auth. 

> 
> In the case where the AS interacts with an RO that is not the User, there would be nothing the Client would need to do. Perhaps there is a use case for something different? If so, please elaborate.
>  
> 
> I think you need to reread the 00 draft. Only one type of authorization request is allowed.
> 
> - list of RAR style for deployments that support multiple resource servers that require independent access tokens.
>  
> 

Apologies on these points — I didn’t catch that this had changed from the earlier drafts. 

> Per earlier feedback from you, I have strived to separate JOSE out into Section 8, so that an extension could use HTTP signing or MTLS. Let me know where JOSE is still an assumption.

The separation is OK in the current draft, but it still states that JOSE is the default, and by implication, preferred. 

> XAuth says from https://tools.ietf.org/html/draft-hardt-xauth-protocol-00#section-12 <https://tools.ietf.org/html/draft-hardt-xauth-protocol-00#section-12> # 3
> 
> Yes, there is working going on. But security it is not a published RFC, there are no libraries for it, and it has not been tested on the open internet. 
> 
> While I wish the HTTP WG luck in this work, and I support it happening, it will be hard.
> 

Which is why we shouldn’t have a normative dependency on it until it’s done, but ignoring it entirely is silly. I’ve always said this needs to be one among many options.

> 
> The widely deployed HTTP Signing is AWS SIGv4 -- which AWS supplies libraries for every API in all popular languages so that developers don't have to do the HTTP signing themselves. 
> 
> I could imagine AWS adopting XAuth and using SIGv4 instead of JOSE if they wanted.

I agree that they should be able to use TxAuth (not necessarily XAuth ;) ) using SIGv4, if they wanted — and that’s assuming they don’t move AWS to HTTP Sig. :)

> I think we agree that refresh is a required feature.

Yes, and I think that the constructs are similar, but the difference matters. By using the same handle for continuing the transaction over time as you do for refreshing, XYZ is giving the client developers a specific model: The transaction itself has a state and value over time, referenced by the transaction handle. The transaction entity still exists after it’s been approved and a token has been issued, but the things you can do with it are different (see below).

Both continuation and refresh are saying to the AS “run this transaction again and if I can get a token (or claims or whatever) in its current state, give me that”. However, they can’t really exist at the same time, so having two separate items to ask the same question doesn’t make much sense. 

> 
> I think a transaction handle is to course grained. I don't think that the AS should be returning all the claims in a refresh. And if there are multiple access tokens returned from the AS, then each has their own refresh handle.

I think this requires a deeper discussion, since the whole idea of multiple access tokens is a very different kind of approach here. 

I see refresh much as it is in OAuth2 and UMA, where it refers to the authorization that was granted. This means that you can do downscoping to get lower-powered access tokens that are a subset of the overall grant, and I think that TxAuth should be able to do a step-up auth where you can build some additional request on top of an existing approval. 

> Not clear how XYZ improves on this.

XYZ does not currently internally specify how to hand user info back, but I was looking at something in line with what Aaron Parecki’s blog post specified last summer. 

> 
> The UserInfo Endpoint solves the Client getting more info than it needs, but the User still needs to give consent each time unless the AS tracks it. So it is unclear to me what value the UserInfo Endpoint brings.

Remembering user consent and delivering claims are two completely separate problems and should not be conflated here. I was addressing the former. 

> 
> Your comments have inspired me on a solution that can be done with XAuth (or XYZ) that can't be done with OAuth 2.0/OIDC.
> 
> 11. XAuth defines an explicit discovery step because the client now needs to know several things about the server. The mix-up attack and a few other attacks in OAuth 2 stem from this kind of process. In XYZ, the client really only needs to know the transaction endpoint URL and it learns everything else from that point. Yes, the client needs to discover that someplace — but it was a deliberate decision in limiting the amount of upfront information that the client needs to get started.
> 

I literally just called it that in the sentence above, so yes. :) What you’re discovering is different though. And doesn’t the client still need to “discover” the discovery endpoint in XAuth?

> 
> Would the Client not need to know the message signing methods supported? JOSE, HTTP Signing, and/or MTLS? 

Only required if the client can programmatically do anything about that. The truth is that just about every client is going to be configured to do one kind of signing, and the developer can usually discover that. I don’t see a problem with having it listed in a discovery document next to the transaction endpoint, but I think we don’t actually need it because of the items below:

>  
> I’ve played with the concept of a “capabilities” list in XYZ, where the client would present a list of things it can do and the AS trims that list to what it can also do.
> 
> Are you suggesting that discovery of everything but the endpoint has to be programatic? 

In no way, shape, or form am I implying that. I’m saying that the items that can be used for programmatic discovery can be returned from the transaction endpoint without need for a separate endpoint. This can even include the signing methods, and the round-trips for an automated client are basically the same. 

So take the XAuth approach:

- client gets configured with the discovery endpoint
- client calls discovery endpoint, self-configures
- client calls tx endpoint

And the XYZ approach:

- client gets configured with the tx endpoint
- client calls tx endpoint, picks whatever default method it wants for signing (TxAuth spec can even declare a preferred version if we want)
	- if it works, tx has already started and things just continue — this optimizes for the happy path
	- if it fails, client gets back information to allow it to self-configure and calls the tx endpoint again

This is what I mean by one-stage negotiation on the discovery. If the client gets it right, that’s fine and things just continue without the extra step. If the client gets it wrong, it’s given the equivalent of information from the discovery endpoint that it can either self correct (which it would be able to do if it could self configure from a discovery document) or it will throw an error (which is what it’d do if it gets a discovery document it can’t do anything with). 

>  
> This type of one-stage negotiation is really powerful and I think we can get a lot from it here.
> 
> Sure ... but for many people what works today is documentation that someone reads to understand what to do. Are you suggesting we not enable that?

I am not suggesting that we disallow human-readable documentation and static configuration. I have no idea where you got that I was suggesting that.

But to be clear, yes you can still document things and pre-configure them. In fact, I think that’s better handled in XYZ that allows the client to be pre-configured and get started with a TX request, and then recover better if things aren’t what it thought.

---

From: Dick Hardt <[email-masked]>
Date: Thu, 30 Jan 2020 14:13:29 -0800

On Thu, Jan 30, 2020 at 1:05 AM Justin Richer <[email-masked]> wrote:

> and OpenID Connect to the new protocol where possible.”
>
>
> I understand the goals here, but I disagree that using the constructs as
> directly as they have been here is the most appropriate approach.
>

Ok. I think we have reasonable clarity on the disagreement.

> I think this may be that you misunderstood the purposes of the handles, as
> you’ve reinvented nearly all of them with different labels in XAuth. :)
>

I understand what a handle is, and what it represents. It appears that the
handles provide a reference to the display, resource, user, and key
objects. XYZ says the AS may issue those, but I could not find determine
when the AS sends them back to the RC. I understand the value of the
transaction handle XYZ, and built on that in XAuth, but XAuth always sends
the display, resource, user and key information by value, not by reference,
so your statement

you’ve reinvented nearly all of them with different labels in XAuth

is confusing.

> I did see that and I addressed it in my comment. The AS admin and
> developer can still refer to an internal identifier without it being
> exposed in the protocol.
>

There needs to be some shared identifier in the protocol, would you not
agree? For Registered Clients, the AS needs to have an identifier to look
up the data it has for the Client.

What is broken with Client ID? What identifier are you proposing in XYZ?

> Would you clarify what is broken with Client IDs for Registered Clients?
> It seems to working fine for registered clients in OAuth 2 / OpenID
> Connect, and migrating those deployments will be simpler if we keep the
> same concept.
>
> Why would the key handle change when the key is rotated? Nothing in XYZ
> dictates how the key handle is generated by the AS or how the key handle is
> mapped to a specific key. It’s not a key identifier, which is why I haven’t
> called it a “key id”.
>

I mistyped, I intended to say key fingerprint, which obviously changes when
the key is rotated.

I reread the XYZ Key Handle section ... and you are suggesting it
represents the Client instance, but it is not clear how the AS maps that to
preregistered client information.

>
> I don’t see why a registered client can’t be identified by its key just
> like a dynamic client would be. What is the value in this split? I think
> there’s value in treating all clients the same and driving the differences
> in policy on the AS. Either I recognize a key handle, or I am being given a
> public key (which I also might recognize). In all of these cases the AS
> gets to run its policy against the party identified by the key.
>

To clarify, your proposal is that the public key, or a fingerprint of it,
is what the AS uses to look up a preregistered Client?

> I don’t understand the second part of this question, because the AS still
> “supports the one the client wants to use” in the XYZ model.
>

I'm looking for a use case where the AS needs to select from a list, rather
than use the one mechanism that the Client wants to use. Why the extra
negotiation?

>
> As for a concrete example, look at how we handle the “qrcode” interaction
> case, based on OAuth 2’s device flow. In this, you want to send a URI to
> the client that it can render as a QR code as well as a code that the user
> can type into a page, in case they can’t scan the QR code. OAuth 2 manages
> this by having a user code as well as a pre-composed URL containing the
> code to be used for rendering. XYZ used to have a mode for this similar to
> XAuth, but we realized that we could describe this using two separate
> flags:
>

I got that. I thought being more crisp in the interaction makes it easier
for implementors to understand.

> Apologies on these points — I didn’t catch that this had changed from the

We can scratch this concern from the list then. Yeah!

> The separation is OK in the current draft, but it still states that JOSE
> is the default, and by implication, preferred.
>

Yes. I think freedom from having to make a choice makes things easier to
implement and deploy.
For deployments where another mechanism will be significantly better, the
choice is available.

Is there something about JOSE that you think is problematic to make it the
default?

> Which is why we shouldn’t have a normative dependency on it until it’s
> done, but ignoring it entirely is silly. I’ve always said this needs to be
> one among many options.
>

I was not ignoring it. When it is done, an extension can be written on how
to use HTTP Signing. Or the extension could be developed at the same time.

> I agree that they should be able to use TxAuth (not necessarily XAuth ;) )
> using SIGv4, if they wanted — and that’s assuming they don’t move AWS to
> HTTP Sig. :)
>

Moving AWS to HTTP Sig is very, very unlikely, having worked there. Having
an easy path to utilize XAuth / TxAuth is a good goal for the resulting
work.

>
>
>
>
>> 8. XAuth adds back in an explicit “refresh token”. In XYZ, we don’t have
>> a refresh token because we can use the transaction handle to continue the
> Yes, and I think that the constructs are similar, but the difference
> matters. By using the same handle for continuing the transaction over time
> as you do for refreshing, XYZ is giving the client developers a specific
> model: The transaction itself has a state and value over time, referenced
> by the transaction handle. The transaction entity still exists after it’s
> been approved and a token has been issued, but the things you can do with
> it are different (see below).
>

The word transaction is muddying what I think you are suggesting here. It
more like a conversation. Transactions from a DB point of view are a set of
actions that all happen, or none happen.

>
> Both continuation and refresh are saying to the AS “run this transaction
> again and if I can get a token (or claims or whatever) in its current
> state, give me that”. However, they can’t really exist at the same time, so
> having two separate items to ask the same question doesn’t make much sense.
>

They have different purposes. The completion (now authorization) handle is
to check if the AS is done with its request processing, and if so, provide
the results, which includes zero or more identity claims, and zero or more
access tokens/handles.

The refresh handle is to refresh a specific access token/handle.

> I think this requires a deeper discussion, since the whole idea of
> multiple access tokens is a very different kind of approach here.
>

It is a feature of XAuth.

In OAuth today, the bearer token is like a movie ticket. Whoever has the
movie ticket gets in the movie.
Using OAuth to obtain a bearer token is like buying a movie ticket.

Sometimes I want to go to more than one movie. OAuth today makes me wait in
line to buy each ticket. Why not let me buy multiple tickets at once?

>
> I see refresh much as it is in OAuth2 and UMA, where it refers to the
> authorization that was granted. This means that you can do downscoping to
> get lower-powered access tokens that are a subset of the overall grant, and
> I think that TxAuth should be able to do a step-up auth where you can build
> some additional request on top of an existing approval.
>

Is "step-up auth" authentication or authorization, ... or both?

> XYZ does not currently internally specify how to hand user info back, but
> I was looking at something in line with what Aaron Parecki’s blog post
> specified last summer.
>
>
> Remembering user consent and delivering claims are two completely separate
> problems and should not be conflated here. I was addressing the former.
>

They are related though. If you are not wanting to ask for consent on each
delivery, how do you know you have consent?

> I literally just called it that in the sentence above, so yes. :) What
> you’re discovering is different though. And doesn’t the client still need
> to “discover” the discovery endpoint in XAuth?
>

What discovery endpoint?

> Only required if the client can programmatically do anything about that.
> The truth is that just about every client is going to be configured to do
> one kind of signing, and the developer can usually discover that. I don’t
> see a problem with having it listed in a discovery document next to the
> transaction endpoint, but I think we don’t actually need it because of the
> items below:
>
>
>
> In no way, shape, or form am I implying that. I’m saying that the items
> that can be used for programmatic discovery can be returned from the
> transaction endpoint without need for a separate endpoint. This can even
> include the signing methods, and the round-trips for an automated client
> are basically the same.
>
> - client calls tx endpoint

Aaah now I see where we don't have common understanding ... that is not the
XAuth approach at all.

   1.  *AS Discovery* The Client discovers the AS end point, keys,
       supported claims and authorizations, and other capabilities.
       Some, or all of this information could be manually preconfigured,
       or dynamically obtained.  Dynamic AS discovery is out of scope of
       this document.

 In other words, here is some information the Client will need. You will
need to manually configure it, or there may be an option to obtain some or
all of the information you need programatically. The programatic discovery
is out of scope.

Perhaps I need to improve the language?

> - client calls tx endpoint, picks whatever default method it wants for
> signing (TxAuth spec can even declare a preferred version if we want)

Most existing Clients are manually configured. The developer reads the AS
documentation to learn what scopes and claims the AS supports, and then
codes that into the Client. The XYZ approach above does not take that into
account, and is in conflict with what you have below.

In XAuth, I'm calling that out as a step, so the developer understands
where that comes from. You effectively are saying the same thing below, so
it is unclear what your concern with XAuth is.

In XYZ, discovery is currently ignored.

>
> This is what I mean by one-stage negotiation on the discovery. If the
> client gets it right, that’s fine and things just continue without the
> extra step. If the client gets it wrong, it’s given the equivalent of
> information from the discovery endpoint that it can either self correct
> (which it would be able to do if it could self configure from a discovery
> document) or it will throw an error (which is what it’d do if it gets a
> discovery document it can’t do anything with).
>
>
>
>
> Sure ... but for many people what works today is documentation that
> someone reads to understand what to do. Are you suggesting we not enable
> that?
>
>
> I am not suggesting that we disallow human-readable documentation and
> static configuration. I have no idea where you got that I was suggesting
> that.
>

Because you were not supportive of the discovery step in XAuth? And you
made no mention of static configuration in your description, contrary to
XAuth?  Hence me asking a probing question to get clarity.

Interpersonal communication hint:  when you have no idea on why someone is
asking a clarifying question, ask yourself what might have been unclear in
your communication. Then just answer the clarifying question.

>
> But to be clear, yes you can still document things and pre-configure them.
> In fact, I think that’s better handled in XYZ that allows the client to be
> pre-configured and get started with a TX request, and then recover better
> if things aren’t what it thought.
>

XAuth documents what information is required, and that it can be
pre-configured.

Where in XYZ is the negotiation after the TX request? Sounds interesting,
but I did not see it.

/Dick
ᐧ

---

From: Justin Richer <[email-masked]>
Date: Fri, 31 Jan 2020 12:22:38 +0100

> On Jan 30, 2020, at 11:13 PM, Dick Hardt <[email-masked]> wrote:
> 
> 
> 
> On Thu, Jan 30, 2020 at 1:05 AM Justin Richer <[email-masked] <mailto:[email-masked]>> wrote:
> On Jan 30, 2020, at 12:25 AM, Dick Hardt <[email-masked] <mailto:[email-masked]>> wrote:
> I understand what a handle is, and what it represents. It appears that the handles provide a reference to the display, resource, user, and key objects. XYZ says the AS may issue those, but I could not find determine when the AS sends them back to the RC. I understand the value of the transaction handle XYZ, and built on that in XAuth, but XAuth always sends the display, resource, user and key information by value, not by reference, so your statement 
> 

I think what you’re missing is that the dynamically generated handles are not the only handles in the system. In addition, you’re making assumptions about how to generate a handle given a piece of information, and how the client gets access to the handle for its use in the request. I think that’s why you’re not realizing that you’re effectively removing, renaming, and replacing them in XAuth, but with what I believe and understand to be  less robust capabilities and semantics. 

The various handles in XYZ can come about in two ways. 

1. They’re generated dynamically by the AS in response to a client request. These are the values returned from the tx endpoint, and I believe this is the use case that you understand better. This is to handle dynamic, non-emphemeral clients that are capable of remembering something in between requests. The client always has the option of sending its information by value, but the handle gives it a short form reference that it can use instead. The transaction handle is just another instance of this type of handle, since it’s generated on the fly. 

2. They’re assigned by the AS in some static or manual fashion. These values could be returned by a developer console page, where the developer or admin goes and statically registers the client’s various values (keys, resources, etc) and returns the associated handles. The developer then statically configures these values into the client — such as the key handle, discussed in depth below. If the developer updates the information in the registration, I wouldn’t expect the handle values to change. Nothing says that they should be derived from the information they represent, as unguessable unique values are fine for most of these cases. Resource handles are likely to be shared across multiple clients, so they’re very likely to be statically configured, and in addition are likely to also be human-readable. 

Part of the power of XYZ is that these handles have the same model in both cases — the string is a reference to an object that could be passed by value as well. Flexibility in how these handles are created and 

> There needs to be some shared identifier in the protocol, would you not agree? For Registered Clients, the AS needs to have an identifier to look up the data it has for the Client. 
> 

I am proposing that the key information takes the place of the client ID for all kinds of clients. As discussed below, the key handle is not a key ID or a key hash — but more on that in a bit. What’s important is that it’s an identifier that the AS can look at and ask itself, “I’ve seen this ID, what authentication method and policy should I use for its requests?” This is the first step in an OAuth 2 AS implementation, where the AS sees the client ID and asks “what authentication method and policy should I use for this request?” This is why I see the key handle — and not a higher level construct like a client handle / client ID — as the component that you would branch your decisions off of at the AS. Once I’ve validated the key, whether by value or by reference, I now know which client I’m talking to. I don’t need a separate client identifier. I know that we don’t do it this way in OAuth 2, and I think that’s a limiting decision that we’ve gotten incorrect.

In the mental model of XYZ, the policy is then tied to whatever software that key represents, and since keys aren’t shared between clients, you get the property of a unique identification system as well. For dynamic clients, they don’t have to send an ID at all — they send the key itself by value, since the ID won’t reference anything that the AS knows about. So we have an identifier for the clients that want a stable reference, a method for passing values for clients that don’t have a stable reference, and a clear way to upgrade from passing by value to passing by reference for clients that want to do the equivalent of “Dynamic Registration”. There are a number of deployments where DynReg is used :just: to give clients in the field a client ID because OAuth 2 requires a client ID, and there’s a key that’s recognized during the DynReg process. But if the server can recognize my key, I ask: why not just start there when you do the request? You can’t in OAuth 2 because of the redirect-first model and keys don’t even show up there. You can in TxAuth because the model allows the client to talk to the AS directly first, and present its keys. 

I’ll again say that this is a pattern that’s applicable across all of the different “handles” within the XYZ protocol. I propose that you could bootstrap an AS-initiated and RS-first protocol by having another component create a transaction handle to kick things off. As discussed below, resource handles can be static or dynamic as well. 

And it’s really important to know that handles do not need to match or be derived from the information that they represent. XYZ intentionally does not tie these together tightly. A key, like a JWK or certificate, is going to have its own internal identifier, and there’s nothing that says the key ID needs to be equal to that or rotate with that. But what if the AS wants to use a key hash as the key handle? That’s not required (or even suggested) in XYZ either -- but if it does, then that’s something that both the client and AS need to update. The AS will need to update its key reference, which means it will update its key hash, which means it will recognize the new key hash and tie it to the client record automatically. The client will need to update its key and send a new hash as its key handle to the AS. However, clients shouldn’t be expected to create a hash on their own — it should update its key with the AS, and the AS should issue a key handle in response. Whether the AS creates that handle using a hash or not is not up to the client. 

> I mistyped, I intended to say key fingerprint, which obviously changes when the key is rotated.
> 
> I reread the XYZ Key Handle section ... and you are suggesting it represents the Client instance, but it is not clear how the AS maps that to preregistered client information.

Right, the key handle doesn’t need to rotate when the key itself is rotated — see the discussion above.

> To clarify, your proposal is that the public key, or a fingerprint of it, is what the AS uses to look up a preregistered Client?

No, my proposal is that a public key is what the AS uses to recognize a preregistered client, and that public key can be represented by a handle. I would expect the handle to be stable over time, like a client ID, but more specific. 

In OAuth 2, the client ID wraps together all of the different aspects of the client and its associated policies. In XYZ, I sought to separate those into different handles because, as we’ve found in OAuth 2, different parts of the client system can vary over time. Our notion of what a “client” is in OAuth 2 is also pretty vague. We have developers all over the place sharing client IDs between different web servers (production and development environments, for example), different instances of software (mobile applications, SPAs, and “public” clients), and different pieces of software altogether (micro-components that are tied together in a single pseudo-app). And we also have the explosion of Client IDs for apps using DynReg for things like ephemeral instances that get used once and then stop existing. 

> I'm looking for a use case where the AS needs to select from a list, rather than use the one mechanism that the Client wants to use. Why the extra negotiation?

The AS isn’t selecting a single value from the list. It’s responding to what the client wants to use, and it could respond to all of them. If the client wants to use one mechanism, it sends only one mechanism. XYZ enables all of the functions of XAuth’s interaction methods, and then some.

> I got that. I thought being more crisp in the interaction makes it easier for implementors to understand. 

I don’t think it’s more crisp, I think it’s more limiting, and it leads to more confusing code paths. Having implemented both styles in XYZ in several languages, I vastly prefer the current XYZ style. 

When you have the “type” field, you then have to specify what different responses mean in the context of different types, like what XAuth does in §4.2. In XYZ, the response fields have a single meaning, and the client does what it can with them. I think it’s presumptuous to assume “qrcode” as a scannable format, for instance. Does the AS actually care how the client communicates the URL to the user? Not really. Even if we were to optimize this for the client and have the AS return an image instead of a URL, I think the AS should be able to return an arbitrary image for the client to display to the user. 

> We can scratch this concern from the list then. Yeah!

Well, kind of — XAuth doesn’t allow the combination of an API-specified element (a scope, a simple string value) and a more fine grained access request. I believe this kind of combination is going to be essential for transition from OAuth2. XYZ manages things differently by putting the “scope” like values (resource handles) at the same level and in the same array structure as the RAR-style complex values. This way, I can ask for access to access to a legacy API and a fine-grained request at the same time, and get an access token that is good for both. A “resource handle” is a “scope”, since an OAuth 2 scope represents some bundle of rights and/or information that the client is requesting, represented as a simple string. These can be defined statically by the API (or the AS) and configured manually in the client. Why not call it a “scope” then? Because they can *also* be dynamically given to the client during the XYZ process. 

RAR also enables this in OAuth2, but does so using the existing “scope” field with its existing syntax and semantics. This is a little bit more problematic because they exist at different levels of the request, but defining clear combination semantics is one of the things that RAR needs to do, and to get right.

I do not see a way to do this combination with XAuth’s model, and that seems to be a deliberate decision, which I find unnecessarily limiting. 

> Yes. I think freedom from having to make a choice makes things easier to implement and deploy. 
> For deployments where another mechanism will be significantly better, the choice is available. ‘

These statements contradict each other. Are you advocating for “freedom from choice” or that the “choice is available” for this particular feature? I am arguing in favor of making choice available in the case of key presentation and removing choice in terms of request format (as in, the core payload). 

> 
> Is there something about JOSE that you think is problematic to make it the default?

Yes, it leads to reliance on putting everything of note in the JOSE payload as part of the base protocol. As explained previously, I want to be able to use HTTP as more than an entity body carrier. We should be using headers and methods and URLs — and importantly, content types. I think JOSE should be switched with things like Content-Type headers and Accept headers, and that JSON bodies should be the default as they’re more universal across different signing and presentation mechanisms. 

My Java XYZ implementation does use JOSE, but by using JWS in a detached fashion to sign the body instead of an internal fashion. The reason for this is that it allows the request and response to be “application/json” and not “application/jws”. 

In all of these cases, I do not think it is a good idea to use JWT claims in the TxAuth request or response namespaces. Where we use JOSE, we should avoid JWT.

> I was not ignoring it. When it is done, an extension can be written on how to use HTTP Signing. Or the extension could be developed at the same time.
> 

The means of using HTTP Signing in TxAuth are already pretty clear, and I’ve implemented it in XYZ based on the existing Cavage draft that is being used as input to the HTTP WG.

> Moving AWS to HTTP Sig is very, very unlikely, having worked there. Having an easy path to utilize XAuth / TxAuth is a good goal for the resulting work.

I still agree that they should be able to easily use TxAuth, which just a stronger argument for the signature/proofing mechanism to be a pluggable thing and that the request/response bodies not be JOSE objects but JSON objects.

> The word transaction is muddying what I think you are suggesting here. It more like a conversation. Transactions from a DB point of view are a set of actions that all happen, or none happen.

I’ve explained previously that the database interpretation is not the only or full interpretation of the word “transaction” here, so I won’t go back into it. Conversation is perhaps more accurate, but “CxAuth” is a problematic acronym. :-D

> They have different purposes. The completion (now authorization) handle is to check if the AS is done with its request processing, and if so, provide the results, which includes zero or more identity claims, and zero or more access tokens/handles.
> 

I don’t see these as being different, and that’s where we disagree. The access token is the end result of the processing. Refreshing is an act of continuing that processing. I do not see a good argument for treating them separately. 

> It is a feature of XAuth. 

Kind of. XAuth allows multiple access tokens in one limited context, and only when using rich authorization requests to do so. I would rather see us have a general mechanism that allows us to get multiple access tokens in a way that’s parallel to how you get one access token.

> 
> In OAuth today, the bearer token is like a movie ticket. Whoever has the movie ticket gets in the movie.
> Sometimes I want to go to more than one movie. OAuth today makes me wait in line to buy each ticket. Why not let me buy multiple tickets at once?

That’s not true. You can get one ticket that’s good for two movies, to borrow your metaphor. 

The semantics of requesting multiple access tokens in parallel is something the working group might want to consider. I am not a fan of how XAuth handles this, with packing things into the authorization list. I think it’s a concept we should consider though.

> Is "step-up auth" authentication or authorization, ... or both?

I think the question you asked is unintentionally misleading because “step up” authentication could be seen from the client or the AS’s perspective. 

The “step up” that I mean here is from the client’s perspective, not from the AS/IdP’s perspective. The client wants more of something — more access to an API, more user information, etc. It’s likely that the AS is going to want to interact with the user to include whatever additional access the client is asking for, but the client doesn’t want to start from scratch. You’ve got a ticket that’s good to see one movie, and you want to add another movie to it for after. The theater already knows who you are and how to get your money, so they can just add it on.

It’s entirely feasible that the process of asking for more information would prompt the AS to re-authenticate the user, including prompting them for additional credentials. However, from the client’s view, that’s a side-effect of its request.

> They are related though. If you are not wanting to ask for consent on each delivery, how do you know you have consent?

We are talking past each other. They’re related in the sense that they’re both a part of the authorization process, but consenting to the release of information and the delivery of that information are completely separate from each other. 

Consent is not the client’s policy, that’s the AS’s policy. My consent is stored on the AS. The client can't know if this is the “first” time or not because it doesn’t know who I am yet, so it can’t ask if I should consent again. If the client knows who I am, it doesn’t need to ask the AS to log me in in the first place. 

However, once I’m interacting with the AS, the AS has a chance of figuring things out. The AS can determine if it’s seen the same client before, if it’s seen the same user before, and if the same client is making the same request for the same user, and the AS knows that it can make that decision without prompting the user. We already do exactly this today with OAuth 2 and OIDC systems. 

But the AS does :not: know which profile and identity claims the client actually :needs:. The only party able to make that decision is the client, and it can only make that decision once it has a reference to which user is there (in terms of an identifier). The AS can (and I argue should) give the client some kind of key for helping make that decision. 

The push of user information into an OAuth-protected API, and separating it from the authentication context, is one of the best parts of OpenID Connect. Yes, the client can always request the user info as long as it has the access token — and to me that’s a feature, because the client is the component that knows when it needs updated info. 

> I literally just called it that in the sentence above, so yes. :) What you’re discovering is different though. And doesn’t the client still need to “discover” the discovery endpoint in XAuth?

The charter currently includes “AS discovery”, per your request to add it. To me, and I would argue to most, “discovery” is a programmatic process. If it’s manual, it’s not really the client “discovering” anything, it’s being told things manually by a developer. That’s not discovery as the term is generally known, and I think this is a key source of confusion here. There is no “discovery” that’s not programmatic — that’s configuration.

> Aaah now I see where we don't have common understanding ... that is not the XAuth approach at all. 
> 
>  In other words, here is some information the Client will need. You will need to manually configure it, or there may be an option to obtain some or all of the information you need programatically. The programatic discovery is out of scope.
> 

Yes, if you mean manual configuration of elements, then that’s not discovery as the term is going to be understood by most.

> Most existing Clients are manually configured. The developer reads the AS documentation to learn what scopes and claims the AS supports, and then codes that into the Client. The XYZ approach above does not take that into account, and is in conflict with what you have below. 
> 

It does take it into account — all of that can happen manually in XYZ. The developer can hard-code the tx endpoint, scopes, keys, and everything else. The developer can hard code handles to represent all of those that they’ve gotten through pre-registration. Or it can happen dynamically using the same mechanisms within the protocol. There’s not a conflict.

> In XAuth, I'm calling that out as a step, so the developer understands where that comes from. You effectively are saying the same thing below, so it is unclear what your concern with XAuth is.
> 

In XYZ, the only value the client absolutely MUST know about is the tx endpoint. Discovery is not ignored, it’s trivial. And what you’re calling “Discovery” is manual/static configuration, which is definitely covered. This can perhaps be made more clear, but it’s in there.

> Because you were not supportive of the discovery step in XAuth? And you made no mention of static configuration in your description, contrary to XAuth?  Hence me asking a probing question to get clarity. 
> 

As stated in the intro to this email, static configuration was always part of XYZ’s model. And as stated above, “discovery” fully implies it being programmatic. I don’t believe there’s a conflict in the way that you’re suggesting.

> Interpersonal communication hint:  when you have no idea on why someone is asking a clarifying question, ask yourself what might have been unclear in your communication. Then just answer the clarifying question. 
>  
> 
> XAuth documents what information is required, and that it can be pre-configured. 

XYZ does the same, so I think we agree that this is an important aspect of TxAuth.

>  
> Where in XYZ is the negotiation after the TX request? Sounds interesting, but I did not see it.

It’s not “after” so much as “part of” the request/response. “Negotiation” is a slippery word, as it often implies a back-and-forth multi-round process. I think that’s a problematic and complicated pattern. What I do think is useful is a single-trip, where the client starts things by declaring what it knows and can do, and the server responds with something that it can do that it now knows the client can do. TLS algorithm negotiation and HTTP content negotiation both work this way, and do so successfully without a complicated protocol.

If the client has been preconfigured to only ask for things the server can do, and if the client is configured to ask for only a single option, then it’s identical to the case where everything is static and making a single choice.

---

From: Justin Richer <[email-masked]>
Date: Fri, 31 Jan 2020 13:38:01 +0100

> Part of the power of XYZ is that these handles have the same model in both cases — the string is a reference to an object that could be passed by value as well. Flexibility in how these handles are…

… used is one of the benefits of XYZ’s model. Handles are opaque and AS-determined. The AS can make these in response to a runtime action or a configuration/development time action. They can be random, they can be hashes, they can even be structured (though in most cases that doesn’t make sense because you could just send the structured object instead). In all cases, they’re serializable as a string and represent an object that could have been passed by value in their stead. The object that the handle represents can change without changing the handle. Two different handles could resolve to the same underlying object. Only the AS determines what the handle maps to, in reality. 

 — Justin

---

From: Dick Hardt <[email-masked]>
Date: Fri, 31 Jan 2020 12:33:55 -0800

Your statement below:

Handles are opaque and AS-determined.

Is not stated in XYZ, and seems in conflict with XYZ where some handles are
SHA3:

9.1 <https://tools.ietf.org/html/draft-richer-transactional-authz-04#section-9.1>.
Presenting handles

   Bearer handles are presented by giving the exact string value of the
   handle in the appropriate place.

   SHA3 handles are validated by taking the SHA3 hash of the handle
   value and encoding it in Base64URL with no padding, and presenting
   the encoded value.

9.2 <https://tools.ietf.org/html/draft-richer-transactional-authz-04#section-9.2>.
Validating handles

   Bearer handles are validated by doing an exact byte comparison of the
   string representation of the handle value.

   SHA3 handles are validated by taking the SHA3 hash of the handle
   value and encoding it in Base64URL with no padding, and comparing
   that using an exact byte comparison with the presented value.

Or are you saying the RC does not present the handle back, but presents
back a SHA3 hash of the handle?

I don't understand what value there is in doing the hash, as it is a
reference to something in the AS, and the RC is always authenticating when
presenting them.
ᐧ

On Fri, Jan 31, 2020 at 4:38 AM Justin Richer <[email-masked]> wrote:

> Part of the power of XYZ is that these handles have the same model in both
> cases — the string is a reference to an object that could be passed by
> value as well. Flexibility in how these handles are created and
>
>
>
> … used is one of the benefits of XYZ’s model. Handles are opaque and
> AS-determined. The AS can make these in response to a runtime action or a
> configuration/development time action. They can be random, they can be
> hashes, they can even be structured (though in most cases that doesn’t make
> sense because you could just send the structured object instead). In all
> cases, they’re serializable as a string and represent an object that could
> have been passed by value in their stead. The object that the handle
> represents can change without changing the handle. Two different handles
> could resolve to the same underlying object. Only the AS determines what
> the handle maps to, in reality.
>
>  — Justin
> --
> Txauth mailing list
> [email-masked]

---

From: Dick Hardt <[email-masked]>
Date: Fri, 31 Jan 2020 14:28:48 -0800

On Fri, Jan 31, 2020 at 3:22 AM Justin Richer <[email-masked]> wrote:

>>> I think XAuth has an interesting take on the problem space that TxAuth
>>> is looking to solve, but in my opinion it generally veers too closely to
>>> 1. XAuth removes “handles” as stand-ins for various elements. In XYZ,
>>> the “handle” concept is a key abstraction point with specific semantics. A
>> I think this may be that you misunderstood the purposes of the handles,
>> as you’ve reinvented nearly all of them with different labels in XAuth. :)
>>
>
> I think what you’re missing is that the dynamically generated handles are
> not the only handles in the system.
>

I did not understand that handles could be generated by the AS and hand
configured, and had missed the sentence in Section 2 for each object that
the RC can present a handle instead.

The Client ID in most deployments is a handle by this definition. The AS
generates it, and the Client presents it in future calls to represent all
the Client information.

My assumption is you did not want to call them identifiers, as you want to
use the term handle everywhere, and make dynamic handles and static handles
interchangeable. Correct?

It is unclear what value a dynamic display, resource, user, or key handle
has for a given transaction, as the information is all represented by your
transaction handle.

Static handles, and reusing a dynamic handle in a subsequent request allows
a developer to pass by reference rather than value, but it is not clear
what real benefit that provides over just passing the value.

The transaction handle is different as it represents all the context the AS
has for the transaction, which the Client does not have access to. All the
other handles seem like they are just shorter version, and are more of an
identifier.

> I am proposing that the key information takes the place of the client ID
> for all kinds of clients. As discussed below, the key handle is not a key
> ID or a key hash — but more on that in a bit. What’s important is that it’s
> an identifier that the AS can look at and ask itself, “I’ve seen this ID,
> what authentication method and policy should I use for its requests?” This
> is the first step in an OAuth 2 AS implementation, where the AS sees the
> client ID and asks “what authentication method and policy should I use for
> this request?” This is why I see the key handle — and not a higher level
> construct like a client handle / client ID — as the component that you
> would branch your decisions off of at the AS. Once I’ve validated the key,
> whether by value or by reference, I now know which client I’m talking to. I
> don’t need a separate client identifier.
>

Got it.

So far the Client ID and the key handle look to me to be the same for
Registered Clients. What is the information referenced by a Client ID at
the AS, that would NOT be referenced by a key handle?

> I know that we don’t do it this way in OAuth 2, and I think that’s a
> limiting decision that we’ve gotten incorrect.
>

Use cases that are limited by that decision would help understand why you
think it was incorrect.

>
> In the mental model of XYZ, the policy is then tied to whatever software
> that key represents, and since keys aren’t shared between clients, you get
> the property of a unique identification system as well. For dynamic
> clients, they don’t have to send an ID at all — they send the key itself by
> value, since the ID won’t reference anything that the AS knows about.
>
So we have an identifier for the clients that want a stable reference, a
> method for passing values for clients that don’t have a stable reference,
> and a clear way to upgrade from passing by value to passing by reference
> for clients that want to do the equivalent of “Dynamic Registration”. There
> are a number of deployments where DynReg is used :just: to give clients in
> the field a client ID because OAuth 2 requires a client ID, and there’s a
> key that’s recognized during the DynReg process. But if the server can
> recognize my key, I ask: why not just start there when you do the request?
> You can’t in OAuth 2 because of the redirect-first model and keys don’t
> even show up there. You can in TxAuth because the model allows the client
> to talk to the AS directly first, and present its keys.
>

So calling it a key handle lets you call it the same thing for both
Registered Clients and Dynamic Clients? The advantage to a Dynamic Client
is that it can present a reference instead of its public key again on
subsequent calls? Is there another advantage?

The AS could also compute a fingerprint of the Dynamic Client key and use
that as its ephemeral identifier for the Dynamic Client.

> And it’s really important to know that handles do not need to match or be
> derived from the information that they represent.
>

Yes. I understand what a handle is. =)

>
> No, my proposal is that a public key is what the AS uses to recognize a
> preregistered client, and that public key can be represented by a handle. I
> would expect the handle to be stable over time, like a client ID, but more
> specific.
>

Which public key?  XAuth describes how different instances of a Registered
Client can have their own private key, so the matching public key is
different for each Client instance. The Client can have a certificate
signed by a private key matching the public key registered for the Client
at the As.

>
> In OAuth 2, the client ID wraps together all of the different aspects of
> the client and its associated policies. In XYZ, I sought to separate those
> into different handles because, as we’ve found in OAuth 2, different parts
> of the client system can vary over time. Our notion of what a “client” is
> in OAuth 2 is also pretty vague. We have developers all over the place
> sharing client IDs between different web servers (production and
> development environments, for example), different instances of software
> (mobile applications, SPAs, and “public” clients), and different pieces of
> software altogether (micro-components that are tied together in a single
> pseudo-app).
>

I don't think it is vague. The "client" is not a specific piece of
software. From the User or RS's perspective, it is the "service" that was
provided the identity claims and/or authorization. They don't want to have
to re-authorize as they move between a mobile client, a desktop client, or
a web client for the same service.

What is clearly problematic is sharing the client secret across all of
these places. Implementations I have worked on have centralized the client
secret in one place, and then handed out the access token to the software
component for it to directly call the RS.

As I discussed above, certificates let a complex Client have each component
independently make calls to the AS.

> And we also have the explosion of Client IDs for apps using DynReg for
> things like ephemeral instances that get used once and then stop existing.
>

As we have discussed, Client IDs for Dynamic Clients is problematic. The
only information an AS has about a Dynamic Client is what it has done with
the Client previously. Note that a mobile app can be a Dynamic Client, and
have a long lifetime.

> I'm looking for a use case where the AS needs to select from a list,
> rather than use the one mechanism that the Client wants to use. Why the
> extra negotiation?
>
>
> The AS isn’t selecting a single value from the list. It’s responding to
> what the client wants to use, and it could respond to all of them. If the
> client wants to use one mechanism, it sends only one mechanism. XYZ enables
> all of the functions of XAuth’s interaction methods, and then some.
>

I understand how it works, and that it is more powerful. It is also more
complex. What does practical value does this provide an implementor?

> I don’t think it’s more crisp, I think it’s more limiting, and it leads to
> more confusing code paths. Having implemented both styles in XYZ in several
> languages, I vastly prefer the current XYZ style.
>

It is more crisp. And it is more limiting, and I think it leads to simpler
code paths.

>
> When you have the “type” field, you then have to specify what different
> responses mean in the context of different types, like what XAuth does in
> §4.2. In XYZ, the response fields have a single meaning, and the client
> does what it can with them. I think it’s presumptuous to assume “qrcode” as
> a scannable format, for instance.
>

A QR Code is a scannable format by definition.

> Does the AS actually care how the client communicates the URL to the user?
> Not really.
>

As I noted in XAuth, the AS does care. While a really long URL works fine
in a redirect or popup, it does not work in a QR code. The AS can return a
short URL for the QR code that redirects to the long URL. The AS does not
want to impose the redirect latency on the redirect or popup.

> Even if we were to optimize this for the client and have the AS return an
> image instead of a URL, I think the AS should be able to return an
> arbitrary image for the client to display to the user.
>

In XAuth I asked if we wanted to allow the Client to over a webview for the
AS to load whatever it wants.

Additionally, since we are designing all of this to be extensible, if
another use case comes up with a different interaction method, we can just
add a new type.

>>> 4. XAuth allows OAuth-style scopes next to RAR-style data structures
>>> (and next to OIDC claims structures). They are treated as completely
>>> separate from each other. In OAuth 2, RAR is defined in the context of
>>> scope (and resource and audience and other parameters), and this
>>> combination is a matter of some debate still that needs to be solved.
>>> However, it’s clear that they’re combined. In XYZ, the only resource
>>> request defined is the object inside the resource request. You can mimic
>>> “scope” behavior by using a Resource Handle, which again is defined as a
>>> single string that stands in for the whole object and could be defined by
>>> the AS (or the API it’s protecting).
>>>
>>
>> - list of RAR style for deployments that support multiple resource
>> servers that require independent access tokens.
>>
>>
>>>
> Well, kind of — XAuth doesn’t allow the combination of an API-specified
> element (a scope, a simple string value) and a more fine grained access
> request.
>

I don't think you went back to reread -00. The oauth-rich type includes a
scope, and an authorizations_details.

I made that change as it was not clear when I looked at RAR (which is still
developing) that it did not include the scope.

> choice is available. ‘
> These statements contradict each other. Are you advocating for “freedom
> from choice” or that the “choice is available” for this particular feature?
> I am arguing in favor of making choice available in the case of key
> presentation and removing choice in terms of request format (as in, the
> core payload).
>

Freedom from choice: if I don't want to have to make a choice, the choice
is made. These are frequently called defaults. They have proven useful. =)

Stated another way: here is what you do unless you have a good reason to do
something else.

While I think JOSE is a better default, I'm open to another method being a
default. I do strongly think there should be a default.

> Yes, it leads to reliance on putting everything of note in the JOSE
> payload as part of the base protocol.
>

In XAuth, I factored out all the JOSE. Once again, have you read -00, or
-01?

https://tools.ietf.org/html/draft-hardt-xauth-protocol-00#section-3

All payloads are JSON. The JOSE section describes how to use JOSE for
message and header signing.

https://tools.ietf.org/html/draft-hardt-xauth-protocol-00#section-8

> As explained previously, I want to be able to use HTTP as more than an
> entity body carrier. We should be using headers and methods and URLs — and
> importantly, content types.
>

I agree.

XAuth uses POST, GET and DELETE

It uses the Authorization header and different parameters to indicate the
type of token.
It uses content type to indicate what the content type is. This will assist
an AS that supports multiple Client authentication methods

> I think JOSE should be switched with things like Content-Type headers and
> Accept headers, and that JSON bodies should be the default as they’re more
> universal across different signing and presentation mechanisms.
>
> My Java XYZ implementation does use JOSE, but by using JWS in a detached
> fashion to sign the body instead of an internal fashion. The reason for
> this is that it allows the request and response to be “application/json”
> and not “application/jws”.
>

Detached signatures work, but I have found them to be problematic in
practice, which is why I chose "application/jws". There is no canonical
form for JSON, so it can get modified, and still be valid JSON, but the
signature does not match. Passing around the signature independent of the
payload is more complex.

A JWS can be easily passed between components and is self contained, with
no worries that the JSON was modified by parsing and re-serializing it.

>
> In all of these cases, I do not think it is a good idea to use JWT claims
> in the TxAuth request or response namespaces. Where we use JOSE, we should
> avoid JWT.
>

I agree. JWT is good for claims. Not so good messages.

>
> I still agree that they should be able to easily use TxAuth, which just a
> stronger argument for the signature/proofing mechanism to be a pluggable
> thing and that the request/response bodies not be JOSE objects but JSON
> objects.
>

We discussed this in early drafts, and XAuth is JSON, with JOSE added on.

> I’ve explained previously that the database interpretation is not the only
> or full interpretation of the word “transaction” here, so I won’t go back
> into it. Conversation is perhaps more accurate, but “CxAuth” is a
> problematic acronym. :-D
>

Naming is hard. =)

> I don’t see these as being different, and that’s where we disagree. The
> access token is the end result of the processing. Refreshing is an act of
> continuing that processing. I do not see a good argument for treating them
> separately.
>

Developers are already familiar with refreshing a token

> Kind of. XAuth allows multiple access tokens in one limited context, and
> only when using rich authorization requests to do so.
>

Given that existing implementations using scopes only support one access
token, it did not seem limiting to only have a oauth_rich_list,
particularly since a RAR request is a superset of functionality of a scope
request.

> I would rather see us have a general mechanism that allows us to get
> multiple access tokens in a way that’s parallel to how you get one access
> token.
>

A general mechanism sounds fine and dandy. Currently we don't have other
ways to request authorization except for oauth scopes and RAR, which is a
super set of RAR. If and when we need a more general mechanism, we could
define a new type.

> Sometimes I want to go to more than one movie. OAuth today makes me wait
> in line to buy each ticket. Why not let me buy multiple tickets at once?
>
>

Which is all you can do in OAuth today. Get one ticket.

>
> The semantics of requesting multiple access tokens in parallel is
> something the working group might want to consider. I am not a fan of how
> XAuth handles this, with packing things into the authorization list. I
> think it’s a concept we should consider though.
>

If you have other ideas, please share them!

To elaborate on my metaphor.

A family is going to the movies. The Father (one component of the family),
is going to purchase tickets. Billy (age 8) can pick from the G rated
movies. Sally (age 15) can pick from G, PG, and PG-13 movies, and Father
can pick anything.

Father does not want to buy 3 tickets that are identical and can work for
any movie. (effectively what an access token is today) He only wants them
to go to a movie he has approved, at the time he has selected.

Father wants to buy 3 different tickets, and give the appropriate ticket to
each child.

The metaphor breaks down here, but each child needs to be able to refresh
their ticket independent of the other's, which is why a refresh handle is
required. The transaction handle is not granular enough.

> I think the question you asked is unintentionally misleading because “step
> up” authentication could be seen from the client or the AS’s perspective.
>

Well, your statement was unclear as "auth" can be one or the other! From
below, you intended authorization.

>
> The “step up” that I mean here is from the client’s perspective, not from
> the AS/IdP’s perspective. The client wants more of something — more access
> to an API, more user information, etc. It’s likely that the AS is going to
> want to interact with the user to include whatever additional access the
> client is asking for, but the client doesn’t want to start from scratch.
> You’ve got a ticket that’s good to see one movie, and you want to add
> another movie to it for after. The theater already knows who you are and
> how to get your money, so they can just add it on.
>
> It’s entirely feasible that the process of asking for more information
> would prompt the AS to re-authenticate the user, including prompting them
> for additional credentials. However, from the client’s view, that’s a
> side-effect of its request.
>

The step-up authentication is a policy decision independent of the Client.
The User is having to provide additional authorization.

> We are talking past each other. They’re related in the sense that they’re
> both a part of the authorization process, but consenting to the release of
> information and the delivery of that information are completely separate
> from each other.
>

Consent is required to release the information. That is how they are
related.

>
> Consent is not the client’s policy, that’s the AS’s policy. My consent is
> stored on the AS.
>

Maybe. Maybe not.

> The client can't know if this is the “first” time or not because it
> doesn’t know who I am yet, so it can’t ask if I should consent again. If
> the client knows who I am, it doesn’t need to ask the AS to log me in in
> the first place.
>

Did you spend anytime looking at my "authentication first" proposal in -01?

The Client asks the AS to authenticate the User, and send that result, then
the Client can decide what, if anything it wants to request for that User.
The AS no longer needs to maintain state.

>
> However, once I’m interacting with the AS, the AS has a chance of figuring
> things out. The AS can determine if it’s seen the same client before, if
> it’s seen the same user before, and if the same client is making the same
> request for the same user, and the AS knows that it can make that decision
> without prompting the user. We already do exactly this today with OAuth 2
> and OIDC systems.
>

Sometimes. Sometimes not. The specifications are mute on saving state.

>
> But the AS does :not: know which profile and identity claims the client
> actually :needs:. The only party able to make that decision is the client,
> and it can only make that decision once it has a reference to which user is
> there (in terms of an identifier). The AS can (and I argue should) give the
> client some kind of key for helping make that decision.
>
> The push of user information into an OAuth-protected API, and separating
> it from the authentication context, is one of the best parts of OpenID
> Connect. Yes, the client can always request the user info as long as it has
> the access token — and to me that’s a feature, because the client is the
> component that knows when it needs updated info.
>

This is where consent and delivery are related. If the user info has been
updated, has the User provided consent for the Client to receive it? The AS
is the endpoint that can interact with the user, not the UserInfo endpoint.

Why not just go back to the AS and ask for the data again. If consent is
not required, the AS returns the data. If consent is required, the AS can
interact with the User to get it.

The UserInfo endpoint seems redundant if the Client can get the claims from
the AS.

>>> 11. XAuth defines an explicit discovery step because the client now
>>> needs to know several things about the server. The mix-up attack and a few
>>> other attacks in OAuth 2 stem from this kind of process. In XYZ, the client
> The charter currently includes “AS discovery”, per your request to add it.
> To me, and I would argue to most, “discovery” is a programmatic process. If
> it’s manual, it’s not really the client “discovering” anything, it’s being
> told things manually by a developer. That’s not discovery as the term is
> generally known, and I think this is a key source of confusion here. There
> is no “discovery” that’s not programmatic — that’s configuration.
>

I think of discovery is going to the AS and learning what it can do --
since discovery is learning. That can be the developer going to the AS docs
and reading, or the Client calling a discovery API.

After manual discovery, the developer decides how to manually configure the
Client, based on what was discovered when reading the documentation.

I have found it useful to call out the manual discovery so that
implementors know where the information comes from. IE it is not in the
specification.

ᐧ