proposal to use subject identifiers (RFC 9493) instead of the plain claim "sub"

[adeinega]

I also propose another important change to keep things unambiguous; moving the spec from using claim sub to subject identifiers defined by (RFC 9493).

https://lists.openid.net/pipermail/openid-specs-ab/2025-April/010775.html

This way, we remove the need for an RP administrator

1. to guess what the sub claim represents (in both OP commands, as well in the ID Token), and
2. to perform manual work, which is always prone to user error

in addition to that, Subject Identifiers are a good extension point for the spec (a variety of identifiers can represent the same subject).

[selfissued]

ID Tokens, Logout Tokens, and Access Tokens [RFC 9068] all use "sub" rather than Subject Identifiers. Given that this spec is extensions to OpenID Connect, I think it makes more sense to stay aligned with Connect.

[adeinega]

@selfissued, It’s also true that other specs use Subject Identifiers (Shared Signals Framework, CAEP, and RISC profiles), they aren't aliens for the OpenID Foundation.

Subject Identifiers don't necessarily mean incompatible changes for ID Tokens; the structure of ID Tokens can remain the same with an exception for a new claim -format... I don’t think it's the right place to discuss this particular aspect though.

I made this proposal because they add value by removing ambiguity on what we get in sub, I'm letting you guys (and the WG) to decide what to do with this next.

[dickhardt]

@adeinega what are the use cases when you would want to use an identifier other than sub?

Currently, the spec is constrained to accounts from an OP, and users are always represented by a sub.

We discussed this on the call today and unless there is a clear use case for expanding the scope, we will stay with sub.

[adeinega]

As of today, the OpenID Connect Core spec (errata set 2) defines the Subject Identifier as

A locally unique and never reassigned identifier within the Issuer for the End-User, which is intended to be consumed by the Client, e.g., 24400320 or AItOawmwtWwcT0k51BayewNvutrJUqsvl6qs7A4.

The sub values 24400320 and AItOawmwtWwcT0k51BayewNvutrJUqsvl6qs7A4 provided above are there for a good reason; they are great from the privacy perspective. However, don't necessarily mean much for an RP administrator who wants to select the appropriate identifiers for user identification within his RP. For example, he could choose from an email, login ID, or corporate ID, or something else, when users are provisioned by an OP using the activate command.

This way, the RP administrator declares "I want an OP to provide a user's corporate ID when it provisions a new user with the help if activate command as that makes sense for an RP I control for its further authorization decision, etc.". If we don't have such a mechanism in place, the administrator needs to manually go from one to another OP trying to figure out what to use from the activate command. This is an error-prone process and it's difficult to automate anything. At scale, these things only get more visible; just as an example, a multi-tenant RP can be integrated with multiple OPs at the same time (different tenants or Orgs in Microsoft Entra AD).

Another use case I had in mind is that an RP may want to have not only information users that are able to log in but also other persons / employees for its own purposes; these won't be (necessary) able to be authenticated. This is also conceptually similar to class Person and organizationPerson in LDAP.

Subject identifiers (RFC 9493) provide this flexibility, or can act as extensibility points to address these use cases.

[dickhardt]

When I read your example, it seems you are wanting to change how OpenID Connect works, which is out of scope for OpenID Provider Commands.

It is a common practice to map from the email address to a record if the sub is not found in OpenID Connect. An implementation of OpenID Provider Commands would likely follow the same pattern.

Being able to share other, arbitrary identifiers for an account would lead to bespoke implementations and significantly reduce interoperability, and reduce automation in my opinion.

A challenge in LDAP is that each deployment is slightly unique, requiring deployment specific config. We aim to remove that in OP Commands.

I'll keep the issue open for a while in case you have a more concrete use case that does not add deployment friction.

[adeinega]

@dickhardt, I was thinking about this more... after all prior discussions on this matter.

Let me put aside the subject identifiers from RFC 9493 (which I suggested to use in the first place).

I’d like RPs to have the ability to communicate to OPs something like “Dear OP, when you create an account, please include the following attributes, as they are crucial for me: user_name (login), employee_id, department, title, and manager”.

Also, as an RP, I would like to ensure that authentication responses I receive from you use the same sub values even in cases one day

1. I move from clientA to clientB on your side (here, I refer to the public and pairwise subject identifier types defined in https://openid.net/specs/openid-connect-core-1_0.html#SubjectIDTypes).
2. I move from one vendor to another vendor of OP (this isn't that uncommon in B2B).

[aaronpk]

Thanks for clarifying the use cases!

Including additional attributes in the user create commands is definitely needed, but I think that should absolutely not be done as an alternative for the plain string sub claim.

Migrating from one vendor to another is an interesting scenario, but I would argue that it should be handled as a migration rather than trying to make the new OP behave like the old OP.

Neither of these should be accomplished by changing the sub value IMO, but we should definitely capture these use cases to solve somehow!

[dickhardt]

@aaronpk fully agree!

The RP communicating what it wants from the OP on account creation seems like something that can be done in the metadata command response from the RP to the OP.

For interop, we would ideally define additional standard claims.

Teasing out some of your comments @adeinega -- there does seem to be something that could be done about mapping the account from the OP context to the RP context. I'm going to chat with @mcguinness about it and then write something up if it makes sense.