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

Tom Jones <thomasclinganjones@gmail.com> Fri, 24 July 2020 18:10 UTC

Return-Path: <thomasclinganjones@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 22E793A0C75 for <txauth@ietfa.amsl.com>; Fri, 24 Jul 2020 11:10:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.095
X-Spam-Level:
X-Spam-Status: No, score=-2.095 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_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=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 3569LPpVperX for <txauth@ietfa.amsl.com>; Fri, 24 Jul 2020 11:10:22 -0700 (PDT)
Received: from mail-ot1-x329.google.com (mail-ot1-x329.google.com [IPv6:2607:f8b0: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 0CF0C3A0C54 for <txauth@ietf.org>; Fri, 24 Jul 2020 11:10:22 -0700 (PDT)
Received: by mail-ot1-x329.google.com with SMTP id v21so373498otj.9 for <txauth@ietf.org>; Fri, 24 Jul 2020 11:10:22 -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=wRuhdHTRiuV8hGWBwECy5+jjElIK7WHLUPrhZWKofQ8=; b=t/3apSG+qPKGJbYFlHv8CVPDCzVWWcURGIGVsPPuugwe/t7JF4YQs0B3zDY/pp4p8D vrclMVF8SDKSZ8Xlqx0WgXsoOQrWzouU+qsfw07UU7I4fk513bOeRLh0RehFHVoCSwbo zJppVdVCG17uzX/div+slFKvmdScDc8J0L2L8W+/Vb1+wtHQb11Zms9K523Yrs/myjX2 j1axYwxkz8ywD3eMlJ8NzcV6RpspTM++QkgjbhtJ70xbvh9/wbvRvshGNektEH8gmtzK LnDdPFyayRMVY5TxNJZbExiyinXfYYu1bWZeQeLK99Ynm0O9aJU8HkhGKAZnO6it3vBw KS1Q==
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=wRuhdHTRiuV8hGWBwECy5+jjElIK7WHLUPrhZWKofQ8=; b=HPOkjfeZWhFzRDwWdyUza0L9pWKBufzqEHt8omMgekLxdgXC0pvEZYAvt+CdOU0oyG KKROT38/2MSTu6E4mnpsH3BO2+DKgau23/CxJFgFj2JXix+OajXpNyUccuIuGEriJxCm YbdbuVAhJjTAYT63u4K+Ojiq/vPGMsDytCehjKBbrkYt9/dVmo4Ij4ZS5buaprDecX27 DJVArKPg6fS8g2/ZhYVxYSy6pR32R+32BpmbLUtaM1cW0JlpCq7axzEjkugiIOmk0fgx mf79Lzz7RqUmagLfQl2vlUs3+Zbb3HgDhFgKo8VRAyHBjyAmtpyRvYGCNeW/paD4A5hK 63WQ==
X-Gm-Message-State: AOAM532fJiZuKTPKnPlMs41nOyHjFy4mcm7Pr8D6QiOo5NlYkf3V5eFV bKM+7YyJ98sXK0WhKBRje/6Q9z9NSBMEC7VDw8I=
X-Google-Smtp-Source: ABdhPJw7UWvfYSKSYNkU/gJnLJo5N6MvHWDLDsw6pdVGsaHq5wP5qrWrMYshnL1XNJ8J0J2pEu0v7boXbPIPD7QTX/0=
X-Received: by 2002:a9d:a03:: with SMTP id 3mr9617333otg.87.1595614221229; Fri, 24 Jul 2020 11:10:21 -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> <CAK2Cwb4CR7PPDiifvv9s88OyBGpGNWCVSamY8xXp3PJxSx9wVg@mail.gmail.com> <CAD9ie-t6XJyF4ZjckQtoPz0zeZ-1p-RXUeQw6+N+fYrDgZ3ooQ@mail.gmail.com>
In-Reply-To: <CAD9ie-t6XJyF4ZjckQtoPz0zeZ-1p-RXUeQw6+N+fYrDgZ3ooQ@mail.gmail.com>
From: Tom Jones <thomasclinganjones@gmail.com>
Date: Fri, 24 Jul 2020 11:10:09 -0700
Message-ID: <CAK2Cwb753sQ-=jtvD-qPTEAtmrmsBOWf+mTW2V4_eXw13JQonA@mail.gmail.com>
To: Dick Hardt <dick.hardt@gmail.com>
Cc: Justin Richer <jricher@mit.edu>, Francis Pouatcha <fpo@adorsys.de>, txauth@ietf.org, Denis <denis.ietf@free.fr>
Content-Type: multipart/alternative; boundary="000000000000dae3ee05ab33e224"
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/9FDw9UQj6La9KnOotsJc7XDcymk>
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 18:10:24 -0000

now that is interesting.
So that i can understand what you're saying.
the access token that is issued (somehow) by the user to give the client
access to rs resources, does not have claims?
boy am i in the wrong place.

Peace ..tom


On Fri, Jul 24, 2020 at 10:50 AM Dick Hardt <dick.hardt@gmail.com> wrote:

> Hi Tom, thanks for sharing.
>
> I would consider the guardianship use case to be issuing an access token,
> not claims, as it is being used to access an RS.
>
> In my view, we keep Claims in GNAP to be only about the User, and the only
> consumer of the Claims is the Client the User is using. This keeps Claims
> from being overly complex.
>
> ᐧ
>
> On Fri, Jul 24, 2020 at 10:32 AM Tom Jones <thomasclinganjones@gmail.com>
> wrote:
>
>> Nat and I just had this discussion about claims & the claims aggregation
>> spec.
>> An example about claims that are not entirely about the user is the
>> gurdian ship case.
>> That case can be solved by creating a signed set if claims (which needs a
>> name) from the RO granting approval to the user to make a "ID Token"
>> (whatever) from the as to the client to be passed to the RS.
>> my suggesting is that claim as not necessarily attributes and the data
>> about the ro from the rs are distinct from the claims about the user from
>> the as.
>> I do not believe that claims aggregation is about claims (at least not
>> often).
>> so then the data from. the ro would never be a claim, even tho it was
>> identical in form and substance from the claim produced by the as.
>> Peace ..tom
>>
>>
>> On Fri, Jul 24, 2020 at 10:25 AM 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
>>>>
>>>