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

Francis Pouatcha <fpo@adorsys.de> Tue, 18 August 2020 20:46 UTC

Return-Path: <fpo@adorsys.de>
X-Original-To: txauth@ietfa.amsl.com
Delivered-To: txauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DC2E3A0C1B for <txauth@ietfa.amsl.com>; Tue, 18 Aug 2020 13:46:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=adorsys.de
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7JR3J2DSN-ua for <txauth@ietfa.amsl.com>; Tue, 18 Aug 2020 13:46:23 -0700 (PDT)
Received: from mail-wr1-x436.google.com (mail-wr1-x436.google.com [IPv6:2a00:1450:4864:20::436]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D0CE3A0C20 for <txauth@ietf.org>; Tue, 18 Aug 2020 13:46:22 -0700 (PDT)
Received: by mail-wr1-x436.google.com with SMTP id r4so19450582wrx.9 for <txauth@ietf.org>; Tue, 18 Aug 2020 13:46:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=adorsys.de; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=EXpb12nYbx1ymCSJjGDDEtxcrUCJxT7No8Rp5upJiIg=; b=MDR9YgpUTqs4dgyEq0Z6tBAcIugnSmLYsI1mgaysRucg3GUWs7JnHX6RTbd8FR91yf IaeTTGCkONlyNb47fHACFaW1Sng6rSoY5FbzvyW9AnbAt8Q9ZN34SNsS9Mlo8vDZRwiw agDmyic2Ua1shyQd6Lwg+MiSGWKMn0WaCLPzA=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=EXpb12nYbx1ymCSJjGDDEtxcrUCJxT7No8Rp5upJiIg=; b=glQOiBURlXvvgGSdvxOFFrKXj5gk0gN9fjJ25NWbSHRbp5MCKjKB93zIAuweFQjQiF Xa8RfiSCUXAIReZ1JeSZ8gRtehljSh4XYzHqPpBaMl+FeMd0uAtX6WrhXjYrzGn1Vrpj rZR3Cj+gU4xGF8P0Ct/xbJ6AZgiJhu4pzGAQ7iRfEhhRfFY/ky/7lRBzfC3q28ixrblq 2G/Wi2GeugKRD1N6V80bjqUbWCKUYWGrevZyAiougaYOfdRQLP+FaYpWP90ZyKcPFbvw 2u9eyvEZ/E6C4uq/7dVid1CrmU3w9WmUNrldOgoHlsSSh7vPRVacdHQH7LvBTzmn1+hh JjOw==
X-Gm-Message-State: AOAM530Cuort5b0zsWfE1iukemeEaMGHG4y6d2dVNqN4EBU6qRbyJhrE Gd5S+R+1fuAOHI7iTeRbeAFoiGB5wu4XB0x6jjnLKg==
X-Google-Smtp-Source: ABdhPJwdAc50O2bH2GgCfuNrjdvdiiLjqe2PLvdb20gkghPAA5tHHIu75ojYFUgxB4qVkzD7O9tH4aim2kw9Vh9MNlQ=
X-Received: by 2002:adf:cc88:: with SMTP id p8mr886881wrj.70.1597783580432; Tue, 18 Aug 2020 13:46:20 -0700 (PDT)
MIME-Version: 1.0
References: <CAD9ie-v_1GHHJWVeXb5cXiUELj-Un7BN6uCdqSRz4qjL_rq=UQ@mail.gmail.com> <CAOW4vyPEzcC0HCM2eRvZ3yjRp_S4rFdVcqqH3gmnpfbCLx-KNg@mail.gmail.com> <CAD9ie-v=7S-a4YRpNfKQxmfszoBEkAJuy6M7g_Z1PREDSFU2jw@mail.gmail.com> <CAOW4vyNuayU+6jSRPoy-nzzNiwtM5GttaF9vVGPNeNSix+E3dQ@mail.gmail.com> <CAM8feuTAjNgVJs=1V_8uqkkPWjM6Ums+A2rYizU7YyPLoVFQGg@mail.gmail.com> <CAOW4vyNBJaZ4eJc+spFiZv0qGEqysYk3WwE1_ExV5STwe86bPQ@mail.gmail.com> <CAM8feuR9t0RDceXBxYiMcdfPLEDStYVmQNLTeFHyhBiX1gnLyQ@mail.gmail.com> <CAOW4vyOfNUPNukxe1=TnrpJu8qDEEs-a_xpgJh=W-WDTf5X5Dg@mail.gmail.com> <CAM8feuRm2+6N+-2kyURZ6hjWVv2Utz5fi-XRc_L9FF0ApxrPyQ@mail.gmail.com>
In-Reply-To: <CAM8feuRm2+6N+-2kyURZ6hjWVv2Utz5fi-XRc_L9FF0ApxrPyQ@mail.gmail.com>
From: Francis Pouatcha <fpo@adorsys.de>
Date: Tue, 18 Aug 2020 16:46:08 -0400
Message-ID: <CAOW4vyMrVbVu0efdsASYcoGHeo98gjvqdt8KDRmbUwcPPBs4EA@mail.gmail.com>
To: Fabien Imbault <fabien.imbault@gmail.com>
Cc: Dick Hardt <dick.hardt@gmail.com>, GNAP Mailing List <txauth@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000bd7b4305ad2cfa22"
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/dVFyKI9wMdN14zFYZtEOZMTNwpU>
Subject: Re: [GNAP] draft-hardt-xauth-protocol-14 update - reworked introduction
X-BeenThere: txauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <txauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/txauth>, <mailto:txauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/txauth/>
List-Post: <mailto:txauth@ietf.org>
List-Help: <mailto:txauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/txauth>, <mailto:txauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 18 Aug 2020 20:46:29 -0000

Hello Fabien,

Thank you for creating the page. I dropped the first SSI use case at:
https://github.com/ietf-wg-gnap/general/wiki/SSI-integration#alice-purchasing-a-concert-ticket-without-disclosing-her-identity

Best regards
/Francis

On Tue, Aug 18, 2020 at 4:57 AM Fabien Imbault <fabien.imbault@gmail.com>
wrote:

> 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 <fpo@adorsys.de> wrote:
>
>> Hello Fabian,
>>
>> On Mon, Aug 17, 2020 at 8:17 AM Fabien Imbault <fabien.imbault@gmail.com>
>> 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 <fpo@adorsys.de> wrote:
>>>
>>>> Hello Fabian, inline
>>>>
>>>> On Mon, Aug 17, 2020 at 6:56 AM Fabien Imbault <
>>>> fabien.imbault@gmail.com> 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=
>>>>> 40adorsys.de@dmarc.ietf.org <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 <dick.hardt@gmail.com>
>>>>>> 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 <fpo@adorsys.de>
>>>>>>> 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 <dick.hardt@gmail.com>
>>>>>>>> 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
>>>>>>>>> TXAuth@ietf.org
>>>>>>>>> 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
>>>>>> TXAuth@ietf.org
>>>>>> 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/
>>
>

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