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

Justin Richer <jricher@mit.edu> Fri, 24 July 2020 12:58 UTC

Return-Path: <jricher@mit.edu>
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 A45043A0A2C for <txauth@ietfa.amsl.com>; Fri, 24 Jul 2020 05:58:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.919
X-Spam-Level:
X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 QzxyEJe62Keb for <txauth@ietfa.amsl.com>; Fri, 24 Jul 2020 05:58:30 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 417A23A0A29 for <txauth@ietf.org>; Fri, 24 Jul 2020 05:58:29 -0700 (PDT)
Received: from [192.168.1.3] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 06OCwOoN023121 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 24 Jul 2020 08:58:25 -0400
From: Justin Richer <jricher@mit.edu>
Message-Id: <EE0A9241-60D6-493F-9351-2F607D59D3E2@mit.edu>
Content-Type: multipart/alternative; boundary="Apple-Mail=_F9B2FD24-14E0-4A5A-A088-0D5C5A064D2E"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Fri, 24 Jul 2020 08:58:24 -0400
In-Reply-To: <CAOW4vyPQgQZ_fZB_rHvWFCvrTon4Vix7raTGG9gdc=Z1_=YA-w@mail.gmail.com>
Cc: Dick Hardt <dick.hardt@gmail.com>, txauth@ietf.org, Tom Jones <thomasclinganjones@gmail.com>, Denis <denis.ietf@free.fr>
To: Francis Pouatcha <fpo@adorsys.de>
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>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/KLUzDbgR9OOatjiPInhiA84nkZM>
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: Fri, 24 Jul 2020 12:58:32 -0000

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