Re: [Txauth] Claims [was: - Dictionary]

Francis Pouatcha <fpo@adorsys.de> Mon, 27 July 2020 01:45 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 60E903A15D9 for <txauth@ietfa.amsl.com>; Sun, 26 Jul 2020 18:45: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 HxodRKIac_iP for <txauth@ietfa.amsl.com>; Sun, 26 Jul 2020 18:45:22 -0700 (PDT)
Received: from mail-wm1-x329.google.com (mail-wm1-x329.google.com [IPv6:2a00:1450:4864:20::329]) (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 A4FD33A15D8 for <txauth@ietf.org>; Sun, 26 Jul 2020 18:45:21 -0700 (PDT)
Received: by mail-wm1-x329.google.com with SMTP id k8so2786271wma.2 for <txauth@ietf.org>; Sun, 26 Jul 2020 18:45: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=nOeut6oFH95peb8A/mZJOd53k/sP3j5SG+fGnVe6QZA=; b=a3JLbuS0HSjDLse/bJQgl9L6iV/3Urg95Vo0I30uQkQ35V+khbuIo2LRIzWKZIcMG0 1bZQjLu3/chxqPtP6qAcLAxT8JV8aXKa+p9uYxDklLFyW0eJLNGylRaXZQLIIWxpBhCV 89L0B4VX/pj6XGKvZxUkFJLpApXcc8Qkqi6Jw=
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=nOeut6oFH95peb8A/mZJOd53k/sP3j5SG+fGnVe6QZA=; b=q+TUOlZ9+sQUqSHpWwHRtdFBs8C2LG1FHat7/tkV6EmVnQE2EOZ1P7cK+ahyWQ7yD5 CfaiI8VmtXJvofgaYHbsJsO1p3MSCkR3OWslBFT4exfbc5b5VTvn2NhbHPJUNDYpy8cN OKBACt04WVMiQVF/A7VgB1NPFJf8PrsH9pjZaDqUpgmqf95Ui7YMa2tUjxCvhEQBv7bh oncv6FjkiYDXJ9y9mTKSfVB0BNR7a8UFku2R3GZZcXpRb9vPr+J9hRjCojQKGP92Lwkh XrizyPZD7BgeNnZxMWAzVBCHLyo+gyJNmou4KLbu+eGVKOmgm6iL2iMgkhZZQI0PMdMS loIg==
X-Gm-Message-State: AOAM53365uaw+xyK3KvolFHkniokG4z/hgcttzNkMTAsCSbW7DlRrNRg GwSgAl7P/BtCKpoNesqzYP3QLqc2/a8MWPoRIeKbXBy5cD0=
X-Google-Smtp-Source: ABdhPJwlyDujTZO2dciNZ2Os05GDohSnoQtUvJ4nt9JJA8AzA5OnzyCkEZcKf1hAvrQwIIX/nYBTHzIP2Ge0Q/QSL34=
X-Received: by 2002:a1c:770c:: with SMTP id t12mr1672449wmi.65.1595814320057; Sun, 26 Jul 2020 18:45:20 -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> <EE0A9241-60D6-493F-9351-2F607D59D3E2@mit.edu> <CAD9ie-u9NUgPSFyUgeeuOYjJewmbugUON64cTttqhWWFGxf41g@mail.gmail.com> <E5F32EB4-D47E-4E40-9F2A-9C25E7DFB86B@mit.edu> <CAD9ie-v1aRaGWEsrs71YfzZ2pdzEdLmmzKfzpVCY1dEHStnJmA@mail.gmail.com> <6AB0512E-A4F9-4C4A-AFC0-768BB04FA765@mit.edu> <CAD9ie-vonF5XRk=1Rm+=gPMBxzNXG=gWmPv7_RMRt4NNNetOLg@mail.gmail.com> <9A074655-FA98-49DA-8CB0-77F4B3D46E0C@mit.edu> <CAD9ie-v-3+zBhZz7WWz5zCM7tnN0SU7pLrsiNhGsmmKa3SN4CQ@mail.gmail.com> <CAOW4vyPVt9TMJxKC6qYYBcYcFz_G45d2jG9M+MdgRBHvXffu5g@mail.gmail.com> <CAD9ie-uUtPyivMCWR03yW7PfZov0695F48N+hh9tQmzBuxEmNA@mail.gmail.com>
In-Reply-To: <CAD9ie-uUtPyivMCWR03yW7PfZov0695F48N+hh9tQmzBuxEmNA@mail.gmail.com>
From: Francis Pouatcha <fpo@adorsys.de>
Date: Sun, 26 Jul 2020 21:45:09 -0400
Message-ID: <CAOW4vyMT=QrtvNm7UdvTmFQya7=7sws7Z5=PnCXzdYtFwXhOtw@mail.gmail.com>
To: Dick Hardt <dick.hardt@gmail.com>
Cc: txauth@ietf.org, Justin Richer <jricher@mit.edu>, Tom Jones <thomasclinganjones@gmail.com>, Denis <denis.ietf@free.fr>, Fabien Imbault <fabien.imbault@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000acc09905ab627912"
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/HW3tkole0q1rDx97o78EJoijo68>
Subject: Re: [Txauth] Claims [was: - 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: Mon, 27 Jul 2020 01:45:26 -0000

Hello Dick,

On Sun, Jul 26, 2020 at 9:14 PM Dick Hardt <dick.hardt@gmail.com> wrote:

> Hi Francis
>
> User is a well understood term in OIDC and OAuth -- and User means the
> same in both.
>

> Resource Owner is who owns the resource, and the term is introduced for
> when the User is NOT the Resource Owner.
>
This distinction is what makes it confusing as we are comparing an Entity
(the User) to a Role (the RO). We need two roles.


>
> I also think that Client and Resource Server are well understood terms.
>
Looks like contributors on the list still need clarification on the
"orchestration" role of a client.

>
> It is not clear to me why we would want to reinvent these terms. Reading
> over your flows, I think it would be useful to understand the requirements
> you have for your use case, otherwise I fear we will be talking past each
> other.
>
The oAuth flow is there as a memo. The other flow is what I proposed
before. Is there to emphasize we need to work on roles and not on entities.
It is not a suggestion to rename well known idioms. It is an attempt to
give them a proper definition in the context of this protocol. Definition
based on their roles in the protocol flows.

Best regards.
/Francis

>
> /Dick
>
> ᐧ
>
> On Fri, Jul 24, 2020 at 7:21 PM Francis Pouatcha <fpo@adorsys.de> wrote:
>
>> Below my opinion on the term Claim:
>>
>> Starting with illustration of parties/roles:
>>
>> User:
>> This word is misleading because of its double role in oAuth2 and OIDC
>> (see below). In GNAP let us have the User play only the role of a
>> requestor. (from Justin reference to "Requesting Party").
>>
>> Client:
>> This is also tightly bound to the oAuth2 and OIDC. The real purpose of
>> this role is to orchestrate resource access on behalf of the "Requestor".
>> Let us call this for now the "Orchestrator"
>>
>> Resource Owner (RO):
>> This is IMO the most correct word in the entire protocol. Authorisation
>> is always about the owner of something granting access to a requestor. It
>> really does not matter if a human interaction is involved. We will have to
>> forget oAuth2 and OIDC of also calling this a User.
>>
>> Grant Server:
>> Even though the definition of the UserInfo endpoint in OIDC as a
>> protected resource hazardously makes an OP an RS, we shall not repeat the
>> same mistake here. We need a clear separation between roles of GS and RS
>> without overlapping.
>>
>> Resource Server: services resources.
>>
>> Unless I got it wrong, GNAP is about grant negotiation and authorization.
>> This means:
>>
>> GNAP is about some party requesting access to some resources.
>> GNAP is about the resource owner consenting access to that resource.
>> GNAP is about defining the infrastructure that allows the requesting
>> party to access a resource.
>>
>> GNAP designs this infrastructure around:
>> - an orchestrator (what we refer to as a client)
>> - an grant manager (what we refer to as a GS/AS)
>> - the custodian of the resource (what we call a RS)
>>
>> As you see:
>> - The word User does not appear here, and is not relevant as the focus is
>> on authorizing access to a resource.
>> - The word Claim is as well absent.
>>
>> Claim related to RO:
>> The word Claim might start getting visible if the orchestrator (a.k.a.
>> Client) or the custodian (a.k.a RS) needs some additional information on
>> the RO to proceed with the access control decision. These claims refer to
>> assertions of attributes or properties of the RO. These claims are issued
>> by the GS as the GS manages interaction with the RO (see below). In this
>> first place information about the requesting party (erroneously.k.a.
>> User) is not relevant to the negotiation and provisioning framework. Let us
>> call this sort of claim "RO-Attributes". A better name is welcome.
>>
>> Some advanced resource provisioning frameworks might require knowledge on
>> attributes of the requesting party (e.k.a User). These attributes shall be
>> collected by the orchestrator (a.k.a Client) and added to the resource
>> request. There is no way the GS can collect these attributes as the GS role
>> has no interaction with the requesting party (e.k.a User). Let us call this
>> sort of claim "Requestor-Attributes". A better name will be welcome.
>>
>> Some assertions are even related to the orchestrator (a.k.a Client)
>> itself. This is the case of the public key of an orchestrator used by the
>> GS to "sender constrain" an access token. Let us call this type of claim
>> "Orchestrator-Attributes".
>>
>> This is a sample mapping of OIDC.
>>
>> +----+    +---+   +---+  +---+
>> |User|    |RP |   |OP |  |RS |
>> +----+    +---+   +-+-+  +---+
>>   |(1) ServiceRequest      |
>>   |-------->|       |      |
>>   |(2) redirect     |      |
>>   |<--------|       |      |
>> === User (requestor) passes control to User (RO) ===
>>   |(3) Auth + Consent      |
>>   |---------------->|      |
>>   |(4) redirect (code)     |
>>   |<----------------|      |
>> === User (RO) passes control back to User (requestor) ===
>>   |(5) get(code)    |      |
>>   |-------->|       |      |
>>   |         |(6) token (code)
>>   |         |------>|      |
>>   |         |(7) token     |
>>   |         |<------|      |
>>   |         |(8) ServiceRequest(token)
>>   |         |------------->|
>>   |         |(9) ServiceResponse
>>   |         |<-------------|
>>   |(10) ServiceResponse    |
>>   |<--------|       |      |
>>   +         +       +      +
>>
>> - RP orchestrates interaction between User and OP to enable the user to
>> obtain the protected resource.
>> - In step 1 & 10 User plays the role of the requestor of the resource.
>> - In step 2 User-Browser is used to pass control from User (in his role
>> as the requestor) to User (in his role as the RO)
>> - In step 4 User-Browser is used to pass control from User (in his role
>> as the RO) back to User (in his role as the requestor)
>>
>> When we are talking claims here, we are talking claims on the User (in
>> his role as the RO). The OP does not have any interaction with the User (in
>> his role as the requestor). In the case of an App2App redirection, the OP
>> can not even assert about the user agent of the User (requestor).
>>
>> If there is any claim the OP can provide, it is a claim on the User (RO).
>>
>> I hope this example clarifies the misunderstanding. Any attempt of
>> bringing this double role of the User into GNAP will also bring this
>> confusion. In order to keep this out of GNAP let us look for the right term
>> for User (as a requestor) using the diagram displayed below.
>>
>> +----+  +------+  +---+  +---+  +---+
>> |Reqs|  |Orchst|  |RS |  |GS |  |RO |
>> +----+  +------+  +---+  +-+-+  +-+-+
>>   |(1) ServiceRequest      |      |
>>   |-------->|       |      |      |
>>   |         |(2) ServiceIntent:AuthZChallenge
>>   |         |<----->|      |      |
>>   |         |       |      |      |
>>   |         |(3) AuthZRequest(AuthZChallenge)
>>   |         |------------->|      |
>>   |         |       |      |(4) ConsentRequest:Grant
>>   |         |       |      |<---->|
>>   |         |(5) GrantAccess(AuthZ)
>>   |         |<-------------|      |
>>   |         |       |      |      |
>>   |         |(6) ServiceRequest(AuthZ):ServiceResponse
>>   |         |<----->|      |      |
>>   |(7) ServiceResponse     |      |
>>   |<--------|       |      |      |
>>   +         +       +      +      +
>>
>> - Replacing the word User helps clarify the difference between both roles
>> "Requestor" and "Resource Owner"
>> - Renaming claim by attaching the Object/target of the claim (e.g.:
>> RO-attributes, Requestor-Attributes, Orchestrator-Attributes) also helps
>> identify the source of those attributes (GS, RS, Client):
>>
>> Best regards.
>> /Francis
>>
>> On Fri, Jul 24, 2020 at 4:58 PM Dick Hardt <dick.hardt@gmail.com> wrote:
>>
>>> It is not clear to me what it matters if a Claim comes from an RS, or
>>> from the GS, so I don't see a need to differentiate them.
>>>
>>> I would include verifiable credentials and user-bound keys as Claims.
>>>
>>> All the payment processing information I have seen has been in RAR. When
>>> would the Client get payment processing directly from the GS?
>>>
>>> What is your example for distributed networks storage locations? If what
>>> is stored is a statement about the user, then I would consider that a Claim
>>> as well.
>>>
>>> We disagree on how to map OIDC to GNAP.  The direct data is a claims
>>> request, the data coming indirectly is an access token request.
>>>
>>>
>>>
>>> On Fri, Jul 24, 2020 at 1:39 PM Justin Richer <jricher@mit.edu> wrote:
>>>
>>>> Since we’re already talking about returning claims as direct data as
>>>> well as a part of the resource API being protected, so we already need a
>>>> way to differentiate the two kinds of items. Just calling it “claims”
>>>> doesn’t help, because as you’ve pointed out they could show up in both
>>>> places. So yes, defining that difference is something we should worry about
>>>> now, even if the core protocol only uses it for claims.
>>>>
>>>> The two forms of direct data that XYZ returns are subject identifiers
>>>> (a subset of identity claims) and assertions — the latter being a container
>>>> not just for identity claims but also authentication information and other
>>>> elements. Assertions are not claims themselves.
>>>>
>>>> Other use cases that have been brought up include verifiable
>>>> credentials and proofs, user-bound keys, payment processing information,
>>>> and distributed network storage locations. I’m sure there are a lot more.
>>>> To me, these are subsets of the “direct data” but not subsets of “claims”.
>>>> GNAP shouldn’t be defining what all of these look like, but it should
>>>> define a way to talk about them.
>>>>
>>>> I think different top-level request objects are better suited for
>>>> different query semantics. Like, for example, the OIDC “claims” request,
>>>> which allows targeting of its claims information into different return
>>>> buckets. This overlaps with the “resources” request at the very least. I
>>>> don’t think GNAP should define how to do this specific combination, that
>>>> should be for OIDF to debate and apply. The same with a DID service based
>>>> query, or Presentation Exchange [1], or anything else that people want to
>>>> come up with.
>>>>
>>>> In my view, GNAP should define query structures for two things: rights
>>>> that get tied to an access token and data that comes back directly to the
>>>> client. For the latter, I think we can do some very limited and very useful
>>>> specific items, which is what I’ve put into XYZ.
>>>>
>>>>  — Justin
>>>>
>>>> [1] https://identity.foundation/presentation-exchange/
>>>>
>>>> On Jul 24, 2020, at 3:58 PM, Dick Hardt <dick.hardt@gmail.com> wrote:
>>>>
>>>> I agree we want GNAP to be a strong foundation.
>>>>
>>>> Do you have an example of other "direct data"? If so, do you expect it
>>>> to be defined in the core protocol?
>>>>
>>>> I would expect an extension for other "direct data" to define top level
>>>> objects, and an appropriate definition for that "direct data".
>>>>
>>>> My "do we need to worry about it now" comment was on creating a generic
>>>> term for "direct data". Unless we are solving those now, we can let further
>>>> work define that "direct data" explicitly.
>>>>
>>>>
>>>>
>>>>
>>>> ᐧ
>>>>
>>>> On Fri, Jul 24, 2020 at 12:42 PM Justin Richer <jricher@mit.edu> wrote:
>>>>
>>>>> Yes, I do think we need to worry about it to the extent that we are
>>>>> not creating something that is over-fit to a limited set of use cases.
>>>>>
>>>>> GNAP should be a foundation that many amazing new things can be built
>>>>> on top of.
>>>>>
>>>>>  — Justin
>>>>>
>>>>> On Jul 24, 2020, at 3:06 PM, Dick Hardt <dick.hardt@gmail.com> wrote:
>>>>>
>>>>> Justin, thanks for clarifying.
>>>>>
>>>>> What are some examples of other "direct data" that the GS may return?
>>>>> If it is not in core GNAP, do we need to worry about now? We can then give
>>>>> the direct data from the GS that is not a claim, an appropriate name in
>>>>> that document.
>>>>>
>>>>>
>>>>>
>>>>> On Fri, Jul 24, 2020 at 11:46 AM Justin Richer <jricher@mit.edu>
>>>>> wrote:
>>>>>
>>>>>> Dick: No, I think you’re misunderstanding what I’m saying. I agree
>>>>>> that “claims” are about the user, in this context*. But the AS could return
>>>>>> other data directly to the client that isn’t about the user. Those aren’t
>>>>>> “claims” by the classical definition. Also since “claims” can come back
>>>>>> from places other than directly, then we shouldn’t call everything that
>>>>>> comes back a “claim”.
>>>>>>
>>>>>> I’m arguing that we keep “claims” to mean what it already means and
>>>>>> come up with a new word to mean “things that come back directly from the
>>>>>> AS”. These aren’t meant to replace Francis’s more complete definitions, but
>>>>>> to simplify:
>>>>>>
>>>>>> Claims:
>>>>>> - information about the user
>>>>>> - can come back directly from the AS
>>>>>> - can come back in a resource from the RS
>>>>>>
>>>>>> Resource:
>>>>>> - Returned from an RS
>>>>>> - Protected by access token
>>>>>> - Could contain claims about the user
>>>>>>
>>>>>> Direct data (or some better name):
>>>>>> - Returned directly from AS
>>>>>> - Could contain claims about the user
>>>>>>
>>>>>> I think the problem is that some people are using “claims” to mean #1
>>>>>> and some to mean #3. It’s clearly #1 in OIDC. But: It’s important to
>>>>>> remember, when talking about OIDC, that an IdP in OIDC combines an AS and
>>>>>> an RS into one entity for identity information. There can be other RS’s as
>>>>>> well, and there usually are in the wild, but the one defined by OIDC is the
>>>>>> UserInfo Endpoint. The fact that it returns user data doesn’t make it any
>>>>>> less of an RS.
>>>>>>
>>>>>>  — Justin
>>>>>>
>>>>>> * In the wider context of things like the information claims inside a
>>>>>> JWT, the claims could be about literally anything, but that’s not what
>>>>>> we’re discussing here and it’s not how it’s being used.
>>>>>>
>>>>>>
>>>>>> On Jul 24, 2020, at 1:24 PM, Dick Hardt <dick.hardt@gmail.com> wrote:
>>>>>>
>>>>>> In OpenID Connect (OIDC), the Client can obtain Claims directly from
>>>>>> the OP in an ID Token, or the Client can obtain Claims using an access
>>>>>> token to call the UserInfo endpoint, a Protected Resource[1].
>>>>>>
>>>>>> The Claims are about the User (not a RO).
>>>>>>
>>>>>> In XAuth, I'm proposing the Client may obtain bare claims from the GS
>>>>>> directly in addition to the mechanisms in ODIC.
>>>>>>
>>>>>> So I don't think we are changing the definition of Claim from how it
>>>>>> has been used in OIDC, and I fail to see any reason to NOT use Claim.
>>>>>>
>>>>>> Justin: you allude to Claims being about a party other than the User.
>>>>>> Would you provide an example?
>>>>>>
>>>>>> /Dick
>>>>>>
>>>>>> [1]
>>>>>>
>>>>>> UserInfo Endpoint
>>>>>> Protected Resource that, when presented with an Access Token by the
>>>>>> Client, returns authorized information about the End-User represented by
>>>>>> the corresponding Authorization Grant. The UserInfo Endpoint URL MUST use
>>>>>> the https scheme and MAY contain port, path, and query parameter components.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> ᐧ
>>>>>>
>>>>>> On Fri, Jul 24, 2020 at 5:58 AM Justin Richer <jricher@mit.edu>
>>>>>> wrote:
>>>>>>
>>>>>>> I want to focus on one aspect here:
>>>>>>>
>>>>>>>
>>>>>>>> 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.
>>>>>>>
>>>>>>>
>>>>>>> This is exactly why I don’t think we should use “claim” in the way
>>>>>>> that we’re using it. Yes, a “claim” could come back through an RS — but in
>>>>>>> the context of GNAP, that makes it a resource. So we need a different word
>>>>>>> for data coming back directly from the AS to the client. Sometimes it’s
>>>>>>> going to be about the user, and that’s what we’re going to focus on here,
>>>>>>> but since you can also get information about the user from a resource we
>>>>>>> can’t just call it a “claim”. I think this has been at the heart of a lot
>>>>>>> of confusion in recent threads, as well as confusion about the scope of the
>>>>>>> inclusion of identity in the GNAP protocol.
>>>>>>>
>>>>>>> So let’s let “claim” mean what it already does, and let’s find a way
>>>>>>> to differentiate between when an item, claim or otherwise,  comes as part
>>>>>>> of a resource and when it comes back directly. This is an important
>>>>>>> differentiating feature for GNAP.
>>>>>>>
>>>>>>> Some straw man ideas, none of which I’m particularly in love with:
>>>>>>>
>>>>>>>  - direct data
>>>>>>>  - properties
>>>>>>>  - details
>>>>>>>  - statements
>>>>>>>
>>>>>>> The important thing here is that it’s not necessarily :about: the
>>>>>>> RO, and that it is :not: in a resource.
>>>>>>>
>>>>>>> Any other thoughts?
>>>>>>>
>>>>>>>  — Justin
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>
>> --
>> 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/