Where Self Sovereign Identity (SSI) is now
Prerequisites for the emergence of Independent Sovereign Identity (ISI)
The relationship to “identity” in the online world has long been discussed and implemented in various forms.
In a 2016 blog post titled “The Road to Sovereign Identity”, Christopher Allen notes that “identity” on the internet has undergone the following evolution Stage 1: Centralized Sovereign Identity (Centrale)
Stage 1: Centralized Identity
A form of centralized identity control by electronic certification authorities, domain registrars or individual sites. Identity controllers proliferate as the Internet world expands and a single user’s identity becomes distributed across sites.
Phase 2: Federated identity
This is a form of interoperability between different identity infrastructures that aims to solve the problem of identity dispersion by allowing a single identity to be used for multiple services. However, each identity will still be managed by its own infrastructure.
Phase 3: User-centric identity
The goal is to enable users to manage their own identity and use different services with it, including OpenID, OpenID Connect, OAuth, FIDO, etc. Although specifications such as OpenID, OpenID Connect, OAuth and FIDO have been developed, due to technical limitations, their implementation often depends on specific service sites or platforms for identity registration and management. As a result, identity management becomes centralized.
Stage 4: Independent identity
The user is in full control of their own Identity. The user becomes the “owner” of his Identity.
As described above, identity management methods have been centralized and decentralized in various forms (like other technologies on the Internet). However, prior to Phase 3, the result was that third parties other than the owner remained responsible for managing identities (and information such as associated attributes) and the owner, who should be the “sovereign” of identities and associated information, was not able to fully control them. One reason for this may be that technological limitations have made the cost of managing this information so high that it was not feasible for individuals to manage it.
Self-Sovereign Identity (SSI) aims to give the sovereign identity owner full control over this information. Reducing the cost of identity management in a distributed manner down to the individual level, for example with the advent of distributed ledger technology, is likely to be one of the driving forces behind SSI.
In the following sections, we will briefly introduce SSI-related standardization at the W3C and then introduce you to the activities being undertaken by various organizations around it.
Basic SSI/DID concepts
DID
The central element in the SSI world is the DID, which is primarily the identifier of the owner of the identifier (the so-called Subject. It is an identifier of a person, object or legal entity).
The definition of DID according to W3C is as follows
A globally unique identifier that does not require a centralized registry authority because it is registered using distributed ledger technology or a globally unique identifier that does not require a centralized registry authority because it is registered using distributed ledger technology or another form of decentralized network.
(A globally unique identifier that does not require a centralized registration authority because it is registered using distributed ledger technology or another form of decentralized network).
DIDs are accepted in the form
did:example:123456789abcdefghi
As mentioned above, a DID consists of three parts separated by colons.
The first part (“did”) is a fixed value indicating that it is a DID.
The second part (“example”) is the name of the method.
The identifier method defined within the method is a name defined in connection with the way the distributed ledger network in which the DID is stored is implemented.
Below is an example of a method defined in the W3C
The third part (“123456789abcdefghi”) is a unique identifier within each method, defined within each method.
DID document
A DID document is a collection of data that characterizes the owner (subject) of a DID, including mechanisms such as public keys and anonymous biometric data that the subject may use to authenticate itself and prove its association with the DID. mechanisms that may be used by the subject to authenticate itself and prove its association with the DID. It may also indicate the endpoints of service provision, such as the point at which the VC is received, as described below.
The definition of a DID document provided by the W3C is as follows
A set of data describing a DID entity, including mechanisms, such as public keys and pseudonymous biometrics, that a DID entity can use to authenticate itself and prove its affiliation with a “DID.”
Below is a sample of a minimum DID unit document.
{
"@context": "https://www.w3.org/2019/did/v1",
"id": "did:example:123456789abcdefghi",
"authentication": [{
// used to authenticate as did:...fghi
"id": "did:example:123456789abcdefghi#keys-1",
"type": "RsaVerificationKey2018",
"controller": "did:example:123456789abcdefghi",
"publicKeyPem": "-----BEGIN PUBLIC KEY...END PUBLIC KEY-----\r\n"
}],
"service": [{
// used to retrieve Verifiable Credentials associated with the DID
"id":"did:example:123456789abcdefghi#vcs",
"type": "VerifiableCredentialService",
"serviceEndpoint": "https://example.com/vc/"
}]
}The subject qualified by “Id” is DID”. The “authentication” item reflects the authentication method. In the case of this sample, authentication is performed by RSA key verification. The actual public key is specified in the “publicKeyPem” field.
The “service” field contains the service endpoint for obtaining information related to this topic.
This section describes where you can get a verified certificate, which will be explained later.
Processing of Personally Identifiable Information (PII)
W3C defines PII (personally identifiable information) in a DID and a DID document as follows
If the DID method specification is written for a public DID Registry, where all DIDs and DID Documents will be publicly available, it is HIGHLY RECOMMENDED that this also allows entities and stakeholders to have access to DID documents.
It also allows entities and parties relying on the GDPR to exercise the right to be forgotten, as no PII will be recorded in an immutable registry.
This will ensure that PII will not be written to an immutable registry, allowing Data Subjects and Relying Parties to exercise the “right to be forgotten” provided by the GDPR).
This means that if the DID and the DID Document are stored in a so-called public blockchain where they can be accessed by anyone, then PII should not be included in it.
Proof of authority and verifiable claims
According to the W3C definition, a Claim is a “statement” by an issuer about the owner of a DID (subject/owner), which basically represents attributive information about the subject, etc. A set of one or more Claims issued by a single Issuer (Issuer) is called a Credential, and a Credential that is tamper-resistant and cryptographically verified for the Issuer is called a Verified Credential.
Verified Credentials consist of Metadata, which describes the type of credential, issuer, issue date, etc., Claims and Proofs, which are digitally signed data, etc., as follows
If the situation requires the presentation of multiple Credentials (or Applications) to the Verifier, they may be presented together as a Verifiable Presentation. In this case, each Verifiable Credential that may be contained in a Verifiable Presentation may have different issuers.
{
// set the context, which establishes the special terms we will be using
// such as 'issuer' and 'alumniOf'.
"@context": [
"https://www.w3.org/2018/credentials/v1",
"https://www.w3.org/2018/credentials/examples/v1"
],
// specify the identifier for the credential
"id": "http://example.edu/credentials/1872",
// the credential types, which declare what data to expect in the credential
"type": ["VerifiableCredential", "AlumniCredential"],
// the entity that issued the credential
"issuer": "https://example.edu/issuers/565049",
// when the credential was issued
"issuanceDate": "2010-01-01T19:73:24Z",
// claims about the subjects of the credential
"credentialSubject": {
// identifier for the only subject of the credential
"id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
// assertion about the only subject of the credential
"alumniOf": {
"id": "did:example:c276e12ec21ebfeb1f712ebc6f1",
"name": [{
"value": "Example University",
"lang": "en"
}, {
"value": "Exemple d'Université",
"lang": "fr"
}]
}
},
// digital proof that makes the credential tamper-evident
// see the NOTE at end of this section for more detail
"proof": {
// the cryptographic signature suite that was used to generate the signature
"type": "RsaSignature2018",
// the date the signature was created
"created": "2017-06-18T21:19:10Z",
// purpose of this proof
"proofPurpose": "assertionMethod",
// the identifier of the public key that can verify the signature
"verificationMethod": "https://example.edu/issuers/keys/1",
// the digital signature value
"jws": "eyJhbGciOiJSUzI1NiIsImI2NCI6ZmFsc2UsImNyaXQiOlsiYjY0Il19..TCYt5X
sITJX1CxPCT8yAV-TVkIEq_PbChOMqsLfRoPsnsgw5WEuts01mq-pQy7UJiN5mgRxD-WUc
X16dUEMGlv50aqzpqh4Qktb3rk-BuQy72IFLOqV0G_zS245-kronKb78cPN25DGlcTwLtj
PAYuNzVBAh4vGHSrQyHUdBBPM"
}In the above you can see information about the issuer (issuer), information about the subject (or Holder, as it is also called), the type of education document — school-leaving certificate (alumniOf), the name of the school in English and French, as well as information about the Confirmation and JSON node Signature (JWS) of the electronic digital signature format.
Movement towards standardization and implementation
Standartization bodies
Various organizations are currently working on the standardization or implementation of SSI from different perspectives. This section introduces some of these organizations and their activities.
W3C
W3C (World Wide Web Consortium) mainly studies and documents DID and Verifiable Credential architectures, data models, use cases, etc. DID is studied by the DID Working Group, Verifiable Credentials are studied by the Credentials Working Group.
DIF
The Decentralized Identity Foundation (DIF) is an organization that aims to develop the elements needed to build a decentralized identity ecosystem, with different working groups Different working groups are working on this. In particular, they are discussing how DIDs themselves are exchanged, how DIDs are used for authentication, how credentials are implemented and how data is stored.
About Sovrin Foundation
The Sovrin Foundation is a non-profit organization established in 2016 with the aim of implementing the Sovrin Network for SSI implementation on the Internet. Various open source tools and libraries have been developed, of which the source code for the distributed ledger part was contributed to the Hyperledger project, a blockchain project run by the Linux Foundation, and became the basis for Hyperledger Indy. It became the basis for Hyperledger Indy.
ERC725
ERC725 is a proposed Ethereum standard for implementing and managing SSI on the blockchain proposed by Fabian Vogelsteller, creator of ERC20 and Web3.js.
The originally proposed ERC725 was split into two draft standards, ERC725-v2 and ERC734, in October 2018, with the latest planning proposal comprising three standards: the ERC725-v2 standard for trusted accounts, the ERC734 standard for key management, and the ERC735 standard for claim holders. ERC735 is the standard for claimants.
Examples of standardization by DIFs
Below is a general overview of the MIS implementations under consideration by the DIF.
It is envisaged that the User Agent will be implemented in the form of a smartphone application, etc., and will be responsible for generating the User Key, DID and DID Document, as well as managing the Account to be verified and communicating with the Verifier(s), etc. The DID/DID Document generated by the Agent is stored on a network such as a distributed ledger or blockchain, and the Universal Solver resolves the differences between the above methods (= distributed ledger implementation). The Universal Solver allows DIDs to be exchanged in a way that is independent of the distributed ledger side implementation.
The credential issuer issues a verifiable credential to the DID holder. If you are issuing a certificate for a school diploma, the school is typically the certificate issuer. Issued Verifiable IDs are stored through the User Agent in the Identity Center, which is a secure offline storage facility. It is always synchronized with the User Agent and deletes the Verifiable Credentials as soon as the User Agent instructs it to do so.
If the Verifier wants to verify a user’s attributes, e.g. a school store wants to verify that a visitor is a student of the school, the store asks the visitor to provide the corresponding Verifiable Credential. The kiosk can verify the verification part of the Verifiable ID presented by the visitor and confirm that it is indeed a school ID issued by the relevant educational institution.
A user can have multiple DIDs. By issuing multiple verified credentials for different DIDs, each representing different attributes of themselves, DID name-calling can be prevented and a higher level of privacy can be ensured.
Conclusion
In this article we have presented the standardization and implementation trends related to SSI/DID.
As before, standardization and implementation methods are still being studied by different organizations, research is being conducted, and only a few of them are in full use. However, the importance of SSI is gradually growing in Europe, where the consistency between SSI and eIDAS is being evaluated and discussed, and in Japan, where the issue is being discussed by the Digital Market Competition Council, which is one of the policy councils.
Links
Thank you for reading to the end.
LinkedIn: https://www.linkedin.com/in/milan-bzovyi-64b7a9221/
Mail: milan.bzovyi.bm@gmail.co