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

[Tom Jones <[e-mail]>]

Right - I have already proposed binding to application level keys in other
venues and strongly oppose continued use of channel binding.
Peace ..tom


On Fri, Jun 26, 2020 at 2:03 PM Justin Richer <[e-mail]> wrote:

> 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]>
> Date: Fri, Jun 26, 2020 at 9:10 AM
> Subject: WG Review: Grant Negotiation and Authorization Protocol (gnap)
> To: IETF-Announce <[e-mail]>
> Cc: <[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]) by 2020-07-06.
>
> Grant Negotiation and Authorization Protocol (gnap)
> -----------------------------------------------------------------------
> Current status: Proposed WG
>
> Chairs:
>   Yaron Sheffer <[e-mail]>
>   Leif Johansson <[e-mail]>
>
> Assigned Area Director:
>   Roman Danyliw <[e-mail]>
>
> Security Area Directors:
>   Benjamin Kaduk <[e-mail]>
>   Roman Danyliw <[e-mail]>
>
> Mailing list:
>   Address: [e-mail]
>   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
>
>
>
> _______________________________________________
> IETF-Announce mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ietf-announce
> ᐧ
> --
> Txauth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/txauth
>
>
> --
> Txauth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/txauth
>