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

[Justin Richer <[e-mail]>]

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 <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] <mailto:[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.
> 
> ᐧ