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

Tom Jones <> Fri, 24 July 2020 18:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 22E793A0C75 for <>; Fri, 24 Jul 2020 11:10:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.095
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 3569LPpVperX for <>; Fri, 24 Jul 2020 11:10:22 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::329]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0CF0C3A0C54 for <>; Fri, 24 Jul 2020 11:10:22 -0700 (PDT)
Received: by with SMTP id v21so373498otj.9 for <>; Fri, 24 Jul 2020 11:10:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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;; 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: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Tom Jones <>
Date: Fri, 24 Jul 2020 11:10:09 -0700
Message-ID: <>
To: Dick Hardt <>
Cc: Justin Richer <>, Francis Pouatcha <>,, Denis <>
Content-Type: multipart/alternative; boundary="000000000000dae3ee05ab33e224"
Archived-At: <>
Subject: Re: [Txauth] Claims [was: - Dictionary]
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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 <> 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 <>
> 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 <> 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 <> 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