Hey, (possible repost - hope not, though I didn't realize I had to subscribe the list first and the first mail seemingly got blocked)
Hopefully this is the right audience. I am discussing a part of the OIDC 1.0 Spec with our third party identity provider and wanted to verify something. They recently implemented a change on their test-system where they create a new "sub"-claim for every single login action. They store a stable unique identifier in another custom claim, let's call it "abcd" instead. This breaks the login for our services, because we rely on the "sub" claim to be consistent (= always have the same value for the same user), as the following part of the specification seems to state pretty clearly: *5.7. Claim Stability and UniquenessThe sub (subject) and iss (issuer) Claims, used together, are the only Claims that an RP can rely upon as a stable identifier for the End-User, since the sub Claim MUST be locally unique and never reassigned within the Issuer for a particular End-User, as described in Section 2. Therefore, the only guaranteed unique identifier for a given End-User is the combination of the iss Claim and the sub Claim.All other Claims carry no such guarantees across different issuers in terms of stability over time or uniqueness across users, and Issuers are permitted to apply local restrictions and policies. For instance, an Issuer MAY re-use an email Claim Value across different End-Users at different points in time, and the claimed email address for a given End-User MAY change over time. Therefore, other Claims such as email, phone_number, and preferred_username and MUST NOT be used as unique identifiers for the End-User.* They argue that it's a "grey area" and they chose to implement a different "Subject identifier Type" they call "transient", where each login generates a random identifier. I argue that it's a clear violation of the specification as "sub" is meant to hold the Subject Identifier, not some random claim like "abcd" - no matter the Subject Identifier Type. Also a Subject Identifier Type "transient" like they describe seems absurd - a random string *identifies nothing*, so that can never be a valid *Subject Identifier *in my opinion. Maybe you can help settle this? Does the specification allow returning a random "sub" for every request and setting the real Subject Identifier in another claim instead? Kind regards, Mario
_______________________________________________ specs mailing list [email protected] https://lists.openid.net/mailman/listinfo/openid-specs
