The article goes through some of the challenges we face when using or implementing identity, authentication and authorization solutions using self sovereign identity. I based my findings after implementing and testing solutions and wallets with the following SSI solution providers:

• Trinsic
• MATTR.global
• Evernym
• Azure Active Directory Verifiable Credentials
• Different Wallets like Lissi

Blogs in this series:

• Getting started with Self Sovereign Identity SSI
• Creating Verifiable credentials in ASP.NET Core for decentralized identities using Trinsic
• Verifying Verifiable Credentials in ASP.NET Core for Decentralized Identities using Trinsic
• Create an OIDC credential Issuer with MATTR and ASP.NET Core
• Present and Verify Verifiable Credentials in ASP.NET Core using Decentralized Identities and MATTR
• Verify vaccination data using Zero Knowledge Proofs with ASP.NET Core and MATTR
• Challenges to Self Sovereign Identity
• Create and issue verifiable credentials in ASP.NET Core using Azure AD
• Implement Compound Proof BBS+ verifiable credentials using ASP.NET Core and MATTR

History

2021-12-11 Added video explaining SSI phishing

2021-10-31 Updated phishing section after feedback.

SSI (Self Sovereign Identity) is very new and a lot of its challenges will hopefully get solved and help to improve identity management solutions.

Some definitions:

• Digital Identity: This is the ID which represents a user, for example an E-ID issued by the state, this could be a certificate, hardware key, verifiable credential etc.
• Identity: This is the user + application trying to access something which usually needs to be authenticated when using a protected user interactive resource.
• Authentication: verifying the “Identity” i.e. application + user for user interactive flows.
• Authorization: verify that the request presents the required credentials, specifying access rights/privileges to resources. This could mean no verification of who or what sent the request, although this can be built in with every request if required. Solutions exist for this in existing systems.

The following diagram from the Verifiable Credentials Data Model 1.0 specification shows a good overview of verifiable credentials with issuers, holders and verifiers. The holder is usually represented through a wallet application which can be any application type, not just mobile applications.

Level of security for user interaction authentication with SSI

Authentication using SSI credentials would have to same level of security as the authenticator apps which you have for existing systems. This is not as safe as using FIDO2 in your authentication process as FIDO2 is the only solution which protects against phishing. The SSI Authentication is also only as good as the fallback process, so if the fallback process, recovery process allows a username or password login, then the level would be passwords.

See this post for more details:

The authentication pyramid

Authentication Issuer

The authentication process is not any better than previous systems, every issuer needs to do this properly. Trust quality of the issuer depends on this. If a verifier wants to use verifiable credentials from a certain issuer, then a trust must exist between the verifier and the issuer. If the issuer of the credentials makes mistakes or does this in a bad way, then the verifier has this problem as well. It is really important that the credential issuer authenticates correctly and only issues credentials to correctly authenticated identities.

SIOP (Self-Issued OpenID Provider) provides one solution for this. With this solution, every issuer requires its own specific IDP (identity provider) clients and OIDC (OpenID Connect) profiles for the credentials which are issued.

When a credential issuer has a data leak or a possible security bug, maybe all credentials issued from this issuer would need to be revoked. This might mean that all data in any verifier applications created from this issuer also needs to be revoked or deleted. This is worse than before where we have many isolated systems. With SSI, we have a chain of trust. A super disaster would be if a government which issues verifiable credentials had to revoke credentials due to a security leak or security bug, then all data, processes created from this would have to evaluate and process the data again, worse case delete and require new proofs.

Authentication/Authorization Verifier

Every verifier application/process has a responsibility for it’s own authorization and the quality of its verification. Depending on what the verifier needs to do, a decision on the required verifiable credentials needs to be taken. A verifier must decide, if it needs only to authorize the verifiable credential it receives from the wallet application, or if it needs to authenticate the digital identity used in the subject of the verifiable credential. If you only authorize a verifiable credential when you should be authenticating the digital identity used in the verifiable credential, this will probably result in false identities in the verifier application or processes run for the wrong user. Once the verifiable credential is accepted as trustworthy, an identity could be created from the verifiable credential and the digital identity if contained in the subject.

Some solutions move the authentication of the digital identity to the wallet and the verifiers accept verifiable credentials from the wallet without authentication of the digital identity. This would mean that the wallet requires specific authentication steps and restrictions. Another solution would be to use a certificate which is attached to the digital identity for authentication on the verifier and on the wallet. SIOP and OpenID Connect would also provide a solution to this.

Access to Wallets, Authentication & Authorization of the holder of the Wallet

One of the biggest problems is to manage and define what verifiable credentials can be loaded into a wallet. Wallets also need to possibility to import and export backups and also share credentials with other wallets using DIDComm or something like this. Enterprise wallets will be used by many different people. This means that solutions which fix the identity to a specific wallet will not work if shared wallets or backups are to be supported. Wallets would also need to support or load verifiable credentials for other people who are not able to do this themselves or do not have access to a wallet. With these requirements it is very hard to prove that a verifiable credential belongs to the person using the wallet. Extra authentication is required on the wallet and also the issuers and the verifier applications cannot know that the credential issued to wallet x, really belongs to person x, which is the subject of the verifiable credential. Extra authentication would be required. Solutions with certificates, or wallet authentication can help solve this but no one solution will fit all solutions.

If a relationship between the person using the wallet, the credentials in the wallet and how the verifiers use and trust the credentials is managed badly, many security problems will exist. People are people and will lose wallets, share wallets when they should not and so on. This needs to be planned for and the issuer of verifiable credentials and the verifier of these credentials need to solve this correctly. This would probably mean when using verifiable credentials from a wallet, the issuer application and the verifier application would need to authenticate the user as well as the credentials being used. Depending on the use case, the verifier would not always need to do this.

Interoperability between providers & SSI solutions

At present it is not possible to use any wallet with any SSI solution. Each solution is locked to its own wallet. Some solutions provide a way of exporting verifiable credentials and importing this again in a different vendor wallet but not using wallet vendor 1 together solution vendor 2. Solutions are also not supporting the same specifications, standards. Each implementation I tried supports different standards and have vendor specific solutions which are not compatible to other vendors.

I have a separate wallet installed now for each solution I tried. It cannot be expected that users install many different wallets to use SSI. Also, if a government issues a verifiable credential with a certain wallet, it would be really bad if all verifiers and further credential issuers must use the same wallet.

With JSON-LD and BBS+, the APIs between the wallets and the SSI services should work together but vendor specific details seem to be used in the payloads. If SSI is to work, I believe any wallet which conforms to a standard x must work with any SSI service. Or the services, vendor implementations needs a common standard for issuing and verifying credentials with wallets and the agents used in the wallets. Some type of certification process would probably help here.

Phishing

Users authenticating on HTTPS websites using verifiable credentials stored on your wallet are still vulnerable to phishing attacks. This can be improved by using FIDO2 as a second factor to the SSI authentication. The DIDComm communication between agents has strong protection against phishing.

Self sovereign identity phishing scenario using HTTPS websites:

1. User opens a phishing website in the browser using HTTPS and clicks the fake sign-in
2. Phishing service starts a correct SSI sign-in on the real website using HTTPS and gets presented with a QR Code and the start link for a digital wallet to complete.
3. Phishing service presents this back on the phishing website to the victim on the phishing website.
4. Victim scans the QR Code using the digital wallet and completes the authentication using the agent in the digital wallet, DIDComm etc.
5. When the victim completes the sign-in using the out of band digital wallet and agent, the HTTPS website being used by the attacker gets updated with the session of the victim.

This can only be prevented by using the browser client-side origin as part of the flow, signing this and returning this back to the server to be validated, thus preventing this type of phishing attack. This cannot be prevented unless the origin from the client browser is used and validated in the authentication process. The browser client-side origin is not used in the SSI login.

Here’s the same problem description: Risk Mitigation for Cross Device Flows

PII databases will still be created

Credential Issuers require PII data to create a verifiable credentials. This data is persisted and can be leaked like we see every day on the internet. Due to costs/laws/charges, verifiers will also copy credentials and create central PII databases as well. The applications doing verifications also will save data to a local database. For example, if an insurance company uses verifiable credentials to create a new account, it will save the data from the verifiable credential to a local database as this is required for its requirements. This will have the PII data as well. So even with SSI solutions we will still share and have many databases of PII data.

If BBS+ ZKP is used which does not share the data with the verifier, just a verification, this is a big improvement compared to existing solutions. At the time of testing, this is not supported yet with any of the solutions I tried, but the specifications exist. Most solutions only support selective or compound proofs. If the verifier does not save this data, then SSI has added a big plus compared to existing solutions. A use case for this would be requesting a government document which only requires proof of the digital identity and this can be issued then without storing extra PII data or requiring a shared IDP with the digital identity issuer.

Complexity of the Self Sovereign Identity

I find the complexity when implementing SSI solutions still very high. Implementation of a basic issue credential, verify credential process requires many steps. Dev environments also require some type of callback, webhooks. ngrok solves this good but this is different after each start and needs to be re-configured regularly, which then requires new presentation templates which adds extra costs and so on. If integrating this in DevOps processes with integration testing or system testing, this would become more complex. Due to the overall complexity to set this up and implement this, developers will make mistakes and this results in higher costs. IDP or PKI solutions are easier to implement in a secure way.

Trust

When using the provided solutions, some of these systems are closed source and you have no idea how the solutions manage their data, or handle the secrets in their infrastructure, or how the code is implemented (closed source). For some solutions, I had to share my OpenID Connect client secret for a flow to complete the SSI SIOP credential issuer flow. This was persisted somewhere on the platform which does not feel good. You also don’t know who they share their secrets with and the company provider has different law requirements depending on your country of origin. Implementing a “full” SSI solution does not seem like a good option for most use cases. Open source software improves this trust at least but is not the only factor.

Notes:

I would love feedback on this and will correct, change anything which is incorrect or you believe I should add something extra. These challenges are based on my experiences implementing the solutions and reading the specifications. I really look forward to the new SSI world and how this develops. I think SSI is cool, but people need to know when and how to use it and it is not the silver bullet to identity but does add some super cool new possibilities.

Reviewers:

• Matteo Locher @matteolocher

Links:

https://docs.microsoft.com/en-us/azure/active-directory/verifiable-credentials/

https://lissi.id/

trinsic

https://mattr.global/

Evernym

The authentication pyramid

https://w3c.github.io/did-core/

https://w3c.github.io/vc-data-model/

https://www.w3.org/TR/vc-data-model/

Home

OIDF OIDC SSI

https://ngrok.com/

https://github.com/swiss-ssi-group