Claim token profiling

[xmlgrrl]

(Also see #119.)

Mike suggested: Why not just link to: http://openid.net/specs/openid-connect-core-1_0.html#IDToken Also, the id_token reference in general is very confusing to me, because user_claims are optional in the id_token--some implementations may only return user claims in the Userinfo JWT. In fact, what's the point of using the code flow if you return the claims in the id_token? You might as well use implicit flow, because you're obtaining use claims without client authentication at the token endpoint...

My response: One of the open issues is to consider defining a couple of proper claim token profiles, one for OIDC (likely as you suggest above) and probably one for SAML assertions. "Hybrid" was meant to allow extension claims, and that's something we should be sure to allow, one way or another. Thoughts?

His response: To me, Hybrid Flow means code + token|id_token and it may include the c_hash for "code id_token" and "code token id_token". I don't know what you mean about Hybrid allowing extension claims. Most people have no idea what Hybrid Flow is about. Jones|Bradley edited out most of the background info in the OpenID Connect specs to minimize editorial discussions. But as a result, it's not terribly clear--maybe I'm missing something. I still think it would be better to use the id_token link.

[xmlgrrl]

Per UMA ad hoc telecon 2017-03-06: Typo: In Sec 6, s/for for/for/

Justin agrees the whole “hybrid” thing makes no sense. But since the client is the primary audience of the ID token, we’re back to:

• Narrow ecosystem: AS=IdP, in which case, it can be entirely “out of band” of UMA because the client already has the user (RqP) context. Eve notes that even in narrow ecosystems, which G2C seems to have a bunch of, interop can be valuable because of independent implementation. And then potentially in future phases, the vertical sectors might want to start combining. The question is, since we no longer have an AAT for “stateful” versions of same, should we pick a better string for the OIDC “stateless” version, namely, http://openid.net/specs/openid-connect-core-1_0.html#IDToken as Mike suggests?
• A medium ecosystem where the audience field pretty much only works if the AS has pre-established trust with the RqP’s IdP — we don’t know of these in the wild yet, but Eve knows of some future-phase projects that may require these. Justin asks the question: What behaviors would change on the client’s part if the AS were to declare support for an OIDC mechanism vs., say, a SAML or PKI?? or whatever mechanism.
• Wide ecosystem — Eve and Justin both expect these to use the interactive flow, which would bootstrap a PCT

We could:

1. Just switch the string in the example, and not define it as a claim token profile or an UMA profile.
2. Define a claim token profile.
3. Switch the notion of claim token profiles to UMA profiles.

Eve will try #1 for now, and issue #119 about IANA registries is pointless. :-) We can soften the language around “claim token profiles” and say it can be another kind of UMA profile if you feel the need.