In the fifth webinar from our series on Decentralized Identity, Condatis experts Richard Astley and Rob Gathergood presented the benefits and use cases of Self–Sovereign Identity. In this blog, we’ll recap the Q&A session from the day.
Head over to our YouTube channel to watch previous sessions in the series, subscribe and click on the bell to receive notifications when we upload new videos.
For any enquiries or suggestions for future webinars and Condatis events, get in touch with our marketing team: marketing@condatis.com.
Limitations of Self-Sovereign Identity (SSI)
What are the limitations of SSI?
When thinking about the limitations of self-sovereign identity, part of it is in the name itself – identity. SSI is a form of decentralization where information can be issued from one decentralized system and transferred to another decentralized system without the systems needing to have a pre-existing relationship. Trust between these systems is created by other means like the distributed ledgers used in SSI.
There are many ways to create decentralized systems to transfer data from one system to another, but SSI is only concerned with identity data. It allows people to carry and present their own identity between systems, letting them know they are interacting with the same person. It is not for systems to issue all the data it holds for that person, like how many orders they have or how many loyalty points they have collected to carry between systems. This data is too volatile, requiring frequent changes, which would mean verifiable credentials need to be revoked and reissued each time it changes; this type of data is not really part of a person’s identity.
A common question that ties into this limitation is how loyalty card points are kept and updated within a digital wallet. In the opinion of Condatis expert Richard Astley, loyalty cards are not best suited to this type of technology where it stores the number of points someone has in a verifiable credential. However, this does not mean that a loyalty card cannot be issued in a verifiable credential. The process just becomes slightly more complicated. The loyalty card verifiable credential only identifies the user between systems and may contain claims, like keys or tokens, used to interact with another system on behalf of the user. These could be used to retrieve or update the user’s data like loyalty card points in this example.
Issuers of a verifiable credential create DID documents containing service endpoints that verifiers can resolve from the distributed ledger and use to interact with the issuing system. In the loyalty card example, the issuer may expose a service endpoint to retrieve the number of loyalty points a person has or a service endpoint to add new points for that person. By sharing the loyalty card with another system, the person grants consent for the system to access or update this data with the original issuing system and provides a common understanding between the systems for who the user is, based on the shared identity. This discovery method is central to how decentralized systems work. Each system exposes information on how to interact with it and a verifiable credential provides an identity that all the systems may use to identify the individual when interacting with other decentralized systems.
This is one of the limitations of SSI, and if anything, it shows that digital wallets are not just for any type of data to be issued in the form of a verifiable credential. The holder can use a credential to carry an identifier between one system and another, and then alternative techniques are used to join these decentralized systems together.
OIDC Bridge
Can the OIDC Bridge be used for purposes other than authentication?
The example discussed in this webinar was the OIDC Bridge being used for authentication to provide system access to a relying party during a sign–on journey. OpenID Connect with OAuth is often used for authentication but can also be used to collect any claims from an OIDC server in the form of a JSON Web Token (JWT); what the claims are used for is up to the relying party.
A relying party may make an OIDC call for claims during a sign–up or registration journey and use the claims to prepopulate a registration form for quick onboarding.
A relying party may need address details to ship a product to a user. They could provide a form for the user to populate, but for a better user experience, the relying party could also request the address from a verifiable credential stored in their wallet and use this to add address details to the system – a quicker solution that is less prone to error than manually entered user data.
A relying party may need to validate someone’s date of birth to sell an age–restricted product like alcohol, so the relying party could ask the user to verify their date of birth from a verifiable credential using the OIDC bridge before processing the restricted sale.
The scenarios in these examples are all achievable without the OIDC Bridge. However, the advantage of using the bridge instead of building SSI verification functionality directly into the relying party is that many agents that can be used for verification. Relying parties would have to integrate all the agents to verify credentials from their corresponding wallets. The OIDC Bridge abstracts the technical implementation of SSI away from relying parties and allows them to leverage verifiable credentials using the well–known and well–established OpenID Connect protocols familiar and used by most relying parties.
Vaccination test credentials
I hear IATA are using vaccination test credentials, are they using this technology?
IATA is indeed using this technology, and our partners Evernym hosted a webinar that goes in–depth on it here: https://www.youtube.com/watch?v=5Sf_4fZbhlc.
In summary, a set of trusted test centres out there can issue these credentials. When individuals get tested, they can carry a digital credential issues from a valid test centre, confirming if they are clear for travel. When traveling between countries and trying to cross borders, a proof request can be made to display the valid test certificate. As part of this, a trust framework is being built, aligning the connection between trusted test centres and various countries.
Can the vaccination test credential be re-used?
Credentials can be re-used. If you fly frequently and travel to multiple countries, this single credential will grant you access to these countries.
Digital wallets
How do digital wallets work?
A digital wallet is an application that can be kept on a mobile device or is available online. The wallet stores verifiable credentials and can answer proof requests by sharing the stored credentials. A digital wallet contains an agent used to communicate with other agents when verifiable credentials are being issued or when answering proof requests.
The agents create public and private key pairs used to sign and verify data exchanged between parties. The private key, secret to your device, is used to create a digital signature when answering proof requests validated using the public key exchanged with the verifier who made the proof request – some digital wallets like Connect.Me, which uses the Hyperledger Aries stack, also maintain connections between agents. This is classed as a pairwise DID, unique decentralized identity (DID) identifiers that are used to enable relationships between two agents. One is the agent within the wallet, and the other being the agent of the verifier or issuer.
A digital wallet is essentially an application that allows a user to manage and share their digital identity. The wallet stores verifiable credentials, manages communication between agents, manages cryptography key pairs used to sign and verify data, and allows users to grant and deny permissions to accept and share attributes.