* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Gnap Status Pages

Grant Negotiation and Authorization Protocol (Active WG)
Sec Area: Roman Danyliw, Benjamin Kaduk | 2020-Jul-10 —  

2020-07-10 charter

Grant Negotiation and Authorization Protocol (gnap)


 Current Status: Active

     Leif Johansson <leifj@sunet.se>
     Yaron Sheffer <yaronf.ietf@gmail.com>

 Security Area Directors:
     Roman Danyliw <rdd@cert.org>
     Benjamin Kaduk <kaduk@mit.edu>

 Security Area Advisor:
     Roman Danyliw <rdd@cert.org>

 Mailing Lists:
     General Discussion: txauth@ietf.org
     To Subscribe:       ​https://www.ietf.org/mailman/listinfo/txauth
     Archive:            https://mailarchive.ietf.org/arch/browse/txauth/

Description of Working Group:

  This group is chartered to develop a fine-grained delegation protocol for
  authorization, API access, user identifiers, and identity assertions. The
  protocol will also allow the client to present unverified identifiers and
  verifiable assertions to the Authorization Server (AS) as part of its
  request. This protocol enables an authorizing party to delegate access
  to client software to use a Resource Server (RS) with this token. 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

  The delegation process will be acted upon by multiple parties in the protocol,
  each performing a specific role. The protocol will decouple the channels used
  by the protocol participants to communicate 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 protocol will include a means of specifying how the user can
  potentially be involved in an interactive fashion during the delegation
  process. The client and AS will use these interaction mechanisms to involve
  the user, as necessary, to make authorization decisions. 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.

  The group will seek to minimize assumptions about the form of client
  applications, allowing 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
  - Multiple access tokens in a single request and response
  - AS-directed dispatch of access tokens to the appropriate RS
  - Separation between the party authorizing access and the party operating the
  client requesting access

  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
  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 related to the identifiers
  and identity assertions about the client
  - Optimized inclusion of additional information (including identifiers and
  identity assertions) 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
  - Data model for granted access and mechanisms for the AS and RS to
  communicate the granted access model

  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 directed to 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 existing 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.

  The initial work will focus on using HTTPS for communication between the client
  and the authorization server, taking advantage of optimization features of
  HTTP/2 and HTTP/3 where possible, and will strive to enable simple mapping to
  other protocols such as CoAP when doing so does not conflict with the primary

  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
  - (if needed) Guidelines on migration paths, implementation, and operations

  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.

  The working group will cooperate and coordinate with other IETF WGs such as
  OAUTH, and work with external organizations, such as the OpenID Foundation,
  as appropriate.

Goals and Milestones:
  Jul 2021 - Core delegation protocol to Working Group Last Call
  Oct 2021 - Key presentation mechanism binding for each communication channel to Working Group Last Call
  Dec 2021 - Guidelines for use of protocol extension points to Working Group Last Call
  Feb 2022 - Guidelines on migration paths, implementation, and operations to Working Group Last Call

All charter page changes, including changes to draft-list, rfc-list and milestones:

Generated from PyHt script /wg/gnap/charters.pyht Latest update: 24 Oct 2012 16:51 GMT -