Re: [GNAP] User consent

[Francis Pouatcha <[e-mail]>]

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]> 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 AND and 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 U2F or 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]> 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]> 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]>
>>> 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]> 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]]
>>>> Sent: Tuesday, August 11, 2020 6:21 PM
>>>> To: Francis Pouatcha
>>>> Cc: Justin Richer; Denis; Benjamin James Kaduk; [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]>> 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]>> 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:
>>>> [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]>> 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..ly/37SSO1p>.
>>>>
>>>>
>>>> On Tue, Aug 4, 2020 at 8:53 PM Benjamin Kaduk <[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]>
>>>> 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
>>>> --
>>>> 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]
>>>> https://www.ietf.org/mailman/listinfo/txauth
>>>>
>>>
>>>
>> --
>> TXAuth mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/txauth
>>
>
> --
> TXAuth mailing list
> [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/