Re: [GNAP] draft-hardt-xauth-protocol-14 update - reworked introduction

[Francis Pouatcha <[e-mail]>]

Hello Fabian,

On Mon, Aug 17, 2020 at 8:17 AM Fabien Imbault <[e-mail]>
wrote:

> Hi Francis,
>
> Thanks for your comments. Mine are inline (marked with "FI"). I think most
> of that is clear now (except from the way to make it visible on a diagram).
>
> I'd actually like to focus more specifically on the previous exchange:
>
> Are we sure we need to formally separate B and C? This goes beyond
>> previous discussions of separating the front and back channels, and I don't
>> really see the advantage (maybe there is: which use cases would be
>> impossible to do otherwise?).
>>
> We have a situation where RP =!= RC. And each of them have their own AS.
>
> > In most cases, getting the asynchronous consent from the RC (distinct
> from the end-user) would be an issue (unless the end-user is ok to wait).
> > Here I guess you're considering the case where you want to interactively
> ask the RC (distinct from the end-user) to consent, instead of making a
> policy based decision.
>
> A practical scenario where we may encounter a synchronous consent request
> between distinct end-user/RP and RC: a patient has a medical appointment
> with a new doctor.
> The doctor needs to access the medical record of the patient. Here the
> doctor is the end-user/requestor and the patient is the RC.
> Since they're already interacting face to face (physically or through
> video), the patient takes his decision (yes/no for each requested item) as
> soon as the doctor asks him to provide some information.
>
> Is this type of synchronous interaction what you had in mind?
>
Yes. There are a lot of such use cases in banking, government, health.

>
> As for SSI, I think there should be a dedicated use case.
>
> Cheers
> Fabien
>
>
> On Mon, Aug 17, 2020 at 1:28 PM Francis Pouatcha <[e-mail]> wrote:
>
>> Hello Fabian, inline
>>
>> On Mon, Aug 17, 2020 at 6:56 AM Fabien Imbault <[e-mail]>
>> wrote:
>>
>>> Hi Francis,
>>>
>>> I like that alt2 introduces the additional discussions we had previously
>>> (on privacy and other topics) but I think this schema is too prescriptive.
>>>
>> This is why I pushed them into Alt-2.
>> In the most common use case at sight (oAuth2), GS, RC-AS,  RP-AS are
>> roles that might be represented by the same entity. This means the oAuth2
>> instantiated model might look very simple.
>>
>> FI ; yes
>
>>
>>>
>>
>>> Depending on the situation, one may either require the GS to provide the
>>> front-channel, or decide to separate it.
>>>
>> Yes. This is why exposing RC-AS in the diagram makes that case visible.
>> In those situations, [GS]=[RC-AS]=[RP-AS]=GS resulting  in the original
>> model of Dick.
>>
>>
>>> Why mandate that interaction B shall always occur through the GC? If I'
>>> a GC, I could just as well decide that it's enough to just separate the
>>> front-channel from the GS, without handling it myself.
>>>
>> Having GS +++(B)+++> RP is the oAuth2 model again. THis is what Dick has
>> in the original diagram.
>>
>> There are some cases where GS might need to gain knowledge of some claims
>> about RP, but do not need to know their identity. E.g.: age(RP) > 18.
>> In those cases [GS] --(3)-->[GC]++(B)++>[RP] makes sense.
>>
>
> FI : yes, although in practice most verified credentials are bundled with
> some claims about identity. Like I'm a student in a bar, I'm going to show
> the proof of age (instead of date of birth) but am still required to show
> my name too (or a picture, or whatever that proves I didn't get a proof
> which belongs to someone else).
>
RP-AS will verify RP identity and produce different RP-identifiers for each
grant negotiation use case [GC,RS,GS], thereby preservice RP privacy and
preventing correlations.


>
>>
>> And in some cases RP-AS resides on RP's device (SSI). And we find ourself
>> with:
>> [GS] --(3)-->[GC]-->(B0)-->[RP-AS]++(B1)++>[RP]
>>
>
> FI : this type of interaction with SSI wallets directly on the mobile
> device would be interesting to dig into. If it hasn't been done yet, we
> should add a use case.
>
Yes...


>>
>>> Why mandate that interaction C shall always occur through a GS? (I'm
>>> sure Denis will not want this, for instance).
>>>
>> This is not a mandate, but an abstract model. In SSI/DID most of the
>> time, RP-RC will also reside on a user device.
>>
>
> FI : problem is that if you show that, most people will assume it's
> mandatory (as least for the alt2 part). At least I think that's what most
> readers would assume from reading the schema.
>
Therefore it is essential to have Dick introduce the section 1.3 with the
notion that this is an abstract model that might take a different concrete
form for each problem domain (resp. trust model)

errata: Above i meant [RP-AS will also reside on a user device] and not
[RP-RC].
/Francis

>
>
>> Are we sure we need to formally separate B and C? This goes beyond
>>> previous discussions of separating the front and back channels, and I don't
>>> really see the advantage (maybe there is: which use cases would be
>>> impossible to do otherwise?).
>>>
>> We have a situation where RP =!= RC. And each of them have their own AS.
>>
>
> FI : see discussion at the start of the message
>
>>
>>
>>> So overall, I think Alt2 over-complexifies the situation. We need to
>>> remain flexible.
>>> Why not simply have an (optional) way of separating these flows from the
>>> GS?
>>>
>> With GNAP, we are at an abstraction level-0, like referred to in my
>> former post. At level-1 we can address concrete protocols like oAuth, OIDC,
>> [SSI/DiD/VC] and the diagram will look simple.
>>
>
> FI : yes.
>
>>
>>
>>> For instance, an (optional) Interact Server (IS) could provide support
>>> for a decoupled front-channel:
>>> - it does not change the interaction between a GC and a GS. It does
>>> change the trust model though, depending on which options are chosen. In
>>> practice, the GC may specify which IS it wants to use (it can be his own,
>>> for instance). In case nothing is specified, the GS decides.
>>> - the IS is able to handle the front-channel for idclaims and consent,
>>> and return back to the GS what access tokens are required.
>>> - notice that although the IS is focused on front-channel interaction,
>>> there are cases where the consent needs to be based on policies instead of
>>> a direct human interaction (typically when end-user is not the RC, and
>>> therefore the end-user is not the one that is asked for consent / then of
>>> course, if the RC logs in, he would be able to manage his consent
>>> policies).
>>>
>> What you mention here is why I display RP-AS and RC-AS!
>>
>>
>>> So there's really no obligation that B occurs through the GC and C
>>> occurs through the GS. It depends on where your front-channel is located
>>> (GC, GS, third-party).
>>>
>> Yes. I agree with you. How can we make this  visible in a diagram?
>>
>
> FI : let me think about it ;-)
>
>
>>
>> This I think makes it a very flexible model, while enabling what we're
>>> after.
>>>
>> Yes.
>> /Francis
>>
>>>
>>> Fabien
>>>
>>>
>>> On Mon, Aug 17, 2020 at 4:38 AM Francis Pouatcha <fpo=
>>> [e-mail] <40adorsys.de@dmarc..ietf.org>> wrote:
>>>
>>>> Hello Dick,
>>>>
>>>> Thanks for pointing this out. This is the new diagram where ++++
>>>> refers to what Endpoint/Human interaction and ----> refers to interaction
>>>> among services.
>>>>
>>>>     +-------------+                        +----------------+
>>>>     | Requesting  |                        |  Resource      |
>>>>     | Party (RP)  |                        | Controller (RC)|
>>>>     +-------------+                        +----------------+
>>>>         +     +                             +
>>>>         +      +                           +
>>>>        (A)     (B1)                      (C1)
>>>>         +        +                       +
>>>>         +.        +                     +
>>>>         +       +--------+         +--------+
>>>>         +       | RP-AS  |         | RC-AS  |
>>>>         +  +--->|        |     +-->|        |
>>>>         +  |    +--------+     |   +--------+
>>>>         +  |                   |
>>>>         + (B0)                 |
>>>>         +  |                  (C0)
>>>>     +--------+                 |             +------------+
>>>>     | Grant  |--------(1)------|------------>|  Resource  |
>>>>     | Client |                 |             |   Server   |
>>>>     |  (GC)  |       +---------------+       |    (RS)    |
>>>>     |        |--(2)->|     Grant     |       |            |
>>>>     |        |<-(3)->|     Server    |- (6) -|            |
>>>>     |        |<-(4)--|      (GS)     |       |            |
>>>>     |        |       +---------------+       |            |
>>>>     |        |                               |            |
>>>>     |        |--------------(5)------------->|            |
>>>>     +--------+                               +------------+
>>>>
>>>>
>>>> It is still important to know what is part of the protocol:
>>>> Alt-1: only (1..6). This is what you specified in section 1.2, and I am
>>>> fine with that.
>>>> Alt-2: Alt-1 + (B0, C0). This is a result of the discussion we have
>>>> been having around privacy, GS as big brother, aso....
>>>>
>>>> P.S.: an authentication [RP]+++(A)+++>[GC] can be assumed, but shall be
>>>> irrelevant for the protocol. [RP]+++(B1)+++>[RP-AS] is important for later
>>>> instantiation of the model. As in many cases, like in oAuth [RP-AS] could
>>>> be the same entity like [GS].
>>>>
>>>> Best regards.
>>>> /Francis
>>>>
>>>>
>>>> On Sun, Aug 16, 2020 at 7:04 PM Dick Hardt <[e-mail]>
>>>> wrote:
>>>>
>>>>> Hi Francis
>>>>>
>>>>> I was intentional in stating 1.3 that it is human interactions. The
>>>>> connection lines are '+ + +' rather than '-----' to indicate that it is a
>>>>> human interaction rather than a protocol between roles. We can't specify
>>>>> how a human interaction works, but we can show when they might occur
>>>>> relative to the rest of the protocol
>>>>>
>>>>> In the abstract diagram in 1.3, I show the interactions between the
>>>>> User and the GC, the User and the GS, and the RO and the GS. These are NOT
>>>>> interactions that can be technically specified. The User and RO are not
>>>>> roles in the protocol, but are entities in the trust model.
>>>>>
>>>>> I debated keeping the interactions abstract and not stating "what"
>>>>> happened in each interaction, but thought that might be confusing at this
>>>>> stage or our discussions.
>>>>>
>>>>> Since it is just an interaction between human and software, we can
>>>>> have the User authenticate to the GC as well as authorize (provide
>>>>> consent), and have no interaction at the GS. We would need to define how to
>>>>> represent the authorization and the consent for the GC to pass to the GS,
>>>>> but the roles and entities stay the same. The trust model does change
>>>>> though.
>>>>>
>>>>> /Dick
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Sun, Aug 16, 2020 at 3:46 PM Francis Pouatcha <[e-mail]>
>>>>> wrote:
>>>>>
>>>>>> Hello Dick, my feedback below:
>>>>>>
>>>>>> 1.2: Excellent and Focussed
>>>>>> -> The word "Grant Client" looks great for me.
>>>>>>
>>>>>> 1.3:
>>>>>> Title: Human Interaction -> End User Interaction
>>>>>> I would title this "End User" interaction and not "human ...". It is
>>>>>> not about having a human, but a terminating edge of the protocol. An "End
>>>>>> User" can be either human on an IOT device or a car or ...
>>>>>>
>>>>>> Participant: User -> "Requesting Party"
>>>>>> I will still insist on replacing the word "User" with a role name.
>>>>>> Maybe "Requesting Party" as used by UMA.
>>>>>>
>>>>>> Participant: "Resource Controller". In past discussions there was a
>>>>>> consensus on using "Resource Controller" instead.
>>>>>>
>>>>>> (B) I which the GS never interacts with the "Requesting Party" in a
>>>>>> matter of obtaining a grant to a resource (many reasons: privacy,
>>>>>> confidentiality, abstraction, ...). Generally the GS will need information
>>>>>> (claims) about the "Requesting Party" to proceed with the authorisation
>>>>>> decision. In this case, the GS can instruct the GC to obtain those claims.
>>>>>> In some cases, claims on the "Requesting Party" will be obtained from
>>>>>> another "Authorization Server" (AS). The word AS is intentionally chosen
>>>>>> here. In this same login, the path (C0, C1) below will not only return the
>>>>>> RC consent, but might also return some claims on RC.
>>>>>>
>>>>>> ASs provide authentication "of" and consent collection "from" End
>>>>>> Users. End users are in this case the Requesting Party, and the Resource
>>>>>> Controller).
>>>>>>
>>>>>> The result can look like the modified diagram below. With this we can
>>>>>> address some privacy concerns that are being discussed on the list.
>>>>>>
>>>>>>     +-------------+                        +----------------+
>>>>>>     | Requesting  |                        |  Resource      |
>>>>>>     | Party (RP)  |                        | Controller (RC)|
>>>>>>     +-------------+                        +----------------+
>>>>>>         +     +                             +
>>>>>>         +      +                           +
>>>>>>        (A)     (B1)                      (C1)
>>>>>>         +        +                       +
>>>>>>         +.        +                     +
>>>>>>         +       +--------+       +--------+
>>>>>>         +       | RP-AS  |       | RC-AS  |
>>>>>>         +       |        |       |        |
>>>>>>         +       +--------+       +--------+
>>>>>>         +         +                  +
>>>>>>         +       (B0)                +
>>>>>>         +       +                (C0)
>>>>>>     +--------+ +                  +          +------------+
>>>>>>     | Grant  | - - - -(1)- - - - + - - - - ->|  Resource  |
>>>>>>     | Client |                  +            |   Server   |
>>>>>>     |  (GC)  |       +---------------+       |    (RS)    |
>>>>>>     |        |--(2)->|     Grant     |       |            |
>>>>>>     |        |<-(3)->|     Server    |- (6) -|            |
>>>>>>     |        |<-(4)--|      (GS)     |       |            |
>>>>>>     |        |       +---------------+       |            |
>>>>>>     |        |                               |            |
>>>>>>     |        |--------------(5)------------->|            |
>>>>>>     +--------+                               +------------+
>>>>>>
>>>>>> (B0, B1) replace (B). Occur inside step (3), GS asks GC to collect
>>>>>> the claims. GC contacts RP-AS to negotiate those claims. But it is
>>>>>> important to mention that those Claims-RP are not the target Grant being
>>>>>> negotiated for the resource access. They are generally used by GS (and
>>>>>> later RS) as input into performing authz decisions.
>>>>>>
>>>>>> (C0, C1) replace (C). They occur after step (3) (Beware of the
>>>>>> difference to Bs that occur inside 3). This separation address the Big
>>>>>> Brother problem we have been discussing in the list.
>>>>>>
>>>>>> Essential is to mention that in an instantiation of this model for
>>>>>> oAuth for example:
>>>>>> - GS, RP-AS and RC-AS might be the same entity.
>>>>>> - RP and RC might refer to the same "End User".
>>>>>>
>>>>>> Off-topic: The splitting of GS and AS was suggested in some
>>>>>> discussions on the mailing list. But we have no mean yet to isolate good
>>>>>> inputs for later reuse. This is why I suggest we compile some inputs into
>>>>>> tickets or wiki pages (like use cases).
>>>>>>
>>>>>> 1.4:
>>>>>> The Trust model introduces what I would rather call the trust
>>>>>> framework. The purpose of the trust framework will be to address topics
>>>>>> mentioned in this section. There is still a lot of discussion needed to
>>>>>> have a structure for this section.
>>>>>>
>>>>>>
>>>>>> 1.5
>>>>>> I suggest again we replace Human with "End User" and still make them
>>>>>> roles. This is:
>>>>>> Terminology (Are all roles)
>>>>>>   -> These roles can be borne by End Users
>>>>>>      -> Requesting Party (RP)
>>>>>>      -> Resource Controller (RC)
>>>>>>   -> These role can be borne by Services
>>>>>>      -> GS
>>>>>>      -> GC
>>>>>>      -> RS
>>>>>>      -> RP-AS
>>>>>>      -> RC-AS
>>>>>>
>>>>>> I will stop here, as the fundamental agreement on this structure is
>>>>>> necessary for a qualified review of section 2++.
>>>>>>
>>>>>> Best regards
>>>>>> /Francis
>>>>>>
>>>>>> On Sat, Aug 15, 2020 at 7:03 PM Dick Hardt <[e-mail]>
>>>>>> wrote:
>>>>>>
>>>>>>> Hello
>>>>>>>
>>>>>>> I just pushed an updated version of XAuth:
>>>>>>>
>>>>>>> https://tools..ietf.org/id/draft-hardt-xauth-protocol-14.html
>>>>>>> <https://tools.ietf..org/id/draft-hardt-xauth-protocol-14.html>
>>>>>>>
>>>>>>> Highlights:
>>>>>>>
>>>>>>>    - renamed Client -> Grant Client
>>>>>>>    - Introduced Client Owner, Grant Server Owner as new entities
>>>>>>>    - renamed Authorizations -> Access
>>>>>>>    - An Access contains an array of RAR objects now
>>>>>>>    - Reworked diagram an intro to focus on Grant, and separate
>>>>>>>    protocol roles from human interactions.
>>>>>>>
>>>>>>> New introduction included below for your convenience
>>>>>>>
>>>>>>> /Dick
>>>>>>>
>>>>>>>    -
>>>>>>>
>>>>>>> 1.
>>>>>>> <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1>
>>>>>>> Introduction
>>>>>>> <https://tools..ietf.org/id/draft-hardt-xauth-protocol-14.html#name-introduction>
>>>>>>>
>>>>>>> *EDITOR NOTE*
>>>>>>> <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1-1>
>>>>>>>
>>>>>>> *This document captures a number of concepts that may be adopted by
>>>>>>> the proposed GNAP working group. Please refer to this document as:*
>>>>>>> <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1-2>
>>>>>>>
>>>>>>> *XAuth*
>>>>>>> <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1-3>
>>>>>>>
>>>>>>> *The use of GNAP in this document is not intended to be a
>>>>>>> declaration of it being endorsed by the GNAP working group.*
>>>>>>> <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1-4>
>>>>>>>
>>>>>>> This document describes the core Grant Negotiation and Authorization
>>>>>>> Protocol (GNAP). The protocol supports the widely deployed use cases
>>>>>>> supported by OAuth 2.0 [RFC6749
>>>>>>> <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#RFC6749>
>>>>>>> ] & [RFC6750
>>>>>>> <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#RFC6750>
>>>>>>> ], OpenID Connect [OIDC
>>>>>>> <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#OIDC>] -
>>>>>>> an extension of OAuth 2.0, as well as other extensions. Related documents
>>>>>>> include: GNAP - Advanced Features [GNAP_Advanced
>>>>>>> <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#GNAP_Advanced>
>>>>>>> ] and JOSE Authentication [JOSE_Authentication
>>>>>>> <https://tools.ietf..org/id/draft-hardt-xauth-protocol-14.html#JOSE_Authentication>
>>>>>>> ] that describes the JOSE mechanisms for client authentication.
>>>>>>> <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1-5>
>>>>>>>
>>>>>>> The technology landscape has changed since OAuth 2.0 was initially
>>>>>>> drafted. More interactions happen on mobile devices than PCs. Modern
>>>>>>> browsers now directly support asymetric cryptographic functions. Standards
>>>>>>> have emerged for signing and encrypting tokens with rich payloads (JOSE)
>>>>>>> that are widely deployed.
>>>>>>> <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1-6>
>>>>>>>
>>>>>>> GNAP simplifies the overall architectural model, takes advantage of
>>>>>>> today's technology landscape, provides support for all the widely deployed
>>>>>>> use cases, offers numerous extension points, and addresses many of the
>>>>>>> security issues in OAuth 2.0 by passing parameters securely between parties
>>>>>>> rather than via a browser redirection.
>>>>>>> <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1-7>
>>>>>>>
>>>>>>> While GNAP is not backwards compatible with OAuth 2.0, it strives to
>>>>>>> minimize the migration effort.
>>>>>>> <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1-8>
>>>>>>>
>>>>>>> The suggested pronunciation of GNAP is "guh-nap".
>>>>>>> <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1-9>
>>>>>>> 1.1.
>>>>>>> <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.1>The
>>>>>>> Grant
>>>>>>> <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#name-the-grant>
>>>>>>>
>>>>>>> The Grant is at the center of the protocol between a client and a
>>>>>>> server. A Grant Client requests a Grant from a Grant Server. The Grant
>>>>>>> Client and Grant Server negotiate the Grant. The Grant Server acquires
>>>>>>> authorization to grant the Grant to the Grant Client. The Grant Server then
>>>>>>> returns the Grant to the Grant Client.
>>>>>>> <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.1-1>
>>>>>>>
>>>>>>> The Grant Request may contain information about the User, the Grant
>>>>>>> Client, the interaction modes supported by the Grant Client, the requested
>>>>>>> identity claims, and the requested resource access. Extensions may define
>>>>>>> additional information to be included in the Grant Request.
>>>>>>> <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.1-2>
>>>>>>> 1.2.
>>>>>>> <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.2>Protocol
>>>>>>> Roles
>>>>>>> <https://tools..ietf.org/id/draft-hardt-xauth-protocol-14.html#name-protocol-roles>
>>>>>>>
>>>>>>> There are three roles in GNAP: the Grant Client (GC), the Grant
>>>>>>> Server (GS), and the Resource Server (RS). Below is how the roles interact:
>>>>>>> <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14..html#section-1..2-1>
>>>>>>>
>>>>>>>     +--------+                               +------------+
>>>>>>>     | Grant  | - - - - - - -(1)- - - - - - ->|  Resource  |
>>>>>>>     | Client |                               |   Server   |
>>>>>>>     |  (GC)  |       +---------------+       |    (RS)    |
>>>>>>>     |        |--(2)->|     Grant     |       |            |
>>>>>>>     |        |<-(3)->|     Server    |- (6) -|            |
>>>>>>>     |        |<-(4)--|      (GS)     |       |            |
>>>>>>>     |        |       +---------------+       |            |
>>>>>>>     |        |                               |            |
>>>>>>>     |        |--------------(5)------------->|            |
>>>>>>>     +--------+                               +------------+
>>>>>>>
>>>>>>>
>>>>>>> <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.2-2>
>>>>>>>
>>>>>>> (1) The GC may query the RS to determine what the RS requires from a
>>>>>>> GS for resource access. This step is not in scope for this document.
>>>>>>> <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.2-3>
>>>>>>>
>>>>>>> (2) The GC makes a Grant request to the GS (Create Grant Section 3.2
>>>>>>> <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#CreateGrant>).
>>>>>>> How the GC authenticates to the GS is not in scope for this document. One
>>>>>>> mechanism is [JOSE_Authentication
>>>>>>> <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#JOSE_Authentication>
>>>>>>> ].
>>>>>>> <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.2-4>
>>>>>>>
>>>>>>> (3) The GC and GS may negotiate the Grant.
>>>>>>> <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.2-5>
>>>>>>>
>>>>>>> (4) The GS returns a Grant to the GC (Grant Response Section 4.1
>>>>>>> <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#GrantResponse>
>>>>>>> ).
>>>>>>> <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.2-6>
>>>>>>>
>>>>>>> (5) The GC accesses resources at the RS (RS Access Section 6
>>>>>>> <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#RSAccess>
>>>>>>> ).
>>>>>>> <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.2-7>
>>>>>>>
>>>>>>> (6) The RS evaluates access granted by the GS to determine access
>>>>>>> granted to the GC. This step is not in scope for this document.
>>>>>>> <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.2-8>
>>>>>>> 1.3.
>>>>>>> <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.3>Human
>>>>>>> Interactions
>>>>>>> <https://tools..ietf..org/id/draft-hardt-xauth-protocol-14.html#name-human-interactions>
>>>>>>>
>>>>>>> The Grant Client may be interacting with a human end-user (User),
>>>>>>> and the Grant Client may need to get authorization to release the Grant
>>>>>>> from the User, or from the owner of the resources at the Resource Server,
>>>>>>> the Resource Owner (RO)
>>>>>>> <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.3-1>
>>>>>>>
>>>>>>> Below is when the human interactions may occur in the protocol:
>>>>>>> <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.3-2>
>>>>>>>
>>>>>>>     +--------+                               +------------+
>>>>>>>     |  User  |                               |  Resource  |
>>>>>>>     |        |                               | Owner (RO) |
>>>>>>>     +--------+                               +------------+
>>>>>>>         +     +                             +
>>>>>>>         +      +                           +
>>>>>>>        (A)     (B)                       (C)
>>>>>>>         +        +                       +
>>>>>>>         +         +                     +
>>>>>>>     +--------+     +                   +     +------------+
>>>>>>>     | Grant  | - - -+- - - -(1)- - - -+- - ->|  Resource  |
>>>>>>>     | Client |       +               +       |   Server   |
>>>>>>>     |  (GC)  |       +---------------+       |    (RS)    |
>>>>>>>     |        |--(2)->|     Grant     |       |            |
>>>>>>>     |        |<-(3)->|     Server    |- (6) -|            |
>>>>>>>     |        |<-(4)--|      (GS)     |       |            |
>>>>>>>     |        |       +---------------+       |            |
>>>>>>>     |        |                               |            |
>>>>>>>     |        |--------------(5)------------->|            |
>>>>>>>     +--------+                               +------------+
>>>>>>>
>>>>>>> Legend
>>>>>>> + + + indicates an interaction with a human
>>>>>>> ----- indicates an interaction between protocol roles
>>>>>>>
>>>>>>>
>>>>>>> <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.3-3>
>>>>>>>
>>>>>>> Steps (1) - (6) are the same as Section 1.2
>>>>>>> <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#ProtocolRoles>.
>>>>>>> The addition of the human interactions (A) - (C) are *bolded* below.
>>>>>>> <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.3-4>
>>>>>>>
>>>>>>> *(A) The User is interacting with a GC, and the GC needs resource
>>>>>>> access and/or identity claims (a Grant)*
>>>>>>> <https://tools..ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.3-5>
>>>>>>>
>>>>>>> (1) The GC may query the RS to determine what the RS requires from a
>>>>>>> GS for resource access
>>>>>>> <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.3-6>
>>>>>>>
>>>>>>> (2) The GC makes a Grant request to the GS
>>>>>>> <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.3-7>
>>>>>>>
>>>>>>> (3) The GC and GS may negotiate the Grant
>>>>>>> <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.3-8>
>>>>>>>
>>>>>>> *(B) The GS may interact with the User for grant authorization*
>>>>>>> <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.3-9>
>>>>>>>
>>>>>>> *(C) The GS may interact with the RO for grant authorization*
>>>>>>> <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.3-10>
>>>>>>>
>>>>>>> (4) The GS returns a Grant to the GC
>>>>>>> <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.3-11>
>>>>>>>
>>>>>>> (5) The GC accesses resources at the RS
>>>>>>> <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.3-12>
>>>>>>>
>>>>>>> (6) The RS evaluates access granted by the GS to determine access
>>>>>>> granted to the GC
>>>>>>> <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.3-13>
>>>>>>>
>>>>>>> Alternatively, the Resource Owner could be a legal entity that has a
>>>>>>> software component that the Grant Server interacts with for Grant
>>>>>>> authorization. This interaction is not in scope of this document.
>>>>>>> <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.3-14>
>>>>>>> 1.4.
>>>>>>> <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.4>Trust
>>>>>>> Model
>>>>>>> <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#name-trust-model>
>>>>>>>
>>>>>>> In addition to the User and the Resource Owner, there are three
>>>>>>> other entities that are part of the trust model:
>>>>>>> <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14..html#section-1.4-1>
>>>>>>>
>>>>>>>    - *Client Owner* (CO) - the legal entity that owns the Grant
>>>>>>>    Client.
>>>>>>>    <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.4-2.1>
>>>>>>>    - *Grant Server Owner* (GSO) - the legal entity that owns the
>>>>>>>    Grant Server.
>>>>>>>    <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.4-2.2>
>>>>>>>    - *Claims Issuer* (Issuer) - a legal entity that issues identity
>>>>>>>    claims about the User. The Grant Server Owner may be an Issuer, and the
>>>>>>>    Resource Owner may be an Issuer.
>>>>>>>    <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.4-2.3>
>>>>>>>
>>>>>>> These three entities do not interact in the protocol, but are
>>>>>>> trusted by the User and the Resource Owner:
>>>>>>> <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.4-3>
>>>>>>>
>>>>>>>   +------------+           +--------------+----------+
>>>>>>>   |    User    | >> (A) >> | Grant Server |          |
>>>>>>>   |            |           | Owner (GSO)  |          |
>>>>>>>   +------------+         > +--------------+          |
>>>>>>>         V              /          ^       |  Claims  |
>>>>>>>        (B)          (C)          (E)      |  Issuer  |
>>>>>>>         V          /              ^       | (Issuer) |
>>>>>>>   +------------+ >         +--------------+          |
>>>>>>>   |  Client    |           |   Resource   |          |
>>>>>>>   | Owner (CO) | >> (D) >> |  Owner (RO)  |          |
>>>>>>>   +------------+           +--------------+----------+
>>>>>>>
>>>>>>>
>>>>>>> <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.4-4>
>>>>>>>
>>>>>>> (A) User trusts the GSO to acquire authorization before making a
>>>>>>> grant to the CO
>>>>>>> <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.4-5>
>>>>>>>
>>>>>>> (B) User trusts the CO to act in the User's best interest with the
>>>>>>> Grant the GSO grants to the CO
>>>>>>> <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.4-6>
>>>>>>>
>>>>>>> (C) CO trusts claims issued by the GSO
>>>>>>> <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.4-7>
>>>>>>>
>>>>>>> (D) CO trusts claims issued by the RO
>>>>>>> <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.4-8>
>>>>>>>
>>>>>>> (E) RO trusts the GSO to manage access to the RO resources
>>>>>>> <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.4-9>
>>>>>>> 1.5.
>>>>>>> <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1..5>
>>>>>>> Terminology
>>>>>>> <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#name-terminology>
>>>>>>>
>>>>>>> *Roles*
>>>>>>> <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.5-1>
>>>>>>>
>>>>>>>    -
>>>>>>>
>>>>>>>    *Grant Client* (GC)
>>>>>>>    <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.5-2.1.1>
>>>>>>>    - may want access to resources at a Resource Server
>>>>>>>       <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.5-2.1.2.1>
>>>>>>>       - may be interacting with a User and want identity claims
>>>>>>>       about the User
>>>>>>>       <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.5-2.1.2.2>
>>>>>>>       - requests the Grant Service to grant resource access and
>>>>>>>       identity claims
>>>>>>>       <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.5-2.1..2.3>
>>>>>>>    -
>>>>>>>
>>>>>>>    *Grant Server* (GS)
>>>>>>>    <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.5-2.2.1>
>>>>>>>    - accepts Grant requests from the GC for resource access and
>>>>>>>       identity claims
>>>>>>>       <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14..html#section-1.5-2.2.2.1>
>>>>>>>       - negotiates the interaction mode with the GC if interaction
>>>>>>>       is required with the User
>>>>>>>       <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.5-2.2.2.2>
>>>>>>>       - acquires authorization from the User before granting
>>>>>>>       identity claims to the GC
>>>>>>>       <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.5-2.2.2.3>
>>>>>>>       - acquires authorization from the RO before granting resource
>>>>>>>       access to the GC
>>>>>>>       <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.5-2.2.2.4>
>>>>>>>       - grants resource access and identity claims to the GC
>>>>>>>       <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.5-2.2.2.5>
>>>>>>>    -
>>>>>>>
>>>>>>>    *Resource Server* (RS)
>>>>>>>    <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.5-2.3.1>
>>>>>>>    - has resources that the GC may want to access
>>>>>>>       <https://tools.ietf..org/id/draft-hardt-xauth-protocol-14.html#section-1.5-2.3.2.1>
>>>>>>>       - expresses what the GC must obtain from the GS for access
>>>>>>>       through documentation or an API. This is not in scope for this document
>>>>>>>       <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.5-2.3.2.2>
>>>>>>>       - verifies the GS granted access to the GC, when the GS makes
>>>>>>>       resource access requests
>>>>>>>       <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.5-2.3.2.3>
>>>>>>>
>>>>>>> *Humans*
>>>>>>> <https://tools.ietf..org/id/draft-hardt-xauth-protocol-14.html#section-1.5-3>
>>>>>>>
>>>>>>>    -
>>>>>>>
>>>>>>>    *User*
>>>>>>>    <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.5-4.1.1>
>>>>>>>    - the person interacting with the Grant Client.
>>>>>>>       <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.5-4.1.2.1>
>>>>>>>       - has delegated access to identity claims about themselves to
>>>>>>>       the Grant Server.
>>>>>>>       <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.5-4.1.2.2>
>>>>>>>       - may authenticate at the GS...
>>>>>>>       <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.5-4.1.2.3>
>>>>>>>    -
>>>>>>>
>>>>>>>    *Resource Owner* (RO)
>>>>>>>    <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.5-4.2.1>
>>>>>>>    - the legal entity that owns resources at the Resource Server
>>>>>>>       (RS).
>>>>>>>       <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1..5-4.2.2.1>
>>>>>>>       - has delegated resource access management to the GS.
>>>>>>>       <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.5-4.2.2..2>
>>>>>>>       - may be the User, or may be a different entity that the GS
>>>>>>>       interacts with independently.
>>>>>>>       <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.5-4.2.2.3>
>>>>>>>
>>>>>>> *Reused Terms*
>>>>>>> <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.5-5>
>>>>>>>
>>>>>>>    - *access token* - an access token as defined in [RFC6749
>>>>>>>    <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#RFC6749>
>>>>>>>    ] Section 1.4.. An GC uses an access token for resource access
>>>>>>>    at a RS.
>>>>>>>    <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.5-6.1>
>>>>>>>    - *Claim* - a Claim as defined in [OIDC
>>>>>>>    <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#OIDC>
>>>>>>>    ] Section 5. Claims are issued by a Claims Issuer.
>>>>>>>    <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.5-6..2>
>>>>>>>    - *Client ID* - a GS unique identifier for a Registered Client
>>>>>>>    as defined in [RFC6749
>>>>>>>    <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#RFC6749>
>>>>>>>    ] Section 2.2.
>>>>>>>    <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1..5-6.3>
>>>>>>>    - *ID Token* - an ID Token as defined in [OIDC
>>>>>>>    <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#OIDC>
>>>>>>>    ] Section 2. ID Tokens are issued by the GS. The GC uses an ID
>>>>>>>    Token to authenticate the User.
>>>>>>>    <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.5-6.4>
>>>>>>>    - *NumericDate* - a NumericDate as defined in [RFC7519
>>>>>>>    <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#RFC7519>
>>>>>>>    ] Section 2.
>>>>>>>    <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.5-6.5>
>>>>>>>    - *authN* - short for authentication.
>>>>>>>    <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.5-6.6>
>>>>>>>    - *authZ* - short for authorization.
>>>>>>>    <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.5-6.7>
>>>>>>>
>>>>>>> *New Terms*
>>>>>>> <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.5-7>
>>>>>>>
>>>>>>>    - *GS URI* - the endpoint at the GS the GC calls to create a
>>>>>>>    Grant, and is the unique identifier for the GS.
>>>>>>>    <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.5-8.1>
>>>>>>>    - *Registered Client* - a GC that has registered with the GS and
>>>>>>>    has a Client ID to identify itself, and can prove it possesses a key that
>>>>>>>    is linked to the Client ID. The GS may have different policies for what
>>>>>>>    different Registered Clients can request. A Registered Client MAY be
>>>>>>>    interacting with a User.
>>>>>>>    <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.5-8.2>
>>>>>>>    - *Dynamic Client* - a GC that has not been previously
>>>>>>>    registered with the GS, and each instance will generate it's own asymetric
>>>>>>>    key pair so it can prove it is the same instance of the GC on subsequent
>>>>>>>    requests.. The GS MAY return a Dynamic Client a Client Handle for the
>>>>>>>    Dynamic Client to identify itself in subsequent requests. A single-page
>>>>>>>    application with no active server component is an example of a Dynamic
>>>>>>>    Client.
>>>>>>>    <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.5-8.3>
>>>>>>>    - *Client Handle* - a unique identifier at the GS for a Dynamic
>>>>>>>    Client for the Dynamic Client to refer to itself in subsequent requests.
>>>>>>>    <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.5-8.4>
>>>>>>>    - *Interaction* - how the GC directs the User to interact with
>>>>>>>    the GS. This document defines the interaction modes: "redirect",
>>>>>>>    "indirect", and "user_code" in Section 5
>>>>>>>    <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#InteractionModes>
>>>>>>>    .
>>>>>>>    <https://tools..ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.5-8.5>
>>>>>>>    - *Grant* - the user identity claims and/or resource access the
>>>>>>>    GS has granted to the Client. The GS MAY invalidate a Grant at any time.
>>>>>>>    <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.5-8.6>
>>>>>>>    - *Grant URI* - the URI that represents the Grant. The Grant URI
>>>>>>>    MUST start with the GS URI.
>>>>>>>    <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14..html#section-1.5-8.7>
>>>>>>>    - *Access* - the access granted by the RO to the GC and contains
>>>>>>>    an access token. The GS may invalidate an Access at any time.
>>>>>>>    <https://tools.ietf.org/id/draft-hardt-xauth-protocol-14.html#section-1.5-8.8>
>>>>>>>    - *Access URI* - the URI that represents the Access the GC was
>>>>>>>    granted by the RO. The Access URI MUST start with the GS URI.. The Access
>>>>>>>    URI is used to refresh an access token.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> 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/
>>>>>>
>>>>>
>>>>
>>>> --
>>>> 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
>>>>
>>>
>>
>> --
>> Francis Pouatcha
>> Co-Founder and Technical Lead
>> adorsys GmbH & Co. KG
>> https://adorsys-platform.de/solutions/
>>
>

-- 
Francis Pouatcha
Co-Founder and Technical Lead
adorsys GmbH & Co. KG
https://adorsys-platform.de/solutions/