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

From: Mike Jones <[email-masked]>
Date: Tue, 9 Jun 2020 20:47:08 +0000

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 <[email-masked]>
Sent: Tuesday, June 9, 2020 1:15 PM
To: Justin Richer <[email-masked]>
Cc: [email-masked]; Mike Jones <[email-masked]>
Subject: Re: [Txauth] adding identity claim schemas (was: XYZ-08 vs XAuth-08)

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 <[email-masked]<mailto:[email-masked]>> wrote:

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

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

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.

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.

ᐧ