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

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

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 065273A11A0 for <>; Fri, 24 Jul 2020 11:31:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Status: No, score=-2.096 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, 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 YQcUWDUNMWJW for <>; Fri, 24 Jul 2020 11:31:39 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::336]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9F6823A11F1 for <>; Fri, 24 Jul 2020 11:31:39 -0700 (PDT)
Received: by with SMTP id 95so7691870otw.10 for <>; Fri, 24 Jul 2020 11:31:39 -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=ERNnRS+lSC8jeSk36EjZtyxsPy+2g3T0U/l6pfNzon4=; b=ekNmJdkcZihqlRv40m8aGbvf5bw0uKgwsXqe3rdRn8CKAFD2UNUVSDfU/muT74xUVL JQ50ga5HFf5uAQfCXlMaMgulYbAvYgzDEITT5PJhOtkHPLYy5lgfVYCEoq4Q3DXgv6fw vhbEBchiFOw5pzTMpNRsPURqhgalavmZlP8SoXjy3CZ5/IgB/EtNWxHYASQCoDOns117 pQOaRlYnQRDbkEGdkCVMdZ/rU/J6UJEb731ZK9fSuBRXyl7GgLH8I7rn6OTIIYDCraRz hFmNJQiwVQbKZdSyziJ2yLKtCm8q4rNiSn+fMuYt8FlbzW6BROrUPG8c7cSkCHo4SNhf mdXA==
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=ERNnRS+lSC8jeSk36EjZtyxsPy+2g3T0U/l6pfNzon4=; b=J1InnK66i3aK/UAXmGemiOksycRY3pgCeJviid5aZpA/fR0+/THCz3ukS5SMVm9L1N JtaS/9Cy1fpA/+y9IR63JJxvMCRiT+hN+ogPOJedQKnu13UY/R1H82gdUfNuf0VNDFJT xggFdlsKgJyzArOufjg/XxjMEoH9pDl1W8vUNNiNJkS0+bhC4AM0vsxTKrg05ifJemIg FF3mVA1L7W2OEly94Z+lKtYZmW3pZLtmeYEJQFfP/QJunHYB2H81VTEby9k36YKEh6M1 dmVKa2iLSVA2O1lLDRAYvbDZFmntVu4PeyZLsAJJDc7Xlpuc/A0pnH82dNtHv1ZpRMNp kKBQ==
X-Gm-Message-State: AOAM533hwvcZPLh7dDmbeuEvbdcsuLHCNTXR6sMIuWpG3l1M+NNun6it AsDEXlO8iNtGnwZSoFSpZtfB9vyISPgDfMs+PWs=
X-Google-Smtp-Source: ABdhPJyCdEWuuVm9stRLpcXX27xQU5SGMVq+0CBLnE8O7UxSmg0Vp9WT3is9Jlb06CKD3nr3wuDZI3gqD+nSDYuEZdg=
X-Received: by 2002:a9d:66ca:: with SMTP id t10mr9733489otm.358.1595615498819; Fri, 24 Jul 2020 11:31:38 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Tom Jones <>
Date: Fri, 24 Jul 2020 11:31:27 -0700
Message-ID: <>
To: Dick Hardt <>
Cc: Justin Richer <>, Francis Pouatcha <>,, Denis <>
Content-Type: multipart/alternative; boundary="000000000000015daf05ab342fae"
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:31:51 -0000

right - & i want the client to be the as, so i guess there is no need for
what you claim to be the purpose of GNAP in self-issed ids.
Since that is what i want, i am outta here.
Peace ..tom

On Fri, Jul 24, 2020 at 11:27 AM Dick Hardt <> wrote:

> I'm not saying an access token cannot have claims. I'm saying what the
> Client communicates to the GS so that there are claims in an access token
> is out of scope for GNAP.
> Said another way, GNAP specifies a container used by the Client to request
> access tokens from the GS, and then presents those access tokens to the RS.
> The contents of the container in the Client request, and the access token
> contents, are out of scope of the core GNAP protocol.
> On Fri, Jul 24, 2020 at 11:10 AM Tom Jones <>
> wrote:
>> 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