Subject: Re: [Txauth] TxAuth Charter (Take 3.5)

From: Roman Danyliw <[email-masked]>
Date: Wed, 29 Jan 2020 00:13:44 +0000

Hi!

> -----Original Message-----
> From: TxAuth <[email-masked]> On Behalf of Justin Richer
> Sent: Sat, 18 January 2020 14:15 UTCShow
> To: IETF TxAuth <[email-masked]>
> Subject: [Txauth] TxAuth Charter (Take 3.5)
> 

[snip]
> I would really appreciate the security AD's weighing in at this stage. Thanks
> again everyone!

The Sec ADs have reviewed the charter (as of v3.5) and at a high level believe the scope could use a bit more precision.  If there was no prior work, the situation would be different.  However, in this case, relationships with the existing OAuth WG needs to be navigated.  Topics that require discussion and clarity include:

** is TxAuth intended to solve all existing OAuth use cases (i.e., is TxAuth is a superset of OAuth) in a new, non-backward compatible way?  If not all, which would not be addressed?
** what new use cases would TxAuth address (that aren't in scope for OAuth)?
** given a new use case requirement for delegated authorization/identity, what would be the decision process to decide to which WG or WGs it would go?
** notional milestones (not the dates, but the deliverables)

In the details of the text:

(1) Distinguish what's new (instance #1):
OLD:
This group is chartered to develop a delegation protocol for authorization, identity, and API access.

NEW:
This group is chartered to develop a fine-grained delegation protocol for authorization, identity, and API access.

(2) Distinguish what's new (instance #2):
OLD:
The use cases supported by this protocol will include widely deployed use cases currently supported by OAuth 2.0 and OpenID Connect (an extension of OAuth 2.0) as well as new use cases not enabled by OAuth 2.0.

NEW:
It will expand upon the uses cases currently supported by OAuth 2.0 and OpenID Connect (itself an extension of OAuth 2.0) to support authorizations scoped as narrowly as a single transaction, provide a clear framework for interaction among all parties involved in the protocol flow, and remove unnecessary dependence on a browser or user-agent for coordinating interactions.

(3) Style Nit:
OLD:
Web, mobile, single-page, interaction-constrained, and other types of client applications

NEW: 
A variety of client applications, including Web, mobile, single-page, and interaction-constrained applications

(4) Per "Token presentation mechanisms and key bindings", perhaps it might be clearer to say "Mechanisms for presenting tokens to resource servers and binding resource requests to cryptographic keys"

(5) Per "Mechanisms for providing user, software ...", perhaps it might be clearer to say "Mechanism for conveying user, software ..."

(6) Per "Optimization of information and API access beyond identity through the delegation process", is this suggesting the need for optimizing access to TxAuth information for use cases beyond identity? Or the inclusion of information that isn't identity information into the delegation process?  

(7) Refine the protocol focus:
OLD:
While the initial work will focus on using HTTP for communication between the client and the authorization server, the working group will seek to take advantage of optimization features of HTTP2 and HTTP3 where possible, and will strive to enable simple mapping to other protocols such as COAP.

NEW:
The initial work will focus on using HTTP for communication between the client and the authorization server, taking advantage of optimization features of HTTP2 and HTTP3 where possible, and will strive to enable simple mapping to other protocols such as COAP when doing so does not conflict with the primary focus.

Regards,
Roman and Ben

---

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

I'll take a stab at answering your questions:

The Sec ADs have reviewed the charter (as of v3.5) and at a high level
> believe the scope could use a bit more precision.  If there was no prior
> work, the situation would be different.  However, in this case,
> relationships with the existing OAuth WG needs to be navigated.  Topics
> that require discussion and clarity include:
> ** is TxAuth intended to solve all existing OAuth use cases (i.e., is
> TxAuth is a superset of OAuth) in a new, non-backward compatible way?
>

Yes. See below for non-backward compatibility.

> ** what new use cases would TxAuth address (that aren't in scope for

All identity claim use cases. A set of these are solved by OpenID Connect,
which is an extension to OAuth 2.0. TxAuth would also be a superset of
OpenID Connect in addition to OAuth.

> ** given a new use case requirement for delegated authorization/identity,
> what would be the decision process to decide to which WG or WGs it would go?

Identity claim use cases would be in the TxAuth WG, as identity claims are
not in the latest OAuth WG charter.

Some new authorization use cases will be applicable to both, where there is
a desire for the use case to be supported by both protocols. In situations
where the same document can be used by both OAuth and TxAuth such as the
Rich Authorization Request work, I would suggest it be done in the OAuth WG.

Other use cases will require different mechanisms, as the protocols are
different, and work will happen in both.

*How are OAuth 2.0 and TxAuth different?*

OAuth 2.0 uses browser redirects, and query parameters for the Client and
Authorization Server to communicate initially, and then the Client makes a
form encoded POST to the Authorization Server.

Extensions to OAuth 2.0 have added additional parameters, but have been
limited by what can be added to a URL redirect, and the name / value pair
constraints of a form encoded POST.

In contrast, TxAuth uses JSON to encode messages between the Client and the
Authorization Server, and the Client starts the the protocol sending a rich
JSON message to the Authorization Server. TxAuth is a new protocol.

Just as OAuth 2.0 was incompatible with OAuth 1.0, TxAuth is incompatible
with OAuth 2.0. If the work was done in the OAuth WG, it would likely be
called OAuth 3.0. To do that, the OAuth WG Charter would need to be
updated, as identity claims are not in scope. Excerpts from the OAuth WG
Charter https://tools.ietf.org/wg/oauth/charters

  The Web Authorization (OAuth) protocol allows a user to grant a
  third-party web site or application access to the user's protected
  resources, without necessarily revealing their long-term credentials,
  or even their identity.

<snip>

  The ongoing standardization efforts within the OAuth working group
  focus on increasing interoperability of OAuth deployments and to
  improve security.

On Tue, Jan 28, 2020 at 4:13 PM Roman Danyliw <[email-masked]> wrote:

> The Sec ADs have reviewed the charter (as of v3.5) and at a high level
> believe the scope could use a bit more precision.  If there was no prior
> work, the situation would be different.  However, in this case,
> relationships with the existing OAuth WG needs to be navigated.  Topics
> that require discussion and clarity include:
>
> ** is TxAuth intended to solve all existing OAuth use cases (i.e., is
> TxAuth is a superset of OAuth) in a new, non-backward compatible way?  If
> not all, which would not be addressed?
> ** given a new use case requirement for delegated authorization/identity,
> what would be the decision process to decide to which WG or WGs it would go?
> The use cases supported by this protocol will include widely deployed use
> cases currently supported by OAuth 2.0 and OpenID Connect (an extension of
> OAuth 2.0) as well as new use cases not enabled by OAuth 2.0.
>
> NEW:
> It will expand upon the uses cases currently supported by OAuth 2.0 and
> OpenID Connect (itself an extension of OAuth 2.0) to support authorizations
> scoped as narrowly as a single transaction, provide a clear framework for
> interaction among all parties involved in the protocol flow, and remove
> unnecessary dependence on a browser or user-agent for coordinating
> interactions.
>
> (3) Style Nit:
> OLD:
> (4) Per "Token presentation mechanisms and key bindings", perhaps it might
> be clearer to say "Mechanisms for presenting tokens to resource servers and
> binding resource requests to cryptographic keys"
>
> (5) Per "Mechanisms for providing user, software ...", perhaps it might be
> clearer to say "Mechanism for conveying user, software ..."
>
> (6) Per "Optimization of information and API access beyond identity
> through the delegation process", is this suggesting the need for optimizing
> access to TxAuth information for use cases beyond identity? Or the
> inclusion of information that isn't identity information into the
> delegation process?
>
> While the initial work will focus on using HTTP for communication between
> the client and the authorization server, the working group will seek to
> take advantage of optimization features of HTTP2 and HTTP3 where possible,
> and will strive to enable simple mapping to other protocols such as COAP.
>
> NEW:
> The initial work will focus on using HTTP for communication between the
> client and the authorization server, taking advantage of optimization
> features of HTTP2 and HTTP3 where possible, and will strive to enable
> simple mapping to other protocols such as COAP when doing so does not
> conflict with the primary focus.
>
> Regards,
> Roman and Ben
>
> --
> Txauth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/txauth
>

---

From: Torsten Lodderstedt <[email-masked]>
Date: Wed, 29 Jan 2020 06:09:03 +0100

> Am 29.01.2020 um 02:13 schrieb Dick Hardt <[email-masked]>:
> 
> All identity claim use cases. A set of these are solved by OpenID Connect, which is an extension to OAuth 2.0. TxAuth would also be a superset of OpenID Connect in addition to OAuth.

Don’t you think this would make TxAuth a bit complicated? What would be the benefit?

---

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

On Tue, Jan 28, 2020 at 9:09 PM Torsten Lodderstedt <[email-masked]>
wrote:

> > All identity claim use cases. A set of these are solved by OpenID
> Connect, which is an extension to OAuth 2.0. TxAuth would also be a
> superset of OpenID Connect in addition to OAuth.
>

Not any more than today, as many consumer IdPs have both in the same flows,
and that is what is in the proposed charter.

Having the information all in one document would make it simpler to
implement and understand.

Did you have chance to look at XAuth Torsten?

---

From: Torsten Lodderstedt <[email-masked]>
Date: Wed, 29 Jan 2020 08:04:18 +0100

> Am 29.01.2020 um 07:01 schrieb Dick Hardt <[email-masked]>:
> 
> 
> 
> 
>> On Tue, Jan 28, 2020 at 9:09 PM Torsten Lodderstedt <[email-masked]> wrote:
>> 
>> 
> Not any more than today, as many consumer IdPs have both in the same flows, and that is what is in the proposed charter. 
> 
> Having the information all in one document would make it simpler to implement and understand.
> 

I doubt. If i calculate the size of all relevant oauth specs + all relevant openid connect specs (including verified claims), that will most likely be a multi 100 pages spec that few people will fully understand and be able to review/contribute to and fully & correctly implement.

Modularity and extensibility is key to success of this initiative.

> Did you have chance to look at XAuth Torsten?

Not in detail.

---

From: Justin Richer <[email-masked]>
Date: Wed, 29 Jan 2020 09:41:04 +0100

I completely agree that modularity of the documents is key, but keep in mind that the charter specifies only the total end result and not how the documents are split up. How we slice things is a key decision that the working group needs to make. I don’t think we’ll see everything in in a single document, but I do think we’ll see a lot more in a “core” document than is in OAuth 2 today. 

We aren’t setting out to just mash together OAuth 2 and all of its extensions, including OIDC — anything like that would clearly be suited for the OAuth WG. 

I think that if we’re careful and deliberate, especially if we’re not dragging legacy decisions “just because”, then we have a chance to make things really work here without getting overly complex. Much of OIDC’s complexity stems from it adding functionality to OAuth 2 or overcoming limitations in OAuth 2. A lot of that can go away if we are building these aspects together from the start. 

 — Justin

> On Jan 29, 2020, at 8:04 AM, Torsten Lodderstedt <torsten=[email-masked]> wrote:
> 
> 
> 
>> On Tue, Jan 28, 2020 at 9:09 PM Torsten Lodderstedt <[email-masked] <mailto:torsten@lodderstedt..net>> wrote:
>> 
>> 
>> > Am 29.01.2020 um 02:13 schrieb Dick Hardt <[email-masked] <mailto:[email-masked]>>:
>> > 
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/txauth <https://www.ietf.org/mailman/listinfo/txauth>
> -- 
> 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 10:04:26 +0100

Hi Roman, thanks for the review. I’ll respond to the questions in line.

> On Jan 29, 2020, at 1:13 AM, Roman Danyliw <[email-masked]> wrote:
> 
> Hi!
> 
> The Sec ADs have reviewed the charter (as of v3.5) and at a high level believe the scope could use a bit more precision.  If there was no prior work, the situation would be different.  However, in this case, relationships with the existing OAuth WG needs to be navigated.  

That makes a lot of senes, and I appreciate the drive to clarity.

> Topics that require discussion and clarity include:
> 

Yes, it is my perspective that we would be working on a superset of OAuth use cases. However, that does not mean that we would be replicated OAuth functionality exactly — there will be things that we solve in fairly different ways (like single-page apps, for example).

If this were happening in the OAuth WG, this work would likely be called OAuth 3.0, and that might still be the final name at some point in the future. 

How would you recommend we communicate that in the charter? Should we explicitly call out coordination with OAuth WG?

> ** what new use cases would TxAuth address (that aren't in scope for OAuth)?

Identity is a big one, which is what OIDC currently layers on top of OAuth 2. We’d also be looking at user-to-user delegation (the UMA and CIBA use cases). We’re also looking at cases that involve non-web interaction with users (like the DID/VC work, or app-to-app communication on devices). All of these are listed in the proposed text, do they need to be called out as being beyond OAuth 2?

> ** given a new use case requirement for delegated authorization/identity, what would be the decision process to decide to which WG or WGs it would go?

These are different protocols, so a large part of it would be what context is it being solved in? If “using OAuth 2” is a requirement, which is going to be the case for a lot of people for a while yet, then the OAuth WG would pick it up. That’s why we’re still doing PAR, JAR, RAR, and the like over there. If you don’t have to use OAuth 2 or OIDC as your base, or if you need behaviors that are outside the OAuth 2, then you direct the work here. 

Or you bring the use case to both spaces, and maybe there’s an OAuth 2 and a TxAuth version of what you’re after, and these solutions are coordinated as much as makes sense. 

What should the charter say to address this information routing question?

> ** notional milestones (not the dates, but the deliverables)

Is this a proposed document list? I had thought we’d already kinda covered this in the extant text, but I’m taking this comment that we need something that’s more specific. 

> This group is chartered to develop a fine-grained delegation protocol for authorization, identity, and API access.

That works for me.

> It will expand upon the uses cases currently supported by OAuth 2.0 and OpenID Connect (itself an extension of OAuth 2.0) to support authorizations scoped as narrowly as a single transaction, provi…

I like this, thanks.

> A variety of client applications, including Web, mobile, single-page, and interaction-constrained applications

Works for me.

> (4) Per "Token presentation mechanisms and key bindings", perhaps it might be clearer to say "Mechanisms for presenting tokens to resource servers and binding resource requests to cryptographic keys”
> 

That works, though probably “binding resource requests to tokens and associated cryptographic keys"

> (5) Per "Mechanisms for providing user, software ...", perhaps it might be clearer to say "Mechanism for conveying user, software …"

Sounds good.

> (6) Per "Optimization of information and API access beyond identity through the delegation process", is this suggesting the need for optimizing access to TxAuth information for use cases beyond ide…

It’s the latter — there’s been stated interest in including information beyond just an access token in the response. Identity is the first clear use case of this, but I think we can treat identity information as a specific case of a more generic response.

> The initial work will focus on using HTTP for communication between the client and the authorization server, taking advantage of optimization features of HTTP2 and HTTP3 where possible, and will st…

I like this wording, thanks.

---

From: Adrian Hope-Bailie <[email-masked]>
Date: Wed, 29 Jan 2020 11:40:28 +0200

On Wed, 29 Jan 2020 at 11:04, Justin Richer <[email-masked]> wrote:

> relationships with the existing OAuth WG needs to be navigated.
>
> Yes, it is my perspective that we would be working on a superset of OAuth
> use cases. However, that does not mean that we would be replicated OAuth
> functionality exactly — there will be things that we solve in fairly
> different ways (like single-page apps, for example).
>
> If this were happening in the OAuth WG, this work would likely be called
> OAuth 3.0, and that might still be the final name at some point in the
> future.
>
> How would you recommend we communicate that in the charter? Should we
> explicitly call out coordination with OAuth WG?
>
> Identity is a big one, which is what OIDC currently layers on top of OAuth
> 2. We’d also be looking at user-to-user delegation (the UMA and CIBA use
> cases). We’re also looking at cases that involve non-web interaction with
> users (like the DID/VC work, or app-to-app communication on devices). All
> of these are listed in the proposed text, do they need to be called out as
> being beyond OAuth 2?
>

We are most interested in payments use cases. Specifically we find the use
of OAuth 2.0 for delegated access to financial accounts very limited,
forcing us into using things like the "Lodging Intents Pattern". I think
Torsten has made the point well in his blogs on the topic (
https://medium.com/oauth-2/transaction-authorization-or-why-we-need-to-re-think-oauth-scopes-2326e2038948
).

I believe this can be broadened to include any use case where the
authorization flow involves the user/RO giving consent to a client to
perform a specific transaction (as opposed to simply get access to a
resource or API) and the need for the AS to have the details of this prior
to authorization so the details can be properly presented to the user.

>
> > ** given a new use case requirement for delegated
> authorization/identity, what would be the decision process to decide to
> which WG or WGs it would go?
>
> These are different protocols, so a large part of it would be what context
> is it being solved in? If “using OAuth 2” is a requirement, which is going
> to be the case for a lot of people for a while yet, then the OAuth WG would
> pick it up. That’s why we’re still doing PAR, JAR, RAR, and the like over
> there. If you don’t have to use OAuth 2 or OIDC as your base, or if you
> need behaviors that are outside the OAuth 2, then you direct the work here.
>
> Or you bring the use case to both spaces, and maybe there’s an OAuth 2 and
> a TxAuth version of what you’re after, and these solutions are coordinated
> as much as makes sense.
>
> Is this a proposed document list? I had thought we’d already kinda covered
> this in the extant text, but I’m taking this comment that we need something
> that’s more specific.
>
> >
> > This group is chartered to develop a fine-grained delegation protocol
> for authorization, identity, and API access.
> >
>
> That works for me.
>
> > The use cases supported by this protocol will include widely deployed
> use cases currently supported by OAuth 2.0 and OpenID Connect (an extension
> of OAuth 2.0) as well as new use cases not enabled by OAuth 2.0.
> >
> > NEW:
> > (4) Per "Token presentation mechanisms and key bindings", perhaps it
> might be clearer to say "Mechanisms for presenting tokens to resource
> servers and binding resource requests to cryptographic keys”
> >
>
> > (5) Per "Mechanisms for providing user, software ...", perhaps it might
> be clearer to say "Mechanism for conveying user, software …"
>
> Sounds good.
>
> >
> It’s the latter — there’s been stated interest in including information
> beyond just an access token in the response. Identity is the first clear
> use case of this, but I think we can treat identity information as a
> specific case of a more generic response.
>
> >
> > While the initial work will focus on using HTTP for communication
> between the client and the authorization server, the working group will
> seek to take advantage of optimization features of HTTP2 and HTTP3 where
> possible, and will strive to enable simple mapping to other protocols such
> as COAP.
> >
> > NEW:

---

From: Justin Richer <[email-masked]>
Date: Wed, 29 Jan 2020 11:22:35 +0100

> On Jan 29, 2020, at 10:40 AM, Adrian Hope-Bailie <[email-masked]> wrote:
> 
> 
> 
> We are most interested in payments use cases. Specifically we find the use of OAuth 2.0 for delegated access to financial accounts very limited, forcing us into using things like the "Lodging Intents Pattern". I think Torsten has made the point well in his blogs on the topic (https://medium.com/oauth-2/transaction-authorization-or-why-we-need-to-re-think-oauth-scopes-2326e2038948 <https://medium.com/oauth-2/transaction-authorization-or-why-we-need-to-re-think-oauth-scopes-2326e2038948>).
> 
> I believe this can be broadened to include any use case where the authorization flow involves the user/RO giving consent to a client to perform a specific transaction (as opposed to simply get access to a resource or API) and the need for the AS to have the details of this prior to authorization so the details can be properly presented to the user.
>  

Exactly — because OAuth forces this information to go through the browser to get to the authorization page, it’s a bad fit for this type of use where you’re putting potentially sensitive information as inputs to the decision (which account to choose, for instance) that you don’t want leaked through the browser. 

TxAuth is based on the lodging intent pattern from the start. PAR does a great job of back porting this functionality to OAuth 2, but there are limitations and awkwardness to this approach that TxAuth can avoid.

 — Justin

---

From: Torsten Lodderstedt <[email-masked]>
Date: Wed, 29 Jan 2020 11:34:18 +0100

> Am 29.01.2020 um 09:41 schrieb Justin Richer <[email-masked]>:
> 
> Much of OIDC’s complexity stems from it adding functionality to OAuth 2 or overcoming limitations in OAuth 2.

Mind to share examples?

I only see the hybrid response types. Anything else?

---

From: Dick Hardt <[email-masked]>
Date: Wed, 29 Jan 2020 04:32:03 -0800

Let me know your thoughts after you have read it. :)

On Tue, Jan 28, 2020 at 11:04 PM Torsten Lodderstedt <
[email-masked]> wrote:

> Not any more than today, as many consumer IdPs have both in the same
> flows, and that is what is in the proposed charter.
>
> I doubt. If i calculate the size of all relevant oauth specs + all
> relevant openid connect specs (including verified claims), that will most
> likely be a multi 100 pages spec that few people will fully understand and
> be able to review/contribute to and fully & correctly implement.
>