Grant Negotiation and Authorization Protocol
charter-ietf-gnap-00-00

The information below is for an older proposed charter
Document Proposed charter Grant Negotiation and Authorization Protocol WG (gnap) Snapshot
Title Grant Negotiation and Authorization Protocol
Last updated 2020-06-11
State Start Chartering/Rechartering (Internal Steering Group/IAB Review) Rechartering
WG State Active
IESG Responsible AD Roman Danyliw
Charter Edit AD Roman Danyliw
Send notices to (None)

Charter
charter-ietf-gnap-00-00

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

Where possible, the group will seek to make use of tools to guide and inform
the standardization process including formal analysis, architecture documents,
and use case documents. These artifacts will not be considered as working group
milestones or deliverables.