Problems with online user authentication when using self sovereign identity

[damienbod]

Using self sovereign identity (SSI), there is no standardized solutions for solving online user authentication when using verifiable credentials and verifying the identity and user. All solutions result in further compromises and result in new problems. To understand the problems, we need to understand how this works. The following diagram shows the verifiable credential (VC) relationship with Issuer, Holders (behind a software wallet) and the verifier. Trust between the actors and are you required to authenticate the user behind the wallet are key and important requirements for some systems. Verifiable credentials are not issued to a user but to a wallet representing the user.

Use case definition: The user must be authenticated and verified by the “verifier” application using the verifiable credential. Is the user data in the verifiable credential the same user presenting it or a user, application which is allowed to use the VC on behalf of that person. So how can this be solved?

Solution 1: User Authentication is on the wallet.

The wallet application implements the authentication of the user and binds the user to all credentials issued to the wallet through the agents and then sent to verifier applications. With BBS+ verifiable credentials, it is possible to do this. The wallet is responsible for authentication of the user, but this is not standardized, and no wallet does this the same. If the wallet is responsible for user authentication, then applications only need to authorize the verifiable credentials and not authenticate the user behind the wallet and represented in the verifiable credential which is connected to the wallet. The VC is invalid if a different wallet sends this. So the verifier applications only validates that the sender of the VC has possession of the credential, nothing else and trusts that the wallet authenticates the user correctly and also trusts that the wallet prevents misuse. The verifier cannot validate if the application, person using the credential is allowed to use it. The verifier must trust that the wallet does this correctly.

Problems with this solution:

Wallet Software monopoly: If a state body pushes this solution, then it has effectively created a monopoly for the producer of the wallet software. This is because at present with existing wallets, the required authentication is specific to the application and the definition of how this is required and the hardware device used for the wallet. No standards exist for how a user is authenticated in the wallet and what level of initial user authentication is required. This could be improved by creating a new standard for wallets which can be used by the state body and the way the wallet must authenticate the users of the wallet. Then any wallet which fulfills the standard can be used for state created verifiable credentials.

Backup and recovery of wallets becomes really complicated because the user is connected to the software wallet. If I lose my wallet, or would like to switch the wallet, a safe secure standardized way would be required proving that the wallet has authenticated the same person as the initial wallet or a person of trust. All issued credentials would probably need to be re-issued. The user of the wallet and the wallet instance are tightly coupled.

Verifier authorization only, not authentication: The verifier does not authenticate the user behind the wallet, just accepts that it was done correctly. This creates a closed system between the verifier and the wallet even though it is distributed. The verifier is tightly coupled in the relationship if blindly trusting verifiable credentials from wallets which are not in its system scope. If the verifier needs to verify the identity, then FIDO2, OIDC, OAUTH2, PKI or existing online verifying flows could be used as a second factor.

Single point of failure: if the credential issuer VCs can no longer be trusted, then all verifiers using the credentials need to revoke everything created from the VC . This is not a problem if the verifier authenticated it's users directly.

Solution 2: Use the OIDC SIOP standard to authenticate when issuing and verifying the verifiable credentials

https://openid.net/specs/openid-connect-self-issued-v2-1_0-07.html

https://openid.net/specs/openid-connect-4-verifiable-presentations-1_0-08.html

A second way of solving user authentication in SSI is to use OpenID Connect and SIOP. The credential issuer uses it's own OpenID Connect server with pre-registered users where the person has been correctly identified. The credential issuer is responsible for identifying and authenticating the identity, ie the user plus the application. Each credential type which is issued requires a specific OpenID Connect client. When the user, using the SIOP agent from his or her wallet tries to add a new verifiable credential using SIOP, the user is required to authenticate using the identity provider (IDP). This can also be used when verifying credentials. By using this, any wallet which supports the SIOP agent with the correct verifiable credential type used can work. The strong authentication is not required on the wallet because this is part of the flows and the user does not need to be connected to the wallet. If the verifier does not authenticate the user or application sending the verifiable credentials, then strong authentication would still be required on the wallet.

Problems with this solution:

Requires an OIDC server: All credential issuers require an OpenID Connect server and a separate client per credential type.
Verifier authorization only, not authentication: Only proof of possession on the verifier. Verifiers need to start an SIOP verification and the verifier needs to trust the OIDC server used for the client. The OIDC server authenticates and not the verifier.

Single point of failure: if the credential issuer VCs can no longer be trusted, then all verifiers using the credentials need to revoke everything created from the VC . This is not a problem if the verifier authenticated it's users directly.

Solution 3: Verifiers authenticate the user correctly before trusting the verifiable credentials sent from an unspecific wallet.

Another way of solving this is that all credential issuers and all verifiers authenticate the user behind a verifiable credential using their own process. This avoids the single point of failure. Each sign in would require an extra step to authenticate, if using SSI for example a FIDO2 key or a PKI authentication or some OIDC flow can be used. SSI could be used as the first factor in the application authentication. This solution works really good but a lot of the advantages of SSI is lost.

Problems with this solution:

All applications require authentication. This is more effort if implementing a closed system, but all applications need to do this anyway, so it's not really a disadvantage. If you control both the issuer and the verifier, then the verifier application could just do authorization of the verifiable credential.

SSI adds little value. Due to the fact that a second authentication method is used everywhere, this would also work without SSI, so why add SSI then in the first place.

Summary

User authentication is not an easy problem to solve and SSI at present does not solve this in a standard way. All existing solutions do something vendor specific or solve this in a closed system. As soon as inter-op is required, then the problems begin. It is important to solve this in a way which does not require a vendor specific solution or creates a monopoly for a vendor solution. At present, SSI solutions still have very little convergence. We have different ledgers which only work with specific agents. We have different agents, SIOP, DIDComm V1, V2 which are only supported by certain wallets. We have different verifiable credentials standards which do not work together. We have no authentication standards on the wallets, no standard for backup and recovery. It is still not clear how the trust register for credentials issuers will work, I as an application verifier need an easy way to validate the quality of the credential issuer otherwise how can I know if the credential was issued in a good way without doing my own security check. Guardianship will also complicate the user authentication process.

There is no solution to solve all of this and support what the different groups wish for.

Question:

How do you plan to solve this for the E-ID?

[gerry501]

I have a problem with solution 1:
I'm not entirely sure, because I don't know SSI through and through, but I think the wallet makes only a collection of the VCs, processes them according to the Holder wishes, and presents them to a Verifier, but it is not responsible for authentication. Rather, this is the Issuer's responsibility.
Let's look at a classic SAML assertion. The most simple assertion, is the confirmed authentication of the user, without any attributes. This is a confirmation from an IdP, that the user has successfully authenticated on his site. This information comes to an RP in an appropriate form...
In SSI a user can create a self-declared identity. But this is useless, because a Verifier doesn't accept it. A Verifier has to proof the VCs and the binding to a specific Identity (the one of the Holder - or at least the one who has access to a specific secret). So he can create its own identity (private/public key), but he must have it confirmed by a suitable Issuer, otherwise the Verifier cannot proof the genuineness of the VC.
An Issuer issues a VC based only on the authentication of the holder to him (certificate, VC?, FIDO, 2FA,...). The Holder blindly presents his public key to the issuer (so that the issuer cannot see it) and the latter minimally confirms (blind signature) the authenticity of the Holder in the form of a VC, which is handed over to the Holder. The Holder then stores it. He may collect further VCs from the same or other Issuers using the same procedure. Hence, the Issuers cannot correlate except they have the same authentication provider ;-)
When the Holder wants to identify himself to a Verifier, he presents this Identity-VC in a ZKP-oriented proof and the attributes coupled to it. The verifier can now check whether the holder is in possession of the private key. Thus he has confirmed his identity and the associated attributes.
Or have I misunderstood something elementary in this game?

[damienbod]

Hi Gerry
As a verifier application, I am responsible to authenticate my users as well.

The whole problem is that it is not the holder presenting the VC, but the software wallet. This cannot be verified using only a VC presentation. I can verify that the VC created from the VCs were issued to wallet X from n issuer(s), but no more.

Once the credential issuer(s) of the VC(s) can be trusted, a new VC can be presented from this VC or VCs from a wallet X and a verifier can validate that it is genuine using the ledger. (like an access token) This is a solved in SSI.

But a VC can be created and shared with any wallet. Only a wallet which belongs to the holder of the VC for which the VC was intended for should get this, or some wallet allowed to act on behave of. This also needs authentication.

The verifier does not know if the person/software (holder of the wallet software) sending the VC presentation is authenticated to do it. So does the software wallet implement authentication for the user (holder) of the wallet and the verifier blindly trusts the wallet to do this correctly or does it not trust the wallet and do the user authentication itself. The presented VC can be verified without problem that issuer X issued it and that it has not been tampered. (The credential issuer should also require proof of authentication)

For the verifier, proof of possession is not authentication, this is authorization. The VC presentation is genuine, but does it belong to you?

Gruss Damien

[gerry501]

Hi Damien,

BTW: as a verifier application you never authenticate the bearer (except HOK)! In a centralized Identity setup, you trust in the assertion issued by some other... But this is another issue ;-)

A VC hopefully is bound to a holder (called "holder binding"), otherwise someone could steal it and a verifier would have no chance to proof that a specific VC belongs to a holder. An issuer always binds a VC to a holder which he previously authenticated. So in fact VCs are issued to holders, not to wallets. I guess.
CL-signatures or BbsBlsBoundSignature2020 provides this issue, I assume...

Greetings Gerry

[fforootd]

Btw. while talking about binding 😁 The Token Binding who was never really used with OAuth is also mentioned in the vc-data-model.

The reason why I am mentioning this is because I think in all scenarios we might need to consider the problem of attacks against the connections between parties. This even applies when they rely on some for of blockchain, especially when the "client"/"verifier" is not a direct member of the chain.

[msmock]

To my understanding the wallet or waller application can be used as an authenticator. Sure there is a need for regulations which wallets apps can be accepted on a specific Identity Assurance Level. We already use applications on the mobile phone as authenticators or as an authentication factor for 2 factor authentication. Other problems resist but are the price to pay for SSI based on blockchain solutions.

[damienbod]

Hi @msmock

Using wallets as an authenticator as a second factor would be good, using as a single factor not so good. The wallet used together with QR Code scanning on the target website is opened to phishing attacks as is any cross device flow.

Greetings Damien

[gerry501]

Hi everybody,
I think that you can use a DID (or better a private key in your wallet on your smartphone) to authenticate. But this has some impacts. I agree with msmock that not all wallets support an Authn.
The Authn is done classically via an asymmetric CRAM. The holder must make his public key available to the verifier. The easiest way to do this would be via a URL to the DID/DIDDoc. But in this case the public key can be worldwide!!! misused as a unique identifier, if stored in a public BC or DB. Nobody would do this. Hence, this is a very bad idea. A better idea would be to use a dedicated DID for every verifier (or group of verifiers). But in this case the public key must get to the verifier as part of the protocol or by convincing the verifier that a holder is in possession of the keys without revealing them. I think, BbsBlsBoundSignatureProof2020 can do this, but I'm not sure.
Another issue:
If using a DID for Authn this would be a local MFA and less a sequential SFA (like OOB). Because you would have your smartphone (something you have) and activate your private key with a second factor (something you are/know) locally and generate one response as proof for the verifier. Hence, something similar to a SC or FIDO-Token. With a SC we trust in the vendor (e.g. Gemalto) and in the processes to issue this SC. But now we trust in the smartphone / OS manufacturers (e.g. Apple, Samsung, Google,...) and in their SEs. Are they trustworthy? They are doing their best to convince us... ;-)
Greetings Gerry

[romanzoun]

In EU they they want to provide a certified toolkit, which is needed to implement a wallet. Wallets without this toolkit are not certified and not trusted. In the toolkit, software security is not an option, only Hardware is accepted. The goal is that this toolkit will allow interoperability between all actors. Is cross-country Interoperability a topic for Swiss eID?

I think the point is, that disaster recovery is a hot topic for the wallet and is crucial for user acceptance. Trinsic provide a solution, with hybrid wallets. Means in your app you have the private keys, but your VC data is on the cloud.
So the final eID solution will be maybe surprising and just a step towards SSI and not the whole SSI concept 😅

Overall, I miss some user acceptance tests and analyses on the roadmap, in the end, the acceptance and the decision is done by the user in SSI.

For me, I would wish more responsibility and control my personal data in my wallet completely on my own, but I talked to my mother, she is just scared to do something wrong, so she needs full assistance ^^

So no real answer to your question, but more open questions 🤣

Cheers, Roman

[gerry501]

Hi Roman,

Thanks for the Information. This confirms that Switzerland also needs to do something in this direction and coordinate it with Europe. I also heard something about a regulated Swiss ID wallet solution.
We investigated various wallets 2 years ago and unfortunately discovered that there is no common factor and no interoperability between this wallets!
I don't know if Interoperability between countries is a topic for the Swiss eID 😃
Disaster recovery is a not solved yet, but several solution are in the pipeline. Is the Trinsic solution using an agent?

Cheers, Gerry