Dubious support for authentication

[David W Chadwick]

Standard OIDC supports authentication via the sub claim, and presumably the RP does not require any further claims because it assumes the OP’s data about the user is up to date and the user has been authenticated again. Nothing has changed since the last authentication event.

This no longer holds true for SIOPv2 with OIDC4VPs. In this case the user first registered/authenticated by presenting a set of possibly long lived VCs inside a VP. On subsequent authentication, the sub claim alone is not good enough, as all this proves is that the user has not changed the key pair on her mobile device that she first used to prove possession of the accompanying VCs. But the VCs might have changed. They might have been revoked or refreshed with different information. How is the RP to know this? The RP cannot contact the VC issuer as this breaks the privacy protection of the W3C VC data model.

Therefore the use of the sub claim alone is insufficient for a user authentication event when SIOPv2 and OIDC4VP were used on the first connection attempt.

My assertion is that the RP should always ask the user for the VCs/VP each time the user logs in, so that it can validate that the identity of the user has not changed.

[Torsten Lodderstedt]

I think there are two different aspects:

• SIOP provides sub assertion in a trust on first use model. The sub can be used to recognize a returning user. That’s more or less the same model Web Authn uses. SIOP also allows to use a DID for the sub value which gives rotation and multiple keys capabilities.
• VC/VPs (OIDC4VPs) can be used for a number of purposes, including identity verification (e.g. during onboarding), authorization, and login. In some of those use cases, it makes sense to ask for a VP every time, e.g. for login and authorization. I also agree with you the lifecycle of the respective credentials needs to be taken into account as well. However, credential lifecycle management is typically handled differently for different kinds of credentials. For example, for Anon Creds revocation is stored in the DLT and can be obtained from the DLT in a privacy preserving fashion. Other solutions use traditional revocation lists. As OIDC4VPs is trying to be credential format agnostic, I think, lifecycle management should be out of scope.

I think whether SIOP or VCs are used for login is at the discretion of the respective application.

‌

[David W Chadwick]

I agree that SIOP can act like FIDO and use the key for authn only, without any identification of the user. Of course this is not applicable to OIDC4VP when VCs are being provided. The problem tends to be that when we discuss things like the sub claim, we are not specific about the use case and the conversion implies that the discussion is applicable to all use cases e.g. like “the sub is used for (re) authentication (implied always)”

I think we need some explanatory text somewhere to describe these different use cases, so that it apparent when the different standards are being combined together, that certain combinations are not applicable, or that special care is needed by the RP if they do utilise it eg. the SIOP user comes back to the RP with the sub claim only after initially using OIDC4VP to initially identify and authenticate himself.

[David Waite]

An RP could verify credentials every time they log in, but they are accepting new risk each time. Authentication is opting into risk you have already taken on.

Accepting credentials is a trust decision, which implies a certain amount of risk. Unlike business to business federated connections we have with current protocols, direct trust and bilateral agreements may not be available or viable. This means accepting credentials has a much higher risk that is taken on by the verifier.

As such, I disagree broadly that the user will always be brokering an ongoing relationship with the issuer and verifier for providing a stream of updated credentials. The issuer may be hacked, may start acting maliciously, the end user may want to start sharing information from a different issuer (and in the case of things like drivers licenses in the US, may be legally required to stop using the old credential when they move to another state).

[Kristina Yasuda]

I also don’t believe that the user needs to present VP at every single interaction with an RP. As Torsten pointed out there are multiple ways to do VC’s lifecycle management other than requesting a new VC every single time, and we should not be mandating one of those.

We have been discussing this repeatedly, but when SIOP and OIDC4VP are used together, the RP shall be using `sub` claim in the ID Token to (re-)authenticate the user. It is not a VC (and a user identifier in the VC) that the RP uses to “authenticate” the user. Those have very distinct meaning.

User identifier in a VC is user’s identifier within the Issuer and asking the RP to use it as user’s identifier within the RP is a misuse and can lead to certain correlation factors. Meanwhile, sub in the ID Token is an identifier that the user is explicitly telling the RP to use as user's identifier within the RP.

It is a totally valid use-case for the user to send only an ID Token with the same sub to re-authenticate at the RP, to whom she has already provided an ID Token and VC(s) in a previous interaction.

Once we agree, I agree clarification on this should be included in the spec text - probably both in SIOP v2, with a pointer to that section in OIDC4VP.

[Michael Jones]

sub in the ID Token is an identifier that the user is explicitly telling the RP to use as user's identifier within the RP.

I agree that this summarizes the gist of the matter.

[David W Chadwick]

@David Waite Your comment appears to be somewhat contradictory in that you disagree that the user is brokering trust between the issuer and verifier and then you give examples of when this is essential (e.g. user wishes to use a different issuer, or current issued credential is no longer legal). Thus we should include this possibility in the current text, since, whilst it may not always be the case that the user wants to use different credentials, it will certainly have to be the case in some instances. Furthermore in the case of the same credentials, how does the verifier know if the mDL presented some period ago has not changed, unless the user (or the verifier independently) confirms this for the new connection?

@Kristina “It is not a VC (and a user identifier in the VC) that the RP uses to “authenticate” the user”. I agree. But it is used to identify the user. In the VP case, the sub and iss claims in the VP are used to “authenticate” the user (actually it is to Prove Possession of the key pair). In the case of ephemeral keys, having proved possession, how should the verifier identify the user? In the original OP flow, the sub claim did both: authenticate and identify. In the SIOP OIDC4VP flow the sub claim does not (always) do both. It only proves possession (authenticates) in all cases. It cannot be relied on for identification. So we need to document the different ways that identification may be carried out by the verifier, when the sub claim cannot be used for this.

‌

[David W Chadwick]

@ Mike If your highlighted text summarises the gist of the matter then we also have to have a method for the user to tell the RP “do NOT use the sub as my identifier, it should only be used for authentication/proof of possession”. My identity has not changed but my personal key has.

[David W Chadwick]

@Kristina "User identifier in a VC is user’s identifier within the Issuer and asking the RP to use it as user’s identifier within the RP is a misuse" This is surely not a correct statement. If the issuer is an OP, then in traditional OIDC the OP is doing exactly what you say is a misuse. Just because the message flow has changed with SIOP/OIDC4VPs does not mean that the underlying concepts have changed. They are still the same. The OP (or VC Issuer) determines the subject’s identifier and sends it to the RP, either as a sub claim (in traditional OIDC) or as a claim in the VC (in SIOP/OIDC4VP). And the RP should be able to use this to identify the user, regardless of the message flow.

Furthermore, it allows the user to move from mobile to desktop browser and log in to the same account.

[Kristina Yasuda]

I believe “authenticate the user” and “prove possession“ are two distinct, separate functions - it is also the reason why the clear separation of ID Token and VP Token as separate artifacts has been very popular. key used to sign VP is for Proof of Possession, and implications of it being ephemeral must be separated from a key used to sign ID Token as authentication receipt being ephemeral.

It is important to note that “VC Issuer != OP” (if it is, no need to use VCs, just use normal OIDC claims) If VC’s issuer is OP, sure, VC’s user identif

[David W Chadwick]

How can they be separate functions when in both cases the user creates the key pair. So the key must be usable for both functions or neither

[David W Chadwick]

One additional point. There is no requirement for the keys in the id token and vp token to be different. They can be the same.

[Tom Jones]

i guess the point is that the protocol carries claims, the identification, authentication and liveness criteria are determined by the RP using the entirety of the transactions.

[Nat Sakimura]

Had a brief discussion during the Monday/Tuesday call.

Nat pointed out in the call that ID Token is representing the user authentication event and the iss/sub pair in it is describing the subject of that user authentication while VC generally does not represent the user authentication event and the sub in it is just describing the entity that the claims are attached to. User authentication/identification and the description of the subject through VCs should not be conflated.

[David W Chadwick]

Can we clarify the above please for SIOP? The iss/sub pair are the same entity in the SIOP case i.e. the user. So signing the ID Token is proving possession of the key. There may be no user identification claims in this case. The key is the identifier. The VCs on the other hand are identifying the subject (Q. how is this different from describing the subject?). The VP is used to prove possession of the VC when the public key of the VC subject is the issuing key of the VP. So in this case the VP serves the same purpose as the SIOP id token. But in this case there is subject identifying information in the VCs.

‌

[David W Chadwick]

@Tom I agree with your comment.

[Michael Jones]

On the 14-Feb-22 working group call, @Nat observed that “This issue seems to be conflating user authentication and claims about that user. Claims about the user are usually not sufficient to authenticate the user. We cannot use the VC as proof of user authentication."

[Tom Jones]

@Nat Nat the IDtoken from a normal OP does carry authentication information. There are functions that can be carried out by a trusted wallet. The question here is whether the RP will trust the wallet. If not the IDtoken cannot be said to carry authentication information that is acceptable to the RP.

[Kristina Yasuda]

Adding SIOP label for issue tracking purposes. related to issue #1436

[David W Chadwick]

Mike “We cannot use the VC as proof of user authentication.” Correct, but we can use the VP that contains the VC, because the VP can prove possession of the private key whose public key is in the VC.

[David W Chadwick]

Since OIDC4VP can now be used independently of SIOPv2 to interact with the RP, then this issue can be closed as the restrictions of SIOPv2 no longer need to be a barrier.