...

A verifiable credential could be a drivers license, a degree, a certificate from a building inspector, an authorization for a user role to access accounts, etc

1. First the issuer writes a Decentralized Identifier (DID) together with its public key (and any other cryptographic material needed for the issuer’s verifiable credentials) to a blockchain (or other sufficiently trusted public utility).
2. Second, the issuer uses its private key to digitally sign a verifiable credential it issues to a qualified holder, who stores it in her own digital wallet. Note that for privacy preservation, this entire issuance process takes place ​off-chain​.
3. Third, a verifier requests a digital proof of one or more credentials from the holder. If the holder consents, the holder’s wallet generates and returns the proofs to the verifier. Since the proofs contain the issuer’s DID, the verifier uses it to read the issuer’s public key and other cryptographic data from the blockchain.
4. In the final step, the verifier uses the issuer’s public key to verify that the proofs are valid and that the digital credential has not been tampered with.

TOIP Interactive Model showing how Verifiable Credentials Work

...

a>> see how AnonCreds plans to support W3C VC standards

AnonCreds, the most commonly used Verifiable Credential (VC) format in the world*, is now a Hyperledger project. Ledger agnostic and with a formal open specification, AnonCreds continues to evolve as a mature verifiable credential format with unique privacy-protecting capabilities. 

Hyperledger AnonCreds—short for “Anonymous Credentials”—is a type of VC that adds important privacy-protecting ZKP (zero-knowledge proof) capabilities to the core VC assurances. A core element of the Hyperledger Indy project for more than five years, AnonCreds is a mature, complete model and interactions set, with extensive support across Hyperledger Aries frameworks.

Hyperledger AnonCreds is ledger-agnostic and client-agnostic. It is not tied to Hyperledger Indy or Aries. This makes it usable with other verifiable data registries/ledgers and verifiable credential client stacks. As a result, important  privacy-protecting capabilities become available to a much broader audience, and the underlying cryptography can evolve without affecting the features above it.

...

• The AnonCreds Specification, managed by the Hyperledger AnonCreds Specification Working Group and with the potential of being submitted to an appropriate Standards organization
• Ledger/Verifiable Data Registry-agnostic, open source code implementations of the AnonCreds specification, suitable for use with Hyperledger Aries and non-Aries agents
• Guidance for creating ledger-specific AnonCreds Methods to write and resolve AnonCreds objects for specific ledgers
• Documentation on AnonCreds suitable for all audiences, from business audiences to cryptographers
• A test suite to verify adherence to the AnonCreds specification and the interoperability of AnonCreds implementations.

Next steps include evolving the existing AnonCreds Rust implementation to be friendlier to VDRs/ledgers other than Indy, wrapping up the v1.0 specification, and gaining compliance with the W3C Verifiable Credentials Data Model Standard.

TOIP Triangle of Trust and Governance Models, Standards for Verifiable Credentials

...

Toip-model - Interactive Model - Layers & Governance

OpenID for Verifiable Presentations - draft 23

This specification defines a mechanism on top of OAuth 2.0 [RFC6749] that enables presentation of Verifiable Credentials as Verifiable Presentations. Verifiable Credentials and Verifiable Presentations can be of any format, including, but not limited to W3C Verifiable Credentials Data Model [VC_DATA], ISO mdoc [ISO.18013-5], IETF SD-JWT VC [I-D.ietf-oauth-sd-jwt-vc], and AnonCreds [Hyperledger.Indy].

OAuth 2.0 [RFC6749] is used as a base protocol as it provides the required rails to build a simple, secure, and developer-friendly Credential presentation layer on top of it. Moreover, implementers can, in a single interface, support Credential presentation and the issuance of Access Tokens for access to APIs based on Verifiable Credentials in the Wallet. OpenID Connect [OpenID.Core] deployments can also extend their implementations using this specification with the ability to transport Verifiable Presentations.

This specification can also be combined with [SIOPv2], if implementers require OpenID Connect features, such as the issuance of Self-Issued ID Tokens [SIOPv2].

Potential Value Opportunities

...