Same Person different Subject Identifiers

[Alberto Pulido Moyano]

OpenID Core explains the way Subject Identifiers allows RP/OP exchange the user id however, I believe it does not specify how the OP should deal with multiple users belonging to the same natural person.

I think that trust frameworks would benefit from preventing identity providers to allow same person presenting two or more different identities. Imagine an example scenario where I have two set of credentials for operating with my bank, irrespective of the credential I use, my bank knows I am the same person. However, if I use my bank to login/register with another company, and I choose one or the other each time, for that company I could perfectly be two different persons for them.

That scenario is something we are probably OK with but, giving the relevance of this specification for KYC, my proposal is to somehow introduce a way to enforce OPs to deal with that accordingly and try to return the same subject identifier regardless of the user credentials.

I would love to have your opinion on this topic!

Thanks!

‌

[Kosuke Koiwai]

Yes, there are some cases I can think of that RPs would like to have this feature.

• A RP that gives some incentive to new users: $5 credit for new users or first X months free
• A RP that wants to “blacklist” a specific person

RP can prevent duplicate users by matching name and birthdate but it’s not perfect, and it’s always better to have a way without giving out personal data (name/birthdate).

[Kai Lehmann]

In regards to the example with bank accounts, I understand that there are shared accounts (for spuses for instance) where each spouse has their own credentials. hose users are different accounts and should thus also result in different subject identifiers. However, there might be account providers allowing their end users to create several identities for their accounts and the end users can choose what identity is used with which RP. In this case, I would assume that the subject identifiers are also dissimilar. Should an end user decide to use a different identity for a RP the next time they use the SSO feature with their account provider, the end user would usually intend to create another account on the RP side. If those subject identifiers would be the same, the RP would suddenly receive different claim values for the same subject identifier (e.g. email address/phone number changing) and it would not allow the end user to have separate/multiple accounts at the RP. After all, this is also some kind of privacy feature. An end user might create specific identities with separate email addresses and contact information. Providing the same sub identifier for each of those identities would defeat the purpose of having them in the first place as RPs would be able to correlate them.

‌

[Sascha Preibisch]

The ‘sub’ value of the OIDC core specification explicitly introduced a PPID to avoid clients (RP) from being able to correlate users. The clients should not be able to ‘figure out’ that they are being used by the same user.

In my experience merging accounts is an OP level feature but not a standards feature. If an OP has two users that register with the same email address it is most likely the same person. In those cases the OP may offer users to merge these account or at least correlate them.

With eKYC, or for that matter the traditional process of verifying a persons identity, an OP will learn that multiple accounts belong to the same person. If a RP requests verified claims they should be the same, no matter for which of these persons the claims were requested.

To summarize, I believe that a standards based solution for preventing persons from acting as different ones should not be avoided.

[Kosuke Koiwai]

My understanding of the purpose of PPID is to avoid correlation of a user among different RPs. I believe Alberto’s suggestion is a legitimate need of RPs in context of KYC.

However, I am rather reluctant to define the feature in the spec, as how precisely IdP can aggregate single user depends on IdP’s service spec and legal system. For example, in Japan, there is no single universal personal number that won’t change in the course of her life, so even if RP ask for non-duplicated subs, IdPs can’t guarantee the singularities. On the other hand, all claims in eKYC spec are guaranteed under a certain trust framework.

‌

[Vladimir Dzhuvinov]

+1 to leave this up to trust frameworks.

I believe in some trust frameworks it will even be desirable to allow different identities for the same person. Those that must guarantee a singular identity for a person, I imagine useful in eGov, can do what’s necessary to achieve that.

Speaking of identifying uniquely a person by name and birthdate, this definitely won’t work in my country Bulgaria, and I know of cases when banks lost people’s money when they made this assumption.

‌

‌

[Julian White]

+1 The OP should not be required to do this. If they do this because of their own business, e.g. a bank wants a single customer view, then great, but its nothing to do with being an OP.

It would also have a number of unintended consequences, namely that if a person can only have one account then the setup of that account will need to have a high level of assurance to prevent a denial of service against genuine users through false registrations.