Awesome-Mirrors/decentralized-id.github.io
1
0
Fork 0
mirror of https://github.com/Decentralized-ID/decentralized-id.github.io.git synced 2024-12-14 10:04:23 -05:00
Code Issues Packages Projects Releases Wiki Activity
1247ba6758
decentralized-id.github.io/_posts/identosphere-dump/open-standards/verifiable-credentials.md
⧉ infominer e32004b49d begin vcs
2022-11-26 20:13:51 -05:00

41 KiB
Raw Blame History

published
false

Verifiable Credentials

Contents

  • Explainer
  • Comparisons with/ other Tech
  • Varieties
    • JSON-LD
    • JSON-LD ZKP BBS+
    • JSON-JWT
    • ZKP-CL - [IIA] Indy Aries AnnonCreds
    • JWP

Explainer

  • Article three - 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.

Comparisons with/ other Tech

Prerequisites

Trinsic CEO Riley Hughes sat down with One World Identity (OWI) CEO Travis Jarae to have a one-on-one conversation about “The Rise & Adoption of Verifiable Credentials”. Below is a short summary

Today, we proudly present another 25+ Proof of Concepts for VC implementation. These use cases are a compilation of the submissions (in no particular order) made by the participants of the Affindi PoCathon 2021.

When you hear the term “VC” or “Verifiable Credential”, think “authenticatable data container” and you’ll be closer to the truth, plus you’ll be more effective in explaining VCs to the next person. [...]

VCs can carry any sort of data payload, and that isn’t just a good thing, it’s 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.

  • All the data is decentralized, meaning there’s no need for a database of student records that could be jeopardized. Alice’s data lives with her.
  • The employer doesn’t need to keep a copy of Alice’s transcript to verify her education.
  • The college doesn’t play intermediary and doesn’t 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.

This architectural overview introduces the capabilities and components of the Azure Active Directory Verifiable Credentials service. For more detailed information on issuance and validation, see

The original #VerifiableCredentials were PKI-based SIM cards and EMV cards. These bind key pairs to individuals, and to signed assertions (account numbers) to deliver provenance, fidelity and proof of possession. https://constellationr.com/blog-news/not-too-much-identity-technology-and-not-too-little

In my recent podcast with Brad Carr of the Institute of International Finance, we discussed how digital identity and verified credentials can support a digital-first world, something that’s extremely relevant amid the current pandemic.

The NHS can now provide you with a digital verifiable credential to prove your vaccination status, securely stored in the NHS app and easily accessible, generating a QR code to prove to airlines and employers that you are fit to fly or work. But this is just the first step in the development of an enabling technology that can bring benefits to many areas of modern life.

This rich verifiable self-sovereign career identity will be the ‘great transformer’ of the global labor market. It will change the way people navigate their careers and livelihoods, and how employers make talent decisions.

A pertinent example of how this can be applied in the corporate world is this example of the Scottish Social Services Council uses them to underpin workforce learning. The BCS describes this as the future of professional development, with many organizations like Siemens using them this way.

To transition fully to the W3C VC standard, Bloom decided to deprecate the proprietary attestation format and adopt the new open VC standard. The transition will fulfill the vision of giving Bloom users complete, secure control of their private data, while allowing interoperability with the rest of the VC ecosystem.

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

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.

VCs are interoperable across many systems and can be used in almost every possible scenario. Here is a list of use-cases where VCs can be used and PoCs developed based on them.

Want to contribute to the World Wide Web Consortium (W3C) Developers Guide for Verifiable Credentials?

We really hope that a diverse audience will be attracted to the Kantara workshop. The reason I say that is - we're very focused, obviously in the work we do around identity, around assurance programs, around really developing what we recommend the part of standards that are used internationally. And then also taking that the next step and making sure that those standards are implemented in the identity products that are available in the field.

^^ technically important and relevant.

Why make the investment then to put the time and effort into ZCAPs when we’ve 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.

learn how to:

  • Set up Azure Blob Storage for storing your Azure AD Verifiable Credentials configuration files.
  • Create and upload your Verifiable Credentials configuration files.
  • Create the verified credential expert card in Azure.
  • Gather credentials and environment details to set up the sample application.
  • Download the sample application code to your local computer.
  • Update the sample application with your verified credential expert card and environment details.
  • Run the sample application and issue your first verified credential expert card.
  • Verify your verified credential expert card.

First we’re going to create a holder Agent, this will be the Agent that receives the membership credential. During their life, the holder will collect many different verifiable credentials. Memberships, ID-cards, even purchasing records.

We’ve been hard at work writing use cases, helping education standards organizations understand and align with VCs, and we’ve been heading towards a model recommendation doc for the community.

A credential is called a verifiable credential when its authenticity can be cryptographically checked by anyone because the credential contains a cryptographic signature by the issuer, and the issuer's public key is well known.

Your Thrivacy wallet allows you to request all your important, personal information that can be used to identify who you are to be created into what we call verified credentials. Then those same verified credentials or VCs can be downloaded and stored in your own personal wallet that is kept inside your cell phone.

  • Open Data Standards (W3C’s DID & VC Standards)
  • Open Tech Standards (Hyperledger Aries, Indy, Ursa)
  • Achieving W3C-Compliance on Aries and Indy

In this webinar, Evernym's Jamie Smith and Andrew Tobin discuss how verifiable credentials and digital wallets can reduce fraud, automate workflows, and transform customer experiences across the travel and hospitality industries.

If you’re already using a secure mechanism to authenticate your users, then setting up OIDC capability isn’t necessary. As we’ve explored, sending credentials using secure DID messaging directly or via a QR code or deep-link is safe, convenient and allows users to obtain their credentials directly.

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.

The primary focus of this blog post is to highlight the different problems that are likely to occur when going down the path of building an authorization system with verifiable credentials. I’ll be sure to keep things at a higher level so that anyone can understand these tradeoffs, but take you through the details that would be thought through by an architect designing the system.

For the first time ever, data from one ecosystem can be instantly authenticated in any other, online or off, without a direct connection to the source.

Azure AD

  • 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.

  • What are Verifiable Credentials?

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

  • Why the Verifiable Credentials Community Should Converge on BBS+

    BBS+ LD-Proofs use JSON-LD schemas, so credentials that use them can have a rich, hierarchical set of attributes. Instead of the heavy-handed mechanism for the encoding and canonicalization of attributes values that we’d imagined for Rich Schemas, they use RDF canonicalization and a hash function. Rather than expanding the credential definition, they discarded it, taking advantage of some properties of BBS+ keys which allow for deterministic expansion.

  • Verifiable Credentials: Mapping to a Generic Policy Terminology

    Why is this useful? When writing policy, you need a succinct model which is clear enough for subsequent interpretation. To do this, you need conceptual buckets to drop things into. Yes, this model is likely to change, but it’s my best and latest crack at it to synthesize the complex world of digital credentials with an abstraction that might be useful to help us align existing solutions while adopting exciting new capabilities.

  • What BBS+ Means For Verifiable Credentials Evernym

    In a recent Evernym blog post, we discussed why BBS+ LD-Proofs are the privacy-preserving VC format that everyone should implement. In this webinar….

  • A brief history of verifiable credential formats, and how a lack of convergence makes scale and interoperability an ongoing challenge
  • How BBS+ Signatures are the breakthrough that combine the best of the JSON-LD and ZKP formats, while still allowing for selective disclosure and non-trackability
  • The path forward: What remains to be done to fully converge on the BBS+ format

Fundamental problem:

  • Why should a verifier trust a credential?

VC marketplace project at DIF is talking about a reputation system for issuers, using VCs

We need to agree on:

  • Machine-readable document (governance framework)
  • URI for a governance framework that we need to agree on

Sterre’s organization (TNO) is developing a software implementation called a “credential catalogue” which is like the yellow pages for verifiable credentials

  • With yellow pages, who publishes it, and will everyone trust it? That brings us full-circle to the first issue

Drummond shared work at the Good Health Pass is tackling this

  • Trust registries
  • Rules engines
  • Governance frameworks

Original question is: how does the verifier know who to trust? Then how do they know which governance framework to trust? Then who governs that list? And how do you trust that? It always comes full-circle

Using DiDs and VCs for verifiable product data in supply chains, leveraging the largest supply chain standard system in the world,

2.5 million users companies, over 6 billion product scans per day

Product data and attestations from a number of various authoritative sources

Leverage DIDs/VCs for distributed data sharing, verification

How does VC Functional Stack compare to #ToIP Stack?

  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.

The meeting started with a presentation of an updated representation of a trust assurance model being promoted by the Trust over IP Foundation’s Governance Stack Working Group.

Given the audience of 8-10 people, we polled the reasons for attending a topic on Trust Assurance and discussed a few gnarly challenges in the space:

  1. An owner of a background check company conveyed challenges with complying with a myriad of governance authority frameworks audited by a myriad of qualified/unqualified auditors looking at a myriad of evidence to render a judgement
  2. The addition of privacy controls (notice and consent) to augment existing marketplace controls due to the specific need in SSI networks: https://kantarainitiative.org/confluence/display/WA/Privacy+as+Expected%3A+UI+Signalling+a+Consent+Gateway+For+Human+Consent
  3. A discussion of the China Civil Code: https://www.dlapiper.com/en/uk/insights/publications/2020/06/new-chinese-civil-code-introduces-greater-protection-of-privacy-rights-and-personal-information/
  4. A need for a civilian clearance credential.

It was a lively conversation for those who attended.

Credentials Exchange - figuring it out

Killer Whale Jello Salad

Slides to complement this document - https://docs.google.com/presentation/d/1t4o6AXclqR7SqhGCbIJKVtYxh4fm_5mGT11MBx9K95c/edit#slide=id.p

Link to the document that the work and documentation is done in:

ReCap & Summary

  • Because what we need is interoperable - issuance - issue-> holder || holder -> verifier some conversation about SIOP - has not been the focus of the discussion.
  • Goal to create a bridge between
  • the W3C CCG / DHS SVIP - VCI-HTTP-API (VHA) in combination with CHAPI protocol and the (VC Request) for issuing credentials.
  • Aries protocols run on top of DIDComm
  • If we agree on a credential format we can exchange across those universes - JSON-LD ZKP BBS+ then we need a protocol to do it - can go between.
  • Orie proposed - that we rather then extend VHA - that the we take a streamlined path with DIDComm as envelop layer - present proof - presentation exchange as a payload including the DIF work presentation, Aries and hopefully alternative to expanding VHA - for holder interactions - since it doesn’t have a holder interactions leverage existing
  • So can be tested with next SVIP - testing.
  • Presentation Exchange and use of DIDComm and for sake of interop testing pave a narrow path - and expand in future interoperability efforts.
  • Summary: DIDComm, Presentation request, presentation exchange, present proof format using JSON-LD ZKP with BBS+
  • Potentially quickly spinning up a working group at DIF - Decision was to nest within the Credentials and Claims group at DIF

Result:

Current ssi solutions are geared to allow the issuance of a specific verifiable credential by a single issuer. There are use cases that would benefit from enabling the aggregation of multiple credentials into a single credential so that the holder can’t delete sub credentials of the aggregated credential. Is it possible to implement such an aggregation while allowing the holder to present only certain sub credentials of the aggregated credential as required?

An example use case is the issuance of credit history credentials. If each creditor issues separate credentials, the holder can delete the “bad” credentials and only present the “good” credentials. By enabling all creditors to contribute separately to a single credit history credential, the holder must either delete/present the whole credential.

A overview of the GS1 Prototype effort for Q1-2 2021.

There was some feedback that  BBS, PE, and DIDCommV2 are possible points of convergence.

Also comments that WACI Bloom may play a part in convergence

General Framework on how to think of VCs for Assets including leveraging GS1 and other vocabularies in the traceability vocab.

Requirements and Opportunities that block adoption of VCs in Supply chains Current Status of work and Steps Forward

Verifiable credentials, authentication, picos, pico-based application

The slides are at https://bruceatbyu.com/s/HRDDSiiw32

An implementation of anonymous credentials using generic ZKPs, in our case, SNARKs. This gives a lot of flexibility as it replaces developing new, optimized “island” cryptography through generic tools and an “engineering” approach; however, at the cost of significant performance challenges compared to CL/BBS+.

So far, there has not been a cryptographic review on the code.

The major limitation is performance; while prover time is currently ~1s on a Macbook with 12 cores, the CPU and memory requirements are likely too high for general purpose smartphones and IoT devices. STARKs could help, but the larger proof size may be inhibiting.

The implementation covers private holder binding (potentially even using secure hardware for the binding key), private delegation (from the perspective of the holder), revocation, and range proofs for expiration.

A new feature that we implemented and that is probably difficult to achieve without generic ZKPs comprise, e.g., the “Leather Trousers” proof that can be used to demonstrate that an x and y coordinate are inside or outside a polygon defined by the verifier. It is also very easy to add further features that output a computation on the attributes, such as multiplying or adding different attributes.

The presentation slides and also the code will be made public by the end of July at https://github.com/MatthiasBabel/heimdall. The implementation is based on SNARKs, using the libraries https://github.com/iden3/circom and https://github.com/iden3/snarkjs.

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.

Identity Binding, Credential Binding, when they go high, we go low?

What levels of identity enrolment and binding of credential to identity are required for “good” SSI

Is (Using US centric NIST 800.63) IAL 1 sufficient, can self-attestation of identity and of a claim (e.g I am vaccinated) work.

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.

If the risk level is low lower levels of reputation may be acceptable.

Definition of Trust - Sufficient information to leap into the unknown

A certificate must meet 4-criteria of definition         Who issued it/ Who was it issued to/Has it been changed / Has it been revoked

So long as these attributes are clear the verifier can interrogate and make a decision based on the Attribution and Reputation of the issuer.

Concept of what is preferred by the verifier.

For the verifier it is based on risk, it is never going to be based on perfect information.

But it is most important to make sure that you are binding the credential to the correct identity

So what is the requirement for onboarding or enrolling an identity?

Link Slides: https://docs.google.com/presentation/d/1VyxmWan3qbxynxhKvw1CHhWZINiPRF9gjeqSCSDh1MY/edit?usp=sharing

TLDR:

We discussed how the Blockchain Advocacy Coalition’s sponsorship of AB 2004 pushed verifiable credentials into mainstream political discourse and how companies can help us shape public policy and government pilot programs of Verifiable Credential technology.

We are planning on working with legislators to introduce a bill that creates a California Trust Framework and lays the groundwork for use of the technology in the public and private sector.

Our coalition is funded by the companies who participate in it. If you are interested in being part of shaping legislation in California the will build the market for your tools and services please be in touch.  Remember what happens in California shapes what happens nationally and has a global impact.

Ally Medina - head of the Blockchain Advocacy Coalition - ally@blockadvocacy.org

Kaliya Young Chair of the Verifiable Credentials Policy Committee - Kaliya@identitywoman.net

Paper-based Verifiable Credentials allow us to have a low-tech solution for adopting VC's in situations where access to a phone cannot be guaranteed. This presentation looks at how this solution can be used to aid with the distribution of Vaccine Credentials.

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

Verifiable credentials aren’t just P2P.

  • [...] 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.
  • 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.

  • The Flavors of Verifiable Credentials

is complete and published on the Linux Foundation Public Health Blog.

The differences between the different flavors of VCs for technically inclined readers. It elaborated on the differences between JSON and JSON-LD and articulated differences between the two different implementations of ZKP style credentials. The ‘Journey of a VC’ section articulated all steps where VCs are active and highlighted the differences in how different VC flavors ’behave’.

Azure AD Verifiable Credentials

  • Announcing Azure AD Verifiable Credentials MS ID Blog

    We started on a journey with the open standards community to empower everyone to own and control their own identity. I’m thrilled to share that we’ve achieved a major milestone in making this vision real. Today we’re announcing that the public preview for Azure AD verifiable credentials is now available: organizations can empower users to control credentials that manage access to their information.

  • Azure AD Verifiable Credentials Entering Public Preview Kuppinger Cole

    Microsoft announced on April 5, 2020 that its Azure AD Verifiable Credentials is now in public preview. This solution enables organizations to design and issue verifiable credentials to their users, be it enterprises issuing employment credentials to their employees, universities enrolling students or issuing diplomas, governments issuing passports, ID cards, and countless other uses.

  • Azure Active Directory VCs - preview introduction Daniel Krzyczkowski

    Once I discovered that documentation is available, I decided to create a small proof of concept. I have configured Verifiable Credentials accordingly to details in the documentation I have an existing Azure AD B2C tenant so it was much easier because users have to sign in first before they can be issued a verifiable credential.

  • Verifiable Credentials go mainstream at Identiverse 2022 Biometric Update

Verifiable Credentials was a breakthrough topic and it’s clearly on the path to mainstream adoption. Main sessions by Microsoft and Avast showcased their application of VCs in the IAM landscape, showing VCs aren’t the future anymore–they are the present.

VCs need Threat Modeling

Another pre-read recommendation for @identiverse: the @openid for Verifiable Credentials Whitepaper.  It is a great high level explanation of decentralized benefits and use cases, both @kristinayasuda & @tlodderstedt contributed! OpenID for Verifiable Credentials

It also seems to lack any sections about threat modelling and possible risks, making it hard to trust since risks are not directly and clearly addressed.

I agree. We thread model while we are designing the protocol, we also need to add it to the spec. Please note: we build on existing work. There is an extensive thread model for OAuth and countermeasures that we built on (datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics. Feel free to contribute.