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

[Mike Jones <[e-mail]>]

I completely agree with Dick that, as written, XYZ is defining a new ad-hoc identity schema, which is unnecessary and counter-productive (and probably violates our charter).

I agree that explicitly reusing existing claims schemas, rather than inventing new ones, is one of the clear and compelling advantages of XAuth over XYZ.  I’d previously suggested that the Claims section of XYZ<https://tools.ietf.org/html/draft-richer-transactional-authz-08#section-2.7> be revised to not define new “email” and “subject” claims with an unknown schema but that hasn’t been done.  Other instances of this problem occur in the XYZ Transaction Request<https://tools.ietf.org/html/draft-richer-transactional-authz-08#section-2> and Transaction Response<https://tools.ietf.org/html/draft-richer-transactional-authz-08#section-8> sections.

Getting this right matters.

                                                       -- Mike

From: Dick Hardt <[e-mail]>
Sent: Monday, June 15, 2020 5:39 PM
To: Justin Richer <[e-mail]>
Cc: [e-mail]; Mike Jones <[e-mail]>
Subject: Re: [Txauth] adding identity claim schemas (was: XYZ-08 vs XAuth-08)

comments inline ...

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



On Jun 9, 2020, at 4:14 PM, Dick Hardt <[e-mail]<mailto:[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]<mailto:[e-mail]>> wrote:



On Jun 8, 2020, at 5:33 PM, Dick Hardt <[e-mail]<mailto:[e-mail]>> wrote:



On Mon, Jun 8, 2020 at 1:02 PM Justin Richer <[e-mail]<mailto:[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.

[https://mailfoogae.appspot.com/t?sender=aZGljay5oYXJkdEBnbWFpbC5jb20%3D&type=zerocontent&guid=60b8032d-e061-464e-afbb-1a82abd02f21]ᐧ

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?



[https://mailfoogae.appspot.com/t?sender=aZGljay5oYXJkdEBnbWFpbC5jb20%3D&type=zerocontent&guid=ce3e18dc-5740-4cdd-a3b2-69aa92e7755d]ᐧ