Re: [GNAP] User consent

[Denis <[e-mail]>]

Tom,

I will make a reply similar to the one sent to Francis.

You are willing to discuss something else, please open one or two new 
threads (since there are two new topics).

Denis

> Here are some proposals that are working their way through other 
> channels.
> 1. on consent grant.: https://wiki.idesg.org/wiki/index.php/Consent_Grant
> 2 on delegations: https://wiki.idesg.org/wiki/index.php/Delegation
> Comments are welcomed.
> Peace ..tom
>
>
> On Fri, Aug 14, 2020 at 9:13 AM Francis Pouatcha 
> <fpo=[e-mail] <mailto:[e-mail]>> 
> wrote:
>
>     Small digest of the consent discussion into the suggested abstract
>     flow. Please do not nail on the words used (just working
>     assumptions).
>     - GS is used to refer to the token manager (what Justin calls
>     Delegation Server (DS) - handles the back-channel stuff)
>     - AS is used to refer to the authorization server (what Justin
>     calls Interaction Server (IS) - handles the front-channel stuff)
>     - (End User), (Client) are sample entities materializing the
>     corresponding roles (in oAuth2 for example)
>
>     Added Separation between GS and AS (resp. DS and IS sse above)
>     - 3a: GS forwards request for the RC consent to an AS, that knows
>     how to interact with the RC
>     - 3b: AS returns RC consent to GS.
>     This separation might help draw a line between token management
>     and user authorization. This is essential for forward thinking
>     into the world of Fido, SSI, DID.
>
>     Display front channel and back channel (At the Abstraction Level-0
>     -GNAP, this shall not matter.)
>     Steps (1, 4, 7) are good candidates for a front channel, as we are
>     interacting with a potential (End User).
>     Steps (2, 3, 5 , 6) are good candidates for back channel.
>     Steps (3a, 3b) are candidates for both, as AS might be running on
>     a user device.
>
>     Here is the new diagram.
>
>     +-----------+  +--------------+  +----+
>      +----+   +----+  +---------------------+
>     | Requestor |      | Orchestrator |  |    |  |    |   |    |  |
>     Resource Controller |
>     |           |      |     |  | RS |  | GS |   | AS |  |  |
>     |(End User) |      |  (Client)   |  |    |  |    |   |    |  |   
>       (End User)     |
>     +-----------+  +--------------+  +----+
>      +----+   +----+  +---------------------+
>       |(1) ServiceRequest     |          |       |        |          
>          |
>       |---------------------->|            |       |     |            
>        |
>       |                       |(2) ServiceIntent:AuthZChallenge       
>           |
>       |                       |<---------->| |        |                |
>       |                       |            |       |   |                |
>       |                       |(3) AuthZRequest(AuthZChallenge)       
>           |
>       |                       |------------------->|     |           
>         |
>       |                       |            |
>      |(3a)ConsentRequest(AuthZChallenge)
>       |                       |          |       |------->|           
>         |
>       |                       |          |       |        |(4)
>     ConsentRequest:Consent
>       |                       |            |       |   |<-------------->|
>       |                       |            |  |(3b)UserConsent          |
>       |                       |            |  |<-------|                |
>       |                       |(5) GrantAccess(AuthZ).   |           
>         |
>       |                       |<-------------------|     |           
>         |
>       |                       |            |       |   |                |
>       |                       |(6)
>     ServiceRequest(AuthZ):ServiceResponse.    |
>       |                       |<---------->|  |        |                |
>       |(7) ServiceResponse    |            |       |   |                |
>       |<----------------------|            |       |     |           
>         |
>       +                       +            +       +  +                +
>
>     Best regards.
>     /Francis
>
>
>     On Fri, Aug 14, 2020 at 6:14 AM Denis <[e-mail]
>     <mailto:[e-mail]>> wrote:
>
>         This is a new thread built from "Revisiting the photo sharing
>         example (a driving use case for the creation of OAuth)"
>
>         Hi Dick,
>
>>         I don't see how we can technically standardize a user
>>         experience, and it is not clear why a standard would be
>>         needed for interoperability.
>
>         I already wrote a proposal and made it available to the
>         mailing list.
>
>         An access will be granted by a RS based on an mathematical
>         expression which is formed using some combination of ANDand OR
>         conditions.
>
>         Examples of combinations:
>
>             /condition 1/AND/condition 2
>             condition 1/OR /condition 2/
>             (/condition 1/AND/condition 2)/OR/condition 3
>             (condition 1/OR /condition 2)/AND/condition 3/
>
>         The following notation is being used for the /conditions/:
>
>         /condition x/= { AS identifier + set of attributes types }
>
>         Each RS internally constructs an /authorization table/ with
>         the following content:
>
>         1°For the "authentication" operation: either FIDO U2For a
>         mathematical expression using conditions;
>
>         2°For any other operation: a mathematical expression using
>         conditions.
>
>         Given the operation selected by the client, the RS returns the
>         appropriate mathematical expression and only the associated
>         conditions
>         used in that mathematical expression. The User may then decide
>         whether they are appropriate to him or not.
>
>>          In many jurisdictions there are regulations regarding what
>>         information needs to be conveyed to a user, and potentially a
>>         consent requirement,
>>         for example a site explaining its use of cookies -- but I
>>         don't see how IETF would play a role in that.
>>
>>         On a related note, the browsers attempted to standardize the
>>         username / password prompt, and that has been rejected by
>>         pretty much every site.
>>         The only site I've visited in the last decade that has used
>>         the browsers' built in username / password prompt was the W3C
>>         site -- and it was a frustrating
>>         experience since there was no button for account recovery --
>>         it would just keep popping up.
>
>         What I am proposing is unrelated to the two above cases you
>         mention.
>
>         Denis
>
>>
>>
>>         ᐧ
>>
>>         On Thu, Aug 13, 2020 at 10:29 AM Denis <[e-mail]
>>         <mailto:[e-mail]>> wrote:
>>
>>             Dick,
>>
>>>             I think Tom's objection, and I agree with it, is that
>>>             humans don't interact in bits and bytes.
>>>
>>>             I think it is useful to separate human interactions with
>>>             software from software interactions with software.
>>>             The latter we can standardize, the former we can call
>>>             out as part of the overall process, but it is not something
>>>             that is testable or required for interop, so I would
>>>             argue human to software interactions are NOT part of the
>>>             protocol.
>>
>>             I disagree.  A set of a choices should be presented by
>>             the RS to the Client in a standardized way. The choices
>>             made by the user
>>             should be locally recorded by the Client, hence the RS
>>             does not need to be informed of these choices. The RS
>>             will only know
>>             the end result of these choices when/if it gets back one
>>             or more access tokens.
>>
>>             Human to software interactions should be part of the
>>             protocol.
>>
>>                 RS to Client: a set of choices
>>
>>                 Client to RS: Done (choices have been done by the user).
>>
>>             Denis
>>
>>
>>>
>>>             ᐧ
>>>
>>>             On Thu, Aug 13, 2020 at 8:11 AM Justin Richer
>>>             <[e-mail] <mailto:[e-mail]>> wrote:
>>>
>>>                 It’s a role fulfilled by a person, so I’m not sure
>>>                 where the objection you’re raising comes from.
>>>
>>>                 Also, whatever roles we define here, whether
>>>                 software or human-ware, they need to be related to
>>>                 the protocol.
>>>
>>>                  — Justin
>>>
>>>>                 On Aug 13, 2020, at 10:59 AM, Tom Jones
>>>>                 <[e-mail]
>>>>                 <mailto:[e-mail]>> wrote:
>>>>
>>>>                 I strong object to the objectification of human
>>>>                 users. It is way past time that the IETF becaume
>>>>                 user oriented instead of web service oriented.
>>>>                 users are human in my language.
>>>>                 Peace ..tom
>>>>
>>>>
>>>>                 On Tue, Aug 11, 2020 at 4:38 PM Justin Richer
>>>>                 <[e-mail] <mailto:[e-mail]>> wrote:
>>>>
>>>>                     If defined as the party operating the client
>>>>                     software, then the user is a role. I believe
>>>>                     this is more accurate and inclusive than the
>>>>                     definition you have proposed with the user as
>>>>                     an entity.
>>>>
>>>>                      - Justin
>>>>                     ________________________________________
>>>>                     From: Dick Hardt [[e-mail]
>>>>                     <mailto:[e-mail]>]
>>>>                     Sent: Tuesday, August 11, 2020 6:21 PM
>>>>                     To: Francis Pouatcha
>>>>                     Cc: Justin Richer; Denis; Benjamin James Kaduk;
>>>>                     [e-mail] <mailto:[e-mail]>
>>>>                     Subject: Re: [GNAP] [Txauth] Revisiting the
>>>>                     photo sharing example (a driving use case for
>>>>                     the creation of OAuth)
>>>>
>>>>                     Hi Francis
>>>>
>>>>                     The user is an entity, not a role in the
>>>>                     protocol in how I am defining roles, so steps
>>>>                     (1) and (7) are confusing to me on what is
>>>>                     happening.
>>>>
>>>>                     I also think that (2) could be an extension to
>>>>                     GNAP, rather than part of the core protocol.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>                     On Mon, Aug 10, 2020 at 8:04 PM Francis
>>>>                     Pouatcha <[e-mail]
>>>>                     <mailto:[e-mail]><mailto:[e-mail]
>>>>                     <mailto:[e-mail]>>> wrote:
>>>>                     In this context, I suggest we pick some words
>>>>                     to work with, and sharpen them as we move on,
>>>>                     discover and map new use cases to the protocol.
>>>>
>>>>                     In this diagram from the original thread
>>>>                     (https://mailarchive.ietf.org/arch/msg/txauth/IaSLC_72_KimjOBJqdmQY-JOGNw/),
>>>>                     I replaced the words:
>>>>
>>>>                     +-----------+ +--------------+ +----+  +----+
>>>>                     +---------------------+
>>>>                     | Requestor |      | Orchestrator |  |    | |
>>>>                     GS |  | Resource Controller |
>>>>                     |   was     |      |  was      |  | RS |  | or
>>>>                     |  |         was    |
>>>>                     |  User     |      |  Client     |  |    |  |
>>>>                     AS |  |    Resource Owner   |
>>>>                     +-----------+ +--------------+ +----+  +----+
>>>>                     +---------------------+
>>>>                       |(1) ServiceRequest  |            |       |  
>>>>                                 |
>>>>                     |---------------------->|           |       |  
>>>>                             |
>>>>                       |  |(2) ServiceIntent:AuthZChallenge    |
>>>>                       |  |<---------->|    |                |
>>>>                       |  |            |       |               |
>>>>                       |  |(3) AuthZRequest(AuthZChallenge)    |
>>>>                       |  |------------------->|                |
>>>>                       |  |            |  |(4) ConsentRequest:Grant
>>>>                       |  |            |  |<-------------->|
>>>>                       |  |(5) GrantAccess(AuthZ)          |
>>>>                       |  |<-------------------|                |
>>>>                       |  |            |       |               |
>>>>                       |  |(6) ServiceRequest(AuthZ):ServiceResponse
>>>>                       |  |<---------->|    |                |
>>>>                       |(7) ServiceResponse   |            |  |     
>>>>                               |
>>>>                     |<----------------------|           |       |  
>>>>                             |
>>>>                       +  +            +       +               +
>>>>
>>>>                     The purpose of the GNAP protocol is to help
>>>>                     negotiate access to a protected resource. It
>>>>                     starts with a requestor delegating activity to
>>>>                     an orchestrator. These are all roles, no
>>>>                     entities. Let focus on mapping the use cases to
>>>>                     the protocol roles and interactions so wwe can
>>>>                     discover what is missing.
>>>>
>>>>                     It seems cumbersome to use it in discussions as
>>>>                     it is impossible to give the word "Client" a
>>>>                     clear definition.
>>>>
>>>>                     We can mention in the final document, that the
>>>>                     "Orchestrator" (or whatever word we finally
>>>>                     use) plays the same role as the "Client" in oAuth2.
>>>>
>>>>                     Best regards.
>>>>                     /Francis
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>                     On Wed, Aug 5, 2020 at 9:05 PM Dick Hardt
>>>>                     <[e-mail]
>>>>                     <mailto:[e-mail]><mailto:[e-mail]
>>>>                     <mailto:[e-mail]>>> wrote:
>>>>                     I agree with Justin. Redefining well used terms
>>>>                     will lead to significant confusion. If we have
>>>>                     a different role than what we have had in the
>>>>                     past, then that role should have a name not
>>>>                     being used already in OAuth or OIDC.
>>>>
>>>>                     Given what we have learned, and my own
>>>>                     experience explaining what a Client is, and is
>>>>                     not, improving the definition for Client could
>>>>                     prove useful. I am not suggesting the term be
>>>>                     redefined, but clarified.
>>>>
>>>>                     For example, clarifying that a Client is a role
>>>>                     an entity plays in the protocol, and that the
>>>>                     same entity may play other roles at other
>>>>                     times, or some other language to help
>>>>                     differentiate between "role" and "entity".
>>>>
>>>>                     /Dick
>>>>                     [https://mailfoogae.appspot.com/t?sender=aZGljay5oYXJkdEBnbWFpbC5jb20%3D&type=zerocontent&guid=e48e13f4-2306-4d7c-8654-d50e00dbac3a]ᐧ
>>>>                     <https://mailfoogae.appspot.com/t?sender=aZGljay5oYXJkdEBnbWFpbC5jb20%3D&type=zerocontent&guid=e48e13f4-2306-4d7c-8654-d50e00dbac3a]%E1%90%A7>
>>>>
>>>>                     On Wed, Aug 5, 2020 at 8:20 AM Justin Richer
>>>>                     <jricher@mit..edu
>>>>                     <mailto:jricher@mit..edu><mailto:[e-mail]
>>>>                     <mailto:[e-mail]>>> wrote:
>>>>                     I’m in favor of coming up with a new term
>>>>                     that’s a better fit, but I’m not really in
>>>>                     favor of taking an existing term and applying a
>>>>                     completely new definition to it. In other
>>>>                     words, I would sooner stop using “client” and
>>>>                     come up with a new, more specific and accurate
>>>>                     term for the role than to define “client” as
>>>>                     meaning something completely different. We did
>>>>                     this in going from OAuth 1 to OAuth 2 already,
>>>>                     moving from the even-more-confusing “consumer”
>>>>                     to “client”, but OAuth 2 doesn’t use the term
>>>>                     “consumer” at all, nor does it use “server” on
>>>>                     its own but instead always qualifies it with
>>>>                     “Authorization Server” and “Resource Server”.
>>>>
>>>>                     GNAP can do something similar, in my opinion.
>>>>                     But what we can’t do is ignore the fact that
>>>>                     GNAP is going to be coming up in a world that
>>>>                     is already permeated  by OAuth 2 and its
>>>>                     terminology. We don’t have a blank slate to
>>>>                     work with, but neither are we bound to use the
>>>>                     same terms and constructs as before. It’s going
>>>>                     to be a delicate balance!
>>>>
>>>>                      — Justin
>>>>
>>>>                     On Aug 4, 2020, at 3:32 PM, Warren Parad
>>>>                     <[e-mail]
>>>>                     <mailto:[e-mail]><mailto:[e-mail]
>>>>                     <mailto:[e-mail]>>> wrote:
>>>>
>>>>                     I think that is fundamentally part of the question:
>>>>                     We are clear that we are producing a protocol
>>>>                     that is
>>>>                     conceptually (if not more strongly) related to
>>>>                     OAuth 2.0, and reusing terms
>>>>                     from OAuth 2.0 but with different definitions
>>>>                     may lead to unnecessary
>>>>                     confusion
>>>>
>>>>                     If we say that this document assumes OAuth2.0
>>>>                     terminology, then we should not change the
>>>>                     meanings of any definition. If we are saying
>>>>                     this supersedes or replaces what OAuth 2.0
>>>>                     creates, then we should pick the best word for
>>>>                     the job and ignore conflicting meanings from
>>>>                     OAuth 2.0. I have a lot of first hand
>>>>                     experience of industries "ruining words", and
>>>>                     attempting to side-step the problem rather than
>>>>                     redefining the word just confuses everyone as
>>>>                     everyone forgets the original meaning as new
>>>>                     documents come out, but the confusion with the
>>>>                     use of a non-obvious word continues.
>>>>
>>>>                     Food for thought.
>>>>                     - Warren
>>>>
>>>>                     [https://lh6.googleusercontent.com/DNiDx1QGIrSqMPKDN1oKevxYuyVRXsqhXdfZOsW56Rf2A74mUKbAPtrJSNw4qynkSjoltWkPYdBhaZJg1BO45YOc1xs6r9KJ1fYsNHogY-nh6hjuIm9GCeBRRzrSc8kWcUSNtuA]
>>>>
>>>>                     Warren Parad
>>>>                     Founder, CTO
>>>>
>>>>                     Secure your user data and complete your
>>>>                     authorization architecture. Implement
>>>>                     Authress<https://bit. <https://bit./>.ly/37SSO1p>.
>>>>
>>>>
>>>>                     On Tue, Aug 4, 2020 at 8:53 PM Benjamin Kaduk
>>>>                     <[e-mail]
>>>>                     <mailto:[e-mail]><mailto:[e-mail]
>>>>                     <mailto:[e-mail]>>> wrote:
>>>>                     Hi Denis,
>>>>
>>>>                     On Tue, Aug 04, 2020 at 11:31:34AM +0200, Denis
>>>>                     wrote:
>>>>                     > Hi Justin,
>>>>                     >
>>>>                     > Since you replied in parallel, I will make a
>>>>                     response similar to the one
>>>>                     > I sent to Dick.
>>>>                     >
>>>>                     > > Hi Denis,
>>>>                     > >
>>>>                     > > I think there’s still a problem with the
>>>>                     terminology in use here. What
>>>>                     > > you describe as RS2, which might in fact be
>>>>                     an RS unto itself, is a
>>>>                     > > “Client” in OAuth parlance because it is /a
>>>>                     client of RS1/. What you
>>>>                     > > call a “client” has no analogue in the
>>>>                     OAuth world, but it is not at
>>>>                     > > all the same as an OAuth client. I
>>>>                     appreciate your mapping of the
>>>>                     > > entities below, but it makes it difficult
>>>>                     to hold a discussion if we
>>>>                     > > aren’t using the same terms.
>>>>                     > >
>>>>                     > > The good news is that this isn’t OAuth, and
>>>>                     as a new WG we can define
>>>>                     > > our own terms. The bad news is that this is
>>>>                     really hard to do.
>>>>                     > >
>>>>                     > > In GNAP, we shouldn’t just re-use existing
>>>>                     terms with new definitions,
>>>>                     > > but we’ve got a chance to be more precise
>>>>                     with how we define things.
>>>>                     >
>>>>                     > In the ISO context, each document must define
>>>>                     its own terminology. The
>>>>                     > boiler plate for RFCs does not mandate a
>>>>                     terminology or definitions section
>>>>                     > but does not prevent it either. The
>>>>                     vocabulary is limited and as long as
>>>>                     > we clearly define what our terms are meaning,
>>>>                     we can re-use a term already
>>>>                     > used in another RFC. This is also the ISO
>>>>                     approach.
>>>>
>>>>                     Just because we can do something does not
>>>>                     necessarily mean that it is a
>>>>                     good idea to do so.  We are clear that we are
>>>>                     producing a protocol that is
>>>>                     conceptually (if not more strongly) related to
>>>>                     OAuth 2.0, and reusing terms
>>>>                     from OAuth 2.0 but with different definitions
>>>>                     may lead to unnecessary
>>>>                     confusion.  If I understand correctly, a
>>>>                     similar reasoning prompted Dick to
>>>>                     use the term "GS" in XAuth, picking a name that
>>>>                     was not already used in
>>>>                     OAuth 2.0.
>>>>
>>>>                     -Ben
>>>>
>>>>                     --
>>>>                     Txauth mailing list
>>>>                     [e-mail]
>>>>                     <mailto:[e-mail]><mailto:[e-mail]
>>>>                     <mailto:[e-mail]>>
>>>>                     https://www.ietf.org/mailman/listinfo/txauth
>>>>                     --
>>>>                     Txauth mailing list
>>>>                     [e-mail]
>>>>                     <mailto:[e-mail]><mailto:[e-mail]
>>>>                     <mailto:[e-mail]>>
>>>>                     https://www.ietf.org/mailman/listinfo/txauth
>>>>
>>>>                     --
>>>>                     TXAuth mailing list
>>>>                     [e-mail]
>>>>                     <mailto:[e-mail]><mailto:[e-mail]
>>>>                     <mailto:[e-mail]>>
>>>>                     https://www.ietf.org/mailman/listinfo/txauth
>>>>                     --
>>>>                     TXAuth mailing list
>>>>                     [e-mail]
>>>>                     <mailto:[e-mail]><mailto:[e-mail]
>>>>                     <mailto:[e-mail]>>
>>>>                     https://www.ietf.org/mailman/listinfo/txauth
>>>>
>>>>
>>>>                     --
>>>>                     Francis Pouatcha
>>>>                     Co-Founder and Technical Lead
>>>>                     adorsys GmbH & Co. KG
>>>>                     https://adorsys-platform.de/solutions/
>>>>                     -- 
>>>>                     TXAuth mailing list
>>>>                     [e-mail] <mailto:[e-mail]>
>>>>                     https://www.ietf.org/mailman/listinfo/txauth
>>>>
>>>
>>
>>             -- 
>>             TXAuth mailing list
>>             [e-mail] <mailto:[e-mail]>
>>             https://www.ietf.org/mailman/listinfo/txauth
>>
>
>         -- 
>         TXAuth mailing list
>         [e-mail] <mailto:[e-mail]>
>         https://www.ietf.org/mailman/listinfo/txauth
>
>
>
>     -- 
>     Francis Pouatcha
>     Co-Founder and Technical Lead
>     adorsys GmbH & Co. KG
>     https://adorsys-platform.de/solutions/
>     -- 
>     TXAuth mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/txauth
>