decentralized-id.github.io/_posts/web-standards/w3c/working-groups/vc-wg/2020-01-10-verifiable-credentials.md
⧉ infominer c232997115 cleanup
2022-12-12 06:49:53 -05:00

39 KiB
Raw Blame History

date title description excerpt tags categories permalink header redirect_from last_modified_at
2020-01-10 Verifiable Credentials a standard way to express credentials on the Web in a way that is cryptographically secure, privacy respecting, and machine-verifiable. Verifiable credentials (VCs) are the electronic equivalent of the physical credentials that we all possess today, such as: plastic cards, passports, driving licenses, qualifications and awards, etc. The data model for verifiable credentials is a World Wide Web Consortium Recommendation, "Verifiable Credentials Data Model 1.0 - Expressing verifiable information on the Web" published 19 November 2019.
W3C
Verifiable Credentials
Credentials Community Group
VC-WG
JSON-LD
OAuth
FIDO
Claims and Credentials WG
Web Standards
web-standards/w3c/wg/vc/verifiable-credentials/
image caption teaser
/images/verifiable-credentials_head.webp [Verifiable Credentials Data Model](https://www.w3.org/TR/vc-data-model/) /images/verifiable-credentials-teaser.webp
web-standards/w3c/vc-wg/verifiable-credentials/
specs-standards/verifiable-credentials/
web-standards/verifiable-credentials/
specs-standards/verifiable credentials/
2022-12-12

Verifiable credentials (VCs) are the electronic equivalent of the physical credentials that we all possess today, such as: plastic cards, passports, driving licences, qualifications and awards, etc. The data model for verifiable credentials is a World Wide Web Consortium Recommendation, "Verifiable Credentials Data Model 1.0 - Expressing verifiable information on the Web" published 19 November 2019. - Wikipedia

Specification

Explainer

IIW26 Primer On DIDs and VCs

A new type of globally resolvable, cryptographically-verifiable identifier, registered directly on a distributed ledger (aka Blockchain)

  • A Gentle Introduction to Verifiable Credentials

    But while digital records are nothing new, todays credentials come with certain cryptographic superpowers that make them tamperproof, secure, and verifiable. Whereas a simple digital copy of a car title can easily be edited, a verifiable digital credential is one that has been issued by a trusted authority for, and only for, its holder.

  • A Verifiable Credentials Primer

    NOTE: "Verifiable Claims" are now known as "Verifiable Credentials". The W3C Verifiable Claims Working Group's experience with using the term "Verifiable Claims" demonstrated that it led to confusion in the marketplace. The group has since found consensus in shifting to use the term "Verifiable Credentials", which contain "Claims".

  • Verifiable Credentials 101 for SSI - Tyler Ruff - Webinar 11

    Tyler Ruff, product manager at Evernym, will be our next guest to walk us through Verifiable Credentials in the context of Self-Sovereign Identity. He will cover how they are created, issued and shared, as well as cover some common technical questions.

  • Verifiable Credentials—A Quick Overview (VonX)

    The following is a brief overview of the technology underlying SafeEntryBC—Verifiable Credentials. In reading this, think of the process you went through to get an official government document, like a drivers license.

  • Verifiable Credentials: What They Are, Why They Matter (Hackernoon)

    From permanent resident cards to anonymous payments to automatic notarization, verifiable credentials and DIDs are a technology whose time has arrived. Use cases are currently being piloted; many will surface in coming months and years. Security on the internet as we know it may be broken, but it is not beyond saving. A touch of the cryptographic wand, and we'll be able to repair trust once more.

  • Understand Verifiable Cresidentials in 10 Minutes

    This article is a soft introduction into Verifiable Credentials and the potential use cases for organizations, businesses and government institutions and creating new levels of trust for individuals and the services/institutions they use.

  • What are Verifiable Credentials
  • How W3C Verifiable Credentials (VC) Work: Part 1 Issuance

    When an issuer creates a verifiable credential, it contains following information

    • Who has issued DID of the Issuer
    • To whom it is issued User Identifier
    • Attributes of the credential Details of the credential being Issued
    • When it is Issued Date of issuance
    • Credential proof with Issuer signature that makes it tamper evident
    • Revocation details
  • The Role of Witness Organizations in Verifiable Credentials

    The basis is that not every source of a verifiable credential has an interest in issuing verifiable credentials and that it is not only logical but beneficial to the ecosystem of trust that witness organizations will issue on behalf of these sources.

  • An introductory dive into VCs (verifiable credentials) HackerNoon

    Verifiable Credentials heavily utilize Decentralized Identifiers to identify people, organizations, and things and to achieve a number of security and privacy-protecting guarantees. They are issued and cryptographically signed documents, intended to be understood by computers rather than people.

  • How Does a Verifier Know the Credential is Yours? Evernym

    A link secret is a large random number, wrapped in a way that allows the holder to prove that they know the secret.

  • Introduction to Verifiable Credentials Ubisecure

    The Verifiable Credentials specification is quite new, and many pieces that are required to create interoperable solutions are still incomplete or missing at time of writing. However, there is significant momentum around verifiable credentials (VCs). This is partly attributed to VCs being part of the solution for blockchain-based decentralised identity.

  • 8 Reasons to use Verifiable Credentials Affinidi

    VCs are interoperable across many systems and can be used in almost every possible scenario.

  • What are Verifiable Credentials in 3 Minutes Affinidi (video)
  • The VC Lifecycle Credential Master

    In 1956 the switch to consistent shipping containers began, and it changed the physical world profoundly; the switch to consistent, authenticatable digital data containers will do the same for cyberspace.

  • Verifiable Credentials Arent Credentials. And Theyre Not Verifiable In the Way You Might Think Timothy Ruff

    think “authenticatable data container” [...]

    VCs can carry any sort of data payload, and that isnt just a good thing, its a great one. Part two of my container series covers how such fluid data portability could economically affect cyberspace to a degree comparable to how shipping containers affected global trade.

  • Verifiable credentials are key to the future of online privacy HelpNetSecurity
    • All the data is decentralized, meaning theres no need for a database of student records that could be jeopardized. Alices data lives with her.
    • The employer doesnt need to keep a copy of Alices transcript to verify her education.
    • The college doesnt play intermediary and doesnt have access to the list of organizations Alice shares her data with. Other parties have no way of correlating this data as each exchange is private and unique.
    • If desired, Alice could pick and choose what she wants to share. She could prove her degree without sharing her date of graduation or GPA, for example.
  • What are Verifiable Credentials?

    At the most basic level, verifiable credentials, or VC in short, are tamper-proof credentials that can be verified cryptographically.

  • Self Attested vs Chain of Custody - assurance levels in data provenance in VCs by Stew Whitman & Alka Lachhwani

    There are two important factors in establishing “truth” or the trustworthiness of the information. Attributional and Reputational. You need to have both to have trust.

    Digital needs higher level of attestation because it is easier to forge and easier to propagate that forgery.

  • VerifiableCredential.io

    Learn about verifiable credentials, then head to the playground to view examples, explore multiple use-cases and start using them.

  • Do I Need a Verifiable Credential? RSA
  • How a combination of Federated identity and Verifiable Credentials can help with Customer onboarding Pranav Kirtani

    Before we dive into how Federated systems like OIDC and SAML along with Verifiable Credentials (VC) can help improve customer onboarding to your application, let us first understand what are the current methods being used for onboarding.

Comparisons with other Tech

  • Compare and Contrast: OpenBadges vs Verifiable Credentials Affinidi

    As we move towards a world of digital identity, many ways of sharing and verifying Personally Identifiable Information are emerging. Two such modes that well talk about today are Open Badges and Verifiable Credentials.

  • Non-Fungible Tokens (NFTs) vs Verifiable Credentials (VCs) Affinidi

    A common thread that connects both NFTs and VCs is that they leverage the potential benefits of the digital world to give users more security, flexibility, and freedom to monetize.

  • ERC-721 Non-Fungible Token Standard on Ethereum vs. VCs on Hyperledger Indy Michael Herman

    When are Hyperledger Indy/Sovrin VCs better than Ethereum smart contracts for NFEs/NFTs (non-fungible entities/tokens)?

    It seems obvious but I don't have a detailed/worked out answer.  One project I'm associated with wants to use the ERC-721 Non-Fungible Token Standard on Ethereum but I believe VCs are a better route to take. Part of the desire to stay on Ethereum is there is quite a vibrant NFT community on Ethereum and lots of different EC-721 tokens.

  • Compare and Contrast — IRMA vs Verifiable Credentials
  • Could an NFT be a VC? by Grace Rachmany

    Case discussed: A group of villages in Africa using a cryptocurrency platform for alternative currencies. Different organizations issue the coins under different circumstances. When you accept a currency, you want to know who is the issuer. The Red Cross might be more or less trusted than the local leader or agricultural cooperative as the issuer of a currency that is supposedly equivalent to a shilling.

    What types of tech could be used for this?

    • Multiple currencies on the blockchains
    • Certifications in the form of some kind of NFT issued by the issuer.
    • Limited supply tokens or NFTs that are “expired” when you use them
    • Open Credential Publisher framework was suggested
    • VCs are generally authorizations associated with a person, so maybe a person could have the VC and show their credit rating in some way while they are making a transaction
    • Similarly maybe the VC belongs to the organization that is issuing the coin, proving its reputation over time.
  • How does VC Functional Stack compare to #ToIP Stack? @rufftimo
    1. ToIP Layers 2 & 3 compare to Functional Layer 2
    2. ToIP Layer 4 compares to Functional Layers 3 & 4 (horizontal layer for VC Management, vertical layer for Applications)
    3. Functional stack doesn't require #blockchain
    4. Functional Stack doesn't detail steps for trust or verification; ToIP Stack doesn't separate management or storage
    5. Functional Stack clarifies functions, roles, and potential business models; ToIP stack clarifies trust & security They are complementary, not contradictory.
  • What are VCs similar to? Michael Herman (Trusted Digital Web) (Monday, 23 August)

    The chip in your e-passport is the analogy Ive been most successful with
    An issuer gives it to you.
    You carry it around and show to whom you choose
    The verifier can check its integrity without contacting the issuer
    “A VC is like the chip in your passport - bit for any document type”
    So far the best analogy Ive found.  Policy makers say “ah, I see”…

  • Hygiene for a computing pandemic

    This episode of FOSS and Crafts features Christopher Lemmer Webber discussing the object capability security approach. Its a generalization not specific to VCs, continuing from the conversation on the CCG mailinglist, Hygiene for a computing pandemic: separation of VCs and ocaps/zcaps, we shared last month. The podcast show-notes include an epic list of references supporting the discussion.

  • Re: The dangers of using VCs as permission tokens (was: PROPOSALs for VC HTTP API call on 2021-06-22) Manu Sporny

    On 6/24/21 12:35 PM, Kyle Den Hartog wrote:

    Agreed, when it comes to the number of checks that occur it's much greater because of the delegation. With that in mind, looking at the semantics only of the system VCs in my opinion weren't optimally designed for permission tokens. This difference between the two requires that an implementation that wants to support both claims tokens and permissions tokens has to grapple with the different mental model that arise when trying to stuff these things together. This introduces additional complexity. Additionally it leads to weird statements that are being made where it's difficult to tell if the VC is behaving like a claims token or a permissions token.

    Yes, exactly this. Exactly what Kyle states above is the reason why it's so complicated (and thus dangerous) to use VCs as permissions tokens.

    This is one of the primary reasons that we separated out the Authorization Capabilities work from the Verifiable Credentials work. Things get really complicated when you start mixing authz/authn/claims/permissions into a Verifiable Credential. Just because you can do it doesn't mean you should.

    https://kyledenhartog.com/example-authz-with-VCs/

  • Comparing VCs to ZCAP-LD Kyle Den Hartog

    Why make the investment then to put the time and effort into ZCAPs when weve already got VCs? Simply put because security is hard and trying to push square pegs into round holes often times leads to bugs which are elevated to mission critical authentication/authorization bypass vulnerabilities. By designing around a fit for purpose data model with a well defined problem being solved it allows for us to be much more precise about where we believe extensibility is important versus where normative statements should be made to simplify the processing of the data models. By extension this leads to a simpler security model and likely a much more robust design with fewer vulnerabilities.

  • Re: VCs - zCaps / OCap a Discussion Dave Longley 12/5

    TL; DR: My current view is that the main confusion here may be over the difference between VCs and LD Proofs, not VCs and ZCAPs. VCs are not a generalized container for attaching a cryptographic proof to a document. That's what LD proofs (or JOSE style proofs) are for. VCs use LD proofs (or JOSE style proofs) to attach an assertion proof to a document that specifically models statements made by an issuer about some subject, which is therefore inherently about the identity of that subject.

Development

Literature

  • VC Spec Enhancement Proposal Sam Smith

    the VC standard appears to be an adoption vector for Linked Data, not the other way around. My overriding interest is that the concept of a VC as a securely attributable statement is a very powerful and attractive one and therefore should be widely adopted. We should therefore be picking the best technologies that best support broad VC adoption, not the other way around.

  • Verifiable Credential Exchange

    Multi-source identity (MSI) depends on issuing, exchanging, and verifying digital credentials. The specification for verifiable credentials is being formulated by the World Wide Web Consortiums Verifiable Credentials Working Group. Verifiable credentials provide a standard way to express credentials in a way that is cryptographically secure, privacy respecting, and automatically verifiable.

  • Full-text Search for Verifiable Credential Metadata on Distributed Ledgers

    The proposed solution is able to find credential types based on textual input from the user by using a full-text search engine and maintaining a local copy of the ledger. Thus, we do not need to rely on information about credentials coming from a very large candidate pool of third parties we would need to trust, such as the website of a company displaying its own identifier and a list of issued credentials. We have also proven the feasiblity of the concept by implementing and evaluating a prototype of the full-text credential metadata search service.

  • Enabling Decentralised Identifiers and Verifiable Credentials for Constrained IoT Devices using OAuth-based Delegation

    Abstract—Decentralised identifiers (DIDs) and verifiable credentials (VCs) are upcoming standards for self-sovereign privacypreserving identifiers and authorisation, respectively. This focus on privacy can help improve many services and open up new business models, but using DIDs and VCs directly on constrained IoT devices can be problematic due to the management and resource overhead. This paper presents an OAuth-based method to delegate the processing and access policy management to the Authorisation Server thus allowing also systems with constrained IoT devices to benefit from DIDs and VCs.

  • Distributed-Ledger-based Authentication with Decentralized Identifiers and Verifiable Credentials
     Authentication with username and password is becoming an inconvenient process for the user. End users typically have little control over their personal privacy, and data breaches effecting millions of users have already happened several times. We have implemented a proof of concept decentralized OpenID Connect Provider by marrying it with Self-Sovereign Identity, which gives users the freedom to choose from a very large pool of identity providers instead of just a select few corporations, thus enabling the democratization of the highly centralized digital identity landscape. Furthermore, we propose a verifiable credential powered decentralized Public Key Infrastructure using distributed ledger technologies, which creates a straightforward and verifiable way for retrieving digital certificates. 
    
  • Addition of Proof Request/Response to a formal Verifiable Credentials specification

    The W3C Verifiable Credentials (hereafter VC) specification does not currently outline how credential data should be requested by a Verifier. This document outlines the approach taken at Workday and proposes it as an addition or companion to the VC spec.

    At RWoT we wish to present our approach in order to get community feedback and consensus. Workday recently announced our credentialing platform and will shortly begin to issue credentials within our market verticals. We fully intend to support the community standards around credentialing and therefore wish to drive consensus in the community on a simple, standard approach for requesting and sharing VCs between a holder and verifier.

  • Verifiable Credentials (DID Credential Flows) : Technical Overview

    In the perspective of W3C specification, verifiable credential (VC) doesnt rely on DID specification. (i.e, The “id” property used in VC shouldnt be necessarily a DID.) However, in its real implementations, it might be expected that verifiable credentials will resolve DIDs with consistent decentralized manners and technologies. Then, in this post, we also assume that DID is used with verifiable credentials.

    In order to explain things plainly, Ill include not only VC flows, but also other parts of flows, such as, DID flows or OpenID compliant flows.

Working Groups

Verifiable Claims Working Group

  • W3C Verifiable Claims Working Group
  • Verifiable Credentials Data Model 1.0

    Credentials are a part of our daily lives; driver's licenses are used to assert that we are capable of operating a motor vehicle, university degrees can be used to assert our level of education, and government-issued passports enable us to travel between countries. This specification provides a mechanism to express these sorts of credentials on the Web in a way that is cryptographically secure, privacy respecting, and machine-verifiable.

  • Verifiable Credentials Implementation Guidelines 1.0

    This guide provides some examples and resources for implementing protocols which make use of verifiable credentials, beyond those available in the core specification.

  • W3C Verifiable Claims Working Group Test Suite
  • Verifiable Credentials Use Cases

    This document does NOT attempt to define an architecture for the support of Verifiable Claims. Instead it expresses the sorts of needs that real users have that could be addressed through support for some sort of self-sovereign claim environment. It attempts to use terminology that is consistent with the other deliverables of the Verifiable Claims Working Group (you can see the relevant terms in Appendix A).

Credentials Community Group

  • Credentials Community GroupWebsiteMail archive

    The mission of the Credentials Community Group is to explore the creation, storage, presentation, verification, and user control of credentials. We focus on a verifiable credential (a set of claims) created by an issuer about a subject—a person, group, or thing—and seek solutions inclusive of approaches such as: self-sovereign identity; presentation of proofs by the bearer; data minimization; and centralized, federated, and decentralized registry and identity systems. Our tasks include drafting and incubating Internet specifications for further standardization and prototyping and testing reference implementations.

  • w3c-ccg/vc-extension-registry REGISTRY: The Verifiable Credentials Extension Registry - w3c-ccg/vc-extension-registry
  • w3c-ccg/edu_occ_verifiable_credentials WORK ITEM: Drafts and Ideas of Educational and Occupational Verifiable Credentials - w3c-ccg/edu_occ_verifiable_credentials
  • w3c-ccg/vc-examples WORK ITEM: Verifiable Credentials Examples.

Verifiable Credentials Extension Registry

3.1 Proof Methods

This table summarizes the Proof Method specifications currently in development. The table lists the method name, associated specification, authors, stability of the specification, and conformance test suite (if applicable).

3.2 Status Methods

Claims and Credentials Working Group

Claims and Credentials Working Group - Decentralized Identity Foundation

  • 2019 JSON-LD Signature Suite
  • presentation-exchange

    Specification that codifies an inter-related pair of data formats for defining proof presentations (Presentation Definition) and subsequent proof submissions (Presentation Submission)

  • presentation-request

    Requirements Analysis and Protocol Design for a VC Presentation Request Format

  • Credential Manifest
    • Explainer

      Creating trust between DIDs and gaining access to products, services, and systems with DIDs requires the acquisition, generation, and inspection of credentials (DID-signed data objects).

  • Specification - GitHub

    The VC_DATA_MODEL specifies the models used for Verifiable Credentials and Verifiable Presentations, and explains the relationships between three parties: issuer, holder, and verifier. A critical piece of infrastructure out of the scope of those specifications is the Credential Schema.

Interoperability

  • Verifiable Credentials Specification Relationships (ANN)

    diagrams and documentation on the relationship of verfiable credential specifications

    The current release contains some of the most core specifications and their related specs in a diagram. It does not yet address some of the items especially under DIF work groups for secure data storage, SIOP, Sidetree etc.

![]({{ site.baseurl }}/images/VC-spec-map.webp)

Distributed ID Learning Path by Christina Yasuda (based on above spec map)

Use Case

User Experience

Critique

Thread: VCs need Threat Modeling