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

[Fabien Imbault <[e-mail]>]

Hi Francis,

To clarify the various interaction modes, I've entered a new use case:
https://github.com/ietf-wg-gnap/general/wiki/Categories-of-interaction
Compared to the other cases, I think the use case "User != RO and
interact_mode = synchronous" is challenging, but SSI could be of great
help.

I've also entered a SSI use case:
https://github.com/ietf-wg-gnap/general/wiki/SSI-integration (very high
level, more as a reminder for now).

Fabien

On Mon, Aug 17, 2020 at 4:02 PM Francis Pouatcha <[e-mail]> wrote:

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