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

Mike Jones <Michael.Jones@microsoft.com> Mon, 27 July 2020 12:17 UTC

Return-Path: <Michael.Jones@microsoft.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 08F823A1914 for <txauth@ietfa.amsl.com>; Mon, 27 Jul 2020 05:17:53 -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=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, 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_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=microsoft.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 yLFlDOlA4Yzp for <txauth@ietfa.amsl.com>; Mon, 27 Jul 2020 05:17:48 -0700 (PDT)
Received: from NAM06-BL2-obe.outbound.protection.outlook.com (mail-eopbgr650090.outbound.protection.outlook.com [40.107.65.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 361573A1912 for <txauth@ietf.org>; Mon, 27 Jul 2020 05:17:48 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=NIsYPxUO0wrhpgf5vl88h0qI/HOUH3MPH7kKQM4QmTAXA4M4vy6tn0aQZUhnran4xfOm264GL895qC6bceXYuWhWr8ptilVi9Ffhewe13A/feV5sdrRZlXeYHxS+ryt6XGGeDSlJOK3WirtWDxnOvKmiQBpkD8dHiKDorLUuGqUmtXWZYgi/k45UtKEFJ5/+1+y+EbYI4Nz5HKRCp1FvoTR4RSKNkty37cnVaw3qG+sAOzYKaDJ0juYE9W20+XIO8BQoajyNEBgx9mliBw+Iols3BJdfvYSuaCbOvfKRBEjk5/znDC2Md6EpIv8Cgcq9P6gze41tZ9ebU1tiDB3yGw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=wCpU/7xCwrxOAjhTH9elMsKP3ezByola8dakU76wzWg=; b=l9ceH8F08L3Eq8XA15YuFMFG583ISgRUwny503eezeVupNUVgL+RMQETlUXj6cmj5Yma9sXUv0yXR9GC6zlOSlSRrjtM+QImv8cgFbZ8kxwtFRilLFUjKsF3TJ+SISivQksQdCqFz3mwqc4fECDXNnmI4PgsErZ++F9pJFybn2VW8ZEFnXOQ/UjG99u0bP/V656M7sjHEzlMWDKq5WfHHLVINy7J09A6AcSke+QGY7plhJmvdLIG3TZ0vxkc9yeAfQ9jYfFfzs8Bm6s+6fNk6f9GtvQFpUSSl4/FJ5hDS3uRDbGk3B8k1hPajG3wLiYu4JSTrX5PAcP1jODVfQSFsQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=wCpU/7xCwrxOAjhTH9elMsKP3ezByola8dakU76wzWg=; b=GIDsti6TNo2zNx3E0KKUTNrinL24cDoEj97L74LNSMRjTsg9itCkMwk0JmkhMYRUtIaH86YgNpQ8KOW/fdw/i+vWHwFR8/oiNXHpP8znV1QEbrB1igMDPUyFAru2kSi+qO8ciyFewy6Ffyh2FRd7TJ8FVgDNBMnBIjmWyvU+51I=
Received: from CH2PR00MB0679.namprd00.prod.outlook.com (2603:10b6:610:af::7) by CH2PR00MB0746.namprd00.prod.outlook.com (2603:10b6:610:6e::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3264.0; Mon, 27 Jul 2020 12:17:45 +0000
Received: from CH2PR00MB0679.namprd00.prod.outlook.com ([fe80::e478:40a9:9e0b:641c]) by CH2PR00MB0679.namprd00.prod.outlook.com ([fe80::e478:40a9:9e0b:641c%7]) with mapi id 15.20.3273.000; Mon, 27 Jul 2020 12:17:45 +0000
From: Mike Jones <Michael.Jones@microsoft.com>
To: Justin Richer <jricher@mit.edu>, Francis Pouatcha <fpo@adorsys.de>
CC: Tom Jones <thomasclinganjones@gmail.com>, Fabien Imbault <fabien.imbault@gmail.com>, Denis <denis.ietf@free.fr>, "txauth@ietf.org" <txauth@ietf.org>, Dick Hardt <dick.hardt@gmail.com>
Thread-Topic: [Txauth] Claims [was: - Dictionary]
Thread-Index: AdZkD+riq0GJ5lcCRnq7sXrv7U5Heg==
Date: Mon, 27 Jul 2020 12:17:45 +0000
Message-ID: <CH2PR00MB0679BFFBE4251753CCECA430F5720@CH2PR00MB0679.namprd00.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=f10c6cb4-8ab3-4ea7-b2fa-6237a9b0a71e; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-07-27T12:17:06Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47;
authentication-results: mit.edu; dkim=none (message not signed) header.d=none;mit.edu; dmarc=none action=none header.from=microsoft.com;
x-originating-ip: [50.47.89.111]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: 1ae8d08c-47ca-4a04-8b3c-08d8322711cb
x-ms-traffictypediagnostic: CH2PR00MB0746:
x-microsoft-antispam-prvs: <CH2PR00MB074601BC28A64465712033A1F5721@CH2PR00MB0746.namprd00.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: bbyO+Yjl30rMxQxs/L71I1lKYFh4cQErahUKISWDxxKyUFg4U8mDMAQYqDr9w0ssHt2KUYU3tGGJ8TCyefJqtJjqlkwzOz9yzjcXG2ZIsHIoeLornHalSu494uN5ZR9x0EmEFMh0bI6iQ1mX+vFJPTl+R65me76X22XPnrKWcxf0ZwlIm38nTGnz4whlakJcXB4Kt8OCvil/Iip5LXzFOF6VKBy2cpTJOichFoUmZyOS15kHMVMExsuRxLrn2v38LxVxKCYwMmsVomNsJlN/tTqEKiZ5pZa9E8efcf87zy7n6u8wrqZGuVK/1fuuijc5SZljgsw01FNgEF1ZkN/w3f3A3J0w2mqxXSuOGrAClhgK1xKdwOkEbIpBtvX3fNJ9k53jNgL6lj4Ix0j2eb0yPqmcPVUWryprKJU7hWMYLtf04gITTuiikyGfUE8dZoMcrYxbattljHgeuSYiQsn+Jy1q5b43ykGJkn8R957fDTs=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CH2PR00MB0679.namprd00.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(346002)(376002)(136003)(396003)(366004)(39860400002)(6506007)(53546011)(26005)(8990500004)(66946007)(66556008)(66476007)(30864003)(66446008)(76116006)(52536014)(7696005)(478600001)(64756008)(10290500003)(186003)(71200400001)(5660300002)(966005)(2906002)(83080400001)(86362001)(166002)(55016002)(33656002)(8936002)(110136005)(316002)(82950400001)(4326008)(83380400001)(66574015)(8676002)(54906003)(9686003)(82960400001)(99710200001)(15866825006)(559001)(579004); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata: QJbcZSjeCm73oNd6XZGXG7KPgBZbnFl63aBmQtaNdHlzGCkNKbmUXGoNw8mggPJmUDU8wPl4ceWik+NBnEYiUp+jBWThxBDJ5CssTOMx6F0mJo76FTgUk6fHVCZKZxP3K6ngxrUjuujK3nVBzNyuEtmdNsuVTW3PLrx9tsto5Npr35jevztqjAOOm3xOQeOSFGitYqBT0/oUnZ93himjPo5qeACdwGrkfyMDvvAQq7QVePsF/A80be3CjlfbMBC+izipxNAjUQ8xEI9OUofZAjPw8x9BN1Grw8qba5n3UsJPzbDoIWvI1LVDQ8AmCq5zqJklt9GklTUHybTWnWcQ7wcqE8b+ozIPceS2Qvewf48IQyxSB3KNvh9r3xHjjMJiIa/agbstJvviy7423uL4hzxgtx3alfYJyd+axaDM6GGHP2MwI3t9ZqWrPZNm+jMoLy04FCdmKz72N4ohsBF4WTUfSwgFex+nKDBt9AsYPEkUW24MkrfTuV+0LDKirYpozKyYjcerEtruHMmphjAoeao7BA1I+DRF18fjv+zAaa8gWGN1oucZGvsMzOV0CaScL1lrPWUae/LJhK5nRxnAQoLJU6/VSV1BAnLu+4HYvEVJ2Uv1koVwvLWw2Xib8aKAuqLRtvJrDYqm4p5dVv1n+g==
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_CH2PR00MB0679BFFBE4251753CCECA430F5720CH2PR00MB0679namp_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: CH2PR00MB0679.namprd00.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 1ae8d08c-47ca-4a04-8b3c-08d8322711cb
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Jul 2020 12:17:45.4728 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 4AN1QlgQd0ZLfWfpNZi3gQGKiT+YwDYL2zK57YkLxdeAh1ACbw16lFv6h9QPgNIyVsed7Jmvuc4LaXD5Hby2AA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR00MB0746
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/0uBGqL7KZ8xfRmhJLwuoBIA2c3o>
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 12:17:53 -0000

Responding to a few terminology points after catching up this thread.

Quoting from RFC 7519:

   Claim
      A piece of information asserted about a subject.  A claim is
      represented as a name/value pair consisting of a Claim Name and a
      Claim Value.

I believe that this definition remains suitable and applicable and we should keep using it.  The definition is not specific to particular kinds of subjects.  OpenID Connect ID Token claims are about the authentication that was performed.  UserInfo claims are about the End-User.  STIR claims enable verifying the ownership of telephone numbers.  Claims about any kinds of subjects are possible.

Quoting from OpenID Connect Core:

End-User
Human participant.

I’d advocate using “End-User” in this manner.  The term “user” can mean too many other things to people, as documented in this thread.

                                                       -- Mike

From: Txauth <txauth-bounces@ietf.org> On Behalf Of Justin Richer
Sent: Monday, July 27, 2020 5:15 AM
To: Francis Pouatcha <fpo@adorsys.de>
Cc: Tom Jones <thomasclinganjones@gmail.com>om>; Fabien Imbault <fabien.imbault@gmail.com>om>; Denis <denis.ietf@free.fr>fr>; txauth@ietf.org; Dick Hardt <dick.hardt@gmail.com>
Subject: Re: [Txauth] Claims [was: - Dictionary]

I agree with the separation between “roles” and “entities”. It’s exactly that kind of separation into roles that helped OAuth 2 succeed with the AS and RS roles possibly being the same entity, or not, depending on use case.

This is one of the reasons that I think “user” is an overloaded term. The user is an entity, not a role, and in spite of it being “understood” in the OAuth 2 world, it means a wide variety of other things outside that world. The same with “client”, I can’t tell you how many times I’ve had to explain what exactly an OAuth “client” is when I’m teaching a class.

As for specific recommendations: I’m in favor of the role “Requester” or “Requesting Party”. “Client” is arguably more confusing and harder to replace: I had tried to use “Resource Client” to make “client” more specific in XYZ but that turned out to be more confusing than helpful.

 — Justin


On Jul 27, 2020, at 6:12 AM, Francis Pouatcha <fpo@adorsys.de<mailto:fpo@adorsys.de>> wrote:



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


On Sun, Jul 26, 2020 at 6:45 PM Francis Pouatcha <fpo@adorsys.de<mailto:fpo@adorsys.de>> wrote:
Hello Dick,

On Sun, Jul 26, 2020 at 9:14 PM Dick Hardt <dick.hardt@gmail.com<mailto: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.

Or we could think of them all as entities. The RO is the entity that owns the resource. The User is the human that is using the Client.
When we think of them as entities, we run into conflicts when Entity-User eq. Entity-RO.
When we think of them as roles, Role-User is always != Role-RO



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.

When I think of orchestration, I think of coordinating, which is not what I think the Client is doing. The Client wants to consume the Claims and the Resources (combined are a Grant). The Client requests the Grant from the Grant Server. Where is the orchestration?
Look at the client. It is the center of interaction between User, GS and RS.


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.

I'd like to take a step back and understand the requirements. We are deep into solutions.
No, we are at the fundamental level. We Have to decide on whether to build a model based on roles oron entities... Then we use the result [ENTITY XOR ROLES] to define the use cases.
/Francis


Best regards.
/Francis

/Dick

[https://mailfoogae.appspot.com/t?sender=aZGljay5oYXJkdEBnbWFpbC5jb20%3D&type=zerocontent&guid=73419b32-a8e0-43cd-b91b-9330a43a4cf8]ᐧ

On Fri, Jul 24, 2020 at 7:21 PM Francis Pouatcha <fpo@adorsys.de<mailto: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<mailto: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<mailto: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<mailto: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.




[https://mailfoogae.appspot.com/t?sender=aZGljay5oYXJkdEBnbWFpbC5jb20%3D&type=zerocontent&guid=e4df23be-1720-4b85-9c97-a175791ef83c]ᐧ

On Fri, Jul 24, 2020 at 12:42 PM Justin Richer <jricher@mit.edu<mailto: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<mailto: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<mailto: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<mailto: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.



[https://mailfoogae.appspot.com/t?sender=aZGljay5oYXJkdEBnbWFpbC5jb20%3D&type=zerocontent&guid=423af76b-40f5-4bab-ac59-2b640944e5cd]ᐧ

On Fri, Jul 24, 2020 at 5:58 AM Justin Richer <jricher@mit.edu<mailto: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/


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