Chapter 2
The contents of this chapter are:
- What are the principles of the SSI and which are the new roles in the system?
- How do the new decentralized identifiers work? (p2p model)
- Digital credentials for attributes; how to have a solid root of trust (distributed ledgers and blockchain)
- How do digital identity wallets work?
- What is a self-issued OpenID and what is the relationship with previous frameworks?
Chapter 2
The contents of this chapter are:
- What are the principles of the SSI and which are the new roles in the system?
- How do the new decentralized identifiers work? (p2p model)
- Digital credentials for attributes; how to have a solid root of trust (distributed ledgers and blockchain)
- How do digital identity wallets work?
- What is a self-issued OpenID and what is the relationship with previous frameworks?
The ten principles of Sovereign Identity (SSI)
Imagine moving to a new country and having to register to use any type of service: voting, getting a driver’s license, electricity service, and new bank details. At the moment, to open a new account you need to register with each new service provider and prove your identity, and each time, to access, you need to prove your identity by entering your password and credentials. A decentralized identity would radically simplify such a process. It should satisfy certain principles to ensure that it does not have the same problems and limitations as the previous models.
- Existence – Users must have an independent entity
- Control – Users must control their identities
- Access – Users must have access to their personal data
- Transparency – Algorithms and systems must be transparent
- Persistence – Identities must be lasting
- Portability – Identity information and services must be “transportable”
- Interoperability – Identities should be widely usable
- Consent – Users must allow the use of their identities
- Minimization – Disclosure of user statements must be minimized
- Protection – Protection of user rights
The ten principles of Sovereign Identity (SSI)
Imagine moving to a new country and having to register to use any type of service: voting, getting a driver’s license, electricity service, and new bank details. At the moment, to open a new account you need to register with each new service provider and prove your identity, and each time, to access, you need to prove your identity by entering your password and credentials. A decentralized identity would radically simplify such a process. It should satisfy certain principles to ensure that it does not have the same problems and limitations as the previous models.
- Existence – Users must have an independent entity
- Control – Users must control their identities
- Access – Users must have access to their personal data
- Transparency – Algorithms and systems must be transparent
- Persistence – Identities must be lasting
- Portability – Identity information and services must be “transportable”
- Interoperability – Identities should be widely usable
- Consent – Users must allow the use of their identities
- Minimization – Disclosure of user statements must be minimized
- Protection – Protection of user rights
- verifiable data registry: the system that mediates the creation and verification of identifiers and other relevant data, such as diagrams of verifiable credentials, revocation registers, and the issuer’s public keys.
The new roles in the SSI Ecosystem
An autonomous and decentralized management of one’s digital identity corresponds to a necessary adaptation of the roles within the identity management system:
- holder: who possesses one or more verifiable credentials and generates presentations from them
- issuer: the role of the person who affirms the statements of one or more subjects, creating verifiable credentials and transmitting them to the holder
- subject: the entity to which the statements refer. In most cases it coincides with the holder, but not always. (E.g .: the parent has the child’s credentials)
- vérifier: the role of whoever receives one or more credentials, possibly within a presentation, to process and verify
The new roles in the SSI Ecosystem
An autonomous and decentralized management of one’s digital identity corresponds to a necessary adaptation of the roles within the identity management system:
- holder: who possesses one or more verifiable credentials and generates presentations from them
- issuer: the role of the person who affirms the statements of one or more subjects, creating verifiable credentials and transmitting them to the holder
- subject: the entity to which the statements refer. In most cases it coincides with the holder, but not always. (E.g .: the parent has the child’s credentials)
- vérifier: the role of whoever receives one or more credentials, possibly within a presentation, to process and verify
- verifiable data registry: the system that mediates the creation and verification of identifiers and other relevant data, such as diagrams of verifiable credentials, revocation registers, and the issuer’s public keys.
What is a Decentralized Identifier (DID)?
Both in the digital world and in the physical world, our identity is recognized and associated with identifiers: communication addresses (telephone numbers, e-mail addresses), ID numbers (for passports, driving licenses, health insurance), and product identifiers (serial numbers, barcodes) are forms of identifiers. Even on the web, resources and specific web pages are associated with identifiers called Uniform Resource Identifiers (URIs) and Unique Resource Locators (URLs).
Most identifiers are associated with their identity by third parties, which can manage and/or modify them afterward.
Decentralized Identifiers (DIDs) constitute a new type of unique identifiers, similar to URIs with signatures and encryption, created to allow individuals and organizations to generate and own their identifiers, without the need for a fiduciary counterpart. DID, necessary to keep various identities and interactions separate.
DIDs can represent and be associated with legal entities and objects as well.
What is a Decentralized Identifier (DID)?
Both in the digital world and in the physical world, our identity is recognized and associated with identifiers: communication addresses (telephone numbers, e-mail addresses), ID numbers (for passports, driving licenses, health insurance), and product identifiers (serial numbers, barcodes) are forms of identifiers. Even on the web, resources and specific web pages are associated with identifiers called Uniform Resource Identifiers (URIs) and Unique Resource Locators (URLs).
Most identifiers are associated with their identity by third parties, which can manage and/or modify them afterward.
Decentralized Identifiers (DIDs) constitute a new type of unique identifiers, similar to URIs with signatures and encryption, created to allow individuals and organizations to generate and own their identifiers, without the need for a fiduciary counterpart. DID, necessary to keep various identities and interactions separate.
DIDs can represent and be associated with legal entities and objects as well.
As you can see in this schema from the official W3C document, the common schema is “did”, the “did method” is “example”, while the alphanumeric code is the person-specific did method. Different will be network and distributed ledgers, different will also be the “did method“. Among the most famous “did method” are: did: btcr (Bitcoin) and did: ethr (Ethereum). Furthermore, the number of networks working on decentralized identifiers is growing.
The architecture of decentralized identifiers (DID)
In this section, we look at the various components in the DID architecture and how they work with each other.
DID and DID URL
A DID is an alphanumeric string that represents our identity.
Technically, a DID is an ad hoc URI made up of three parts: the did: schema, a method identifier, and a unique identifier specified by the DID method.
A DID may also have associated a DID URL.
A DID URL extends the syntax of the base DID in order to incorporate other standard URI components to place other specific resources related to the entity that holds the DID.
To produce a resource from the DID URL, the software is used which takes the URL of the DID as input and produces a resource as output (this process is called dereferencing).
As you can see in this schema from the official W3C document, the common schema is “did”, the “did method” is “example”, while the alphanumeric code is the person-specific did method. Different will be network and distributed ledgers, different will also be the “did method“. Among the most famous “did method” are: did: btcr (Bitcoin) and did: ethr (Ethereum). Furthermore, the number of networks working on decentralized identifiers is growing.
The architecture of decentralized identifiers (DID)
In this section, we look at the various components in the DID architecture and how they work with each other.
DID and DID URL
A DID is an alphanumeric string that represents our identity.
Technically, a DID is an ad hoc URI made up of three parts: the did: schema, a method identifier, and a unique identifier specified by the DID method.
A DID may also have associated a DID URL.
A DID URL extends the syntax of the base DID in order to incorporate other standard URI components to place other specific resources related to the entity that holds the DID.
To produce a resource from the DID URL, the software is used which takes the URL of the DID as input and produces a resource as output (this process is called dereferencing).
The architecture of decentralized identifiers (DID)
DID Documents
DID documents accompany DIDs and these files can be used in a network and in the public sphere. DID documents contain other valuable information for use and identification security such as:
- The reference to the specific DID
- Verification methods using cryptographic keys
- The authentication methods
- External service endpoints for post-post interactions
- The creation date of the DID (timestamp)
- The signature of the creator of the DID for its integrity
Under the DID method, the mechanism by which a particular type of DID and its corresponding document is created, resolved, updated, and deactivated changes.
DID resolvers and DID resolution
The DID solver is a system component that takes the DID as input and outputs a compliant DID document. This process is called DID Resolution. The steps for resolving a specific type of DID are defined by the relevant DID method.
To be solvable into DID documents, DIDs are registered on an underlying system or network. Regardless of the technology used, any system that supports DID registration and the return of data to create a DID document is called a verifiable data registry.
The architecture of decentralized identifiers (DID)
DID Documents
DID documents accompany DIDs and these files can be used in a network and in the public sphere. DID documents contain other valuable information for use and identification security such as:
- The reference to the specific DID
- Verification methods using cryptographic keys
- The authentication methods
- External service endpoints for post-post interactions
- The creation date of the DID (timestamp)
- The signature of the creator of the DID for its integrity
Under the DID method, the mechanism by which a particular type of DID and its corresponding document is created, resolved, updated, and deactivated changes.
DID resolvers and DID resolution
The DID solver is a system component that takes the DID as input and outputs a compliant DID document. This process is called DID Resolution. The steps for resolving a specific type of DID are defined by the relevant DID method.
To be solvable into DID documents, DIDs are registered on an underlying system or network. Regardless of the technology used, any system that supports DID registration and the return of data to create a DID document is called a verifiable data registry.
- . Second Chapter (%) 30%
DID subjects
By definition, the subject of a DID is the entity identified by the DID.
The subject of the DID does not have to be a person, it can also be identified with an organization, a group, an object or a concept.
To deepen the subject, here is the link of the W3C document, where it sets the standards to be followed for the various protocols and networks.
The architecture of decentralized identifiers (DID)
There is a clear distinction to be made between “who controls” the DID and “who is associated” with the DID, especially in parental situations and/or with limitations in the public sphere.
DID controllers
The controller of a DID is an entity (person, organization or standalone server) that has the ability to make changes to a DID document.
This capability is typically affirmed by checking a series of cryptographic keys used by the software acting on behalf of the controller.
A DID can also have more than one controller and the DID subject can be the controller itself.
- . Second Chapter (%) 30%
The architecture of decentralized identifiers (DID)
There is a clear distinction to be made between “who controls” the DID and “who is associated” with the DID, especially in parental situations and/or with limitations in the public sphere.
DID controllers
The controller of a DID is an entity (person, organization or standalone server) that has the ability to make changes to a DID document.
This capability is typically affirmed by checking a series of cryptographic keys used by the software acting on behalf of the controller.
A DID can also have more than one controller and the DID subject can be the controller itself.
DID subjects
By definition, the subject of a DID is the entity identified by the DID.
The subject of the DID does not have to be a person, it can also be identified with an organization, a group, an object or a concept.
To deepen the subject, here is the link of the W3C document, where it sets the standards to be followed for the various protocols and networks.
The main benefits of the decentralized identifier
In this table taken from the W3C document, we analyze various aspects that make DIDs better than past identifiers for identity management.
- Inter-jurisdictional – Inter-jurisdictional identifiers do not depend on the jurisdiction of the country in which they were issued.
- Cannot be administratively deleted – These identifiers cannot be deleted or subtracted from administrative functions. This prevents interference from political instability. (anti-censorship)
- Minimized rents – These identifiers incur no charges when unused
- No monopoly – Identifiers are not dependent on any vendor
- Self-issued, self-managed – Identifiers are created and managed by the subject or the identifier
- Simplified rotation – When the material needs to be updated, the identifiers can be updated without the direct intervention of the parties and with minimal intervention by the individual.
- No phone home – When identifiers are used, there is no need to contact the issuer of the identifier for verification.
- No surveillance capitalism – Identifiers limit the effectiveness of surveillance capitalism by minimizing the correlation between services.
- Encryption is not obsolescent – Identifiers can be updated as technology evolves.
- Survive the disappearance of organizations – Identifiers survive the disappearance of the organizations that issued them.
- Survives deployment end-of-life – These identifiers are usable even after the systems used by the parties become obsolete.
- Surviving relationship with the service provider – The identifiers are independent, they remain even if the service provider’s mandate fails.
- Cryptographic authentication and communication – Identifiers allow the authentication of individuals using cryptographic techniques, and also allow secure communications with the subject to which the identifier refers, using public-private keys.
- Service discovery – These identifiers allow the parties to search for services available to communicate with the person to whom the identifier refers.
- Registry agnostic – These identifiers can be on any registry that has a compatible interface.
The main benefits of the decentralized identifier
In this table taken from the W3C document, we analyze various aspects that make DIDs better than past identifiers for identity management.
- Inter-jurisdictional – Inter-jurisdictional identifiers do not depend on the jurisdiction of the country in which they were issued.
- Cannot be administratively deleted – These identifiers cannot be deleted or subtracted from administrative functions. This prevents interference from political instability. (anti-censorship)
- Minimized rents – These identifiers incur no charges when unused
- No monopoly – Identifiers are not dependent on any vendor
- Self-issued, self-managed – Identifiers are created and managed by the subject or the identifier
- Simplified rotation – When the material needs to be updated, the identifiers can be updated without the direct intervention of the parties and with minimal intervention by the individual.
- No phone home – When identifiers are used, there is no need to contact the issuer of the identifier for verification.
- No surveillance capitalism – Identifiers limit the effectiveness of surveillance capitalism by minimizing the correlation between services.
- Encryption is not obsolescent – Identifiers can be updated as technology evolves.
- Survive the disappearance of organizations – Identifiers survive the disappearance of the organizations that issued them.
- Survives deployment end-of-life – These identifiers are usable even after the systems used by the parties become obsolete.
- Surviving relationship with the service provider – The identifiers are independent, they remain even if the service provider’s mandate fails.
- Cryptographic authentication and communication – Identifiers allow the authentication of individuals using cryptographic techniques, and also allow secure communications with the subject to which the identifier refers, using public-private keys.
- Service discovery – These identifiers allow the parties to search for services available to communicate with the person to whom the identifier refers.
- Registry agnostic – These identifiers can be on any registry that has a compatible interface.
The new verifiable credentials in the dematerialization scenario
We are dealing with the concept of verifiable credentials every day; driving licenses, university degrees, and passports are credentials that attest to some of our attributes. A mechanism is, therefore, necessary that allows these credentials to be expressed on the Web in such a way as to respect the privacy of individuals and which is cryptographically secure.
In the physical world, a credential can consist of:
- information related to the recognition of the subject of the credential (a photo, name, identification number)
- information related to the issuing authority (a town hall, a national agency)
- information related to the type of credential (a Dutch passport, an American driving license, a health insurance card)
- information related to specific attributes or properties affirmed by the issuing authority regarding the subject (nationality, date of birth, type of vehicle that can drive)
With the W3C standard, a verifiable credential is able to represent all the information a physical credential possesses. Holders of a verifiable credential can generate verifiable presentations and show them to verifiers while remaining in possession of them.
The new verifiable credentials in the dematerialization scenario
We are dealing with the concept of verifiable credentials every day; driving licenses, university degrees, and passports are credentials that attest to some of our attributes. A mechanism is, therefore, necessary that allows these credentials to be expressed on the Web in such a way as to respect the privacy of individuals and which is cryptographically secure.
In the physical world, a credential can consist of:
- information related to the recognition of the subject of the credential (a photo, name, identification number)
- information related to the issuing authority (a town hall, a national agency)
- information related to the type of credential (a Dutch passport, an American driving license, a health insurance card)
- information related to specific attributes or properties affirmed by the issuing authority regarding the subject (nationality, date of birth, type of vehicle that can drive)
With the W3C standard, a verifiable credential is able to represent all the information a physical credential possesses. Holders of a verifiable credential can generate verifiable presentations and show them to verifiers while remaining in possession of them.
The figure on the right shows the role of the three elements that make up the data model of a verifiable credential, in the scenario of verifying possession of an academic credential. The proof will be the validity of the digital signature of the referring university.
The attribute of the user is to be a student, the signature with a public key of a university attests to the attribute, and the metadata is your other information in that precise credential.
However, as we are going to see, thanks to verifiable presentations it is possible to show data, guaranteeing its validity without other related data.
The data model of a verifiable credential (VC)
A verifiable credential is a set of non-breachable claims and data that cryptographically prove who issued it. The credential can be signed by the issuer.
The figure on the left shows the basic components of a credential: standard metadata, attributes, and a cryptographic proof of security.
The data model of a verifiable credential (VC)
A verifiable credential is a set of non-breachable claims and data that cryptographically prove who issued it. The credential can be signed by the issuer.
The figure on the left shows the basic components of a credential: standard metadata, attributes, and a cryptographic proof of security.
The figure on top shows the role of the three elements that make up the data model of a verifiable credential, in the scenario of verifying possession of an academic credential. The proof will be the validity of the digital signature of the referring university.
The attribute of the user is to be a student, the signature with a public key of a university attests to the attribute, and the metadata is your other information in that precise credential.
However, as we are going to see, thanks to verifiable presentations it is possible to show data, guaranteeing its validity without other related data.
The Verifiable Presentation data model
One of the most interesting principles to follow is the concept of minimizing the data, that is, showing only the necessary data. To ensure data minimization, the user can combine a presentation with the required information from his credentials. The figure on the left shows the components of a verifiable presentation: the presentation metadata, verifiable credentials, and cryptographic evidence.
The figure on the left shows the complete representation of a previous presentation, where the user demonstrates that he has a university credential, without showing his name. Log in to the library, without leaving sensitive data in the library.
The first graphic expresses a verifiable presentation, containing the respective metadata. The presentation refers to one or more credentials, contained in the second chart.
The third chart corresponds to the digital signature referring to the credential, while the fourth contains the signature proving the verifiable presentation.
The Verifiable Presentation data model
One of the most interesting principles to follow is the concept of minimizing the data, that is, showing only the necessary data. To ensure data minimization, the user can combine a presentation with the required information from his credentials. The figure on the left shows the components of a verifiable presentation: the presentation metadata, verifiable credentials, and cryptographic evidence.
The figure on top shows the complete representation of a previous presentation, where the user demonstrates that he has a university credential, without showing his name. Log in to the library, without leaving sensitive data in the library.
The first graphic expresses a verifiable presentation, containing the respective metadata. The presentation refers to one or more credentials, contained in the second chart.
The third chart corresponds to the digital signature referring to the credential, while the fourth contains the signature proving the verifiable presentation.
- The owner and the verifier count on the issuer to issue true credentials regarding the subject and to revoke them if they are inappropriate.
- The owner expects that the credentials are stored securely, that they are not released to third parties, and that they are not tampered with or lost.
This model differs from the others in that the issuer does not need to know the verifier.
How do the trust model works in SSI?
The model of trust between actors using verifiable credentials provides that:
- The verifier expects the issuer to issue the credential it has received. To establish this trust, the credential should:
- include a signature proving that the issuer generated the credential
or - be transmitted in a clear way, which establishes that the issuer has generated the verifiable credential and that the credential has not been tampered with.
All entities count on the data log to be tamper-proof and to be a correct record of entity-controlled data.
How do the trust model works in SSI?
The model of trust between actors using verifiable credentials provides that:
- The verifier expects the issuer to issue the credential it has received. To establish this trust, the credential should:
- include a signature proving that the issuer generated the credential
or - be transmitted in a clear way, which establishes that the issuer has generated the verifiable credential and that the credential has not been tampered with.
All entities count on the data log to be tamper-proof and to be a correct record of entity-controlled data.
- The owner and the verifier count on the issuer to issue true credentials regarding the subject and to revoke them if they are inappropriate.
- The owner expects that the credentials are stored securely, that they are not released to third parties, and that they are not tampered with or lost.
This model differs from the others in that the issuer does not need to know the verifier.
Root of trust management and use of online sovereign identity
Trust in the SSI framework is given by the technological tools it uses to ensure the privacy, control, and security of personal information. We have seen in the sub-chapter that there are many “did” methods on the market, offered by companies and ecosystems that use the blockchain and the distributed ledger for business and crypto. In this part, we will talk about the other technologies used for the usability, interoperability, and custody.
Root of trust management and use of online sovereign identity
Trust in the SSI framework is given by the technological tools it uses to ensure the privacy, control, and security of personal information. We have seen in the sub-chapter that there are many “did” methods on the market, offered by companies and ecosystems that use the blockchain and the distributed ledger for business and crypto. In this part, we will talk about the other technologies used for the usability, interoperability, and custody.
Blockchain, distributed ledger and network
The blockchain is a ledger used as a public, shared, and democratic root-of-trust, where no one can enforce it.
Let’s try to better understand why.
The blockchain (literally “chain of blocks”) is a shared data structure. Its immutability is given by a low probability of malicious attackers in the network thank to a good synchronization of economic incentives. It is defined as a digital register whose entries are grouped into “blocks”, concatenated in chronological order. They use hash functions to correlate information and Merkle trees to summarize data and to ensure the immutability of the transaction.
Thanks to cryptography, distributed science and game theory, a blockchain is a great shared and public root of trust.
- Second Chapter (%) 57%
These technologies are included in the broader family of Distributed Ledgers, which can be read and modified by multiple nodes on a network.
Within the business model of the SSI, the register can be used for the following purposes:
- Verify a verifiable credential
- Revocation of a verifiable credential
- Creation of a DID, based on the DID Method of the protocol
- Blacklisting of a DIDs
- Verification of DID Document and data related to DID controller and DID Subject
Blockchain, distributed ledger and network
The blockchain is a ledger used as a public, shared, and democratic root-of-trust, where no one can enforce it.
Let’s try to better understand why.
The blockchain (literally “chain of blocks”) is a shared data structure. Its immutability is given by a low probability of malicious attackers in the network thank to a good synchronization of economic incentives. It is defined as a digital register whose entries are grouped into “blocks”, concatenated in chronological order. They use hash functions to correlate information and Merkle trees to summarize data and to ensure the immutability of the transaction.
Thanks to cryptography, distributed science and game theory, a blockchain is a great shared and public root of trust.
- Second Chapter (%) 57%
These technologies are included in the broader family of Distributed Ledgers, which can be read and modified by multiple nodes on a network.
Within the business model of the SSI, the register can be used for the following purposes:
- Verify a verifiable credential
- Revocation of a verifiable credential
- Creation of a DID, based on the DID Method of the protocol
- Blacklisting of a DIDs
- Verification of DID Document and data related to DID controller and DID Subject
The Resolver’s job is to discover and recover this additional information. This information contains elements such as services for communicating with entities and the cryptographic keys associated with them.
This allows the construction of data formats and multi-layer protocols, regardless of the blockchain used to register the identifier. Internally, the Universal Resolver achieves this goal through its architecture consisting of a driver for each type of supported identifier.
Universal Resolver and interoperabilità
To improve the solvers of the DID documents and ensure greater interoperability, the Universal Resolver technology has been designed. This is important, because the identifiers are the basis for the communication and identification systems; without identifiers, we cannot have relationships, transactions, and data sharing between entities.
The Universal Resolver allows us to build architectures and protocols on self-sovereign identifiers. There is no longer a need for a central authority to issue, maintain or revoke identifiers.
A DID-based blockchain that supports the Universal Resolver must define and implement a DID driver that connects the Resolver to the DID method used to read DID documents.
Universal Resolver and interoperabilità
To improve the solvers of the DID documents and ensure greater interoperability, the Universal Resolver technology has been designed. This is important, because the identifiers are the basis for the communication and identification systems; without identifiers, we cannot have relationships, transactions, and data sharing between entities.
The Universal Resolver allows us to build architectures and protocols on self-sovereign identifiers. There is no longer a need for a central authority to issue, maintain or revoke identifiers.
A DID-based blockchain that supports the Universal Resolver must define and implement a DID driver that connects the Resolver to the DID method used to read DID documents.
The Resolver’s job is to discover and recover this additional information. This information contains elements such as services for communicating with entities and the cryptographic keys associated with them.
This allows the construction of data formats and multi-layer protocols, regardless of the blockchain used to register the identifier. Internally, the Universal Resolver achieves this goal through its architecture consisting of a driver for each type of supported identifier.
The Digital Wallet (Crypto Wallet or DKMS)
A digital wallet, in the context of self-sovereign identity, is an encrypted application and database that stores credentials, keys, and other “secrets” required for a self-sovereign identity.
Credentials are issued, transferred, and verified by using digital wallets.
Technically these wallets are defined as DKMS (Decentralized Key Management System) deriving from the new Key Management approach used with the blockchain and distributed ledger technologies (DLTs) in which there are no longer central authorities. With DKMS, the initial “relationship of trust” between all participants consists of each distributed ledger that supports a new form of identity registry called DID.
The DKMS architecture brings the following benefits:
- No single point of failure
- Interoperability
- Strong and flexible infrastructure
- Key recovery
- Second Chapter (%) 91%
The DKMS architecture is based on three levels:
The DID level is the fundamental one, made up of DIDs registered and solved through distributed ledgers.
The cloud level is made up of wallets and agents that allow communication and mediation between the DID level and the edge level. This layer allows peer-to-peer communication for exchanges and verification of DIDs, public keys and verifiable credentials.
The edge layer is made up of mobile devices, agents, and wallets used directly by the identity holders to generate and store private keys and perform management operations.
The Digital Wallet (Crypto Wallet or DKMS)
A digital wallet, in the context of self-sovereign identity, is an encrypted application and database that stores credentials, keys, and other “secrets” required for a self-sovereign identity.
Credentials are issued, transferred, and verified by using digital wallets.
Technically these wallets are defined as DKMS (Decentralized Key Management System) deriving from the new Key Management approach used with the blockchain and distributed ledger technologies (DLTs) in which there are no longer central authorities. With DKMS, the initial “relationship of trust” between all participants consists of each distributed ledger that supports a new form of identity registry called DID.
The DKMS architecture brings the following benefits:
- No single point of failure
- Interoperability
- Strong and flexible infrastructure
- Key recovery
- Second Chapter (%) 91%
The DKMS architecture is based on three levels:
The DID level is the fundamental one, made up of DIDs registered and solved through distributed ledgers.
The cloud level is made up of wallets and agents that allow communication and mediation between the DID level and the edge level. This layer allows peer-to-peer communication for exchanges and verification of DIDs, public keys and verifiable credentials.
The edge layer is made up of mobile devices, agents, and wallets used directly by the identity holders to generate and store private keys and perform management operations.
OpenID Connect defines a mechanism by which an End User can use an OpenID Provider to their advantage to release identity information to a third party.
This specification defines the concept of Self Issued OpenID Provider, or a provider under the control of the end user. The latter can thus authenticate independently and submit statements to third parties. This allows users to interact with third parties without relying on an external provider.
How does SSI relate to online identification protocols today?
The goal of the SSI is to make the sovereign digital identity scalable and interoperable by talking to existing frameworks. The OpenID Foundation along with the DIF suggested the integration of the sovereign digital identity with the OpenID Connect authentication standard. Currently, it has not yet been implemented.
Let’s analyze this in more detail.
An OpenID Provider (OP) releases information about the identity in the form of a token ID. A Self-issued token, on the other hand, is a token issued by a Self-issued OpenID Provider. In the latter case, the trust relationship is direct with the end user.
A Self-issued OpenID Provider can have two types of verifiable credentials, that are self-issued or issued by an external issuer and still remain cryptographically verifiable.
How does SSI relate to online identification protocols today?
The goal of the SSI is to make the sovereign digital identity scalable and interoperable by talking to existing frameworks. The OpenID Foundation along with the DIF suggested the integration of the sovereign digital identity with the OpenID Connect authentication standard. Currently, it has not yet been implemented.
Let’s analyze this in more detail.
An OpenID Provider (OP) releases information about the identity in the form of a token ID. A Self-issued token, on the other hand, is a token issued by a Self-issued OpenID Provider. In the latter case, the trust relationship is direct with the end user.
A Self-issued OpenID Provider can have two types of verifiable credentials, that are self-issued or issued by an external issuer and still remain cryptographically verifiable.
OpenID Connect defines a mechanism by which an End User can use an OpenID Provider to their advantage to release identity information to a third party.
This specification defines the concept of Self Issued OpenID Provider, or a provider under the control of the end user. The latter can thus authenticate independently and submit statements to third parties. This allows users to interact with third parties without relying on an external provider.
The advantages of the SSI system through Self-Issued OP
The advantages of the Self-Issued Op can be:
- Resilience against inoperability of the OP – The infrastructure of an OpenID Provide may be unavailable: Self-issued OP solves the problem
- Authentication – Self-Issued OP provides direct authentication, without having to use remote OPs, speeding up the process.
- Sharing of credentials in a single transaction – Self-Issued OP directly represents the user, so they can have a huge set of information that a traditional OP does not have.
- Aggregation of multiple services under one self-issued OP – End users usually use different Hosted Open ID Providers for different third parties. This use can create friction if the user returns at a later time and does not remember the OP used previously.
The Self-issued single OP model, on the other hand, allows you to meet a need for privacy and ease of use, using the credential issuer’s reputational trust.
The advantages of the SSI system through Self-Issued OP
The advantages of the Self-Issued Op can be:
- Resilience against inoperability of the OP – The infrastructure of an OpenID Provide may be unavailable: Self-issued OP solves the problem
- Authentication – Self-Issued OP provides direct authentication, without having to use remote OPs, speeding up the process.
- Sharing of credentials in a single transaction – Self-Issued OP directly represents the user, so they can have a huge set of information that a traditional OP does not have.
- Aggregation of multiple services under one self-issued OP – End users usually use different Hosted Open ID Providers for different third parties. This use can create friction if the user returns at a later time and does not remember the OP used previously.
The Self-issued single OP model, on the other hand, allows you to meet a need for privacy and ease of use, using the credential issuer’s reputational trust.