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

[Tom Jones <[e-mail]>]

Again to be blunt, my flow for consent doesn't match yours.

thx ..Tom (mobile)

On Tue, Jul 7, 2020, 10:04 AM Denis <[e-mail]> wrote:

> Justin,
>
> Denis,
>
> A lot of what you’re describing below changes the very nature of the roles
> in the system. The component that manages the consent and issues tokens is,
> by definition, the AS.
>
> The current charter states: "the artifacts for this work are not intended
> or expected to be backwards-compatible with OAuth 2.0 or OpenID Connect".
> So we are not bound to OAuth 2.0 nor OpenID Connect. Hence, we do not need
> to stick with all their concepts.
>
> I believe that the user's consent should be given after a dialogue with
> the RS which does not mean that the RS shall capture the user's consent
> since it is the duty of the client. When a user selects one operation
> among a choice of operations proposed by the RS, the RS should inform
> the client about which attributes it needs to present and from which ASs.
> It is only at this moment that the clients learns which ASs are
> adequate. Before this moment, the dialogue *cannot* be handled by an AS.
> Then after the duty of the client is to look for these attributes and
> to get them from one or more ASs. ASs are all equal. There is no single AS
> with which the user shall be bound or have a particular relationship
>
> Managing the authorization (and the user's consent) at the RS is simple: I
> have proposed a way to do it (and FIDO U2F is even included).
>
> Managing the authorization at the AS would mandate a close synchronization
> between the RS and all the ASs with which it has a relationship.
> There would be the need to define a synch. protocol and it is much simpler
> to avoid to use such a protocol and thus not to define it.
> "Out-of-bands" means for such a synchronisation would not be a better
> solution. But the major issue by managing the user's consent at the AS
> is to allow the AS to act as Big Brother.
>
> A copy and paste from a document published under the "Digital Europe for
> All" (DE4A) project :
>
> The privacy principle requires that the private life, the home and the
> communications of each citizen
> are respected and that no personal data are gathered without a legitimate
> reason and purpose.
>
> Data protection and privacy should (as far as possible) be *achieved by
> design*, i.e. be embedded in the
> technical solutions and services in a way that misuse or illegitimate
> access is made impossible or at
> least very difficult through the technical approach itself, and *without
> having to rely on organisational *
> *measures or solely on legal measures to guarantee the compliance*.
>
> Main sources for this principle: CFREU, GDPR, eIDAS, eGov Action Plan,
> EIF, Tallinn Declaration, and
> SDGR.
>
> The user shouldn’t ever have to interact directly with the RS, since the
> RS is, by definition, an API that is called by software, not an interactive
> component.
>
> But it’s important to note that these are only :roles: to be played and
> not strictly speaking separate pieces of software, and that these roles can
> be combined and split in a variety of ways. For instance, in what you’re
> talking about below, instead of saying that it’s the RS that manages the
> consent, what if you saw it as the functionality of the AS that’s been
> split between two components: one privacy-preserving element that issues
> tokens, and another that deals with interaction and consent. This is
> already a pattern that some in the WG have expressed interest in supporting
> with GNAP, and the core charter tenet of separating the interaction from
> the delegation channels is something that could help there.
>
> Would it be possible to look at your use case in this different light?
>
> I could see the RS (i.e. not the AS) split into two components: an API and
> an MMI to manage the choices and the consent of the user.
> This looks artificial but would it help ?
>
> Denis
>
> It’s always possible that we need to re-cast some of these roles, and
> that’s been done before: in OAuth 2 we defined the AS and RS roles
> separately, even though they can always be deployed together anyway. So
> with that it’s possible that there are other distinct pieces here that are
> working together that we need to tease out, but that’s something for the WG
> to figure out. We can always decide to separate out the parts and allow
> them to be recombined in deployment, But I do not think it is helpful to
> redefine the existing roles, especially by moving key facets from one
> existing role to another.
>
>  — Justin
>
> On Jul 7, 2020, at 8:43 AM, Denis <[e-mail]> wrote:
>
> Hi Roman,
>
> Hi Denis!
>
> Thanks for the feedback and for repeating your review on the revised
> text.  More inline …
>
> *From:* iesg <[e-mail]> <[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]) *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.<o:p cl
>
>