Subject: [Txauth] TxAuth Charter (Take 3.5)

From: Justin Richer <[email-masked]>
Date: Sat, 18 Jan 2020 09:15:05 -0500

Thanks for all the feedback and discussion on the last round of the charter. I’ve made a few tweaks to it based on the conversations on this list, and a couple off-list, and have incorporated them here.

This group is chartered to develop a 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. 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.

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 the authorizing party as necessary through interaction mechanisms indicated by the protocol. This decoupling avoids many of the security concerns and technical challenges of OAuth 2.0 as well as providing 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 multiple resources and APIs in a single interaction
- Separation between the party authorizing access and the party operating the client requesting access
- Web, mobile, single-page, interaction-constrained, and other types of client 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
- Mechanisms for providing user, software, organization, and other pieces of information used in authorization decisions
- Token presentation mechanisms and key bindings
- Optimization of information and API access beyond identity through the delegation process

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 porting from OAuth 2.0 and OpenID Connect to the new protocol where possible.

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.

I would really appreciate the security AD’s weighing in at this stage. Thanks again everyone!

 — Justin

---

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Mon, 20 Jan 2020 18:05:48 +0000

NIT: Mixed verb tenses in the last sentence of paragraph 2. Replace “as well as providing” with “and provides”.

–
Annabelle Richard Backman
AWS Identity

From: Txauth <[email-masked]> on behalf of Justin Richer <[email-masked]>
Date: Saturday, January 18, 2020 at 6:16 AM
To: "[email-masked]" <[email-masked]>
Subject: [Txauth] TxAuth Charter (Take 3.5)

 — Justin

---

From: Torsten Lodderstedt <[email-masked]>
Date: Tue, 21 Jan 2020 11:56:07 +0100

another NIT: Approval of “access to” multiple resources and APIs in a single interaction

> On 20. Jan 2020, at 19:05, Richard Backman, Annabelle <richanna=[email-masked]> wrote:
> 
> -- 
> Txauth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/txauth

---

From: Justin Richer <[email-masked]>
Date: Tue, 21 Jan 2020 13:47:35 -0500

Thanks, both of those nits make sense and we’ll be sure to incorporate them. 

 — Justin

> On Jan 21, 2020, at 5:56 AM, Torsten Lodderstedt <[email-masked]> wrote:
>

---

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

Small suggestion: s/porting/migrating/

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 porting *migrating* from OAuth 2.0 and OpenID
Connect to the new protocol where possible.

On Tue, Jan 21, 2020 at 10:47 AM Justin Richer <[email-masked]> wrote:

> >> Thanks for all the feedback and discussion on the last round of the
> charter. I’ve made a few tweaks to it based on the conversations on this
> list, and a couple off-list, and have incorporated them here.
> >>
> >>>
> >>> This group is chartered to develop a 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. 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.
> >>>
> >>> 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 the
> authorizing party as necessary through interaction mechanisms indicated by
> the protocol. This decoupling avoids many of the security concerns and
> technical challenges of OAuth 2.0 as well as providing a non-invasive path
> for supporting future types of clients and interaction channels.
> >>>
> >>> - Mechanisms for providing 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 porting from OAuth 2.0 and OpenID Connect to the new
> protocol where possible.
> >>>
> >>> 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.
> >>