Subject: Re: [Txauth] XYZ vs XAuth - 5 differences

From: Mike Jones <[email-masked]>
Date: Tue, 24 Mar 2020 18:54:16 +0000

Justin, if you want to take the identity claims reuse argument off the table, publish a new draft of draft-richer-transactional-authz in which you add something like this language to the Claims section at https://tools.ietf.org/html/draft-richer-transactional-authz-06#section-2.7:

The requested claim names here and those in the corresponding response are intended to come from the IANA “JSON Web Token Claims” Registry [IANA.JWT.Claims].  Where this specification defines new claims, it registers them in this registry.

And then populate the IANA Considerations section of the new draft to register new claims that the document uses that are not already registered, such as “subject”.

I’ll be watching to see whether you do this as a statement of intent to reuse of existing identity claims or whether you choose not to.

                                                       Best wishes,
                                                       -- Mike

P.S.  The IANA JWT Claims Registry [IANA.JWT.Claims] is of course at https://www.iana.org/assignments/jwt/.

From: Justin Richer <[email-masked]>
Sent: Tuesday, March 24, 2020 7:48 AM
To: Mike Jones <[email-masked]>
Cc: [email-masked]; Dick Hardt <[email-masked]>
Subject: Re: [Txauth] XYZ vs XAuth - 5 differences

Two quick notes I missed:

On Mar 24, 2020, at 9:41 AM, Justin Richer <[email-masked]<mailto:[email-masked]>> wrote:

I mentioned this on the call yesterday, but this is an incredibly weak argument to pick one draft over another, especially at such an early stage. I would consider everything XYZ malleable, especially what the fields get named. It’s short sighted to throw out an entire specification because of the names of fields that were added very recently to the draft.

In other words, I think it’s too early to judge based on things like this, and it shows blindness to the rest of the draft. It’s true that Dick and I have taken a very different approach to re-use, but both have re-use.  XYZ does re-use many elements from OAuth 2, OIDC, and XYZ, but they’ve been translated into a system that’s internally consistent in a way that the source material is not. Dick has said several times that “XYZ doesn’t use OAuth 2 scopes” which is blatantly

One correction — I meant to say “OAuth 2, OIDC, and others like UMA,”. :)

not true — we designed the system explicitly so that you could do that. However, we didn’t just put in a field labeled “oauth_scopes” because, as we’ve found in defining RAR in OAuth 2, it gets complicated quickly trying to combine them if you have different layers of semantics within the protocol. XYZ puts the scope style requests at the same level as the rich requests.

So let’s say you wanted to do a full mapping of an OIDC request, just swapping out OAuth 2 for XYZ, it’d look something like this:

{
  "keys": "client-id-1234556",
  "resources": ["openid", "profile", "email", "phone", "address"],
  "claims": { "oidc_id_token": true },
  "interact": {
              "redirect": true,
              "callaback": {
                           "url": "https://client.example/redirect_uri",
                           "nonce": "1233455"
              }
  }
}

This would get you back an OIDC id token and access token with the OIDC scopes tied to the server’s UserInfo Endpoint. But as I’ve been saying, I don’t think it’s within the purview of this working group to define that level of detail. What we should do is define what the “resources” field means, what the “claims” field means, and put a few buckets in there for common identifiers and assertions so that people do things the same way. And I’ll repeat that I would personally prefer the simple identity mapping layer be in a separate document from the core delegation protocol — but that’s a matter for the WG to decide.

I’ll also repeat my argument that I don’t think we should just blindly re-use OIDC’s names for things, but that is not me saying that we should, of necessity, invent new things entirely "just because”. Every choice we make, including what we name fields, needs to have a good reason.

And if the WG does end up creating new names for some things? That’s not the end of the world. When we were working on OIDC, there was an opportunity to re-use field names from LDAP (specifically, to use inetOrgPerson and/or eduOrgPerson as the schema), but as you (Mike) know, we decided not to, and the world is OK for that even though it meant people had to write a simple translator when wrapping their LDAP servers with OIDC capabilities (and complained about it at the time).

Re-use does not just mean copying. It means examining what is there and pulling the best from it — and that is going to include sources beyond OAuth2 and OIDC. At this point we should be looking at what features we like from the entire ecosystem, including the two proposed drafts, and decide what we want to bring forward into TxAuth. And in terms of flexibility, stability, simplicity, and consistency, I believe that XYZ makes a much stronger base for building on.

And an addition — if you want to just keep using OAuth 2 and back port functionality to OAuth2 in a compatible way, that work should be done in the OAuth 2 working group. Here, we’re trying to move forward, not just rest on what’s been done. That’s not an argument to invent everything from whole cloth, it’s an argument to build things better wherever we can. I’m really glad to have the deep experience of so many participants feeding into this group for exactly that reason!

 — Justin

 — Justin

On Mar 23, 2020, at 3:53 PM, Mike Jones <[email-masked]<mailto:[email-masked]>> wrote:

I would prefer XAuth as a starting point over XYZ because XAuth is clearly trying to reuse existing identity representations, whereas XYZ is creating a new one.

You can see XAuth’s reuse, for instance, at https://tools.ietf.org/html/draft-hardt-xauth-protocol-06#section-4.6.6.

You can see XYZ’s invention of a new identity schema at https://tools.ietf.org/html/draft-richer-transactional-authz-06#section-2.7.  Yes, it’s similar to some others but not the same, and rather than reusing existing registered claims, it’s creating its own unique set.

                                                       -- Mike

From: Txauth <[email-masked]<mailto:[email-masked]>> On Behalf Of Dick Hardt
Sent: Friday, March 20, 2020 1:18 PM
To: [email-masked]<mailto:[email-masked]>
Cc: Justin Richer <[email-masked]<mailto:[email-masked]>>
Subject: [EXTERNAL] Re: [Txauth] XYZ vs XAuth - 5 differences

ACTION REMINDER

Please weigh in with your preference, your rationale, as well as any pros and cons not described.

Yaron and I were hopeful that we would get more feedback on these topics, as it would help determine if either the XYZ or XAuth documents are roughly aligned with the consensus direction of the group so that we have a starting document.

We will NOT be able to do hums in the BoF ... so we will not be able to use that to judge rough consensus.

/Dick

On Mon, Mar 16, 2020 at 4:04 PM Dick Hardt <[email-masked]<mailto:[email-masked]>> wrote:
Hello everyone

Justin and I have had some emails back and forth comparing and contrasting XYZ and XAuth. I'm going to post a message for each of the major points, with Justin's rationale and my rationale for our respective design decisions. Feel free to ask clarifying questions in those threads.

Please weigh in with your preference, your rationale, as well as any pros and cons not described.

We would like to get a sense for the group's views on these topics for the virtual BoF in a week.

The latest drafts are:

XYZ: https://tools.ietf.org/html/draft-richer-transactional-authz-06

XAuth: https://tools.ietf.org/html/draft-hardt-xauth-protocol-05

Thanks!

/Dick
ᐧ

--
Txauth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/txauth

---

From: Justin Richer <[email-masked]>
Date: Tue, 24 Mar 2020 16:13:53 -0400

My intent with a small portion of an individual draft is irrelevant, to be honest. It will be up to the working group to decide the source for all the syntactical elements of the protocol, and whether those will be managed by an existing registry or a new registry or  a semantic schema document or something else is all up for debate. Yes, that is all very important to decide-- But it’s not important to decide at this stage, and I would argue even premature to do so with no intent of possibly changing later.

I think you are taking the current state of one part of the I-D to mean too much. 

 — Justin

> On Mar 24, 2020, at 2:54 PM, Mike Jones <[email-masked]> wrote:
> 
> Justin, if you want to take the identity claims reuse argument off the table, publish a new draft of draft-richer-transactional-authz in which you add something like this language to the Claims section at https://tools.ietf.org/html/draft-richer-transactional-authz-06#section-2.7 <https://tools.ietf.org/html/draft-richer-transactional-authz-06#section-2.7>:
>  
> P.S.  The IANA JWT Claims Registry [IANA.JWT.Claims] is of course at https://www.iana.org/assignments/jwt/ <https://www.iana.org/assignments/jwt/>.
>  
> On Mar 24, 2020, at 9:41 AM, Justin Richer <[email-masked] <mailto:[email-masked]>> wrote:
>  
>                            "url": "https://client.example/redirect_uri <https://client.example/redirect_uri>",
>                            "nonce": "1233455"
>               }
>   }
> }
>  
> On Mar 23, 2020, at 3:53 PM, Mike Jones <[email-masked] <mailto:[email-masked]>> wrote:
>  
> You can see XAuth’s reuse, for instance, at https://tools.ietf.org/html/draft-hardt-xauth-protocol-06#section-4.6.6 <https://tools.ietf.org/html/draft-hardt-xauth-protocol-06#section-4.6.6>.
>  
> You can see XYZ’s invention of a new identity schema at https://tools.ietf.org/html/draft-richer-transactional-authz-06#section-2.7 <https://tools.ietf.org/html/draft-richer-transactional-authz-06#section-2.7>.  Yes, it’s similar to some others but not the same, and rather than reusing existing registered claims, it’s creating its own unique set.
>  
>                                                        -- Mike
>  
> From: Txauth <[email-masked] <mailto:[email-masked]>> On Behalf Of Dick Hardt
> To: [email-masked] <mailto:[email-masked]>
> Cc: Justin Richer <[email-masked] <mailto:[email-masked]>>
> On Mon, Mar 16, 2020 at 4:04 PM Dick Hardt <[email-masked] <mailto:[email-masked]>> wrote:
> Hello everyone
>  
> XYZ: https://tools.ietf.org/html/draft-richer-transactional-authz-06 <https://tools.ietf.org/html/draft-richer-transactional-authz-06>
>  
> XAuth: https://tools.ietf.org/html/draft-hardt-xauth-protocol-05 <https://tools.ietf.org/html/draft-hardt-xauth-protocol-05>
>  
> Thanks!
>  
> /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: Tue, 24 Mar 2020 16:50:22 -0400

OK, so — I’m not comfortable pointing to a specific external registry for this kind of thing in the draft (unless we’re directly using it), but in fact I didn’t really point to ANY registry in the draft at this point for a lot of things that will probably ultimately have registries. I can add language to the various extensible sections (such as the claims request and claims response) that point to a “future TBD registry” for the set of fields. That’s a fairly small text change that I hope will help us move forward.

 — Justin

> On Mar 24, 2020, at 4:13 PM, Justin Richer <[email-masked]> wrote:
> 
>> On Mar 24, 2020, at 2:54 PM, Mike Jones <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> From: Justin Richer <[email-masked] <mailto:[email-masked]>> 
>> To: Mike Jones <[email-masked] <mailto:[email-masked]>>
>> Cc: [email-masked] <mailto:[email-masked]>; Dick Hardt <[email-masked] <mailto:[email-masked]>>
> [email-masked]