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

[Dick Hardt <[e-mail]>]

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.
>
> ᐧ