Menu

SSI (Self-Sovereign Identity) Glossary

SSI: It is a digital identity mechanism that a User (or better to say an Agent) can create, maintain and control their digital Identity. Agent can be anything from human to animal or things. Fundamentally it is worked based on public key infrastructure(PKI).

Is SSI an alternative to Username & Password(it means Authentication)? YES, Instead of using common security systems (Centralized or Federated), Agents can hold their Identity to login to system.

Can we use SSI for Authorization? Yes, we can put information such as claims in the issued document or VC and use it for the purpose of Authorization.

This diagram showing all the main elements that play the main role in SSI

SSI Roles

Holder: Agent that holds VCs and has an Identifier. Mostly Holders are the subject of VCs but they can also be the Holder of another agent. (You can Hold a VC of your child)

Issuer: Issuer is an agent that issue a document(VC or Verifiable Credential) to a subject.

Verifier: Agent that can verify the originality of a VC, that it is issued for this holder and it is not tampered.

Note: All agents can play all 3 different roles in the SSI mechanism.

Example Scenario: Imagine police stops and asks me to provide a driving license. It is the flow:

  • Police provide identity to show me they are real police.
    • Police is Holder, that should show me a VC which is original and they are real police.
    • Police-Organization is Issuer here, that validate and issued a VC for the police.
    • I am a Verifier. That verify the VC that is original one and also belong to a person who stopped me as a Police.
  • I provide police my driving license
    • I am a Holder of driving license. Because I have passed all the stages of driving license successfully and a VC issued for me.
    • Traffic department is the Issuer of driving license for me.
    • Police is the verifier. and verify that provided VC, belongs to me and it is valid one.

DID(Decentralized Identifier): A new type of globally unique identifier—similar to the URLs — that used as Digital Identity that the holder of it can create, maintain and control it independently without any need of a centralize power as a source of truth.
Example: did:eth:564refv8serwer6sdf5v8sev8s99erw8e2343rwdfgwee

VC(Verifiable Credential): A tamper proof document that issued for a subject. Because of the digital signature and PKI infrastructure the Holder of VC can not change it.

Subject: The subject of the VC, that means for whom the VC issued. Take into account a scenario that Holder of a VC is not the subject of VC. For example I can provide a VC to identify my Dog or my Kid.

VP(Verifiable Presentation): The document that a Holder provide to a Verifier that contains different fields that can come from one or more than one credentials.

Holder Agent: The software that interacts with the VC ecosystem on behalf of the Holder. This could be an app that you load onto your mobile phone or a program you run on your laptop.

Wallet: The entity that holds the VCs for the Holder. In many cases, the Wallet is integral to the Holder’s Agent, but the model allows for a remote wallet to exist, such as a cloud storage wallet.

DID Document: A document that represent essential and non-essential information for a DID or Identifier. The essential information such a a Public-Key of cryptography wallet that being used for digital signature. And non-essential or meta-data can be the address or logo of a business.
Example: Issuers need to sign a VC for a Holder. They need to have a DID-Document connected to their DID, so a verifier can verify an issued VC by Issuer’s public key that included into DID-Document.

DID Method: We can implement SSI mechanism using different infrastructures that can support decentralized-identifier. DID-Method is the way and the infrastructure and repository that provide a DID.
Examples:
did:eth:564refv8serwer6sdf5v8sev8s99erw8e2343rwdfgwee
This DID is provided by Ethereum infrastructure. and did-document is located on Ethereum blockchain and in a smart-contract.

did:btcr:sev8s99erw8e2343rwdfg
This DID is provided by bitcoin infrastructure. and did-document is located on Bitcoin blockchain.

did:web:aceconscious.studio
The above DID is provided by normal DNS web hosting infrustructure. and did-document is located on a URL address.

DID Resolver: The process that we can reach to a DID-Document related to a DID(identifier). It means we have an Identifier, so we know about the did-method from the identifier, we can reach to the DID-Document of that Identifier for any purpose. Like issuing and digital signature, or for signature proof.
Example: We want to find the public key of this DID: did:eth:564refv8serwer6sdf5v8sev8s99erw8e2343rwdfgwee
To reach the public key for verification process and digital signature. This DID is telling us the DID-Method is ethereum and the DID-Document is located on the Ethereum contract in this address: 564refv8serwer6sdf5v8sev8s99erw8e2343rwdfgwee

DIDComm: The message protocol that different roles use to communicated to each other. Each scenario of Issuing, Presenting and Verifying the Credentials happen during an flow of connection and communication between different parties. Parties used DIDComm protocol to have a secure connection. So the sender of a message(either Holder, Issuer or Verifier) need to know about the target which is Identifier. So they need to encrypt the message with the Public of receiver. So they need to use Resolver to reach to the DID-Document which means all parties of the SSI mechanism, should have an Identifier and a DID-Document and a Wallet(Pair Key).

Data Registry: An internet-accessible registry that holds all the essential data and metadata that enables the SSI ecosystem to operate. For example in Ethereum did-method it is blockchain and on a Holochain did-method it is DHT(Distributed Hash Table).

Revoke: Issuer can revoke an issued credential. The challenge here that there should be a database for revoked credentials and a verifier should query them constantly, which can have a conflict with GDPR.

Selective Disclosure: If a Holder can provide part of the a VC or VCs that a verifier required to know and validate, without revealing extra information for the privacy.
We can use different approaches to implement this purpose like Zero-Knowledge-Proof(ZKP) cryptography or BBS+ Signature.

  • Predicate Proofs: Holder can present a VC that proof a true/false statement. For example I am older than 18 without showing a verifier my Birth-date.
  • Multi Credential Proofs: Holder can provide just an essential part of information to a verifier in Presentaion and not all the fields of a Verifiable Credentials.

OOB(Out of the Band) Message: For many reason different parties would like to exchange some data and have a pre-setup workflow and then going to the main process of SSI actions. We call all of those communications and exchanges Out-of-the-Band messages.

Manifest: The template for some type of credential that an issuer should follow and the Holder should provide relevant information for it.
Example: Traffic-Department wants to issue a Driving-License for people. There are some required information that any Holder should provide for that VC which is driving license. We call this schema descriptor as Manifest.

Mediator: Is a mechanism or we can say a protocol that Issuer can send a message to a Holder when they are not online. So holders can receive messages when they are back online via a Mediator.
You can imagine Mediator like Smtp and Imap protocols in email. Someone can send you an email while you are offline and then you can query it later and read the message.

Verifiable Credential Structure

Note: This diagram is from: “Mastering Blockchain” book.

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://w3id.org/vc/status-list/2021/v1"
  ],
  "id": "http://example.edu/credentials/3732",
  "type": ["VerifiableCredential", "UniversityDegreeCredential"],
  "issuer": "https://example.edu/issuers/14",
  "validFrom": "2010-01-01T19:23:24Z",
  "credentialSubject": {
    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
    "degree": {
      "type": "BachelorDegree",
      "name": "Bachelor of Science and Arts"
    }
  },
  "credentialStatus": {
    "id": "https://example.edu/credentials/status/3#94567",
    "type": "StatusList2021Entry",
    "statusPurpose": "revocation",
    "statusListIndex": "94567",
    "statusListCredential": "https://example.edu/credentials/status/3"
  }
}
https://www.w3.org/TR/vc-data-model-2.0/#example-a-simple-example-of-a-verifiable-credential

Verifiable Presentation Structure

Note: This diagram is from: “Mastering Blockchain” book.

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://www.w3.org/ns/credentials/examples/v2"
  ],
  "id": "urn:uuid:3978344f-8596-4c3a-a978-8fcaba3903c5",
  "type": ["VerifiablePresentation", "CredentialManagerPresentation"],
  "verifiableCredential": [{ ... }],
  "proof": [{ ... }]
}
https://www.w3.org/TR/vc-data-model-2.0/#example-basic-structure-of-a-presentation

Useful Links and Resources

Verifiable Credentials Data Model v2.0
https://www.w3.org/TR/vc-data-model-2.0/

DID Specification Registries
https://www.w3.org/TR/did-spec-registries/

DIF Presentation Exchange
https://identity.foundation/presentation-exchange/spec/v2.0.0/

DIDComm Messaging v2.x Editor’s Draft
https://identity.foundation/didcomm-messaging/spec/

Wallet And Credential Interactions
https://identity.foundation/wallet-and-credential-interactions/

DIDComm.org
https://didcomm.org/

WACI Issue Credential
https://github.com/decentralized-identity/waci-presentation-exchange/tree/main/issue_credential

Aries Artifacts
https://github.com/hyperledger/aries-rfcs/tree/main/concepts

keri.one (did-keri)
https://keri.one/keri-resources/
https://github.com/decentralized-identity/keri
https://weboftrust.github.io/ietf-did-keri/draft-pfeairheller-did-keri.html

ZKP-LD Playground
https://playground.zkp-ld.org/

I will try to keep this post updated.

Comments

So empty here ... leave a comment!

Leave a Reply

Your email address will not be published. Required fields are marked *

Last posts

Sidebar