We will release an updated digest, covering the past 6 months, around the new year for our patrons and paypal supporters.
Please do support our creation of this educational content and our continued work mapping out the ecosystem of information surrounding verifiable credentials and decentralized identity.
The mission of the W3C 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.
The course is available on the Open University’s OpenLearn Create platform and is licensed under CC BY-NC-SA 4.0. Upon completion of the course, learners earn a free statement of participation.
NSF is introducing a new program called "Pathways to Enable Open-Source Ecosystems" (POSE). The purpose of the program is to harness the power of open-source development for the creation of new technology solutions to problems of national and societal importance. Many NSF-funded research projects result in publicly accessible, modifiable, and distributable open-sourced software, hardware or data platforms that catalyze further innovation.
The Ford Foundation paper attached provides the references. However, this thread should not be about governance philosophy but rather a focus on human rights as a design principle as we all work on protocols that will drive adoption of W3C VCs and DIDs at Internet scale.
A data NFT represents the copyright (or exclusive license against copyright) for a data asset on the blockchain — we call this the “base IP”. When a user publishes a dataset in OceanOnda V4, they create a new NFT as part of the process. This data NFT is proof of your claim of base IP. Assuming a valid claim, you are entitled to the revenue from that asset, just like a title deed gives you the right to receive rent.
What we've found as a good framework is the concept of "Principal Authority" which comes from the Laws of Agency, which allows us to leverage fiduciary style Laws of Custom to define requirements for practices when digital identity is delegated to others (whether for authorization or for use of data).
I've written up a layman's article (as I am not a lawyer) introducing this topic at:
Spruce, MATTR, and Digital Bazaar have collaborated on creating an interoperability test suite for something we're calling the "Verifiable Driver's License" (temporary name):
The test suite demonstrates that a few things are possible in addition to what mDL provides:
1. The mDL data model can be expressed cleanly using W3C Verifiable Credentials
interoperable specifications for QR-based air-gap cryptographic use cases that we call Universal Resources (aka "UR").
Our UR specifications are designed for the interoperable transmission and storage of a variety of kinds of information, but in particular cryptographic data, and we have an advanced QR and CBOR-based architecture. (For more information on this see URs: An Overview.)
For make it easier to implement our specs we also make available open source reference libraries and demo apps in our repos on Github
[link]The kinds of signature suite definitions that define Linked Data Proofs made strange bedfellows with the in-built mechanisms of JWT, which were hardened and commoditized earlier. This results in a slightly “balkanized” landscape of VC-JWTs that make different concessions to the expectations of JSON-LD-native parsers and systems.
I wanted to share some very recent (experimental and unstable) work we've done to enable Decentralized Identifiers and Verifiable Credentials to assist with the software supply chain.
The key idea is to enable github actions to sign and verify credentials that conform to the W3C Verifiable Credentials standard (which in turn supports various envelope formats including JOSE, COSE and PGP).
In the 17 years i worked at W3C, the formal objections were
(1) "we [the objector] wanted to be on record as saying this but go ahead and publish" (the most common);
(2) we [the objector] have a product, or are about to ship a product, and the feature(s) in this spec would cause problems in the short-term for our product, and that's more important to us than the Web (no-one will ever admit to this but it's not uncommon)
(3) we object to this spec, we prefer another approach, so here's a bunch of fake objections to slow things down because we can't share our actual business strategy
(4) we believe there's a technical problem with this spec, but we didn't notice it over the past four years despite a last call review (this one is actually rare but does happen)
Just a reminder that these "politics" and "other-ing" isn't some weird by product of the "identity community", or DIF, or CCG, or OpenID... it's endemic in any long-lived community composed of human beings.
It's not something you're ever rid of... it's something you manage over time;
This is a friendly reminder that anyone in the community that is doing something interesting that you think the community should know about whether that work is done here in the CCG or elsewhere, can email the chairs with what you want to share and we can get you on the calendar. It's best if you email all 3 chairs.
there are statements like: "Buy our products! We're the best!" (with nothing else that we can learn from) that is frowned upon... but, in general, even if it is a feature in one of your products, chances are that we want to hear about it if it has relevance to how we might interoperate on that feature (or use it to meet a goal of the community).
This major organizational overhaul to the W3C is also happening at a time of unprecedented activity and change for the internet. Will the web support crypto and Web3 industry proposals? How will the web support advertising? What should be the baseline web browser security standards?
"We designed the W3C legal entity in a way that keeps our core unchanged," said Dr. Jeff Jaffe, W3C CEO. "Our values-driven work remains anchored in the royalty-free W3C Patent Policy, and the W3C Process Document where we enshrined dedication to security, privacy, internationalization and web accessibility. W3C and its Members will continue to play a fundamental role in making the web work for billions of people."
[...] I can speak to the work of the DHS SVIP Program and our approach and perspective across our two work-streams that touch upon the two points.
1. Governments “lobbying” for single DID method and Non-Interoperability
* “tantek: concerned to hear that there are governments looking to adopt, with only single implementation methods and non interop, sounds like lobbying may have occurred, … advocating for single-implementation solutions that are centralized wolves in decentralized clothing”
* “<cwilso> +1 to tantek's concern that governments are responding to lobbying attempts on non-interoperable methods”
Now, here's the REAL irony. Mozilla and others are pointing to the URI spec and existing URI schemes as the precedent without recognizing that in in section 9.11 of the DID spec, we specifically compare the DID spec to the *URN spec*, RFC 8141. In fact we deliberately patterned the ABNF for DIDs after the ABNF for URNs—and patterned DID method names after URN namespaces. And we set up a registry for the exactly the same way RFC 8141 establishes a registry of URN namespaces.
Now: guess how many URN namespaces have been registered with IANA?
The motivation for verification relationships in the DID spec stems from the general security recommendation of "use separate keys for separate purposes".
There's a testimonial from UNECE near the bottom. I thought the community might be interested in the white paper from UNECE on VCs and DIDs for cross border trade - https://unece.org/trade/uncefact/guidance-material
The publication of this DID Method specification realizes, in large part, a 4-year quest (or should I say personal mission) to create a platform to Tokenize Every Little Thing (ELT).
The broader generalisation of this question is : "for trust anchors like governments that issue VCs to their constituents, what rules should govern which did:methods they should accept as the *subject* identifier for the VCs they issue?" Are those rules context specific?
I'm not sure of the answer - but it's why did:ion was on my list - as an allowed *subject* of a government issued vc - and as the issuer of trade documents. should I take it off my list pending a bit more maturity (eg that azure service goes out of beta into full production)? or is it safe enough for this use case? if so what others would also be "safe enough"?
My did:tag proposal is, I believe, the only proposed DID Method that addresses the use of email addresses and email as a resolution method
There are quite a number of issues with using email addresses as identifiers, or parts of identifiers, and I'm hoping that discussion and development of the did:tag method will illuminate those issues and potentially find solutions for them.
We have had the same issue... per the did core spec, there are really 2 main key types, in our crypto libraries for the key pair classes themselves, we do our best to support both and handle translation for you:
These VC’s (etc.) will be embedded into the assets (e.g., video, images, documents, etc.) in a tamper-evident manner, so that in addition to the individual VC’s “proof”, any attempt to change the CreativeWork relationships, etc. can also be detected. [..] we have no protection against a malicious actor simply copying the VC from one asset and dropping it into another (and then signing the new setup), because there is nothing that binds the credential to the asset in our case.
This seems more of a feature of the architecture than a threat, as long as you understand that the signing of the anti-tamper mechanism is, by its nature, an attestation about the affinity of that VC to the rest of the PDF, made by that signing authority (and by neither the VC issuer nor the Holder, unless the tamper signature can be independently demonstrated to be either the issuer or holder).
A common example of this is when someone uses a "Power of Attorney," to sign a contract. When they do, they typically sign documents with their own names and an annotation "on behalf of," "for," or "by power of attorney," they don't forge the signature of the one who granted the power of attorney.
Note that this is different than binding multiple credentials together in a Verifiable Presentation (and having the presenter sign the VP). In the VP case, the binding just means "this presenter is authenticating the handing over of these unrelated credentials". Whereas in the linked VC case, the credentials are aware of each other, and the peer or hierarchical relationship is built into the VC itself.
I am excited to share with you today the release of Blockcerts V3. As you may already know the earlier versions of Blockcerts were architected by Kim H. Duffy through Learning Machine and leveraged the Open Badge standard.
* to provide an overview of all existing flavors of credential chaining (What current and new techniques exist or are being researched?)
* to gather the reasons and requirements for credential chaining
* to come up with best practices and create a sort of decision tree that helps map the requirements of the use case with the implementation of credential chaining
* to provide working code with concrete implementations on different chaining variants
* to integrate credential chaining into future versions of the Verifiable Credentials Data Model
If you have a few minutes, I would love some review of what the DIF implementation is doing, and how we can either push it all the way into the LD Proof camp, or all the way into the VC-JWT camp.
as you know we spent quite some time on the text in the VC Data Model v1.1 to differentiate between a credential and a verifiable credential, and to highlight that regardless of the proof format (JWT, LD-Proof etc) the credential is always the same once the proof has been removed.
Therefore the obvious way to me to store any type of VC in a wallet is to store the credential as JSON, along with the proofed VC, then the same wallet will be able to receive any type of proofed VC and store the embedded credential in the same way. I have also been highlighting this model in the DIF PE group, so that the same Presentation Definition can be used by any wallet to select any type of credential, regardless of the proof type.
If the VCs in the cloud are a commitment to a DID instead of a hardware bound key... then their presentation from hardware bound keys achieves the same effect, but if the device is lost, the holder just registers new device bound keys, and no need to re-issue the VCs (but a DID Update operation is required).
Indeed the use case is for so called bearer credentials. The example of a concert ticket mentioned in there is a good one, although the actual bachelor degree example nr 33 is questionable since a degree is not subject independent. That seems to come more from the fact that the degree is used throughout the spec as an example.
This document proposes Verifiable Web Forms -- a new way to provide Verifiable Credentials [VC-DATA-MODEL] to Web Browser via Clipboard. By using Verifiable Web Forms, users can provide third-party verified data with standard user interfaces without typing. The data is also verifiable on the server-side too.
I've made a pass at updating the registry to be more helpful to people and organizations that are not involved in the week-to-week with VCWG or CCG. The update, which adds proof methods, links to specs, implementations, and test suites can be found here:
We design, implement, and evaluate a solution for achieving continuous authorization of HTTP requests exploiting Verifiable Credentials (VCs) and OAuth 2.0. Specifically, we develop a VC issuer that acts as an OAuth 2.0 authorization server, a VC verifier that transparently protects HTTP-based resources, and a VC wallet implemented as a browser extension capable of injecting the necessary authentication data in HTTP requests without needing user intervention.
This evidence could be a test score, a link to an image, video, and/or web page, etc. that demonstrates competency or participation. These specs are working towards aligning with VCs and it was originally thought that this type of evidence would be included as part of the credentialSubject if it existed.
But since VCs already have an evidence property that allows for an array of evidence, it seems to make sense to use that property instead of using a separate property like the one demonstrated above.
This draft Rebooting the Web of Trust 11 paper explores ways in which the Verifiable Credentials data model could be extended to support visual, audio, and physical renderings for Verifiable Credentials.
Typical solutions to this problem require that you put the binary data outside of the VC, if at all possible. This works well for common static images such as logos. It is also possible to split the VC into two VCs... one with the machine-readable data from the issuer (with a digital signature) and one with the image data from any source (without a digital signature, since, if hashlinked, the signature will verify the validity of the image data). That latter approach can be more privacy preserving AND more complex than many might feel is necessary.
We are happy to announce today that we have our first demonstration of cross-vendor interoperability between Danube Tech and Digital Bazaar for the VC Issuer API and VC Verifier API. The test suites test the OAS definition files (which are used to generate the specification):
I think I'm starting to understand how RAR fits into this picture. This decision can be made for us by punting the question to the authorization process entirely. With RAR we can force the user to authorize for the actual subject they are issuing the credential about. Is Alice authorized to issue VCs with claims about did:example:12345? To answer that question Alice asks for a token with the following RAR request
'create:credentials': Grants permission to create credentials 'derive:credentials': Grants permission to derive credentials 'create:presentations': Grants permission to create presentations 'verify:presentations': Grants permission to verify presentations 'exchange:presentations': Grants permission to exchange presentations
So what’s the problem? I can say with full confidence after years of experience building and deploying systems to support parameterized scopes like this that they are fragile, awkward, and lead to insecure corner cases.
Proposal 1: The APIs that use OAS3.0 MUST define securitySchemes per the OAS 3.0 spec. (@OR13 proposal addresses 4)
Proposal 2: The APIs that use OAS3.0 MUST define the use of the Link Header for suite and issuer id discovery (@TallTed 's proposal addressing 1/2/3)
Proposal 3: The APIs that use OAS3.0 MUST define the use of a .well-known JSON resource for conveying supported issuer ids and suites. (@OR13 's. proposal addressing 1/2/3)
TL;DR: chapi.io is a site that helps developers integrate Verifiable Credential issuance, holding, and presentation into their applications. It includes a playground that can issue arbitrary VCs to digital wallets (web and native). It also includes tutorials on how Web Developers can add CHAPI integration to their websites. All you need to try it out is a web browser.
The credential selector is an icon-based selector for all the credentials that the chapi.io playground currently supports issuing. You can now click on an image of the credential you'd like to issue. [...] We have added a permanent resident card from the fictitious Government of Utopia to the list of credentials that can be issued. This credential uses the Citizenship Vocabulary[...]
TL;DR: In an attempt to support the current Jobs for the Future Plugfest, an Open Badge v3.0 example for an Academic Achievement has been added to the chapi.io playground. You can now see what a JFF badge issuance and transfer to a Holder wallet looks like in CHAPI (on mobile and web, on any device that can run a web browser). Images of the flow are attached.
This type of independent review is critically important for U.S. Government entities who are deploying capabilities based on these standards to ensure that the technologies conform to relevant U.S. Federal government standards and requirements, including the Federal Information Security Management Act (FISMA) and National Institute of Technology (NIST) standards for use of cryptography.
Please find attached (and online at the link below) the results of this independent review and the associated cryptography implementation recommendations.
It has a proposal that enables credential issuers to encrypt sensitive parts of credentials in such a way that can only be decrypted by parties tha satisfy the issuer's policy (that was used to encrypt these parts). The blog motivates the need, introduces a high-level architecture, explains how it would work, and discusses some issues that need to be looked into.
Cryptography Review of W3C Verifiable Credentials Data Model (VCDM) and Decentralized Identifiers (DIDs) Standards and Cryptography Implementation Recommendations by David Balenson & Nick Genise
It's largely a view from the US NIST cybersecurity standards, which are used through most of the world, but not everywhere. In any case, it's a valuable perspective that I hope the VC2WG and DIDWG takes into the next stage of the work.
We are happy to announce today that we have our first demonstration of cross-vendor interoperability between Danube Tech and Digital Bazaar for verification regarding the Data Integrity and Ed25519Signature2020 work items:
Now that the DIDComm v2 spec is nearing completion, and there are robust libraries in multiple programming languages, we are starting a user group to share learnings as we put DIDComm into production. We will organize community resources, produce a handbook, foster application-level protocol creation, maintain the didcomm.org website and repo, and recommend best practices.
This document describes a mechanism to transfer digital credentials securely between two devices. Secure credentials may represent a digital key to a hotel room, a digital key to a door lock in a house or a digital key to a car. Devices that share credentials may belong to the same or two different platforms (e.g. iOS and Android). Secure transfer may include one or more write and read operations. Credential transfer needs to be performed securely due to the sensitive nature of the information.
As most of us know, that eventually led to the realization of the many dimensions of decentralization and creation of the excellent "DID Method Rubric" by JoeA, RyanG, and DanielH (with support from a very large cast of characters in this community).
It feels like we're in the early throes of a "Wallet Rubric".
I think what happens is that a first blank node is created for the proof, and since that node has `@container` `@graph`, instead of being able to trace the relationships directly from credential to proof to verification method...
Each proof is being treated as a disjoint subgraph, and the relationship is not being preserved during import… [...]
But I wonder if we might correct this behavior in VC Data Model 2.0, such that RDF representations don't have this odd behavior when imported as labeled property graphs. [...]
The goal of this group is to standardize the way many of us digitally sign Verifiable Credentials. This working group has been about decade in the making (some would say two decades) and is important for achieving things like BBS+ selective disclosure as well as standardizing the way we format Verifiable Credentials before they are digitally signed.
I've instrumented the rdf-canonicalize library so I can inspect the order of execution, and it appears that what differs between my implementation and the Javascript one is the order of the permutations. The spec doesn't say how the permutations should be ordered, and my intuition is that the order does indeed matter - though I'm happy to be corrected if I'm wrong.
So, here is my question(s): - Does the order of the permutations matter? - If so, what order should they be in?
What this means is that it is now possible to not have to depend on one signature format, and instead use multiple to meet different needs. The VC above supports NIST-approved cryptography today, while enabling the advanced use of BBS+ (if an organization would like to use it /before/ it is standardized at IETF), and also enabling protection if a quantum computer were to break both Ed25519 and BBS+... all on the same VC in a fairly compact format.
The TLDR is to assume that we need hard answers as a community, and at the standards level, on crypto agility by 2024, as well as support for the key algorithms as listed above.
Just wanted to update folks here that the C2PA has released version 1.0 of their specification at https://c2pa.org/specifications/specifications/1.0/index.html. As previously mentioned, it includes native support for VC’s for use in identification of actors (be they human, organizations, etc.). Thanks to everyone here for their input on our work and helping us to deliver.
