Using the subject identifier to re-identify the subject

[David W Chadwick]

The current SIOP model requires the sub identifier to always be the same if the same user returns to the same RP to access the same account. This is no longer necessary with verifiable credentials.

In the same way that the issuer attests to the subject identifier, VC issuers attest to the subject’s identity attributes. Thus it is perfectly possible for a RP to uniquely identify a subject each time from their verifiable subject attributes. After all, a subject identifier is simply a subject attribute that is guaranteed to uniquely identify the subject within some context. But a combination of subject attributes can equally well do this in a given context. (And if one subject attribute can do this on its own, e.g. a government issued NI number in a verifiable credential, then it is by definition a subject identifier.)

The proposal is that we no longer need to rely on the sub identifier to uniquely identify the user. Instead the RP can rely on a set of verifiable subject attribute that it determines for itself (and that it relays to the user in the request for VCs). i.e. the RP will specify the set of attributes and their trusted issuers.

Instead of the user having to keep a persistent key pair for communicating with the RP, and asserting this public key as the sub identifier each time, the user can use a transient public key freshly minted for each session, and the RP can rely on trusted VC Issuers to assert the subject’s identity attribute(s) each time.

I don't believe that any change is required to the protocol, but only to the accompanying text that explains how the RP can use verifiable credentials to uniquely identify the user each time instead of relying on the sub identifier.

[Kristina Yasuda]

As Mike and Daniel F. explained during the 2021-Dec-16 SIOP call, using user attributes to identify the user is a well-known anti-pattern in the industry. It is being exploited by the attackers for example by incerting victim’s email address into a token with attacker’s sub, which allows impersonation if the RP does not check the sub.

The question becomes if the above anti-pattern changes, if the attribute you want to use to identify the user is inside the VC. I don’t think it does. It just changes based on what the RP trusts the attributes - issuer signature on the VC, or the legal agreement with that OP. Attacker can trick the issuer to issue combination of attributes equivalent to the victim’s. The way to prevent impersonation becomes the RP checking sub in JWT-VC, so you are simply moving the issue from the ID Token's sub to the VC sub. Yes, this impersonation attack would become harder with the VCs, but I don’t think it changes the anti-pattern of not using attributes to identify the user.

We cannot stop implementations from using attributes for the identification purposes, but I would not be in favor of adding text that would imply it is possible

[Michael Jones]

As discussed in the 6-Jan-22 special call, using mutable claims to identify the user is a security problem and a source of many real attacks. At most, only immutable claims controlled by the issuer should ever be used in this manner.

[David W Chadwick]

I agree that only immutable claims should be used. But this is precisely what VCs issued by sources of authority are e.g. a passport VC issued by a national government, or a driving license by a driving authority. Thus these VCs can unambiguously identify the subject without relying on subjectID.

[Kristina Yasuda]

closing since rough consensus is that using VCs to user claims to identify the user is a security anti-pattern hence no spec text required

[David W Chadwick]

This is not correct.

Using mutable claims from non-authoritative source is an anti-pattern. Using immutable VCs from trusted issuers is not an anti-pattern. If it were, then the OIDC4VPs spec cannot be used on its own without SIOPv2.

‌