Re: [Txauth] adding identity claim schemas (was: XYZ-08 vs XAuth-08)

[Dick Hardt <[e-mail]>]

comments inline ...

On Wed, Jun 10, 2020 at 8:07 AM Justin Richer <[e-mail]> wrote:

>
>
> On Jun 9, 2020, at 4:14 PM, Dick Hardt <[e-mail]> wrote:
>
> Forking this topic to a new thread
>
> +Mike as he has expressed concern about creating new identity claims
>
> On Tue, Jun 9, 2020 at 9:10 AM Justin Richer <[e-mail]> wrote:
>
>>
>>
>> On Jun 8, 2020, at 5:33 PM, Dick Hardt <[e-mail]> wrote:
>>
>>
>>
>> On Mon, Jun 8, 2020 at 1:02 PM Justin Richer <[e-mail]> wrote:
>>
>> <snip>
>
>> I don't follow how this would work. Perhaps you could provide an example
>>> in JSON?
>>>
>>>
>>> One method is defining a new value inside the XYZ “claims” request
>>> object that maps to a specific sub-schema:
>>>
>>> claims: {
>>>    “subject”: true,
>>>    “email”: true,
>>>    “oidc”: {
>>>        "userinfo":
>>>         {
>>>          "given_name": {"essential": true},
>>>          "nickname": null,
>>>          "email": {"essential": true},
>>>          "email_verified": {"essential": true},
>>>          "picture": null,
>>>          "http://example.info/claims/groups": null
>>>         },
>>>        "id_token":
>>>         {
>>>          "auth_time": {"essential": true},
>>>          "acr": {"values": ["urn:mace:incommon:iap:silver"] }
>>>         }
>>>       }
>>> }
>>>
>>>
>>> That should look pretty familiar. Alternatively, this could be done with
>>> a separate top-level request object field:
>>>
>>>
>>> claims: {
>>>    “subject”: true,
>>>    “email”: true
>>> },
>>> “oidc_claims_request”: {
>>>        "userinfo":
>>>         {
>>>          "given_name": {"essential": true},
>>>          "nickname": null,
>>>          "email": {"essential": true},
>>>          "email_verified": {"essential": true},
>>>          "picture": null,
>>>          "http://example.info/claims/groups": null
>>>         },
>>>        "id_token":
>>>         {
>>>          "auth_time": {"essential": true},
>>>          "acr": {"values": ["urn:mace:incommon:iap:silver"] }
>>>         }
>>> }
>>>
>>>
>>> In both cases the AS is going to need to knit them together into a
>>> sensible request policy, especially since the OIDC claims query language
>>> has overlapping implications to one particular resource, the UserInfo
>>> endpoint. My contention wasn’t with your proposed solution, my contention
>>> was you claiming that XYZ has a fixed schema and is therefore limited in
>>> extensibility.
>>>
>>
>> One of the objectives of this work is to have extension points. My point
>> was that XAuth had a clear extension point for adding schemas. How to
>> extend XYZ was not clear in your proposal.
>>
>>
>> I am sorry that the extensibility of the protocol was not clear. It is
>> stated in each section that additional items can be added, and I have
>> stated repeatedly that it’s extensible and demonstrated how, here on this
>> list.
>>
>> I think the XAuth proposal is better than the two examples you proposed.
>> In your first example, the schema is a second class schema, and in your
>> second example, claims are spread across to top level options. Both of
>> these pollute other schemas.
>>
>>
>> Not surprisingly, I disagree about the cleanliness of XAuth’s proposed
>> approach. The proposal here adds external schemas as extensions instead of
>> relying on them internally.
>>
>> If anything, I think that the OpenID Foundation would be the ones to
>> define how to make an OIDC claims request using this protocol, not us,
>> since they own and control that query syntax and everything it implies. We
>> can provide a means of extension.
>>
>> I also think there’s value in defining a set of core interoperable
>> identity fields, which themselves could also be extended.
>>
>> All of these mechanisms should be controlled by some combination of
>> registries and collision-resistant namespaces, which is the approach I’ve
>> taken for extensibility throughout XYZ.
>>
>
>
> JSON by its nature is extensible. Adding new members to an object is
> straight forward. XYZ is not unique here. It sounds like your idea of
> extensibility is telling people that they can add new members to JSON. Of
> course they can. That is like saying you can add new query parameters to a
> front channel OAuth 2 request.
>
>
> Yes, exactly. And that’s exactly how OAuth 2 has been extended. I’m glad
> you see that now.
>

I think you are missing my point. Adding query parameters to OAuth 2 was
not a defined extension point. It was inherent in how query parameters
work. OAuth 2 did define the type of grant as an extension point.


>
> My concern was that XYZ does not have a clear way to add new identity
> claim schemas. You have two examples, add a schema as a member of the
> claims object, which is mixing claims with schema extensions, or adding a
> root member, which is then putting claims into more than one place. It is
> not clear where to add a new schema, so we could easily end up with new
> schemas in both places. That sounds confusing.
>
>
> In XAuth, the members of the claims object are the schema. Adding a new
> schema is done one, consistent way.
>
>
> I provided a couple examples off the cuff of possible ways to extend
> something, as your base claim was that XYZ could not be extended with new
> or external query schemas. Of the two, I think that it makes more sense for
> it to be a separate top-level object. Why? Because the OIDC “claims”
> request syntax not only dictates claims within the OIDC schema, it also
> specifies how the information comes back. The XYZ claims request talks
> about information that comes back in the XYZ claims section of the
> response.
>

I would put the OIDC request to acquire claims from a user_info endpoint
into the authorization request so that there is a consistent way to get
back an access token, as opposed to a new top level object that could
return claims and/or an access token.


> Since the OIDC request allows for targeting specifically to the ID token
> and UserInfo Endpoint, I think it is much cleaner to be at the top level as
> its own thing.
>

My point is that XYZ does not *define* how to add new schemas. An extension
can add anything it wants to the JSON, and as you have shown there is more
than one way to do it, and I think long term when there are divergent
mechanisms, the code is going to get ugly in detecting what claims are
being asked for.



>
> wrt. "defining a set of core interoperable identity fields", the charter
> says we should be NOT develop a new schema:
>
> The group is chartered to develop mechanisms for conveying identity
> information within the protocol including identifiers (such as email
> addresses, phone numbers, usernames, and subject identifiers) and
> assertions (such as OpenID Connect ID Tokens, SAML Assertions, and
> Verifiable Credentials). The group is not chartered to develop new
> formats for identifiers or assertions, nor is the group chartered to
> develop schemas for user information, profiles, or other identity
> attributes, unless a viable existing format is not available.
>
>
> wrt. OIDC claims, the charter explicitly calls out developing mechanisms
> for conveying ... OIDC ID Tokens.
>
> ᐧ
>
>
> Precisely: the charter says we will have a way to convey identifiers and
> assertions. The XYZ “claims” section lists identifiers that can come back,
> in plain text, and assertions, that can also come back along side them.
>

These claims are a schema. We will have an IANA entry for what claims are
allowed inside of the claims object. This is defining a new schema.


> It’s not a full query language and isn’t intended to be, and I think that
> it would actually be dangerous for this to be a full identity schema, but
> it is itself extensible internally if someone wants to do that. Claiming
> that a list of identifiers is “developing a new schema” is an argument
> several bridges too far from reality.
>

You are not inventing new identifiers, but you will be defining which
strings are being used to represent which concepts. FOr example you have
"email" vs "email_address", or any other string combination that a human
would likely interpret as an email like object.  Then there is specifying
what can be in the field.


> I picked a couple examples out of thin air, with the idea that we’d
> bikeshed them eventually and tie them to a registry. We might want to
> re-use a set of identifiers here, and for that I actually like Annabelle
> Backman’s proposal to the SECEVENT group better than most that I’ve seen in
> the space:
>
> https://tools.ietf.org/html/draft-ietf-secevent-subject-identifiers
>

That is one schema. And it has advantages for the subject identifiers, but
obviously does not cover the wide array of other identity attributes.

Why would we not want to reuse existing schemas? And support all of them?



ᐧ