From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: txauth@ietf.org
Reply-To: iesg@ietf.org
Subject: WG Review: Grant Negotiation and Authorization Protocol (gnap)
A new IETF WG has been proposed in the Security Area. The IESG has not made
any determination yet. The following draft charter was submitted, and is
provided for informational purposes only. Please send your comments to the
IESG mailing list (iesg@ietf.org) by 2020-07-06.
Grant Negotiation and Authorization Protocol (gnap)
-----------------------------------------------------------------------
Current status: Proposed WG
Chairs:
Yaron Sheffer <yaronf.ietf@gmail.com>
Leif Johansson <leifj@sunet.se>
Assigned Area Director:
Roman Danyliw <rdd@cert.org>
Security Area Directors:
Benjamin Kaduk <kaduk@mit.edu>
Roman Danyliw <rdd@cert.org>
Mailing list:
Address: txauth@ietf.org
To subscribe: https://www.ietf.org/mailman/listinfo/txauth
Archive: https://mailarchive.ietf.org/arch/browse/txauth/
Group page: https://datatracker.ietf.org/group/gnap/
Charter: https://datatracker.ietf.org/doc/charter-ietf-gnap/
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 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 Authorization Server (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
- 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
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 (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
- 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 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, unless a viable
existing format is not available.
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 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
- (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.
Milestones:
Jul 2021 - Core delegation protocol in WGLC
Oct 2021 - Key presentation mechanism binding to the core protocol, TLS, to
WGLC
Oct 2021 - Key presentation mechanism binding to the core protocol,
detached HTTP signatures, to WGLC
Oct 2021 - Key presentation mechanism binding to the core protocol,
embedded HTTP signature, to WGLC
Dec 2021 - Guidelines for use of protocol extension points to WGLC
Feb 2022 - Guidelines on migration paths, implementation, and operations to
WGLC
WG action announcement
WG Action Announcement
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: txauth@ietf.org,
gnap-chairs@ietf.org,
The IESG <iesg@ietf.org>
Subject: WG Action: Formed Grant Negotiation and Authorization Protocol (gnap)
A new IETF WG has been formed in the Security Area. For additional
information, please contact the Area Directors or the WG Chairs.
Grant Negotiation and Authorization Protocol (gnap)
-----------------------------------------------------------------------
Current status: Proposed WG
Chairs:
Yaron Sheffer <yaronf.ietf@gmail.com>
Leif Johansson <leifj@sunet.se>
Assigned Area Director:
Roman Danyliw <rdd@cert.org>
Security Area Directors:
Benjamin Kaduk <kaduk@mit.edu>
Roman Danyliw <rdd@cert.org>
Mailing list:
Address: txauth@ietf.org
To subscribe: https://www.ietf.org/mailman/listinfo/txauth
Archive: https://mailarchive.ietf.org/arch/browse/txauth/
Group page: https://datatracker.ietf.org/group/gnap/
Charter: https://datatracker.ietf.org/doc/charter-ietf-gnap/
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
interactions.
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 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
- (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.
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