Re: [Txauth] Reviewing draft-hardt-xauth-protocol-11 - Dictionary

Francis Pouatcha <fpo@adorsys.de> Fri, 24 July 2020 12:15 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 90E273A0881 for <txauth@ietfa.amsl.com>; Fri, 24 Jul 2020 05:15:25 -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, HTML_FONT_LOW_CONTRAST=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 (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 sx-SgMn6wq_V for <txauth@ietfa.amsl.com>; Fri, 24 Jul 2020 05:15:22 -0700 (PDT)
Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com [IPv6:2a00:1450:4864:20::434]) (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 8BAFD3A08A5 for <txauth@ietf.org>; Fri, 24 Jul 2020 05:15:21 -0700 (PDT)
Received: by mail-wr1-x434.google.com with SMTP id b6so8097457wrs.11 for <txauth@ietf.org>; Fri, 24 Jul 2020 05:15:21 -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=mSzfKmWq3OkDBEhH3p6OQaA8vC7lPMBu3ZAXLXwxnGs=; b=QcTwYutNXO/G8xyYL16sc4AaH91TKoeRsRTX80G1Ty887dOPHavpBRxNB75wyV8egA tBxlMYXK3TSLYpTUpCPIJtdyB6wNuaYzxSOtYblUW4pSpvRBU3nqqayL00j6je1JT9Kg vR7lnGS9zLj4LqEraegTjWR025VLJARgohbc4=
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=mSzfKmWq3OkDBEhH3p6OQaA8vC7lPMBu3ZAXLXwxnGs=; b=OWx4NYGkqGPX7XOnhqV69xjvuph/HWaZgBljO9WQA+V76T2isXzxtZ/wmyF5O58jwB l1Ta3wZGUp26uxR4W+LUA9NHbIngXeD0KhId715t5HXq7mauZ/6RxaVKLUuBZ0Jt6Kzn 4aaP9Xi7IO1lGDO2B7tUoBwAZZIDJ4QIv9+djkjliZWSfzrETd3VZfIO49P4DVc5YzqH ynSr01i6wfGxZgwl9VUr/NPIllDuh6z+KepXX71wryCzwrz799Z6/dkO1jYX/YtV1St1 /ZOKfKwL1ibqi9vQSNdXyFJURs09yyHug+4Tp2qHYp3GKdCJPmHpmvWf+eHm4VTSAMwy ZnUw==
X-Gm-Message-State: AOAM532ax5QcmjGNMBAh9Dts/aGxAC0ewveGriBYagZJB5cldqYwSPQx hWI4hLFumm/5w1eFYEyx542k1zba2McFOG6NU8wiWg==
X-Google-Smtp-Source: ABdhPJyT0vEfDwcsi7VyycFjaImtYIedPnZna7u6DHjeH5gwcz1irbchFZzB5TmzqphaOq7HDR8YSfSHOEUSiOwaEI8=
X-Received: by 2002:a5d:45c9:: with SMTP id b9mr8199130wrs.283.1595592919666; Fri, 24 Jul 2020 05:15:19 -0700 (PDT)
MIME-Version: 1.0
References: <CAOW4vyO2C1E3Sg58CrSVT81t0T3iCTY87tdAx+a8d2A+cNa3nA@mail.gmail.com> <CAD9ie-vMzepgmaP-jUunKSo-chWrGpB230TWgJq7u8Yt-afDxA@mail.gmail.com> <CAOW4vyObyZC7USUqsW_qdDV9Hcpvg9OHKmM1yMEjSUvmjx0UZQ@mail.gmail.com> <CAD9ie-sWn41XDiwyFMcTgV3a8MMESXqf36fNJcTaSYDKwU+LPg@mail.gmail.com> <CAOW4vyNzGG95eNf6RRLf_jgHoQDMJHz8kPF10EENeaAq9vkrVQ@mail.gmail.com> <CAD9ie-vPDMPM8CRid169WsssD0r3dWNqoNCDJcgrxEs+MfvtjQ@mail.gmail.com> <CAOW4vyOjpL3Qoy02uV1dxc+wYir+yh0wWKiaV93OqzRXtk_Sxg@mail.gmail.com> <CAOW4vyMgW=3-nrgODnhj-BweWhJgW3WzTJDhSAwdnHFdho6msg@mail.gmail.com> <B55BD16B-8982-4621-A35F-6878F5045630@mit.edu> <CAD9ie-vA07gB-sQNc4Ft3jr6586N-Jh7dE5-e9ob8-wN_B0Xiw@mail.gmail.com> <CAOW4vyPQgQZ_fZB_rHvWFCvrTon4Vix7raTGG9gdc=Z1_=YA-w@mail.gmail.com> <CAD9ie-sV_P22QrnL6L5xUpu+AMAiNfv5SjP-GraSfqzo5DpZiw@mail.gmail.com>
In-Reply-To: <CAD9ie-sV_P22QrnL6L5xUpu+AMAiNfv5SjP-GraSfqzo5DpZiw@mail.gmail.com>
From: Francis Pouatcha <fpo@adorsys.de>
Date: Fri, 24 Jul 2020 08:15:08 -0400
Message-ID: <CAOW4vyMa6z1LzaevXQFdFzPEiPPY-fp8T-6d+gKBocXH3FJ5xg@mail.gmail.com>
To: Dick Hardt <dick.hardt@gmail.com>
Cc: Justin Richer <jricher@mit.edu>, txauth@ietf.org, Tom Jones <thomasclinganjones@gmail.com>, Denis <denis.ietf@free.fr>
Content-Type: multipart/alternative; boundary="0000000000002ee98405ab2eed01"
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/J3lt3QstwhkweR-X1QBgeydHS-4>
Subject: Re: [Txauth] Reviewing draft-hardt-xauth-protocol-11 - Dictionary
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: Fri, 24 Jul 2020 12:15:26 -0000

On Thu, Jul 23, 2020 at 10:44 PM Dick Hardt <dick.hardt@gmail.com> wrote:

>
>
> On Thu, Jul 23, 2020 at 7:16 PM Francis Pouatcha <fpo@adorsys.de> wrote:
>
>> Hello Dick, my feedback inline
>>
>> @Fabian : i am not yet consistent with using the notation you referred to
>> in https://www.iso.org/obp/ui/#iso:std:iso-iec:27000:ed-5:v1:en. Still
>> to come.
>>
>> On Thu, Jul 23, 2020 at 7:52 PM Dick Hardt <dick.hardt@gmail.com> wrote:
>>
>>> Hi Francis
>>>
>>> Thanks again for putting this together. I have taken your definitions
>>> and adjusted them to match how I think of them. I dropped the term
>>> "parties" because I did not think it added value. I am explicit about what
>>> each party is -- software, a human, or an entity. Let me know where you
>>> disagree!
>>>
>>>
>>> Resource - protected data or software functionality
>>>       - controlled by a Resource Owner (RO),
>>>       - protected by the Resource Server (RS)
>>>
>> Yes
>>
>>>
>>> Claim - a statement about the User
>>>
>> I would stay with RO not User. I added some clarification after the
>> feedback of Justin (see below)
>>
>
>
>
>
>>       - may be obtained from the Grant Server (GS) by a Client
>>>
>> Yes.
>>
>>>       - may be a Resource the Client can access through an RS
>>>
>> Not sure we need to refer to a Resource as a Claim.
>>
>
> Here is why I say a Claim may be a Resource.
>
> A Claim may be obtained by a Client calling an RS. This is effectively
> what the userinfo endpoint is in OpenID Connect. A Client may also update a
> Claim that is managed by an RS.
>
In OIDC the UserInfo endpoint is exposed by the OP not by an RP. Spec
wording is confusing because the endpoint is referred to as a protected
resource. If you derive from this that the OP is a resource server (RP),
you turn the OP into an RP relying on itself. This cyclic relationship has
to be broken in GNAP for simplicity.

Note-x on GS definition: having a GS protecting access to some Claims does
not make the GS a RS.

For simplicity, let us keep overlapping out:
- GS guards Claims
- RS guards Resources

I do not see a Client updating a Claim in the scope of any of these
protocols. Neither GNAP nor oAuth2 nor OIDC.

>
>
>>
>> A Claim - an assertion of the truth of some properties or attributes of
>> the RO.
>>   Note-1: A Claim is issued either by the GS or by another claim issuer.
>>
>
>
> I'm viewing the Claims Issuer as an entity, not a piece of software. It is
> the entity trusted by other parties to make a Claim about the User. The GS
> and RS may issue claims on behalf of the Claims Issuer.
>
No. Issuer is GS. Any twiking of the word will diverge it from oAuth2 and
OIDC and increase complexity.

This is why RS shall not issue anything, shall not deal with claims, ....
RS guards Resources. If you start dealing with RS issuing claims, you start
dealing with RS exposing jwks-url so issued claims can be verified, then
you fall back at having those RSes being GSes.

>
>
>
>>   Note-2: A Claim is held and guarded by the Grant Server (GS).
>>
>
> What is the significance of this statement? Signed claims don't exist
> until asked for, so they are not "held" anywhere.
>
A Claim can exist before. GS might hold a Claim issued by an external
"Claim Issued".

>
>
>>   Note-3: A Claim is released by the GS to a Client.
>>
>
> The model of a Claim being obtained from an RS is a common use case.
>
I am not aware of any of them. Unless we are calling a GS a RS.

>
>
>>   Note-4: The permission to release of a Claim is given by the RO.
>>
>
> I will see what you say below on User ...
>
>
>>
>>
>>> Grant - the Claims and/or Resource Access the User and/or RO have
>>> granted to the Client by the GS
>>>     - requested by a Client
>>>     - granted by a GS after any required consent has been obtained from
>>> the User and/or RO
>>>
>> "User and/or RO" is confusing. I suggest we keep the term User out. Term
>> User is even eligible for renaming. I suggest staying with RO.
>>
>
> The User of the Client and the RO may not be the same entity. Some
> resources may be controlled by the RO, and others by the User. That is why
> User and/or RO. They are two different parties.
>
I need the example of a User that is different from the RO and that
controls the RO's Resource.

And if a User controls a Resource, then he does it as the "Owner" of that
Resource(playing the role of the RO for that Resource).

If we talk about roles and not entities, we will not fall into this
confusion.

>
>
>>
>>
>>> Access Token - an artifact representing the access a client has been
>>> granted to one or more Resources
>>>     - created by the GS
>>>     - presented by the Client when accessing a Resource at an RS
>>>
>> An access token might contain Claims.
>>
>
> While there may be statements about the User in the access token, it is
> not the mechanism for transmitting Claims to the Client -- and I think the
> access token SHOULD be opaque to the Client most of the time.
>
- Access "might" contain a claim ("must" not). Precision is essential as we
can not kill this practice without removing the concept of assertion based
tokens.
- Returning the information to the client does not mean the client is the
consumer of the information. The client might not have access to the
content of an encrypted token, or even just to the embedded encrypted
claim. The intended destination of the claim will consume the claim. But
for the GNAP, the GS returns the token to the client.

>
>
>>
>> Access Token - an artifact representing the access a client has been
>> granted to one or more Resources
>>   Note-1: An access token is created by the GS
>>   Note-2: An access token can also contain claims
>>
>
> See above.
>
>
>>   Note-3: An access token is presented by the Client when accessing a
>> Resource at an RS
>>
>>
>>> Resource Owner (RO) - the entity that
>>>       - controls a Resource,
>>>       - has delegated Resource access control to one or more GSes
>>>       - may be the User
>>>
>> Confused here with the word "controls" both at RO and GS. I think RO
>> delegates Resource access management to GS but keeps control (or decision).
>>
>
> agreed - access management is better.
>
>
>>
>> Resource Owner (RO) - the entity that
>>       - controls a Resource,
>>       - relies on the services the GS to manage access to that Resource,
>>       - relies on the services of a RS to hold a Resource and guard
>> access to that Resource,
>>
>
> I don't think "guard" is a good verb. "protect" is often used.
>
OK.

>
> If we are switching from "owns a resource" to "controls a resource", then
> perhaps the entity should be a Resource Controller (RC)?
>
Great. Will remove confusion.

>
>
>
>>       - controls a Claim,
>>
>
> Why does the RO control a claim?
>
because a Claim is an assertion of the truth of some properties or
attributes of the RO.

>
>
>>       - relies on the services the GS to release that Claim to a Client.
>>
>>>
>>> Resource Server (RS) - the software that controls access to one or more
>>> Resources
>>>       - accessed via an API by Clients presenting an access token
>>>       - accepts access tokens from one or more GSes
>>>
>> I suggest "guards" instead of "controls". As access to a resource is
>> controlled by the RO.
>>
>
> How about "protects access"?
>
OK for me.

>
>
>>
>> Resource Server (RS) - the software that guards access to one or more
>> Resources
>>       - accessed by the Client that presents an access token
>>       - accepts access tokens from one or more GSes
>>
>>
>>>
>>> Grant Server (GS) - the software that manages Grants
>>>     - has been delegated to manage Resource access by the RO
>>>     - has been delegated to release Claims about the User
>>>     - grants the Client access to Resources after obtaining the required
>>> consent from the RO
>>>     - provides the Client Claims about the User after obtaining the
>>> required consent from the User
>>>
>> Term User is confusing here. This is why it is eligible for renaming.
>> - Claims are about RO not User
>> - Consent is from RO not User.
>>
>
> I'm confused why the Claims are about the RO and not the User.
>
Because the  user consumes the resource and the claim. I do like Justin's
suggestion to call user the "Requesting Party"

>
> We have introduced the term RO so that entity can be differentiated from a
> User, and there are many use cases where there is a User. Not having a User
> seems very confusing to me.
>
Then let us call him a  "Requesting Party"

>
>
>>
>> Grant Server (GS) - the software that manages Grants
>>     - has been delegated to manage Resource access by the RO
>>     - has been delegated to release Claims about the RO
>>     - grants the Client access to Resources after obtaining the required
>> consent from the RO
>>     - provides the Client Claims about the RO after obtaining the
>> required consent from the RO
>>
>>
>>> Client - the software that wants to access Resources and obtain Claims
>>>     - executed by a User or a non-human service account
>>>     - requests Grants from the Grant Server
>>>     - accesses Resources at an RS using access tokens
>>>
>> Client - the software that wants to access Resources and obtain Claims
>> on behalf of a User or non-human service account
>>    Note-1: in a typical interaction cycle, the client:
>>       - receives the resource access request from the User or acts
>> autonomously,
>>       - interacts with the RS to discover authorization requirements,
>>       - interacts with the GS to obtain Access Tokens,
>>       - interacts with the RS to access the Resource using Access Tokens.
>>
>
> The Client also transfers the user experience to the GS in some flows.
>
Yes but this is just a mechanism. Not an act.

>
> Where do Claims fit into the cycle above?
>
A claim is just an Assertion (attribute, property) related to the RO. This
can be part of the authorization requirements. e.g. User/Client/RS are
requesting to know the e-mail of the RO.

>
>
>>
>>
>>>
>>> User - the human using a Client
>>>     - may also be the RO for one or more Resources
>>>     - may have Claims managed at a GS
>>>
>> Not sure a user has to be human.
>>
>
> Why not? I think NOT having the User be a human is confusing.
>
Let us stay by the role "Requesting Party"instead of the entity "User"

>
>
>> Maybe first renaming to "Requesting Party" might help with narrowing the
>> term.
>>
>
>>
>>> Some comments:
>>>
>>> A Claim is a well understood term in the field. We should use it. It is
>>> still a Claim if it comes directly from the GS or from an RS.
>>>
>> I do not understand why a Resource release by an RS shall be h to as a
>> claim, even if the content of the Resource is an assertion. It will lead to
>> confusion. If we limit claims to information GS releases into Token, User
>> Info, and other objects it returns, this will help separate
>> responsibilities between GS and RS. As soon as RS services and information,
>> this is called a Resource, no matter the nature of the content of that
>> information.
>>
>>
>>> I think Grant Server is the right term. A Grant contains claims and/or
>>> access to resources. I have defined all the terms above without using the
>>> term authorization. :) -- I am pondering renaming most things called
>>> Authorization in XAuth to Access.
>>>
>> Ok.
>>
>>>
>>> Claim Issuer - I think we may need to add this party to our
>>> nomenclature. This is the entity that issues Claims. It may be a GS or an
>>> RS.
>>>
>> Yes for the term "Claim Issuer".
>>
>> No for a "Claim Issuer" being an RS. At least not in its role as an RS.
>> RS shall focus on guarding and serving a Resource. Issuing a claim is
>> authoritative and might come with more complexity (verification of
>> authenticity). Having an RS issue a claim will overload the role of an RS
>> and increase the complexity of the framework.
>>
>> /Francis
>>
>>
>>> /Dick
>>>
>>> ᐧ
>>>
>>> On Thu, Jul 23, 2020 at 8:07 AM Justin Richer <jricher@mit.edu> wrote:
>>>
>>>> Up-front question to the Chairs, do we have a good place to capture
>>>> this kind of thing? A non-spec document like this would be a good candidate
>>>> for a wiki page. Do we have plans to set up a GitHub repository or similar?
>>>> If so we could use the wiki capabilities there to at least get this stuff
>>>> written down. Use cases would be good to capture there as well.
>>>>
>>>>
>>>>
>>>> Francis,
>>>>
>>>> First, I want to thank you for putting the work in to getting some
>>>> vocabulary down. This is not an easy task! Some notes on specific items
>>>> inline below.
>>>>
>>>> On Jul 21, 2020, at 8:33 PM, Francis Pouatcha <fpo@adorsys.de> wrote:
>>>>
>>>> Hello Dick, Justin, Tom, Denis,
>>>>
>>>> Below is a new version of the dictionary includings comments from
>>>> different threads. Change log includes:
>>>> - avoided the expression "owns a resource" in favor of the expression
>>>> "controls a resource"
>>>> - included the clarification "resource access" and "claim release"
>>>> - included a clarification User vs. RO
>>>> - tried to clarify the word User-Agent
>>>> - added the definition of a Claim
>>>>
>>>> Terms
>>>> =====
>>>>
>>>> Party - represents a role in the GNAP protocol flow. A party can take
>>>> the form of a web service, an application installed on the user device and
>>>> acting autonomously or the form of a natural person (resp. of an autonomous
>>>> device) using an application to interact with other parties.
>>>>
>>>> Resource - a piece of data or web service
>>>>       - controlled by a Resource Owner (RO),
>>>>       - held and guarded by a Resource Server (RS) and
>>>>       - serviced by the RS to a Client, if the Client provides a valid
>>>> Authorization.
>>>>
>>>> Claim - a piece of data
>>>>       - controlled by a Resource Owner (RO),
>>>>       - held and guarded by the Grant Server (GS) and
>>>>       - released by the GS to a Client as part of an Authorization.
>>>>
>>>>
>>>> The differentiation between “resource” and “claim” is important since
>>>> it separates items that get tied to an access token’s rights (“resources”)
>>>> with items that come back directly to the client without going through a
>>>> separate API. The term “claim” is problematic here though because it is
>>>> used broadly in the community to mean, roughly, “a statement about the end
>>>> user”. It’s therefore both too broad and too narrow in the wrong ways: a
>>>> “claim” could come back as part of an API response, like the OIDC UserInfo
>>>> Endpoint, and so it’s not a good name for this item. Even the OIDC “claims”
>>>> query language defines several different targets for returning the “claims”
>>>> about the user, and none of them match the method that GNAP is looking to
>>>> use here. A “claim” is also generally understood in the identity community
>>>> to be a statement about the user, and the data coming back directly to the
>>>> client might be about the user or something else, especially as we look
>>>> forward to extensions of GNAP.
>>>>
>>>> I think we should focus on the separation of the delivery mechanism,
>>>> but I’m not sure what good alternatives would be. Perhaps:
>>>>
>>>>  - “access right” for things tied to the API/token
>>>>  - “data response” for things coming back directly to the client
>>>>
>>>> I’m not particularly thrilled by these names, but I think recent list
>>>> conversation shows that we need to get away from “claim” as it’s overloaded.
>>>>
>>>>
>>>> Resource Owner (RO) - the party that
>>>>       - controls a Resource,
>>>>       - relies on the services the GS to manage access to that Resource,
>>>>       - relies on the services of a RS to hold the Resource and guard
>>>> access to that Resource,
>>>>       - controls a Claim,
>>>>       - relies on the services the GS to release that Claim to a Client.
>>>>
>>>> Resource Server (RS) - the party that
>>>>       - holds a resource and guards access to that resource on behalf
>>>> of the RO,
>>>>       - services the Resource to the requesting Client, provided the
>>>> Client presents a valid Authorization.
>>>>       The RS is generally deployed as a web service.
>>>>
>>>> Grant Server (GS) - the party that
>>>>       - manages access to a Resource on behalf of the RO,
>>>>       - holds Claims and releases them when consented by the RO.
>>>>       For each Resource access request, the GS might request the
>>>> Consent of the RO and produce a corresponding Authorization that is given
>>>> to the requesting Client.
>>>>
>>>>
>>>> I don’t like the shift from “Authorization Server” to “Grant Server”,
>>>> and it especially doesn’t make sense in light of the definitions of “grant”
>>>> and “authorization” above. I believe we should stick with “Authorization
>>>> Server” if it’s a single role. I would also propose that we have a separate
>>>> term for the RO-interactive portion vs. the client-facing portion, as has
>>>> been brought up in a few threads. Maybe these get different names entirely,
>>>> or maybe they are “aspects” of the AS, I’m not sure.
>>>>
>>>>
>>>> Consent - act of an RO :
>>>>       - approving access to a Resource, means approval that a Resource
>>>> he controls can be given to the Client by the RS.
>>>>       - approving release of a Claim, means approval that a Claim he
>>>> controls can be included by the GS in an Authorization to be returned to
>>>> the Client.
>>>>
>>>> Grant - material form of an RO Consent. In order not to interact with
>>>> the RO on each Resource access request, the GS might store the RO Consent
>>>> in the form of a Grant for reuse.
>>>>
>>>> Authorization - externalized form of a Grant as known to the GS and the
>>>> RS.
>>>>       - The GS converts a Grant into an Authorization for use in a
>>>> Resource access request.
>>>>       - The RS evaluates an Authorization to decide on whether or not
>>>> to release the Resource to the Client.
>>>>
>>>> Client - the party that provides the infrastructure used by a User to
>>>> access a Resource. The client infrastructure is designed to:
>>>>       - Receive the resource access request from the User,
>>>>       - Interact with the RS to discover authorization requirements,
>>>>       - Interact with the GS to obtain an Authorization to access the
>>>> Resource,
>>>>       - Interact with the RS to access the Resource on behalf of the
>>>> User.
>>>>
>>>>
>>>> I think we should be clear that what we call the “client” is a piece of
>>>> software operated by the user. It’s true that this software might have
>>>> multiple parts of its “infrastructure” but it’s always software.
>>>>
>>>>
>>>> User - the party using the infrastructure of the Client to gain access
>>>> to a Resource or a Claim.
>>>>
>>>>
>>>> In UMA, we call this the “Requesting Party”, or RqP. We might want to
>>>> consider adopting this terminology here as well.
>>>>
>>>>
>>>> Clarifications:
>>>> ==========
>>>>
>>>> User vs. RO :
>>>>       - the User is the party using the infrastructure of the Client to
>>>> gain access to a Resource or a Claim,
>>>>       - the RO is the party controlling access to a Resource or
>>>> controlling the release of a Claim.
>>>> In many use cases, User and RO will be represented by the same party
>>>> (see oAuth2), but GNAP exposes use cases where User and RO are represented
>>>> by different parties.
>>>>
>>>> User-Agent :
>>>> User and RO are parties that might be represented by a natural person
>>>> or an autonomous device. In those cases, User (resp. RO) might need the
>>>> help of an application to interact with other parties. Such an application
>>>> is generally referred to as the "User-Agent".
>>>>
>>>>
>>>> The term “user agent” is often used to be equivalent to the web
>>>> browser, and not the more general use here. I think we’re seeing more
>>>> “agent” terminology for helper applications like digital wallets and AI
>>>> bots, which would seem to be covered under your definition here.
>>>>
>>>>
>>>> Feedbacks are welcome.
>>>>
>>>>
>>>> Again, thanks so much for getting this going!
>>>>
>>>>  — Justin
>>>>
>>>> Best regards,
>>>> /Francis
>>>>
>>>>
>>>> On Tue, Jul 21, 2020 at 2:27 PM Francis Pouatcha <fpo@adorsys.de>
>>>> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Tue, Jul 21, 2020 at 2:15 PM Dick Hardt <dick.hardt@gmail.com>
>>>>> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Tue, Jul 21, 2020 at 11:09 AM Francis Pouatcha <fpo@adorsys.de>
>>>>>> wrote:
>>>>>>
>>>>>>>
>>>>>>> On Tue, Jul 21, 2020 at 1:59 PM Dick Hardt <dick.hardt@gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> FYI: I consider the release of claims to be an "authorization" as
>>>>>>>> well.
>>>>>>>>
>>>>>>> Great. Then it is included.
>>>>>>>
>>>>>>
>>>>>> I pivoted to using the term Grant rather than authorization so that
>>>>>> it included both authorizing access to a resource, and authorizing the
>>>>>> release of an identity claim.
>>>>>>
>>>>>> Perhaps we should not use the word "authorization"?
>>>>>>
>>>>> Authorization is currently used to refer to the token issued by the
>>>>> GSand presented to the RS by the Client. I have no alternative word for now.
>>>>>
>>>>>>
>>>>>> "resource access" and "claim release"
>>>>>>
>>>>>> A Grant then covers both?
>>>>>>
>>>>> Yes, Great! The word Grant fits best for both. I suggest adding this
>>>>> clarification to that dictionary.
>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>> IE, the user authorizes the GS to release a DOB claim to a Client.
>>>>>>>>
>>>>>>> I guess you mean the "RO" authorizes the GS to release a DOB!
>>>>>>>
>>>>>>
>>>>>> Yes, thanks for clarifying!
>>>>>>
>>>>>> /Dick
>>>>>>
>>>>>>>
>>>>>
>>>>> --
>>>>> 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/
>>
> ᐧ
>


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