Re: [Txauth] TxAuth Charter

[Dick Hardt <[e-mail]>]

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.*

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




On Thu, Mar 26, 2020 at 1:11 PM Dick Hardt <[e-mail]> 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.
>
> 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
>