Re: [Txauth] WG Review: Grant Negotiation and Authorization Protocol (gnap)

[Justin Richer <[e-mail]>]

I agree with this proposed change in wording for the milestones. We don’t want to artificially limit the key binding presentation mechanisms. While I think the three listed are likely to be among the first ones we see (based on prior art and current community interest), I don’t think we can predict entirely what will be developed by the group and when. 

 — Justin

> On Jun 26, 2020, at 1:21 PM, Dick Hardt <[e-mail]> wrote:
> 
> 
> 
> I am concerned with the following milestones:
> 
> 
>   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
> 
> I think it is overly prescriptive to specify which key presentation mechanisms will be created, and it implies that other key presentation mechanisms will not be worked on. While it is possible that channel binding mechanisms such as TLS, detached HTTP signatures, and embedded HTTP signatures will be appropriate key presentation mechanisms for GNAP, it is also quite possible that the WG will determine one or more are not appropriate, or the underlying mechanism may not gain acceptance, or channel binding is not always needed. For example, the effort to bind OAuth access tokens using RFC8471 was disbanded.
> 
> Additionally, there are two primary communication channels in the protocol that have different security requirements. The client to authorization server, and the client to resource server. The term "core protocol" is vague and could be construed that the same mechanism MUST be used in both channels.
> 
> I propose the following new wording:
> 
> Oct 2021 - Key presentation mechanism binding for each communication channel to WGLC.
> 
> 
> ---------- Forwarded message ---------
> From: The IESG <[e-mail] <mailto:[e-mail]>>
> Date: Fri, Jun 26, 2020 at 9:10 AM
> Subject: WG Review: Grant Negotiation and Authorization Protocol (gnap)
> To: IETF-Announce <[e-mail] <mailto:[e-mail]>>
> Cc: <[e-mail] <mailto:[e-mail]>>
> 
> 
> 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 ([e-mail] <mailto:[e-mail]>) by 2020-07-06.
> 
> Grant Negotiation and Authorization Protocol (gnap)
> -----------------------------------------------------------------------
> Current status: Proposed WG
> 
> Chairs:
>   Yaron Sheffer <[e-mail] <mailto:[e-mail]>>
>   Leif Johansson <[e-mail] <mailto:[e-mail]>>
> 
> Assigned Area Director:
>   Roman Danyliw <[e-mail] <mailto:[e-mail]>>
> 
> Security Area Directors:
>   Benjamin Kaduk <[e-mail] <mailto:[e-mail]>>
>   Roman Danyliw <[e-mail] <mailto:[e-mail]>>
> 
> Mailing list:
>   Address: [e-mail] <mailto:[e-mail]>
>   To subscribe: https://www.ietf.org/mailman/listinfo/txauth <https://www.ietf.org/mailman/listinfo/txauth>
>   Archive: https://mailarchive.ietf.org/arch/browse/txauth/ <https://mailarchive.ietf.org/arch/browse/txauth/>
> 
> Group page: https://datatracker.ietf.org/group/gnap/ <https://datatracker.ietf.org/group/gnap/>
> 
> Charter: https://datatracker.ietf.org/doc/charter-ietf-gnap/ <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
> 
> 
> 
> _______________________________________________
> IETF-Announce mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/ietf-announce <https://www.ietf.org/mailman/listinfo/ietf-announce>
> ᐧ
> -- 
> Txauth mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/txauth <https://www.ietf.org/mailman/listinfo/txauth>