Subject: [Txauth] XAuth vs AuthZ vs ...

From: Vijay IETF <[email-masked]>
Date: Mon, 9 Mar 2020 14:41:55 +0530

Hi,

I spent yesterday catching up with the mailing list. That was too much to
digest in a day and I am still trying to figure out the boundaries and
scope.

One thing that is not clear is regarding the multiple proposals in draft
form that have been going around.

The best disambiguation I could find was:

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

My question is do these proposals converge, compete or the best one by
consensus or otherwise supersedes the other?

Apologies if that is a dumb question. A map of efforts/proposals/drafts of
this WG would be quite helpful to new comers such as myself. Thx!

---
Vijay

---

From: Justin Richer <[email-masked]>
Date: Tue, 10 Mar 2020 10:11:59 -0400

Vijay, it’s a great question.

So what basically happened is that I have been developing my proposed draft, XYZ, for over a year. We have implementations in multiple languages that interop with each other, much of which is available open source. When I proposed this working group, I put the XYZ spec (draft-richer-transactional-authorization) up for consideration as the starting point to the group. It’s been revised a number of times based on feedback both from reviewers on and off the list as well as implementers. There are a number of items that are not in the XYZ spec that we marked as “things to consider” as it moves forward — multiple tokens, management endpoint URLs for tokens, different key presentation mechanisms, etc. You can see notes of all of this up on the website I made for the project, https://oauth.xyz/ . Why aren’t these in the spec text itself? I didn’t want to add anything in that we didn’t have at least one piece of code for. The mantra of the IETF is “rough consensus and running code”, and I strongly believe in that.

Dick’s proposal, XAuth, is an exercise in a different way to approach some of the same problems. As far as I am aware, there are no extant implementations of XAuth. As you saw on the list, it has some good ideas and there are some disagreements on how it goes about doing things. Dick’s proposal is now also in consideration for an input to the working group. 

There is no “TXAuth” draft, yet. When the working group forms, we will start with one draft, either the XYZ or the XAuth draft or some combination of the two. It’s clear and expected that whatever TXAuth turns out isn’t going to exactly be XYZ or XAuth, and it’s entirely possible that it won’t look like either.

What I would recommend to the working group is to start with one and add features in from the other as needed. They represent pretty deeply different worldviews on how things talk and what is represented, and take a very different philosophy to the “ease of transition” part of the proposed charter. 

My personal take would be to start with XYZ and add in what I think are some of the best ideas in XAuth:
 - Management URLs for access tokens, separate from the transaction
 - OPTIONS on the tx endpoint for service discovery 
 - A way for the client to request and AS to return long and short URLs for interaction (but using XYZ’s interaction structure)

If the working group is chartered, this is the path that I hope we take, and I volunteer myself to be the editor for the spec. It’s also possible that some of these functions will be spun out into separate documents, but that’s up to the eventual WG to figure out how best to split things.

 — Justin

> On Mar 9, 2020, at 5:11 AM, Vijay IETF <[email-masked]> wrote:
> 
> Hi,
> 
> I spent yesterday catching up with the mailing list. That was too much to digest in a day and I am still trying to figure out the boundaries and scope. 
> 
> One thing that is not clear is regarding the multiple proposals in draft form that have been going around.
> 
> My question is do these proposals converge, compete or the best one by consensus or otherwise supersedes the other?
> 
> Apologies if that is a dumb question. A map of efforts/proposals/drafts of this WG would be quite helpful to new comers such as myself. Thx!
> 
> ---
> Vijay
> -- 
> Txauth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/txauth

---

From: Vijay IETF <[email-masked]>
Date: Wed, 11 Mar 2020 13:08:31 +0530

Justin,

Thanks. The fog is lifting :-)

Fwiw, I am a strong believer of “rough consensus and running code” as well.

---
Vijay

On Tue, 10 Mar 2020 at 19:42, Justin Richer <[email-masked]> wrote:

> So what basically happened is that I have been developing my proposed
> draft, XYZ, for over a year. We have implementations in multiple languages
> that interop with each other, much of which is available open source. When
> I proposed this working group, I put the XYZ spec
> (draft-richer-transactional-authorization) up for consideration as the
> starting point to the group. It’s been revised a number of times based on
> feedback both from reviewers on and off the list as well as implementers.
> There are a number of items that are not in the XYZ spec that we marked as
> “things to consider” as it moves forward — multiple tokens, management
> endpoint URLs for tokens, different key presentation mechanisms, etc. You
> can see notes of all of this up on the website I made for the project,
> https://oauth.xyz/ . Why aren’t these in the spec text itself? I didn’t
> want to add anything in that we didn’t have at least one piece of code for.
> The mantra of the IETF is “rough consensus and running code”, and I
> strongly believe in that.
>
> Dick’s proposal, XAuth, is an exercise in a different way to approach some
> of the same problems. As far as I am aware, there are no extant
> implementations of XAuth. As you saw on the list, it has some good ideas
> and there are some disagreements on how it goes about doing things. Dick’s
> proposal is now also in consideration for an input to the working group.
>
> There is no “TXAuth” draft, yet. When the working group forms, we will
> start with one draft, either the XYZ or the XAuth draft or some combination
> of the two. It’s clear and expected that whatever TXAuth turns out isn’t
> going to exactly be XYZ or XAuth, and it’s entirely possible that it won’t
> look like either.
>
> What I would recommend to the working group is to start with one and add
> features in from the other as needed. They represent pretty deeply
> different worldviews on how things talk and what is represented, and take a
> very different philosophy to the “ease of transition” part of the proposed
> charter.
>
>  - A way for the client to request and AS to return long and short URLs
> for interaction (but using XYZ’s interaction structure)
>
> If the working group is chartered, this is the path that I hope we take,
> and I volunteer myself to be the editor for the spec. It’s also possible
> that some of these functions will be spun out into separate documents, but
> that’s up to the eventual WG to figure out how best to split things.
>
>  — Justin
>
> > I spent yesterday catching up with the mailing list. That was too much
> to digest in a day and I am still trying to figure out the boundaries and
> scope.
> >
> > > 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.
> > Apologies if that is a dumb question. A map of efforts/proposals/drafts
> of this WG would be quite helpful to new comers such as myself. Thx!
> >
> > ---
> > Vijay
> > --
> > Txauth mailing list
> > [email-masked]