Subject: [Txauth] TxAuth Charter

From: Dick Hardt <[email-masked]>
Date: Thu, 26 Mar 2020 13:11:37 -0700

Thanks for all the great discussion in the virtual call Monday. Justin has
made additional changes to the charter with input from myself and Yaron.
Most of the changes are scoping "identity" in the charter.

Actual text changes highlighted below, semantically it amounts to:

 - inclusion of interop statement
 - clarifying that “identity” is about identifier claims, assertions, and
the carriers for those
 - explicit call out of multi-access-token (and multi-RS) use cases
 - explicit call out of token model/schema for as-rs agreement
 - statement that we aren’t going to be creating assertion formats of user
profile schemas or things like that (within this group)

Diff available online at http://www.mergely.com/RehoJJvW/?wl=1 and in the
attached file.

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.

*The group will define interoperability for this protocol between different
parties, including*
* - client and authorization server;*
* - client and resource server; and*
* - authorization server and resource server.*

Additionally, the delegation process will allow for:

- Fine-grained specification of access
- Approval of AS attestation to *identifiers and other* identity claims
- Approval of access to multiple resources and APIs in a single interaction
- *Support for multiple access tokens in a single request and response*
*- 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 identifiers and identity assertions*)

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 *including* TLS,
detached HTTP signature, and embedded HTTP signatures
*- Conveyance mechanisms for identifiers and assertions*
- Guidelines for use of protocol extension points

---

From: Dick Hardt <[email-masked]>
Date: Thu, 26 Mar 2020 13:44:52 -0700

I had the correct merge link, but the wrong text (we made a change to the
first paragraph as well wrt. identity). Here is the correct text:

This group is chartered to develop a fine-grained delegation protocol for
authorization and API access, *as well as requesting and providing user
identifiers and claims*. 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.

Milestones to include:

On Thu, Mar 26, 2020 at 1:11 PM Dick Hardt <[email-masked]> wrote:

> *The group will define interoperability for this protocol between
> different parties, including*
> - A variety of client applications, including Web, mobile, single-page,
> and interaction-constrained applications
>
> - Mechanisms for presenting tokens to resource servers and binding
> resource requests to tokens and associated cryptographic keys
> 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

---

From: Justin Richer <[email-masked]>
Date: Thu, 26 Mar 2020 16:49:27 -0400

Also, here’s the .diff file if you want to look over the changes more directly. This can also be downloaded from link given in the first email.

Please note that this is a comparison against the charter that Yaron had mailed out for comment on March 6, 2020 and not the ones I had sent out in the interim.

Thanks to everyone for your inputs and the chairs for putting this up!

 — Justin

> On Mar 26, 2020, at 4:44 PM, Dick Hardt <[email-masked]> wrote:
> 
> I had the correct merge link, but the wrong text (we made a change to the first paragraph as well wrt. identity). Here is the correct text:
> 
> This group is chartered to develop a fine-grained delegation protocol for authorization and API access, as well as requesting and providing user identifiers and claims. 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.
> 
> The group will define interoperability for this protocol between different parties, including
>  - client and authorization server;
>  - client and resource server; and
>  - authorization server and resource server.
> 
> - Approval of AS attestation to identifiers and other identity claims
> - Support for multiple access tokens in a single request and response
> - 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 
> - 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 identifiers and identity assertions)
> 
> Additionally, the group will provide mechanisms for management of the protocol lifecycle including:
> 
> - 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 including TLS, detached HTTP signature, and embedded HTTP signatures
> - Conveyance mechanisms for identifiers and assertions
> On Thu, Mar 26, 2020 at 1:11 PM Dick Hardt <[email-masked] <mailto:[email-masked]>> wrote:
> Thanks for all the great discussion in the virtual call Monday. Justin has made additional changes to the charter with input from myself and Yaron. Most of the changes are scoping "identity" in the charter.
> 
>  - clarifying that “identity” is about identifier claims, assertions, and the carriers for those
>  - statement that we aren’t going to be creating assertion formats of user profile schemas or things like that (within this group)
> 
> Diff available online at http://www.mergely.com/RehoJJvW/?wl=1 <http://www.mergely.com/RehoJJvW/?wl=1> and in the attached file.
> 
> 
> 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.
> 
> The group will define interoperability for this protocol between different parties, including
>  - client and authorization server;
>  - client and resource server; and
>  - authorization server and resource server.
> 
> - Approval of AS attestation to identifiers and other identity claims
> - Support for multiple access tokens in a single request and response
> - 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 
> - 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 identifiers and identity assertions)
> 
> Additionally, the group will provide mechanisms for management of the protocol lifecycle including:
> 
> - 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 including TLS, detached HTTP signature, and embedded HTTP signatures
> - Conveyance mechanisms for identifiers and assertions

---

From: Vladimir Dzhuvinov <[email-masked]>
Date: Fri, 27 Mar 2020 09:43:17 +0200

What is the opinion about using formal analysis to back up the design
process?

Given the experience with OAuth 2.0 I think we can gain if we find a way
and resources to involve formal analysis early on. So we don't end up in
a regrettable situation to have to patch up the protocol after the fact.
If there's general agreement on this I suggest it's included in the
charter.

Vladimir

---

From: Justin Richer <[email-masked]>
Date: Fri, 27 Mar 2020 13:50:30 -0400

From my perspective, it’s a valuable tool for the WG to use, but putting it in the charter doesn’t make sense since it’s not a deliverable and it’s not a problem space. The charter is meant to guide what the WG works on (and doesn’t), not really define how the WG works on it. The same as the automated testing that Torsten was talking about — still a very good thing, but not really something appropriate for the charter.

This is an argument to make with the chairs of the newly-chartered group, when it’s formed. If this is something that we can build into the group’s culture from early days, then it can really help us a lot going forward, like automated testing and use case wikis and things like that.

 — Justin

> On Mar 27, 2020, at 3:43 AM, Vladimir Dzhuvinov <[email-masked]> wrote:
>

---

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Fri, 27 Mar 2020 18:31:17 +0000

There may be room in the charter to include testability as a secondary goal. In other words, we should strive to provide testable solutions, but not at the expense of functional requirements. I don’t think we should prescribe specific testing methodology, as different technical solutions may require difference choices there.

—
Annabelle Backman (she/her)
AWS Identity

> On Mar 27, 2020, at 10:52 AM, Justin Richer <[email-masked]> wrote:
> 
> --
> Txauth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/txauth

---

From: Yaron Sheffer <[email-masked]>
Date: Fri, 27 Mar 2020 22:49:51 +0300

TLS 1.3 is much more credible because they insisted on thorough formal analysis of the protocol. I'm very much for encouraging such analysis. But I'm on the fence when it comes to adding it to the charter, because it's an external dependency: we would need to get external experts (=academy) interested and wait for them to complete what is often lengthy and complicated analysis.

Thanks,
	Yaron

On 3/27/20, 21:31, "Richard Backman, Annabelle" <[email-masked]> wrote:

    —

---

From: Daniel Fett <[email-masked]>
Date: Sat, 28 Mar 2020 10:08:24 +0100

> TLS 1.3 is much more credible because they insisted on thorough formal analysis of the protocol. I'm very much for encouraging such analysis. But I'm on the fence when it comes to adding it to the…

I think that any new, sufficiently complex protocol should come with a
formal security analysis. (To the suprise of no one ;-) .)

Experience with other protocols has shown that it is just too easy to
overlook even simple security flaws.

To be effective, a formal analysis must not stand at the end of the
protocol design process. For TLS 1.3, researchers were involved from the
very beginning and they influenced key decisions in the design of the
protocol. (As a side effect, they enforced a clearly written
specification, as ambiguous phrasing makes formal analysis much harder.)
Formal analysis takes time, particularly so in the Web and mobile
application setting. As of today, there are no software tools that are
suitable for an in-depth analysis of web and mobile application
protocols. Pen-and-paper proofs are detailed, often easier to
comprehend, and thorough, but take a lot of time (e.g., FAPI and OAuth
2.0 both took about 6 months using the "Web Infrastructure Model").

I share the sentiments of Yaron regarding the charter. I propose to put
it into the charter as something that the group aims to do, but not as a
MUST, i.e.,

"The group seeks the cooperation with researchers for a formal
verification of the security of the protocol." (or "should seek" or
something)

If there is sufficient support in this group for such a cooperation (be
it written in the charter or not), I am willing to lead these efforts
and to get in touch with the respective research groups.

-Daniel

---

From: Justin Richer <[email-masked]>
Date: Sat, 28 Mar 2020 11:19:59 -0400

I agree that the more analysis we can do on this protocol from an early stage the better off we’ll be in the end. So many of OAuth 2’s problems come from a feature or option inadvertently opening up a hole that we might have been able to see coming. This is hindsight conjecture, of course, but it would be silly of us to do the same thing and expect different results. :)

I’m still not keen on making it a requirement in the charter for the reasons stated before. However, I would be amenable to such language as “The group will seek…” so as to show intent and not requirement tied to a deliverable. The same way we’ll seek to make things not horrible for porting to COAP or other protocol stacks, if someone wants to do that in the future (which I think likely as well).

Big thanks to Daniel offering to lead this effort!

 — Justin

> On Mar 28, 2020, at 5:08 AM, Daniel Fett <[email-masked]> wrote:
> 
> I think that any new, sufficiently complex protocol should come with a formal security analysis. (To the suprise of no one ;-) .)
> 
> Experience with other protocols has shown that it is just too easy to overlook even simple security flaws.
> 
> To be effective, a formal analysis must not stand at the end of the protocol design process. For TLS 1.3, researchers were involved from the very beginning and they influenced key decisions in the design of the protocol. (As a side effect, they enforced a clearly written specification, as ambiguous phrasing makes formal analysis much harder.) Formal analysis takes time, particularly so in the Web and mobile application setting. As of today, there are no software tools that are suitable for an in-depth analysis of web and mobile application protocols. Pen-and-paper proofs are detailed, often easier to comprehend, and thorough, but take a lot of time (e.g., FAPI and OAuth 2.0 both took about 6 months using the "Web Infrastructure Model").
> 
> I share the sentiments of Yaron regarding the charter. I propose to put it into the charter as something that the group aims to do, but not as a MUST, i.e., 
> 
> "The group seeks the cooperation with researchers for a formal verification of the security of the protocol." (or "should seek" or something)
> 
> 
> 
> If there is sufficient support in this group for such a cooperation (be it written in the charter or not), I am willing to lead these efforts and to get in touch with the respective research groups.
> 
> -Daniel
> 
> 
> -- 
> Txauth mailing list
> [email-masked]

---

From: Dick Hardt <[email-masked]>
Date: Sat, 28 Mar 2020 08:45:07 -0700

+1 to adding the intention of formal analysis to the charter

Thanks Daniel for volunteering to lead the effort!
ᐧ

On Sat, Mar 28, 2020 at 8:20 AM Justin Richer <[email-masked]> wrote:

> I agree that the more analysis we can do on this protocol from an early
> stage the better off we’ll be in the end. So many of OAuth 2’s problems
> come from a feature or option inadvertently opening up a hole that we might
> have been able to see coming. This is hindsight conjecture, of course, but
> it would be silly of us to do the same thing and expect different results.
> :)
>
> I’m still not keen on making it a requirement in the charter for the
> reasons stated before. However, I would be amenable to such language as
> “The group will seek…” so as to show intent and not requirement tied to a
> deliverable. The same way we’ll seek to make things not horrible for
> porting to COAP or other protocol stacks, if someone wants to do that in
> the future (which I think likely as well).
>
> formal security analysis. (To the suprise of no one ;-) ..)
>
> protocol. (As a side effect, they enforced a clearly written specification,
> as ambiguous phrasing makes formal analysis much harder.) Formal analysis
> takes time, particularly so in the Web and mobile application setting. As
> of today, there are no software tools that are suitable for an in-depth
> analysis of web and mobile application protocols. Pen-and-paper proofs are
> detailed, often easier to comprehend, and thorough, but take a lot of time
> (e.g., FAPI and OAuth 2.0 both took about 6 months using the "Web
> Infrastructure Model").
>
> I share the sentiments of Yaron regarding the charter. I propose to put it
> into the charter as something that the group aims to do, but not as a MUST,
> i.e.,
>
> If there is sufficient support in this group for such a cooperation (be it
> written in the charter or not), I am willing to lead these efforts and to
> get in touch with the respective research groups.
>
> -Daniel
>
> --
> Txauth mailing list
> [email-masked]