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

[Denis <[e-mail]>]

Hi Roman,
>
> 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.
>
BTW, I sent an email yesterday evening with the subject: *Support of 
FIDO* and data minimization by RSs, where I indicated that the charter 
should
mention FIDO U2F so that it should be possible to logon to a RS using 
either FIDO or by presenting one (or more) access tokens from one (or 
more) AS.

The original email is here : 
https://mailarchive.ietf.org/arch/msg/txauth/fTwQCOfq6do9oL3iIPQczD7icwE/

>
>     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 would be appreciated.

> 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?

I believe my message is quite clear : If the AS is handling the 
delegation process, it will know what the client is doing or where it is 
going.
On the contrary, if the RS is handling the delegation process, the AS 
will be unable to know what the client is doing. In addition, an AS-centric
architecture would not be scalable and would need a lot of 
synchronizations between ASs and RSs. The user consent should be handled 
by the RS
and not by the AS. When a RS is unable to provide the service, it is 
best placed to tell directly to the client what it could do next.

RFC 6973 is very good document. Section 7.1 states:

           b.  Data.  What information does the protocol expose about 
individuals, their devices, and/or their device usage (other than the 
identifiers discussed in (a))?

Data includes both the operation and the data associated with the 
operation. An AS should be kept ignorant of both the operation and the 
data associated with the operation.

    c.  Observers.  (...) Are there ways for protocol implementers to 
    choose to limit the information shared with each entity?

If theses guidances were followed, the proposed architecture would not 
be AS-centric.

> 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.

Since delegation should not be handled by the AS, a delegation channel 
should not exist.

> 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?

Except for added complexity, there is no need to have separate channels. 
It is simpler to send the access token in addition to the data
and, for additional security, to sign the data using a private key 
corresponding to a public key present in the access token.

> 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.

As explained above, it is possible to sign the data using a private key 
corresponding to a public key present in the access token.

> -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.
>
In a previous post, I proposed a much shorter text.

Denis

> 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]  <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
>
>        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
>