Re: [Txauth] WG scope wrt. identity (Was: Polymorphism (Was: JSON Schema?))

[Dick Hardt <[e-mail]>]

My interpretation is pretty straight forward:

1) GNAP should be able to return ANY claim, not just identifiers.

2) GNAP should not define any claim schema, contrary to what XZY does

The pushback in the group, which I am pretty familiar with having been a
BoF chair at the time, and I personally worked to resolve, was that
"identity" was too broad, and there was concern the scope included defining
new schemas. The revised charter made that clarification. I don't recall
ANY discussion that GNAP should only return identifiers. The charter reads
that identifiers are included in what could be returned.

If you did not agree with non-identifier claims being in XAuth since the
beginning, why did you not say anything? I have not agreed with XYZ
defining a new schema, and have voiced that concern a number of times.

The above reasons are why I was surprised to suddenly learn your position.






On Fri, Jul 10, 2020 at 1:09 PM Justin Richer <[e-mail]> wrote:

> It seems to be pretty clear that you and I are interpreting the charter
> text differently, so I’d like to hear what the chairs think the best
> approach will be when we finally get to defining what’s included in GNAP.
> This should perhaps be a discussion point for the group in the upcoming
> meeting. Until then, I can hopefully expand on what I interpret.
>
> The charter uses the term “identity information within the protocol
> including existing identifiers ... and assertions” and not “claims”, which
> I think is more precise and that GNAP should use language instead of
> “claims” for this reason. I think the XYZ use of the term “claims” is a
> mistake and it should change because it’s confusing.
>
> The only time “claims” are mentioned in the charter is in the section
> about not making assumptions about the client and having a protocol
> “allowing for … Approval of AS attestation to identifiers and other
> identity claims”. To me, this does not say that the protocol should have
> room for more advanced identity stuff, not that GNAP should specify how
> it’s requested or returned.
>
> There are use cases for getting signed assertions back from the AS as
> well, and so the protocol should allow for that. While assertions can often
> contain non-identifier claims, it’s not up to GNAP to define what those
> claims are, how they’re requested, or how they’re returned. There are also
> lots of valid use cases for the client requesting a specific set of
> non-identifier claims about the user. The question is, how much of that
> detail should we be solving directly here in GNAP? I think it’s pretty
> clear that the answer is “not much at all”.
>
> My original XYZ proposal didn’t have any identity information in it, much
> like OAuth 2. After talking with Aaron and a few others, I was convinced
> that we could have a very small delta to let the client know who the user
> is. When writing the charter text, that’s what I originally had in mind by
> the “identity” language throughout. Several people spoke up and said that
> they would like space left to return signed assertions as well, and there
> seemed to be enough support to have that as an option in the charter so it
> was added. What I did not see support for, and in fact saw explicit
> pushback against, was defining ways to return additional user information
> in the GNAP response, at least as defined internally by GNAP. That seems to
> be what you’re arguing for doing here.
>
> I think there will be room, and need, for a protocol on top of GNAP to
> define identity schemas, assertions, session handling, authentication
> contexts, and identity-based APIs in a standard way. It’s my understanding
> that all of this is outside of GNAP’s core focus, but that GNAP should keep
> this kind of work in mind in its design. So that, for instance, we don’t
> accidentally design a protocol that prevents an AS from tying both identity
> information and
>
> I realize that Xauth had non-identifier claims since early drafts, and I
> disagree with their inclusion. I think that the group is going to have to
> decide how far down this identity road we really want to go with GNAP, and
> I don’t think that’s an answered question yet.
>
>  — Justin
>
>
> On Jul 10, 2020, at 2:33 PM, Dick Hardt <[e-mail]> wrote:
>
> Justin, your stance is surprising for the following reasons:
>
> 1) Both XYZ and XAuth use the term claims, rather than identifiers. "A
> claim is a statement that one subject, such as a person or organization,
> makes about itself or another subject."[1]. A claim is clearly more than an
> identifier.
>
> 2) XAuth has had non-identifier claims in the examples since -01 (name,
> photo).
>
> 3) The charter does not state that ONLY identifiers will be returned,
> identifiers are one of the examples, as are OIDC ID Tokens, SAML
> assertions, and Verifiable Credentials. All of these often bind
> non-identifiers to one or more identifiers.
>
> [1]
> https://en.wikipedia.org/wiki/Claims-based_identity#Identity_and_claims
>
> Justin's stance earlier in the discussion:
>
>
> My stance is that we allow the client to ask for a small set of
> identifiers about the user, or even just ask to “identify the user”, and
> leave everything else to a higher level identity protocol. I do not think
> that having an identity and profile query/response language at the core of
> GNAP is a good idea, and it’s certainly not in our charter.
>
>
> On Thu, Jul 9, 2020 at 5:44 PM Justin Richer <[e-mail]> wrote:
> <snip>
>
>> I’m sorry that you are surprised by my stance, but it hasn’t changed
>> since I helped write the section of the charter that you quoted below. A
>> big reason that I chose that wording was to support this use case but not
>> to go in depth with an identity protocol, which I never really wanted us to
>> do. However, it seems as soon as “identity” was brought up previously,
>> people immediately jumped into talking about a full stack of user
>> attributes and profile information. That wasn’t my intent in talking about
>> identity, and I don’t think it’s something GNAP ought to do, at least not
>> on its own.
>>
>> I do think there’s room for us to provide identifiers alongside the
>> access token, so that’s there. There was stated interest in providing
>> signed assertions as well, so I made sure that was enumerated for those who
>> want to do such work. And I think it makes sense for us to provide a way to
>> describe what kinds of things I want to get from an access token by
>> defining a general purpose syntax for describing those things (notably, as
>> a combination of reference strings and multi-dimensional objects). With
>> these two, we can get most of what we need for a basic login system.
>> Anything beyond that is going to need user profiles, authentication
>> contexts, session control, and a lot of other identity-protocol stuff that
>> GNAP shouldn’t be focusing on. We should keep it in mind as we build GNAP,
>> but I think that like OIDC all that important extra stuff should be built
>> separately. To me, that’s what not defining schemas and formats means.
>>
>> I don’t see any conflict with the charter here, and I’m surprised that
>> you do.
>>
>> ᐧ
>
>
>