Key Points

an open identity network providing DIDs, VCs to any registered client
real-time revocation verifications through DID-comm protocol
Based on Indy open-source identity platform from Hyperledger
3 separate networks run by stewards that operate nodes
The networks are governed by the Sovrin foundation
https://sovrin.org/the-sovrin-alliance/

References

Reference_description_with_linked_URLs_______________________	Notes______________________________________________________________

Digital Identity Concepts
Identity Management security concepts
m TOIP Trust Over IP
pssig-210312-Self Sovereign Identity in Govtech for Financial & Healthcare Inclusion gdoc
identity-use-cases-info. gdoc

LFS172x - Introduction to Hyperledger Sovereign Identity bc.docx
Hyperledger Identity Working Group-paper.docx - 2018


DID Articles - technology and use cases

Top 15 Blockchain Identity Platforms of 2024 article

Building Trust with Registries.pdf << TGFP ONLY

tgfp-environment-mgt-trust-casco_building-trust.pdf. GD

Trust Registries

For trust registries, particularly in the context of metadata registries and digital trust, relevant ISO standards include ISO/IEC 11179 (Information Technology – Metadata Registries) and ISO 17068 (Trusted third party repository for digital records). [1, 2, 3, 4, 5, 6]

Here's a more detailed breakdown: [4, 6]

ISO/IEC 11179 (Metadata Registries): [4, 6]
- This series of standards provides a framework for understanding and implementing metadata registries. [4, 6]
- It covers aspects like the structure of metadata registries, registration procedures, and data element definitions. [3, 5, 7]
- Specific parts include: [4]
  - ISO/IEC 11179-1: Framework [4]
  - ISO/IEC 11179-3: Registry metamodel and basic attributes [8]
  - ISO/IEC 11179-6: Registration [3]
  - ISO/IEC 11179-33: Metadata registries (MDR) [9]
  - ISO/IEC 11179-31: Formulation of data representations [10]
ISO 17068 (Trusted third party repository for digital records): [2]
- This standard specifies requirements for a trusted third-party repository (TTPR) to support the authorized custody service. [2]
- It focuses on safeguarding the integrity and authenticity of clients' digital records, ensuring they can serve as reliable evidence. [2]
ISO 22385 (Security and resilience): [1]
- This standard establishes a framework for a trustworthy environment for information processing and communication. [1]
- It aims to protect integrity along the supply chain of physical and related electronic documents, products, software, and services. [1]
ISO/IEC 18013-5 (Digital identity and attributes trust framework): [11, 12]
- This standard defines a mechanism to support establishing trust in trust networks where relying parties need to verify Mobile Credentials issued by numerous different issuers. [11, 12]
Other relevant standards: [13]
- ISO/IEC 27001: Information security management systems [13]
- ISO 37301: Compliance management systems [14]
- ISO 27701: Privacy Information Management System (PIMS) [15]
- ISO 42001: AI management systems [16]

Generative AI is experimental.

[1] https://www.iso.org/standard/50287.html

[2] https://www.iso.org/standard/66760.html

[3] https://www.iso.org/standard/78916.html

[4] https://www.iso.org/standard/78914.html

[5] https://www.iso.org/standard/44936.html

[6] https://digital.library.unt.edu/ark:/67531/metadc926399/

[7] https://en.wikipedia.org/wiki/ISO/IEC_11179

[8] https://www.iso.org/standard/50340.html

[9] https://www.iso.org/standard/81725.html

[10] https://www.iso.org/standard/78925.html

[11] https://www.gov.uk/government/publications/uk-digital-identity-and-attributes-trust-framework-beta-version/uk-digital-identity-and-attributes-trust-framework-beta-version

[12] https://learn.mattr.global/docs/digital-trust-service

[13] https://www.iso.org/standard/27001

[14] https://www.iso.org/standard/75080.html

[15] https://accscheme.com/services/iso-27701-pims/

[16] https://www.schellman.com/blog/iso-certifications/ai-data-considerations-iso-42001-and-iso-9001

[-] https://learn.mattr.global/docs/digital-trust-service

the-role-of-trust-registries-in-an-ssi-ecosystem. Gataca

gataca.io-The role of trust registries in an SSI ecosystem.pdf. GD

In the same way that anyone can falsify documents in the physical world, anyone can create a verifiable credential without being authorized to do so.
This raises the following question, how can a verifier assess that a verifiable credential is not fake and that it came from an authorized issuer? And vice-versa, how can users know which
verifiers are trustworthy and is all right to share their credentials with them?
This article explores the concept of trust registries and how Gataca implements our Registries to create trust in our SSI environment.

What are Trust Registries?

The trust framework in SSI is formed by a set of registries that provide a secure and reliable basis for entities within the system to trust and interact with each other. These registries, also called trust registries or trust anchors, contain information about who is authorized and trusted to issue or verify credentials. There are different trust frameworks (EBSI Registries is one example), and consulting about the validity of a specific credential implies knowing the trust framework it is anchored on. Trust Frameworks are typically provided by government agencies, but they could also be built by industry consortia or other private entities.

These trust registries are typically stored on blockchain ledgers due to their enhanced traceability and immutability properties, and hence the trust they provide when multiple unknown/untrusted entities are in the ecosystem. these trust registries in alternative storage systems such as centralized databases.

Issuing credentials for registered issuers

This registry contains a list of entities that are authorized to issue certain types of credentials ("Trusted Issuers"). For example, a bank included in the trust registry may be authorized to issue a bank account credential or a credit score but not a university diploma. Trusted Issuers may include businesses, government agencies, educational institutions, and other organizations with the authority to issue, verify, and revoke digital credentials.

DID Registry

A DID registry maintains a directory of DIDs and their associated DID documents. More on DIDs and DID documents here.

Trusted Schema Registry (TSR)

This registry contains the list of schemas allowed in the ecosystem. Schemas are templates that define the structure and semantics of verifiable credentials. As such, a schema defines which claims are included in a specific credential type (e.g., Academic Diploma) and the format of each claim (e.g., text, date, boolean). It also includes the rules for how it should be formatted and presented. Defining globally recognized schemas contribute to interoperability in the market.

Trusted Accreditation Organization Registry (TAOR)

This registry contains the list of organizations authorized to accredit another entity to issue certain VCs; they define who are Trusted Issuers. For example, in a specific Trust Framework, the Ministry of Education could be the Trusted Accreditation Organization (TAO) entitled to decide which universities can be listed in the TIR as Trusted Issuers of University Diplomas credentials. Not all Trust Frameworks have a TAOR. While EBSI’s trust framework has a TAOR, Gataca’s own trust framework does not.

Trusted Verifiers Registry (TVR)

This registry contains the list of entities that are Trusted Verifiers. This registry guarantee that it is safe for a user to share credentials with them. The TVR ensures that only trusted entities can verify the authenticity of verifiable credentials in the SSI ecosystem, helping to prevent fraud or abuse. Not all Trust Frameworks have a TVR. While EBSI’s trust framework does not have a TVR, at Gataca, we’ve implemented this registry as an extra security measure.

How are Trust Registries used?

In practice, these trust registries are consulted every time a credential is shared. During a presentation exchange, the following verification checks are executed on the verifier side before a credential can be considered successfully validated:

the credential complies with a schema listed in the TSR
the credential is issued by an issuer listed in the TIR
the issuer’s signature can be verified with the public keys listed in the DID Registry
the issuer is authorized by a TAO to issue credentials using this schema

Gataca Trust Framework

Gataca’s technology has been designed to connect and interoperate with multiple Trust Frameworks. This means that we do not build upon or rely on one specific blockchain network and that our products can easily read and interact with different protocols, ledgers, or databases if needed, enabling global interoperability.

Gataca’s technology is connected with its own Trust Framework and to the EBSI's Trust Framework, so users can seamlessly store credentials whose verification properties are anchored in either framework.

Hyperledger Indy ledger,

designed for decentralized identity, is a standards-compliant trust registry, particularly when it comes to Decentralized Identifiers (DIDs) and Verifiable Credentials (VCs), adhering to standards like W3C DID and VC specifications

VSLT - a DLT evolution - Value Chain Smart Ledger Technology

a Smart Directory Service that Links multiple ledgers into a ledger network providing clients easy access to a consolidated trust view over multiple ledgers

Logical DIDs can link multiple DIDs by reference from different ledgers

Trust-registries - verifiable-accreditation-trust-chain-model. cheqd

Key Concepts

A Study of Decentralized Identity Applications 2025

Trust-registries - verifiable-accreditation-trust-chain-model. cheqd

we are digital twins - we exist in both physical and digital worlds with identities

https://hyperledger.github.io/indy-did-method/

Cheqd - SSI network on Indy

https://cheqd.io/blog/sovrin-mainnet-shutdown-what-it-means-for-your-ecosystem/

Benefits of cheqd

Like we mentioned in our recent blog on Expanding cheqd into ACA-Py, cheqd provides a few improvements on Sovrin / Hyperledger Indy networks in terms of:

Interoperability: Through cheqd support, projects historically on Sovrin can expand more easily to other credential formats such as VC JWTs, SD-JWTs or JSON-LD – as well as AnonCreds, with each being able to resolve to the same foundational DID method. This will allow projects to expand to meet EU ARF requirements as they develop further.
Speed: cheqd is able to crunch over 5,000 transactions per second, improving on Indy/Sovrin’s ~4 transactions per second.
Decentralisation: cheqd is able to support over 100 node operators (currently at 64), building on Indy/Sovrin’s maximum of 25.
Trust Registries: cheqd supports ledger based trust registries through a “Verifiable Accreditation” model (see documentation here), allowing tiered hierarchies of trust to be built into its supported ecosystems.
Monetisation models: cheqd supports “payment gated” DID-Linked Resources, which facilitate “Verifier pays Issuer” commercial models. This optional feature affords ACA-Py communities and builders a new way to monetise their product offerings, with payments available in MiCA regulated eMoney including for USD and EURO.
Ecosystem: cheqd’s infrastructure is built on the Cosmos SDK, which is an actively maintained ecosystem with a healthy developer community and ~50 commits to main per week. cheqd itself then deploys multiple releases per year, always with significant feature releases, e.g. fee abstraction where users no longer need to hold the underlying $CHEQ token.

We’ve been building since 2021 and for a more in depth analysis of how cheqd compares against Hyperledger Indy and Sovrin, please see the comparison table in our documentation here.

Cheqd block explorer

https://explorer.cheqd.io/

Potential Value Opportunities

Referencing a Remote DID on another ledger from a Local DID in Indy

https://cheqd.io/blog/sovrin-mainnet-shutdown-what-it-means-for-your-ecosystem/

cheqd is making available a grant scheme (in $CHEQ) to facilitate the migration of traffic across to cheqd by minimising any switching cost.

Within this scheme, we will be able to reference historic did:sov DIDs using the alsoKnownAs property within our did:cheqd method, creating equivalent DIDs potentially based on the same key pairs.

Moreover, we will be able to support all of Sovrin’s functionality, including AnonCreds schemas, credential definitions and revocation lists through our AnonCreds Object Method, allowing for projects to continue operating as usual with minimal service disruption.

Further, as we have already done with Credo, we will be extending our support into ACA-Py to provide support for both major SDKs used by the Sovrin community. We will be in attendance at IIW and we will speak with the current maintainers of Sovrin to explore what might be the most effective solution for those projects built on the network, as they will need to find an alternative network to maintain business continuity.

Based upon public announcements, Sovrin mainnet is expected to be shut down by the end of March 2025, possibly earlier, after which it will be unavailable, for both writes and reads. Transparently, we have also reached out directly to the Sovrin team to see if there are any other alternatives.

Owing to the historical significance of Sovrin and the current projects running on top of the network, cheqd is making available a grant scheme (in $CHEQ) to facilitate the migration of traffic across to cheqd by minimising any switching cost.

Within this scheme, we will be able to reference historic did:sov DIDs using the alsoKnownAs property within our did:cheqd method, creating equivalent DIDs potentially based on the same key pairs.

A Grant Scheme

We will be providing a grant in our native token, $CHEQ, to fund transactions which require migration. This grant is primarily intended for those building on Sovrin, but we would also be happy to accommodate those looking to migrate from other networks or methods, such as did:web, did:ion or other networks to take advantage of the cutting edge functionality we provide (see following section) whilst it is open.

If you are interested in speaking to our team about a potential migration from Sovrin or another network, please fill out the form below, which will help our team curate the best migration path for your business.

Potential Challenges

Sovrin mainnet shutdown done 2025

This difficult decision follows a careful evaluation of the network’s sustainability.

Key Reasons:

1. Decline in MainNet Usage: In 2024, no new Transaction Endorsers joined, and efforts to revitalize interest did not increase engagement or revenue.
2. Regulatory Uncertainty: Ambiguities around decentralized identity have discouraged investments, hindering Sovrin’s growth.
3. Technical Challenges: Resources invested in upgrading Steward nodes were diverted to address issues on the TestNet, straining resources.
4. Governance and Community Involvement: Limited involvement from the Steward community in governance has placed a heavy burden on the Trustees, who have also faced a $2M debt from the previous Board.

Timeline and Future Considerations:

Barring significant changes, MainNet operations are expected to cease by March 31, 2025. If technical or financial changes occur that make it infeasible to operate the network, operations could cease sooner. The Board is also willing to work with others in the community with the leadership and resources to keep Sovrin MainNet operational. Without this, Sovrin will close in an orderly fashion.

Managing DIDs and VCs after Sovring Indy Ledger mainnet shutdown

After the Sovrin mainnet shutdown, the DIDs and VCs issued on it remain valid, but the ability to create new ones on the Sovrin network is gone. Cheqd is offering a grant scheme to help migrate traffic to their network, minimizing switching costs and allowing reference to historical Sovrin DIDs. [1, 2]

Here's a more detailed explanation: [1, 2]

Sovrin's Shutdown:The Sovrin network, which was a public Hyperledger Indy ledger, shut down its mainnet.
DID and VC Validity:DIDs and VCs issued on the Sovrin network remain valid and are not invalidated by the shutdown.
No New Issuance:You can no longer create new DIDs or VCs on the Sovrin network since the mainnet is no longer operational.
Migration to Cheqd:Cheqd is facilitating the migration of traffic from the Sovrin network to their own network by providing a grant scheme to minimize switching costs.
Grant Scheme Details:Within this scheme, Cheqd allows referencing historical did:sov DIDs, enabling a smoother transition for projects that were built on top of Sovrin.
Scope of Deletion:Sovrin's DID method specification states that deletion only prevents new history from accruing, ensuring that no malicious actor can recover and reactivate a deleted identity.

Generative AI is experimental.

[1] https://cheqd.io/blog/sovrin-mainnet-shutdown-what-it-means-for-your-ecosystem/

[2] https://sovrin-foundation.github.io/sovrin/spec/did-method-spec-template.html

Candidate Solutions

Top 15 Blockchain Identity Platforms of 2024 article

exploring these pioneering platforms, we aim to illuminate the significant advantages and transformative potential of blockchain identity in our increasingly digital lives.

youtube on digital identity concepts

digital id is based on email, phone or issued user profiles now before DIDs, VCs

DIDs issued are independent of most organizations ( from governments or identity service authorities instead ) and stored in digital wallet services

Credentials can be issued by anyone and stored in your wallet

The DID model provides privacy, security, and autonomy.

SSI DID model benefits over traditional digital identity systems

How DIDs and VCs work in 5 seconds

When access or authorization needed to a service, organization or resource, the verifier organization issues a challenge to prove the holders of digital ID and the related VCs from the issuers to gain access to authorized resources and services.
Privacy is protected because the holders don't need to supply PII ( Personal Identifying Information ) which is private, just present the DIDs and VCs instead to the verifier appropriate for the use case ( "am I old enough to drink in this bar?").
This process in based on strong cryptographic digital objects and governance services with automated verification services for the verifier, holder, issuers

Simple use case for a student verifying their id online for a university access

for improved reliability, the digital wallet, identity & credentials can be paired with a physical ID card with a QR code as a backup option for alternate access

TOIP - Trust Over IP - defines 4 layers for both the digital identity processes and the goverance of those processes ensuring integrity and trust

"Trust fuels the World and we are low"

Key Concepts on digital identities

entities for digital IDs are people, organizations, living things, assets ( real and virtual )
wallet services provide store and access to any digital asset ( DIDs, VCs, claims, consents, assets etc )

Step-by-step guide for Example

sample code block

sample code block

Key Points

References

DID Articles - technology and use cases

Building Trust with Registries.pdf << TGFP ONLY

Trust Registries

the-role-of-trust-registries-in-an-ssi-ecosystem. Gataca

What are Trust Registries?

Issuing credentials for registered issuers

DID Registry

Trusted Schema Registry (TSR)

Trusted Accreditation Organization Registry (TAOR)

Trusted Verifiers Registry (TVR)

How are Trust Registries used?

Gataca Trust Framework

Hyperledger Indy ledger,

VSLT - a DLT evolution - Value Chain Smart Ledger Technology

Trust-registries - verifiable-accreditation-trust-chain-model. cheqd

Key Concepts

A Study of Decentralized Identity Applications 2025

Trust-registries - verifiable-accreditation-trust-chain-model. cheqd

we are digital twins - we exist in both physical and digital worlds with identities

https://hyperledger.github.io/indy-did-method/

Cheqd - SSI network on Indy

Benefits of cheqd

Cheqd block explorer

Potential Value Opportunities

Referencing a Remote DID on another ledger from a Local DID in Indy

A Grant Scheme

Potential Challenges

Sovrin mainnet shutdown done 2025

Managing DIDs and VCs after Sovring Indy Ledger mainnet shutdown

Candidate Solutions

Top 15 Blockchain Identity Platforms of 2024 article

SSI DID model benefits over traditional digital identity systems

How DIDs and VCs work in 5 seconds

Simple use case for a student verifying their id online for a university access

TOIP - Trust Over IP - defines 4 layers for both the digital identity processes and the goverance of those processes ensuring integrity and trust

Key Concepts on digital identities

Step-by-step guide for Example

Recommended Next Steps

Related articles

Browser not supported