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

Fabien Imbault <fabien.imbault@gmail.com> Mon, 17 August 2020 06:13 UTC

Return-Path: <fabien.imbault@gmail.com>
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 3D8FA3A09C5 for <txauth@ietfa.amsl.com>; Sun, 16 Aug 2020 23:13:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, 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 (2048-bit key) header.d=gmail.com
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 GbE3fB54uxvZ for <txauth@ietfa.amsl.com>; Sun, 16 Aug 2020 23:13:24 -0700 (PDT)
Received: from mail-io1-xd33.google.com (mail-io1-xd33.google.com [IPv6:2607:f8b0:4864:20::d33]) (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 194F03A09C1 for <txauth@ietf.org>; Sun, 16 Aug 2020 23:13:24 -0700 (PDT)
Received: by mail-io1-xd33.google.com with SMTP id b16so16553822ioj.4 for <txauth@ietf.org>; Sun, 16 Aug 2020 23:13:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=lURbfUGMRldcP/EkDl8xs7QJzHbJymroAXb3OA1tqms=; b=Yv8TuB/WAQTE+y1nOwVqVtXpU6tNWq/T1AHDLo8Ilh4yvzlFoqqVPgw1LHPMDIJGAa WR0TKmOt0KMlbDbLh64LNLOguMFynveBA2XZNyoNdDY2sP0XPVfaHSPjLeNUIu9JWFbt LXb4dfS7xUwBsvRAYO/wjs/n9egQornKkYqpFFE0wT/sEpuDOAt/P5Bd+28r97Nb2Ftq jQtbwcoi/V6FLdD/5U0BHEbudCqQY+U4h5FxLBZfnQi/R3NeqAu+up9PAXswXQMD6JsA Ef3GbVqk1M6DI9Ug39rCA0BFTnrBtsklTMlcOylJsbyGFWY9jmp6LxknkJRiIpDrfPvi /LZA==
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=lURbfUGMRldcP/EkDl8xs7QJzHbJymroAXb3OA1tqms=; b=nseEwTpYv/7ErOzALVqJD755wAVpPetlWnkZiz7jwlIMSNpFXEu6MmLTvxCFqZqNyl 3YwC7iDQKGBiwKIpeZMWyPJeBuzkjB5jCk96eCoue2NLdKZZruKqevEEhPDwVBPkeujg vSzhg90efZjzQ2DbWLezBbFwG1DrR2nFKNowFM82t1QbqlAbH3gQr32iWEdLtUqihQ1E mME5T9ubrLQA9pdqvwVNxziW+sjyL689SY3wJFd1w3KGjcVa91D0mxmLyBz4/1w1lfAq 9K0KtlXSLinjSSo90+x+lZ54I/wDSRtmtqL8v5WepZyio3N8gCTuKkxLMGDH5zyWU7OJ ygMA==
X-Gm-Message-State: AOAM531qd+mhxJ4EvrwAfb2QrLVTo7+8E0ytPhEoKL6EBO0dYf8nGJd7 /a/ygZXuro4ONLZpL1GpIBX/grGvwDmDcyCZjHU=
X-Google-Smtp-Source: ABdhPJxEPCgbV5IlXysu/rNHDgiTYnV/qnfoDczVHYkE0sLLEFfGj3P8Csrq+vDVeMulCbu9J8A3+Fx3VKaE/khs55Q=
X-Received: by 2002:a6b:e70d:: with SMTP id b13mr11231595ioh.141.1597644803175; Sun, 16 Aug 2020 23:13:23 -0700 (PDT)
MIME-Version: 1.0
References: <CAD9ie-v_1GHHJWVeXb5cXiUELj-Un7BN6uCdqSRz4qjL_rq=UQ@mail.gmail.com> <CAOW4vyPEzcC0HCM2eRvZ3yjRp_S4rFdVcqqH3gmnpfbCLx-KNg@mail.gmail.com> <CAK2Cwb47h=yHpbabY8xERArN6589q+cEaPU583iNW7ksc8_r4A@mail.gmail.com> <CY4PR14MB1752A444DB20E509F1B74357DA5E0@CY4PR14MB1752.namprd14.prod.outlook.com>
In-Reply-To: <CY4PR14MB1752A444DB20E509F1B74357DA5E0@CY4PR14MB1752.namprd14.prod.outlook.com>
From: Fabien Imbault <fabien.imbault@gmail.com>
Date: Mon, 17 Aug 2020 08:13:11 +0200
Message-ID: <CAM8feuS-avdP+eJYHvuydrZgg_78MBwSnrP5rB-MAiChO8-2zw@mail.gmail.com>
To: Mark Lizar <mark@openconsent.com>
Cc: Tom Jones <thomasclinganjones@gmail.com>, Francis Pouatcha <fpo=40adorsys.de@dmarc.ietf.org>, GNAP Mailing List <txauth@ietf.org>, Dick Hardt <dick.hardt@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000f87b8705ad0caaca"
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/VHHAMhNn3kH1uR3Eh_Ty3zBW0nc>
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: Mon, 17 Aug 2020 06:13:28 -0000

Not necessarily. It is a human when user=RO (which is indeed a very common
case).
But when the 2 roles are handled by different persons, then most often we
end up using an automated policy engine.

Cheers
Fabien

Le lun. 17 août 2020 à 01:59, Mark Lizar <mark@openconsent.com> a écrit :

> - consent is the human management of a permission grant the system manages
> .   +1 for not mixing human and system terms for the same endpoint.
>
> Get Outlook for iOS <https://aka.ms/o0ukef>
> ------------------------------
> *From:* TXAuth <txauth-bounces@ietf.org> on behalf of Tom Jones <
> thomasclinganjones@gmail.com>
> *Sent:* Sunday, August 16, 2020 7:38:13 PM
> *To:* Francis Pouatcha <fpo=40adorsys.de@dmarc.ietf.org>
> *Cc:* GNAP Mailing List <txauth@ietf.org>rg>; Dick Hardt <
> dick.hardt@gmail.com>
> *Subject:* Re: [GNAP] draft-hardt-xauth-protocol-14 update - reworked
> introduction
>
> i disagree - end user needs to be a human = use term like subject or
> endpoint if you want a non-human
> Peace ..tom
>
>
> On Sun, Aug 16, 2020 at 3:46 PM Francis Pouatcha <fpo=
> 40adorsys.de@dmarc.ietf.org> 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
>
> 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/
> --
> TXAuth mailing list
> TXAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/txauth
>
> --
> TXAuth mailing list
> TXAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/txauth
>