Subject: [Txauth] Updated Proposed TxAuth Charter

From: Justin Richer <[email-masked]>
Date: Fri, 7 Feb 2020 11:58:03 -0500

I’ve updated the proposed charter text based on feedback and conversation here on the list:

This group is chartered to develop a fine-grained delegation protocol for authorization, identity, and API access. This protocol will allow an authorizing party to delegate access to client software through an authorization server. 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. 

The delegation process will be acted upon by multiple parties in the protocol, each performing a specific role. The protocol will decouple the interaction channels, such as the end user’s browser, from the delegation channel, which happens directly between the client and the authorization server (in contrast with OAuth 2.0 which is initiated by the client redirecting the user’s browser). The client and AS will involve a user to make an authorization decision as necessary through interaction mechanisms indicated by the protocol. This decoupling avoids many of the security concerns and technical challenges of OAuth 2.0 and provides a non-invasive path for supporting future types of clients and interaction channels.

Additionally, the delegation process will allow for:

- Fine-grained specification of access
- Approval of AS attestation to identity claims
- Approval of access to multiple resources and APIs in a single interaction
- Separation between the party authorizing access and the party operating the client requesting access
- A variety of client applications, including Web, mobile, single-page, and interaction-constrained applications

The group will define extension points for this protocol to allow for flexibility in areas including:

- Cryptographic agility for keys, message signatures, and proof of possession 
- User interaction mechanisms including web and non-web methods
- Mechanism for conveying user, software, organization, and other pieces of information used in authorization decisions
- Mechanisms for presenting tokens to resource servers and binding resource requests to tokens and associated cryptographic keys
- Optimized inclusion of additional information through the delegation process (including identity)

Additionally, the group will provide mechanisms for management of the protocol lifecycle including:

- Discovery of the authorization server
- Revocation of active tokens
- Query of token rights by resource servers

Although the artifacts for this work are not intended or expected to be backwards-compatible with OAuth 2.0 or OpenID Connect, the group will attempt to simplify migrating from OAuth 2.0 and OpenID Connect to the new protocol where possible.

This group is not chartered to develop extensions to OAuth 2.0, and as such will focus on new technological solutions not necessarily compatible with OAuth 2.0. Functionality that builds directly on OAuth 2.0 will be developed in the OAuth Working Group, including functionality back ported from TxAuth to OAuth 2.0.

The group is chartered to develop mechanisms for applying cryptographic methods, such as JOSE and COSE, to the delegation process. This group is not chartered to develop new cryptographic methods. 

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.

Milestones to include:
 - Core delegation protocol
 - Key presentation mechanism bindings to the core protocol for TLS, detached HTTP signature, and embedded HTTP signatures
 - Identity and authentication conveyance mechanisms
 - Guidelines for extension points

We’ve scheduled a BoF for Vancouver, and there’s a chance we can maybe get a charter approved and WG spun up in time to have an official meeting. Either way, we’ll be meeting to discuss TxAuth.

 — Justin

---

From: Dick Hardt <[email-masked]>
Date: Fri, 7 Feb 2020 19:42:02 -0800

+1

On Fri, Feb 7, 2020 at 8:58 AM Justin Richer <[email-masked]> wrote:

> This group is chartered to develop a fine-grained delegation protocol for
> authorization, identity, and API access. This protocol will allow an
> authorizing party to delegate access to client software through an
> authorization server. 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.
>
> The delegation process will be acted upon by multiple parties in the
> protocol, each performing a specific role. The protocol will decouple the
> interaction channels, such as the end user’s browser, from the delegation
> channel, which happens directly between the client and the authorization
> server (in contrast with OAuth 2.0 which is initiated by the client
> redirecting the user’s browser). The client and AS will involve a user to
> make an authorization decision as necessary through interaction mechanisms
> indicated by the protocol. This decoupling avoids many of the security
> concerns and technical challenges of OAuth 2.0 and provides a non-invasive
> path for supporting future types of clients and interaction channels.
>
> - Mechanism for conveying user, software, organization, and other pieces
> of information used in authorization decisions
> - Mechanisms for presenting tokens to resource servers and binding
> resource requests to tokens and associated cryptographic keys
> Although the artifacts for this work are not intended or expected to be
> backwards-compatible with OAuth 2.0 or OpenID Connect, the group
> will attempt to simplify migrating from OAuth 2.0 and OpenID Connect to the
> new protocol where possible.
>
> This group is not chartered to develop extensions to OAuth 2.0, and as
> such will focus on new technological solutions not necessarily compatible
> with OAuth 2.0. Functionality that builds directly on OAuth 2.0 will be
> developed in the OAuth Working Group, including functionality back ported
> from TxAuth to OAuth 2.0.
>
> The group is chartered to develop mechanisms for applying cryptographic
> methods, such as JOSE and COSE, to the delegation process. This group is
> not chartered to develop new cryptographic methods.
>
> 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.
>
> Milestones to include:
>  - Key presentation mechanism bindings to the core protocol for TLS,
> detached HTTP signature, and embedded HTTP signatures
> We’ve scheduled a BoF for Vancouver, and there’s a chance we can maybe get
> a charter approved and WG spun up in time to have an official meeting.
> Either way, we’ll be meeting to discuss TxAuth.
>
>  — Justin
> --
> Txauth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/txauth
>

---

From: Mike Varley <[email-masked]>
Date: Mon, 10 Feb 2020 15:06:51 +0000

+1
We are really looking forward to the development of this protocol, as it hits some key areas that our OAuth 2.0 / IODC / SAML based solutions struggle with. Having a standard method for addressing scenarios like “bring your own client app” and “bring your own IdPs” will be very valuable and SecureKey hopes to contribute where we can.

Thank-you,

MV

From: Txauth <[email-masked]> on behalf of Dick Hardt <[email-masked]>
Date: Friday, February 7, 2020 at 10:42 PM
To: Justin Richer <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [Txauth] Updated Proposed TxAuth Charter

+1

On Fri, Feb 7, 2020 at 8:58 AM Justin Richer <[email-masked]<mailto:[email-masked]>> wrote:
I’ve updated the proposed charter text based on feedback and conversation here on the list:

This group is chartered to develop a fine-grained delegation protocol for authorization, identity, and API access. This protocol will allow an authorizing party to delegate access to client software through an authorization server. 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.

This group is not chartered to develop extensions to OAuth 2.0, and as such will focus on new technological solutions not necessarily compatible with OAuth 2.0.. Functionality that builds directly on OAuth 2.0 will be developed in the OAuth Working Group, including functionality back ported from TxAuth to OAuth 2.0.

Milestones to include:

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

This email and any attachments are for the sole use of the intended recipients and may be privileged, confidential or otherwise exempt from disclosure under law. Any distribution, printing or other use by anyone other than the intended recipient is prohibited. If you are not an intended recipient, please contact the sender immediately, and permanently delete this email and its attachments.

---

From: Matthew De Haast <[email-masked]>
Date: Mon, 10 Feb 2020 09:10:34 +0200

+ 1

On Sat, Feb 8, 2020 at 5:42 AM Dick Hardt <[email-masked]> wrote:

>> supported by OAuth 2..0 and OpenID Connect (itself an extension of OAuth
>> with OAuth 2.0.. Functionality that builds directly on OAuth 2.0 will be
>> We’ve scheduled a BoF for Vancouver, and there’s a chance we can maybe
>> get a charter approved and WG spun up in time to have an official meeting.

---

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Mon, 10 Feb 2020 20:48:21 +0000

+1

–
Annabelle Backman (she/her)
AWS Identity
https://aws.amazon.com/identity/

From: Txauth <[email-masked]> on behalf of Matthew De Haast <matt.dehaast=[email-masked]>
Date: Monday, February 10, 2020 at 9:27 AM
To: Dick Hardt <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, Justin Richer <[email-masked]>
Subject: Re: [Txauth] Updated Proposed TxAuth Charter

+ 1

On Sat, Feb 8, 2020 at 5:42 AM Dick Hardt <[email-masked]<mailto:[email-masked]>> wrote:
+1

Although the artifacts for this work are not intended or expected to be backwards-compatible with OAuth 2.0 or OpenID Connect, the group will attempt to simplify migrating from OAuth 2..0 and OpenID Connect to the new protocol where possible.

Milestones to include:

 — Justin

---

From: George Fletcher <[email-masked]>
Date: Tue, 11 Feb 2020 14:43:04 -0500

I'm also +1. I'm looking forward to the discussion in Vancouver!

On 2/7/20 11:58 AM, Justin Richer wrote:
>     This group is chartered to develop a fine-grained delegation
>     protocol for authorization, identity, and API access. This
>     protocol will allow an authorizing party to delegate access to
>     client software through an authorization server. 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.
>
>     The delegation process will be acted upon by multiple parties in
>     the protocol, each performing a specific role. The protocol will
>     decouple the interaction channels, such as the end user’s browser,
>     from the delegation channel, which happens directly between the
>     client and the authorization server (in contrast with OAuth 2.0
>     which is initiated by the client redirecting the user’s browser).
>     The client and AS will involve a user to make an authorization
>     decision as necessary through interaction mechanisms indicated by
>     the protocol. This decoupling avoids many of the security concerns
>     and technical challenges of OAuth 2.0 and provides a non-invasive
>     - A variety of client applications, including Web, mobile,
>     single-page, and interaction-constrained applications
>
>     - Mechanism for conveying user, software, organization, and other
>     pieces of information used in authorization decisions
>     Although the artifacts for this work are not intended or expected
>     to be backwards-compatible with OAuth 2.0 or OpenID Connect, the
>     group will attempt to simplify migrating from OAuth 2.0 and OpenID
>     Connect to the new protocol where possible.
>
>     This group is not chartered to develop extensions to OAuth 2.0,
>     and as such will focus on new technological solutions not
>     necessarily compatible with OAuth 2.0. Functionality that builds
>     directly on OAuth 2.0 will be developed in the OAuth Working
>     Group, including functionality back ported from TxAuth to OAuth 2.0.
>
>     The group is chartered to develop mechanisms for applying
>     cryptographic methods, such as JOSE and COSE, to the delegation
>     process. This group is not chartered to develop new cryptographic
>     methods.
>
>     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.
>
>     Milestones to include:
>      - Key presentation mechanism bindings to the core protocol for
>     TLS, detached HTTP signature, and embedded HTTP signatures
> get a charter approved and WG spun up in time to have an official 
> meeting. Either way, we’ll be meeting to discuss TxAuth.
>
>  — Justin
>

---

From: Roman Danyliw <[email-masked]>
Date: Wed, 26 Feb 2020 19:40:21 +0000

Hi!

A few minor nits from the Ben and me as we button up this text ...

> From: Txauth <[email-masked]> On Behalf Of Justin Richer
> Sent: Friday, February 07, 2020 11:58 AM
> To: [email-masked]
> Subject: [Txauth] Updated Proposed TxAuth Charter
> 
> authorization, identity, and API access. This protocol will allow an authorizing
> party to delegate access to client software through an authorization server. 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.
> 
> The delegation process will be acted upon by multiple parties in the protocol,
> each performing a specific role. The protocol will decouple the interaction
> channels, such as the end user’s browser, from the delegation channel,
> which happens directly between the client and the authorization server (in
> contrast with OAuth 2.0 which is initiated by the client redirecting the user’s
> browser). The client and AS will involve a user to make an authorization
> decision as necessary through interaction mechanisms indicated by the
> protocol. This decoupling avoids many of the security concerns and technical
> challenges of OAuth 2.0 and provides a non-invasive path for supporting
> future types of clients and interaction channels.
> 
> - Mechanism for conveying user, software, organization, and other pieces of
> information used in authorization decisions

s/Mechanism/Mechanisms/

> resource requests to tokens and associated cryptographic keys

Is there any scoping we need to add here?

> process (including identity)

Can anything be said about the properties/metric being optimized here?

> This group is not chartered to develop extensions to OAuth 2.0, and as such
> will focus on new technological solutions not necessarily compatible with
> OAuth 2.0. Functionality that builds directly on OAuth 2.0 will be developed in
> the OAuth Working Group, including functionality back ported from TxAuth
> to OAuth 2.0.
> 
> methods, such as JOSE and COSE, to the delegation process. This group is not
> chartered to develop new cryptographic methods.
> 
> 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.
> 
> Milestones to include:

Is there interest in publishing a document to cover new use cases not already covered in OAuth 2 or Open ID specs?

> detached HTTP signature, and embedded HTTP signatures

Is this one mechanism?  Or three?

Are there other WGs with which this activity should be coordinated (e.g., HTTPbis)?

>  - Identity and authentication conveyance mechanisms

What exactly is that?  How many are there?

>  - Guidelines for extension points

Is this the same as "Implementation Guidance for publishing extension points"?

Thanks,
Roman

---

From: Justin Richer <[email-masked]>
Date: Wed, 26 Feb 2020 15:36:18 -0500

Hi Roman, answers inline below. I’m not sure how or if we’d want to change the text in order to be more clear, but I’m open to suggestions (from anyone). Thank you!

> On Feb 26, 2020, at 2:40 PM, Roman Danyliw <[email-masked]> wrote:
> 
> Hi!
> 

OK.

> Is there any scoping we need to add here?

I don’t think so — I think we want to be open to different kinds of presentation mechanisms here. The group can decide if any particular mechanism is worth defining within the group or pushing it elsewhere if it’s a better fit.

> Can anything be said about the properties/metric being optimized here?

The optimization that’s been identified in early conversations is to include some information in the response to the authorization call, in addition to a token enabling the client to call an API. So for a concrete example, you’d be able to ask for an identifier for the current user but also call a user API (like an OIDC UserInfo Endpoint or a SCIM endpoint) with the access token to get their profile information. So you’re optimizing that first bit of information with a specific part of the request/response within this protocol. 

> Is there interest in publishing a document to cover new use cases not already covered in OAuth 2 or Open ID specs?

I’m not a fan of publishing use case documents as official WG documents. I believe they are useful for organizing group thoughts and activities, but they should not be set in stone (as an RFC, for instance). Just about every instance of this I’ve been a part of in the IETF has been a failure and waste of effort. That’s why I didn’t include it in the milestones, but I’m happy if the group decides to use it as an organizational tool.

> Is this one mechanism?  Or three?

Three mechanisms to do similar things. There are likely others out there as well.

> Are there other WGs with which this activity should be coordinated (e.g., HTTPbis)?

Only a little coordination is going to be needed - what we’re after here is applying work done in other WG’s to this problem. So we’ll be providing a use case for that specific work, but the good news is that the editors for that spec are also here in TxAuth. But we don’t want to invent new things — that’s why we’re targeting the HTTPbis signature work, MTLS, and JWS as three specific mechanisms; the crypto work is outside this group, but how that fits into this specific protocol would be within scope. There might be others identified in the course of the working group’s activities, but I don’t see that as a change in charter if it’s picked up after we’re done with these.

> What exactly is that?  How many are there?

This is what I’m talking about about above — a way to get user info back from the AS. There’s disagreement even in initial conversations here on the list as to what would be included (how much of the profile) and what form it would take (plain field vs. signed assertion), but there’s agreement that we’d want to return some kind of identity stuff. I don’t think we can be more specific without pre-determining a solution.

> Is this the same as "Implementation Guidance for publishing extension points”?

I’m not sure it’s quite the same. We want to make sure our artifacts include clear guidance around what the extension points of this protocol are. Maybe this should be “Guidelines for use of protocol extension points”?

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