Subject: Re: [Txauth] Proposed TxAuth charter Text

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

I agree that the updates represent some progress.  I’d like to tighten the statement about what the group is not chartered to do to add new registries for identity claims are also out of scope.  I propose that revise the statement below per my text in red:

The group is chartered to develop mechanisms for conveying identity information within the protocol including identifiers (such as email addresses, phone numbers, usernames, and subject identifiers) and assertions (such as OpenID Connect ID Tokens, SAML Assertions, and Verifiable Credentials). The group is not chartered to develop new formats for identifiers or assertions, nor is the group chartered to develop schemas for user information, profiles, or other identity attributes, or new registries for listing such schema elements or identity attributes, unless a viable existing format is not available.

Like Torsten, Kim, and others, I’d still rather that we tackled identity separately, if at all.  My proposal above is my fallback position if we can’t get consensus to remove identity from the charter.

                                                       -- Mike

From: Dick Hardt <[email-masked]>
Sent: Saturday, March 21, 2020 12:56 PM
To: Mike Jones <[email-masked]>; Kim <[email-masked]>; Filip Skokan <[email-masked]>; Torsten Lodderstedt <[email-masked]>
Cc: [email-masked]
Subject: Re: [Txauth] Proposed TxAuth charter Text

(replying with those that had expressed concerns about the charter on the To: list to bring it to the top of their inbox)

Mike, Kim, Torsten, Filip: are your concerns addressed with the changes below?

(apologies to anyone I missed in the To: list)

On Sat, Mar 21, 2020 at 12:41 PM Justin Richer <[email-masked]<mailto:[email-masked]>> wrote:
After some great discussions on the list in the last week, Yaron, Dick, and I have pulled together a new proposed charter. I think this is version 5.0? But I forget exactly. :)

I’ve highlighted the new lines in bold here,  for those reading this email in HTML. There’s a diff available online at  http://www.mergely.com/RehoJJvW/  (note: go to view->word wrap to be able to read it better). I’m attaching the .DIFF file generated by Mergely as well, for those of us crusty old unix type folks who like to see that.

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
- Support for multiple access tokens in a single request
- Support for directed, audience-restricted access tokens
- 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
- Mechanisms 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 asserted identity claims)

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

- Discovery of the authorization server
- Revocation of active tokens
- Mechanisms for the AS and RS to communicate the access granted by an access token

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 the protocol developed here 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 group is chartered to develop mechanisms for conveying identity information within the protocol including identifiers (such as email addresses, phone numbers, usernames, and subject identifiers) and assertions (such as OpenID Connect ID Tokens, SAML Assertions, and Verifiable Credentials). The group is not chartered to develop new formats for identifiers or assertions, nor is the group chartered to develop schemas for user information, profiles, or other identity attributes, unless a viable existing format is not available.

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 use of protocol extension points

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

---

From: Justin Richer <[email-masked]>
Date: Mon, 23 Mar 2020 15:32:11 -0400

Mike,

A registry is a specific implementation for publishing a schema, and so I don’t think it’s appropriate to list it in the charter as either preferred or prohibited when the real goal is to define the boundaries and touchpoints of this protocol.

 — Justin

> On Mar 23, 2020, at 3:25 PM, Mike Jones <Michael.Jones=[email-masked]> wrote:
> 
> From: Dick Hardt <[email-masked] <mailto:[email-masked]>> 
> To: Mike Jones <[email-masked] <mailto:[email-masked]>>; Kim <[email-masked] <mailto:[email-masked]>>; Filip Skokan <[email-masked] <mailto:[email-masked]>>; Torsten Lodderstedt <[email-masked] <mailto:[email-masked]>>
> Cc: [email-masked] <mailto:[email-masked]>
> On Sat, Mar 21, 2020 at 12:41 PM Justin Richer <[email-masked] <mailto:[email-masked]>> wrote:
> I’ve highlighted the new lines in bold here,  for those reading this email in HTML. There’s a diff available online at  http://www.mergely.com/RehoJJvW/ <http://www.mergely.com/RehoJJvW/>  (note: go to view->word wrap to be able to read it better). I’m attaching the .DIFF file generated by Mergely as well, for those of us crusty old unix type folks who like to see that.
>  
>  
>  
>  
>  
> [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: Vijay IETF <[email-masked]>
Date: Tue, 24 Mar 2020 02:02:22 +0530

+1
---
Vijay

On Tue, 24 Mar 2020 at 01:02, Justin Richer <[email-masked]> wrote:

> Mike,
>
> A registry is a specific implementation for publishing a schema, and so I
> don’t think it’s appropriate to list it in the charter as either preferred
> or prohibited when the real goal is to define the boundaries and
> touchpoints of this protocol.
>
>  — Justin
>
> On Mar 23, 2020, at 3:25 PM, Mike Jones <
> Michael.Jones=[email-masked]> wrote:
>
> I agree that the updates represent some progress.  I’d like to tighten the
> statement about what the group is not chartered to do to add new registries
> for identity claims are also out of scope.  I propose that revise the
> statement below per my text in red:
>
> *The group is chartered to develop mechanisms for conveying identity
> information within the protocol including identifiers (such as email
> addresses, phone numbers, usernames, and subject identifiers) and
> assertions (such as OpenID Connect ID Tokens, SAML Assertions, and
> Verifiable Credentials). The group is not chartered to develop new formats
> for identifiers or assertions, nor is the group chartered to develop
> schemas for user information, profiles, or other identity attributes, or
> new registries for listing such schema elements or identity
> attributes, unless a viable existing format is not available.*
>
> Like Torsten, Kim, and others, I’d still rather that we tackled identity
> separately, if at all.  My proposal above is my fallback position if we
> can’t get consensus to remove identity from the charter.
>
>                                                        -- Mike
>
> *From:* Dick Hardt <[email-masked]>
> *Sent:* Saturday, March 21, 2020 12:56 PM
> *To:* Mike Jones <[email-masked]>; Kim <[email-masked]>;
> Filip Skokan <[email-masked]>; Torsten Lodderstedt <
> [email-masked]>
> *Cc:* [email-masked]
> *Subject:* Re: [Txauth] Proposed TxAuth charter Text
>
> (replying with those that had expressed concerns about the charter on the
> To: list to bring it to the top of their inbox)
>
> On Sat, Mar 21, 2020 at 12:41 PM Justin Richer <[email-masked]> wrote:
>
> After some great discussions on the list in the last week, Yaron, Dick,
> and I have pulled together a new proposed charter. I think this is version
> 5.0? But I forget exactly. :)
>
> I’ve highlighted the new lines in bold here,  for those reading this email
> in HTML. There’s a diff available online at
> http://www.mergely.com/RehoJJvW/  (note: go to view->word wrap to be able
> to read it better). I’m attaching the .DIFF file generated by Mergely as
> well, for those of us crusty old unix type folks who like to see that.
>
>
>
>
>
> 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.
>
> *- Support for multiple access tokens in a single request*
> *- Support for directed, audience-restricted access tokens*
> - Mechanisms 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 *asserted* identity *claims*)
>
> *- Mechanisms for the AS and RS to communicate the access granted by an
> access token*
>
> 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 the protocol developed here 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 group is chartered to develop mechanisms for conveying identity
> information within the protocol including identifiers (such as email
> addresses, phone numbers, usernames, and subject identifiers) and
> assertions (such as OpenID Connect ID Tokens, SAML Assertions, and
> Verifiable Credentials). The group is not chartered to develop new formats
> for identifiers or assertions, nor is the group chartered to develop
> schemas for user information, profiles, or other identity attributes,
> unless a viable existing format is not available. *
>
> 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
> [email-masked]
> [email-masked]
> [email-masked]