Subject: [Txauth] XYZ vs XAuth - 5 differences

From: Dick Hardt <[email-masked]>
Date: Mon, 16 Mar 2020 16:04:33 -0700

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
ᐧ

---

From: Dick Hardt <[email-masked]>
Date: Fri, 20 Mar 2020 13:18:29 -0700

ACTION REMINDER

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

---

From: Vijay IETF <[email-masked]>
Date: Sat, 21 Mar 2020 03:20:03 +0530

Hi Dick,

Super helpful. Thanks for doing this.

---
Vijay

On Tue, 17 Mar 2020 at 04:35, Dick Hardt <[email-masked]> wrote:

> <https://tools..ietf.org/html/draft-hardt-xauth-protocol-05>
>
> Thanks!
>
> /Dick
> ᐧ
> --
> Txauth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/txauth
>

---

From: Mike Jones <[email-masked]>
Date: Mon, 23 Mar 2020 19:53:03 +0000

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]> On Behalf Of Dick Hardt
Sent: Friday, March 20, 2020 1:18 PM
To: [email-masked]
Cc: Justin Richer <[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:

Thanks!

/Dick
ᐧ

---

From: Justin Richer <[email-masked]>
Date: Tue, 24 Mar 2020 09:41:11 -0400

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

 — Justin

> On Mar 23, 2020, at 3:53 PM, Mike Jones <[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
>  
> 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
> ᐧ

---

From: Justin Richer <[email-masked]>
Date: Tue, 24 Mar 2020 10:48:03 -0400

Two quick notes I missed:

> On Mar 24, 2020, at 9:41 AM, Justin Richer <[email-masked]> wrote:
> 
> 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.
> 
> 		"url": "https://client.example/redirect_uri <https://client.example/redirect_uri>",
> 		"nonce": "1233455"
> 	 }
>   }
> }
> 

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:
>> 
>> From: Txauth <[email-masked] <mailto:[email-masked]>> On Behalf Of Dick Hardt
>> To: [email-masked] <mailto:[email-masked]>

---

From: Leif Johansson <[email-masked]>
Date: Tue, 24 Mar 2020 16:18:48 +0100

On 2020-03-23 20:53, Mike Jones 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.
> 

I wish somebody would have made that argument in favor of reusing OID URNs from SAML in OIDC :-)

	Cheers Leif