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

[Tom Jones <[e-mail]>]

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 <[e-mail]> 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 <[e-mail]>
> 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 <[e-mail]> 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 <[e-mail]>
>>> 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 <[e-mail]>
>>>> 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 <[e-mail]> 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
>>>>>>
>>>>>