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

[Tom Jones <[e-mail]>]

I guess I disagree with several of the assertions made by Denis, especially
the one about the AS knowing as little as possible about the requirement of
the client as it will be presented to the RS. That may be his use case, but
in mine the AS is tightly bound to the user and the ONLY means for the user
to get information about why the client wants or deserves access to the
resources. In the healthcare case, the client and the RS understand the
meaning of the data, the AS and the user have a limited understanding of
the data. The AS formulates the grant, which is in terms of the request for
access, which the AS needs to understand the request to present to the user
for approval. The AS creates a grant, which is not in terms of the claims
provided, but in terms of the requirements for access. Clearly the AS and
RS (and client) need a shared taxonomy of the request types. The AS does
not need to understand the presentation of access from the RS to the
client, but the AS does need full understanding of the request in terms the
user can comprehend.
Peace ..tom


On Mon, Jul 6, 2020 at 8:08 PM Roman Danyliw <[e-mail]> wrote:

> Hi Denis!
>
>
>
> Thanks for the feedback and for repeating your review on the revised
> text.  More inline …
>
>
>
> *From:* iesg <[e-mail]> *On Behalf Of * Denis
> *Sent:* Monday, July 6, 2020 10:55 AM
> *To:* [e-mail]
> *Cc:* [e-mail]
> *Subject:* Re: [Txauth] WG Review: Grant Negotiation and Authorization
> Protocol (gnap)
>
>
>
> Since it is today the last day to send back comments, you will find
> hereafter my comments on the last charter version-05.
> charter-ietf-gnap-00-05
>
> This group is chartered to develop a fine-grained delegation protocol for authorization, API access, user identifiers, and identity assertions.
>
>
>
> [Denis] Fine.
>
>
>
> The protocol will also allow the client to present unverified identifiers and verifiable assertions to the AS as part of its request.
>
>
>
> [Denis] This sentence is too vague because "as part of its request" is not explicit enough. If it means  "as part as an access token request"
>
> this should be explicitly said. If, it is not the case, then it should be clearly explained. The AS should know as little as possible (including nothing)
>
> about what the client is doing.
>
>
>
> [Roman] The “request” here is the “access token request”.  That can be made clearer.
>
>
>
> This protocol will allow an authorizing party to delegate access to client software through an authorization server.
>
>
>
> [Denis] The word "*privacy*" is still missing in the charter. "Delegating access to client software through an authorization server"
>
> is negating the fact that the user's privacy will ever be considered. IMHO, I believe that a RS may delegate some operation to another RS,
>
> but I don't believe that an AS should be concerned by any form of delegation, otherwise it would have the ability to act as "Big Brother".
>
> OAuth has not been constructed taking into consideration the user's privacy. The major difference with it should be that GNAP has been
>
> constructed along "*privacy by design*" principles.
>
>
>
> [Roman]  I don’t exactly follow how considerations for privacy are being negated.  Above and beyond use-case specific considerations that would be defined later, RFC6973 is the IETF consensus design guidance that will guide the privacy threats and mitigations of the work.  What design guidance would you recommend that the WG should consider that aren’t captured in RFC6973?
>
>
>
> 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.
>
>
>
> [Denis] There is no need to refer to OAuth 2.0 and OpenID Connect. Some existing uses cases (i.e. "*non-expanded"* use cases) should be supported
>
> differently from OAuth 2.0 and OpenID Connect, in particular to support the user's privacy.
>
>
>
> [Roman] I’d want to hear others on this rescoping.  Building upon the use cases of OAuth 2.0 and OpenID Connect has been core, consensus-validated tenant for some time now.
>
>
>
> 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).
>
>
>
> [Denis] Here again, the delegation process, if any, should be handled by RSs and not by ASs.
>
> The term "delegation channel" is being used but it is left undefined. It is not understandable.
>
>
>
> [Roman] This sentence was just added into -05 address Security AD feedback.  In this case, it was made to distinguish between in-band signaling and the new purpose-to-be-built channel.
>
>
>
> 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.
>
>
>
> [Denis] Here again, the delegation process, if any, should be handled by RSs and not by ASs. The AS should know as little as possible (including nothing)
>
> about what the client is doing.
>
>
>
> [Roman] Understood – as I understand it, you have concern with the scope of the AS behavior.  I’d be interesting in hearing additional support for this rescoping.
>
>
>
> 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.
>
>
>
> [Denis] This is not understandable to me. Is such a sentence really needed in a charter ?
>
>
>
> [Roman] Can someone on the TxAuth mailing list remind us on why this sentence is here?  With a fresh read, I also can’t remember why we need it.
>
>
>
> 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.
>
>
>
> [Denis] In order to support the user's privacy, there should be no interaction at all between an authorization server and a resource server
>
> *at the time of a client request*.
>
>
>
> 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
>
> [Denis] As-directed dispatch does not allow to support the user's privacy. However, RS-directed dispatch allows to support the user's privacy.
>
> It should be explicitly mentioned.
>
> [Roman] As above (per the AS vs. RS behavior)
>
> -          Separation between the party authorizing access and the party operating the client requesting access
>
>
>
> [Denis] It is questionable whether such a separation would be really beneficial. In doubt, this item should be removed.
>
> [Roman] Could you say more on why this flexibility wouldn’t be worth it?
>
> 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
>
> Data model for granted access and mechanisms for the AS and RS to communicate the granted access model
>
>
>
> [Denis] While it is the duty for the RS to communicate the granted access model to the client *at the appropriate instant of time*,
>
> the AS should be kept fully ignorant of it.
>
>
>
> 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
>
> [Denis] Before defining a "Core delegation protocol", a simple client server-protocol involving the presentation of several access tokens to one RS should be defined.
>
> Privacy principles should be applied when defining the protocol. Then after, a delegation mechanism allowing one RS to forward an operation to another RS should be defined.
>
> -          Key presentation mechanism bindings to the core protocol including TLS, detached HTTP signature, and embedded HTTP signatures
>
> [Denis] Bindings to TLS are now deprecated, why should they be maintained ?
>
> Signatures may be needed but they do not necessarily need to be "detached HTTP signature, and embedded HTTP signatures".
>
> This item should be either removed or reworded.
>
> [Roman] Noted.  I’d want to hear others on this rescoping.
>
>
>
> -          Conveyance mechanisms for identifiers and assertions
>
> -          Guidelines for use of protocol extension points (if needed)
>
>      -    Guidelines on migration paths, implementation, and operations
>
> [Denis] The above three lines are rather mysterious.
>
> [Roman] The guidelines on migration paths came from the initial IESG
> review in order to have a named activity to action the design goal of “…
> the group will attempt to simplify migrating from OAuth 2.0 and OpenID
> Connect to the new protocol where possible” a bit earlier in the text.
>
> 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.
>
> [Denis] The charter should be shorter.
>
>
>
> [Roman] Definitely.  Nevertheless, we have the current text through rough
> consensus process achieved from two BoFs and multiple mailing list
> consensus calls.
>
>
>
> Regards,
>
> Roman
>
>
>
> /Denis
>
>
>
> 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]> <[e-mail]>
>
>   Leif Johansson <[e-mail]> <[e-mail]>
>
>
>
> Assigned Area Director:
>
>   Roman Danyliw <[e-mail]> <[e-mail]>
>
>
>
> Security Area Directors:
>
>   Benjamin Kaduk <[e-mail]> <[e-mail]>
>
>   Roman Danyliw <[e-mail]> <[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
>
>
>
>
>
>
>
>
> --
> Txauth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/txauth
>