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

Dick Hardt <> Fri, 24 July 2020 17:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5BC4A3A1050 for <>; Fri, 24 Jul 2020 10:25:11 -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 xHrhoNxC_AKh for <>; Fri, 24 Jul 2020 10:25:08 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id ECCF23A104C for <>; Fri, 24 Jul 2020 10:25:07 -0700 (PDT)
Received: by with SMTP id r19so10708336ljn.12 for <>; Fri, 24 Jul 2020 10:25:07 -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=55tWg9kEsMPbmLuAPKlMX9oTpjj0IHC+Vkd8B2ZT6+s=; b=opOb4mSJ8cyUptevOJZoRHrxcwpZB4Qd4K1RQoSsIEyYR+oKGALd02lyIUyIV/Hbi4 g1w1IaxWzYY99muwh9rmFFg3Z/nsSrAyX5l3JGj+mO3uye9x/d03JLS5r8HRMMsAG4Pc FoM4Nbin5xeujh6nTDECdvVgxv8LfgwULiQSfisKj/mn6YvPZXF6zDOBXdv31GiEtc53 7rSqR0tYouCnehOqXWVZoh4BQ9Sgz9SN/w2PmyTd3cQJs0r6rQUzLE5b5fWImfiKAUuF ugf4PkQTCQ0CicHdlJLSTvOlCYFkAiBpN/TdFDjzLBbiAQ6CHero0QuaMBjFMyMO6nuP KkQA==
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=55tWg9kEsMPbmLuAPKlMX9oTpjj0IHC+Vkd8B2ZT6+s=; b=Y0zIqMZYbilQGcOEgxql1Jx0oBIls2fYIpOyytrOeKIW81F7lqim0CcHUGc30m4m0o Kcl3mfQSOi13YgEffbxti3kSepgFSb0JyQFFIY+Zzvwx+vkW0Ozp4XbCb2fKhBupsjJJ 8fMsxAsn+1pC//emtLLicFNKFWDvoldlyKL43JMCV2/ZY4DHZb3F+rF3Os4L/5I2qUY+ VlPSCdM+5ou7//FSv0kah0GUHvlb9w9RviyICkXjA9rqYyIeFn1DaYEYdSKzBUPbHCQz zLBN2rzMTfYH2FkP8h19AsigwWhDUdRegOvERD2Jl0GevbUHoWB3ETCcVS1fNrYF4Pg/ 0mpw==
X-Gm-Message-State: AOAM532xg1PflOwGV5rs2S2O7CjhwQc5TwAP7JoMKwUIEt5rgpR6yIZf eyd2a+B3ULISVjRonLfA0FMZaBiKTNOiCr/+7as=
X-Google-Smtp-Source: ABdhPJzJZMdBYar8p6UFf3yHxyergCUchRTvY5pI5dwL8BwAuamGi+1Jt5MCOEqq/jp7MMXGexfsJDfiiJUWQopfZgY=
X-Received: by 2002:a2e:900a:: with SMTP id h10mr4996267ljg.242.1595611506083; Fri, 24 Jul 2020 10:25:06 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Dick Hardt <>
Date: Fri, 24 Jul 2020 10:24:30 -0700
Message-ID: <>
To: Justin Richer <>
Cc: Francis Pouatcha <>,, Tom Jones <>, Denis <>
Content-Type: multipart/alternative; boundary="000000000000050e6005ab3341d8"
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 17:25:12 -0000

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?



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