decentralized-id.github.io/_posts/identosphere-dump/organizations/CCGWGDigest.md

---
published: false
---

# CCGWGDigest

## Credentials Community Group - Digest july 2021 - july 2022

* [https://www.w3.org/community/credentials/](https://www.w3.org/community/credentials/)

* [https://lists.w3.org/Archives/Public/public-credentials/](https://lists.w3.org/Archives/Public/public-credentials/)

## Decentralization

* [New Badged Open Course: Decentralising Education Using Blockchain Technology](https://lists.w3.org/Archives/Public/public-credentials/2021Oct/0044.html)

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.

* [You can view the course here](https://www.open.edu/openlearncreate/course/view.php?id%3D7981). Your feedback is very welcome.

* [New article about decentralized protocols to rule the world...](https://lists.w3.org/Archives/Public/public-credentials/2021Dec/0105.html)

* [Great Protocol Politics](https://foreignpolicy.com/2021/12/11/bitcoin-ethereum-cryptocurrency-web3-great-protocol-politics/) - The 21st century doesn’t belong to China, the United States, or Silicon Valley. It belongs to the internet.

## Funding

* [FYI on National Science Foundation (NSF) Funding Opportunity: Pathways to Enable Open-Source Ecosystems program](https://lists.w3.org/Archives/Public/public-credentials/2022Feb/0142.html)

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.

* [https://beta.nsf.gov/funding/opportunities/pathways-enable-open-source-ecosystems-pose](https://beta.nsf.gov/funding/opportunities/pathways-enable-open-source-ecosystems-pose)

## Human Rights

* [What Companies Can Do Now to Protect Digital Rights In A Post-Roe World](https://lists.w3.org/Archives/Public/public-credentials/2022Jun/0046.html)

Good topic for CCG discussion and reading on the implications of a lot of

the tech we are working on:

* [What Companies Can Do Now to Protect Digital Rights In A Post-Roe World | Electronic Frontier Foundation](https://www.eff.org/deeplinks/2022/05/what-companies-can-do-now-protect-digital-rights-post-roe-world)

* [Human rights perspective on W3C and IETF protocol interaction](https://lists.w3.org/Archives/Public/public-credentials/2022Jan/0014.html) Adrian Gropper (Wednesday, 5 January)

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.

* [https://redecentralize.org/redigest/2021/08/](https://redecentralize.org/redigest/2021/08/) says: *Human rights are not a bug*

## NFT

* [New twist on Verifiable Capability Authorizations: Data NFTs in the Ocean Protocol V4](https://lists.w3.org/Archives/Public/public-credentials/2022Apr/0069.html) Michael Herman (Trusted Digital Web) (Saturday, 9 April)

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.

* [China is using #blockchain technology to manage #prisoners as if each #prisoner was an #NFT](https://lists.w3.org/Archives/Public/public-credentials/2021Dec/0147.html) Michael Herman (Trusted Digital Web) (Sunday, 26 December)

China is using #blockchain technology to manage #prisoners as if each #prisoner was an #NFT/token on the blockchain...

* [https://www.taiwannews.com.tw/en/news/4384071](https://www.taiwannews.com.tw/en/news/4384071)

## Legal Identification

* [Principal Authority – new article on Wyoming law defining Digital Identity](https://lists.w3.org/Archives/Public/public-credentials/2021Sep/0083.html) Christopher Allen (Thursday, 16 September)

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:

* [https://www.blockchaincommons.com/articles/Principal-Authority/](https://www.blockchaincommons.com/articles/Principal-Authority/)

* [Verifiable Driver's Licenses and ISO-18013-5 (mDL)](https://lists.w3.org/Archives/Public/public-credentials/2021Nov/0105.html) Manu Sporny (Monday, 29 November)

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](http://w3id.org/vdl/interop-reports) 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

* ["Apple launches the first driver’s license and state ID in Wallet with Arizona”](https://lists.w3.org/Archives/Public/public-credentials/2022Mar/0231.html) Liam McCarty (Wednesday, 23 March)

It’s sad and frustrating that this isn’t based on verifiable credentials… it appears vendor lock in is going to be hard to prevent.

For anyone who missed the November coverage about this, here’s a pretty outrageous CNBC article: "[Apple is sticking taxpayers with part of the bill for rollout of tech giant's digital ID card](https://www.cnbc.com/2021/11/14/apple-sticking-taxpayers-with-part-of-the-bill-for-digital-id-rollout.html)”

* [On why revocation is important...](https://lists.w3.org/Archives/Public/public-credentials/2022May/0052.html) Mike Prorock (Tuesday, 24 May)
  >[https://arstechnica.com/information-technology/2022/05/digital-drivers-license-used-by-4m-australians-is-a-snap-to-forge/](https://arstechnica.com/information-technology/2022/05/digital-drivers-license-used-by-4m-australians-is-a-snap-to-forge/)

Yikes!

For those that didn't read the article, the TL;DR is:

Tough to forge digital driver’s license is… easy to forge... 4 million mobile driver's licenses in NSW Australia compromised in an unrecoverable way.

## Code

* [re: RAR resources?](https://lists.w3.org/Archives/Public/public-credentials/2021Jul/0083.html) Justin Richer (Monday, 12 July)

* [RAR has been implemented and is available in Authlete (and supporting libraries):](https://www.authlete.com/developers/relnotes/2.2.8/)

* [And in Connect2ID (and supporting libraries)](https://connect2id.com/blog/connect2id-server-12):

I know there are others out there, too, but these I’ve worked with.

* [New Swift Library for Optimized QR-Code Generation](https://lists.w3.org/Archives/Public/public-credentials/2021Aug/0381.html) Christopher Allen (Monday, 30 August)

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](https://github.com/BlockchainCommons/crypto-commons/blob/master/Docs/ur-1-overview.md)

For make it easier to implement our specs we also make available open source reference libraries and demo apps in [our repos on Github](https://github.com/BlockchainCommons)

* [DIF Grant #1: JWS Test Suite .. with specific references to the JSON-JSON-LD Divide](https://lists.w3.org/Archives/Public/public-credentials/2021Aug/0356.html) Michael Herman (Trusted Digital Web) (Monday, 23 August)

* [[link](https://link.medium.com/a0416tjJXib)]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.

* [#didlang Language 0.2, a new language for working with DID Identifiers, DID Documents, DID Agents, and DID Objects](https://lists.w3.org/Archives/Public/public-credentials/2022Jan/0021.html) Michael Herman (Trusted Digital Web) (Wednesday, 5 January)

...with new capabilities for coercing the Agent serviceEndpoint selector and Agent interface method selector ([13 minutes](https://youtu.be/bJBzrPnpJVo).

* [DIDs and Vanilla JWS with GitHub Actions](https://lists.w3.org/Archives/Public/public-credentials/2022Apr/0099.html) Orie Steele (Monday, 18 April)

I wanted to share another DID Web + JOSE + GitHub demo:

- [https://github.com/OR13/signor](https://github.com/OR13/signor)
- [https://github.com/OR13/jose-actions](https://github.com/OR13/jose-actions)

TLDR - JWS linked to DIDs from a Github Action [...] this will also work for VCs.

* [GitHub DIDs & VCs for Supply Chain Traceability](https://lists.w3.org/Archives/Public/public-credentials/2022Mar/0027.html) Orie Steele (Monday, 7 March)

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.

- [](https://github.com/transmute-industries/verifiable-actions)[https://github.com/transmute-industries/verifiable-actions](https://github.com/transmute-industries/verifiable-actions)
- [https://github.com/transmute-industries/public-credential-registry-template](https://github.com/transmute-industries/public-credential-registry-template)

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

* [GitHub Integrations for securing Container Registries with Decentralized Identifiers & Verifiable Credentials](https://lists.w3.org/Archives/Public/public-credentials/2022Mar/0157.html)

I wanted to share some updates I made to the github action we created for working with DIDs and VCs in GitHub Workflows.

* [https://github.com/transmute-industries/public-credential-registry-template/blob/main/docs/public-container-registry.md](https://github.com/transmute-industries/public-credential-registry-template/blob/main/docs/public-container-registry.md)

* [...] TLDR:

- Creating Container Revision VCs with DID Web in a GitHub Action
- Uploading the VC-JWT for the signed revision as a label to GitHub Container Registry
- Pulling the latest container registry tag and checking the vc for the revision.

## Standardization

* [FYI: What makes a standard ‘world class’?](https://lists.w3.org/Archives/Public/public-credentials/2021Aug/0213.html) Michael Herman (Trusted Digital Web) (Saturday, 14 August)

*   A world class standard should have well-defined objectives that respond to real needs in a timely manner.

*   Its technical content should be complete and accurate.

*   It should be easy to understand (or as easy as the subject matter allows!) and easy to implement.

*   Its requirements should be expressed clearly and unambiguously.

*   It should be validated.

*   It should be well-maintained.

Reference: [A Guide To Writing World Class Standards](https://www.etsi.org/images/files/Brochures/AGuideToWritingWorldClassStandards.pdf)

* [Re: historical background regarding success of responses to formal objections](https://lists.w3.org/Archives/Public/public-credentials/2021Sep/0076.html) Liam R. E. Quin (Monday, 13 September)

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)

* [We're not the only community with problems (Fwd: Open Letter to Debian election candidates about Debian vendettas)](https://lists.w3.org/Archives/Public/public-credentials/2022Mar/0127.html) Manu Sporny (Saturday, 19 March)

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;

## Procedure \ CCG

* [IRC mailing list bridge](https://lists.w3.org/Archives/Public/public-credentials/2022Apr/0117.html) Charles E. Lehner (Saturday, 23 April)

Notifications of messages to this mailing list (public-credentials) are now sent to our IRC channel (#ccg).

* [re: How to contribute to new standards work? (was:Re: RDF Dataset Canonicalization - Formal Proof)](https://lists.w3.org/Archives/Public/public-credentials/2021Aug/0172.html) Manu Sporny (Tuesday, 10 August)

* [The CCG Work Item process is outlined here](https://docs.google.com/document/d/1vj811aUbs8GwZUNo-LIFBHafsz4rZTSnRtPv7RQaqNc/):

* [Here's how you get started:](https://docs.google.com/document/d/1vj811aUbs8GwZUNo-LIFBHafsz4rZTSnRtPv7RQaqNc/edit%23heading%3Dh.f28tyzjvad8g)

This process is open to anyone -- no W3C Membership dues, fees, etc. required to participate.

* [Reminder: You can present to the CCG](https://lists.w3.org/Archives/Public/public-credentials/2022Mar/0151.html)

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.

* [Clarity about the group charter](https://lists.w3.org/Archives/Public/public-credentials/2022Jun/0044.html) Manu Sporny (Wednesday, 22 June)

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

* [2022-2026 Verifiable Data Standards Roadmap [DRAFT]](https://lists.w3.org/Archives/Public/public-credentials/2022Mar/0068.html)  Manu Sporny (Saturday, 12 March)

![https://www.notion.soimages/image1.png](https://www.notion.soimages/image1.png)

## W3C

* [does the CCG have any thoughts about possible changes to W3C itself?](https://lists.w3.org/Archives/Public/public-credentials/2022Apr/0067.html)  Daniel Hardman (Saturday, 9 April)

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?

* [Announcement: W3C to become a public-interest non-profit organization](https://lists.w3.org/Archives/Public/public-credentials/2022Jun/0063.html)  Kimberly Wilson Linson (Tuesday, 28 June)

* [W3C to become a public-interest non-profit organization](https://www.w3.org/2022/06/pressrelease-w3c-le.html.en)

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

## Decentralized Identifiers (DID)

* [re: Defining load balanced, failover clusters for DID Document serviceEndpoints?](https://lists.w3.org/Archives/Public/public-credentials/2022Jan/0056.html)  (Monday, 10 January)

#didlang 0.3 includes support for round-robin, load-balanced DID Agent serviceEndpoint clusters. [Here's a demo](https://youtu.be/mf0aKLvJoCw)

* [W3C Decentralized Identifiers v1.0 is a W3C Proposed Recommendation](https://lists.w3.org/Archives/Public/public-credentials/2021Aug/0030.html)  Manu Sporny (Tuesday, 3 August)

* [W3C Decentralized Identifiers v1.0 is a W3C Proposed Recommendation](https://www.w3.org/blog/news/archives/9179):

* [The published version that will be voted on by W3C Members can be found here](https://www.w3.org/TR/2021/PR-did-core-20210803/):

This is the final step of the W3C global standardization process.

If you are a W3C Member, you can now vote to approve it as a global standard here:

* [DID 1.0 Comments / Meeting Minutes (was RE: Mozilla Formally Objects to DID Core)](https://lists.w3.org/Archives/Public/public-credentials/2021Sep/0135.html)  John, Anil (Monday, 27 September)

* [https://www.w3.org/2021/09/21-did10-minutes.html](https://www.w3.org/2021/09/21-did10-minutes.html) is fascinating reading!

* [...] 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”

* [Mozilla Formally Objects to DID Core](https://lists.w3.org/Archives/Public/public-credentials/2021Sep/0010.html)  Drummond Reed (Thursday, 1 September)

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](https://www.w3.org/TR/did-core/%23dids-as-enhanced-urns), we specifically compare the DID spec to the *URN spec*, [RFC 8141](https://datatracker.ietf.org/doc/html/rfc8141). In fact we deliberately patterned the [ABNF for DIDs](https://www.w3.org/TR/did-core/%23did-syntax)  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](https://www.iana.org/assignments/urn-namespaces/urn-namespaces.xhtml).

Now: guess how many URN namespaces have been registered with IANA?

- [SEVENTY*. Count em.](https://www.iana.org/assignments/urn-namespaces/urn-namespaces.xhtml)

I don't see anyone complaining about interoperability of URN namespaces. Amd RFC 8141 was published over four years ago.

* [Some questions regarding DID verification relationships](https://lists.w3.org/Archives/Public/public-credentials/2021Dec/0009.html) Dmitri Zagidulin (Thursday, 2 December)

The motivation for verification relationships in the DID spec stems from the general security recommendation of "use separate keys for separate purposes".

You can see this at work in other specifications, such as JWKS (JSON Wek Key Set), specifically in the 'use' (Public Key Use) parameters, from [https://datatracker.ietf.org/doc/html/rfc7517#section-4.2](https://datatracker.ietf.org/doc/html/rfc7517%23section-4.2)

* [DID press release and UNECE white paper](https://lists.w3.org/Archives/Public/public-credentials/2022Jul/0087.html)  steve capell (Wednesday, 20 July)

great to see that press release at [https://www.w3.org/2022/07/pressrelease-did-rec.html.en](https://www.w3.org/2022/07/pressrelease-did-rec.html.en)

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](https://unece.org/trade/uncefact/guidance-material)

* [DID Press Release Testimonials](https://lists.w3.org/Archives/Public/public-credentials/2022Jul/0022.html)  Zundel, Brent (Friday, 8 July)

This message is to inform the DID WG and CCG that the W3C intends to write a press release.

To that end, we are seeking testimonials about Decentralized Identifiers.

For an example of the sort of thing we're looking for, please see: [https://www.w3.org/2019/03/pressrelease-webauthn-rec.html](https://www.w3.org/2019/03/pressrelease-webauthn-rec.html)

The testimonials may be submitted as a reply to this email.

DID Methods

* [Announcement: New DID Method Specification: did:object](https://lists.w3.org/Archives/Public/public-credentials/2021Dec/0067.html)  (Tuesday, 14 December)

The publication of [this DID Method specification](https://github.com/mwherman2000/TrustedDigitalWeb/blob/master/specifications/did-methods/did-object.md) realizes, in large part, a 4-year quest (or should I say personal mission) to create a platform to Tokenize Every Little Thing (ELT).

* [Re: CCG Community opinions needed to define CCG scope (specifically re: did methods as work items)](https://lists.w3.org/Archives/Public/public-credentials/2021Aug/0376.html)  Manu Sporny (Thursday, 26 August)

On 8/26/21 12:37 PM, Heather Vescent wrote:

> 1. What are the *pros* of including did methods as work items in the CCG?

Community vetting and approval of particular DID Methods.

Basically, broader and deeper review of DID Methods that we expect to be of

great use to the world. I expect there will be DID Methods that the community

wants to eventually propose as DID Methods for standardization (did:key and

did:web feel like two ones where we could get consensus on doing so).

* [DID methods as W3C standards - a happy compromise?](https://lists.w3.org/Archives/Public/public-credentials/2022Feb/0117.html)  steve capell (Tuesday, 22 February)

can't we pick just a small number of un-controversial methods to standardise?  even if it's just did:key and did:web to start with.

* [Cross border identity use case - which did methods?](https://lists.w3.org/Archives/Public/public-credentials/2022Mar/0016.html)  steve capell (Sunday, 6 March)

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"?

![https://www.notion.soimages/image2.png](https://www.notion.soimages/image2.png)

DID:TAG[re: Using Email as an Identifier](https://lists.w3.org/Archives/Public/public-credentials/2021Nov/0065.html)  Bob Wyman (Friday, 12 November)

My [did:tag](https://github.com/bobwyman/did_method_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.

DID:WEB

* [re: some thought after using did:web](https://lists.w3.org/Archives/Public/public-credentials/2022Jan/0031.html)  Orie Steele (Wednesday, 5 January)

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:

* [https://github.com/transmute-industries/verifiable-data/blob/main/packages/ed25519-key-pair/src/Ed25519KeyPair.ts#L78](https://github.com/transmute-industries/verifiable-data/blob/main/packages/ed25519-key-pair/src/Ed25519KeyPair.ts%23L78)

* [https://github.com/transmute-industries/verifiable-data/blob/main/packages/ed25519-key-pair/src/types/Ed25519VerificationKey2018.ts](https://github.com/transmute-industries/verifiable-data/blob/main/packages/ed25519-key-pair/src/types/Ed25519VerificationKey2018.ts)

* [https://github.com/transmute-industries/verifiable-data/blob/main/packages/ed25519-key-pair/src/types/Ed25519VerificationKey2020.ts](https://github.com/transmute-industries/verifiable-data/blob/main/packages/ed25519-key-pair/src/types/Ed25519VerificationKey2020.ts)

* [https://github.com/transmute-industries/verifiable-data/blob/main/packages/ed25519-key-pair/src/types/JsonWebKey2020.ts](https://github.com/transmute-industries/verifiable-data/blob/main/packages/ed25519-key-pair/src/types/JsonWebKey2020.ts)

* [DID Web, OpenSSL and Certificate Authorities](https://lists.w3.org/Archives/Public/public-credentials/2022Feb/0078.html)  Orie Steele (Thursday, 17 February)

We then generate a DID Web DID Document from the public keys for the 3 children, and encode the ca chain from them back to the root using `x5c`.

We then issue a JWT from the private key for 1 of them.

We then verify the JWT signature using the public key.

We then check the x5c using open seel to confirm the certificate chain.

My questions are:

1. Is it possible to use JOSE to automate this further?

2. Is there a better way of accomplishing this?

3. Should the CA chain be pushed into the JWT?

DID:JWK

* [did:jwk is reborn!](https://lists.w3.org/Archives/Public/public-credentials/2022Apr/0066.html)  Orie Steele (Friday, 8 April)

* [https://github.com/w3c/did-spec-registries/pull/432](https://github.com/w3c/did-spec-registries/pull/432)

DID:KEY

* [did-key-creator published](https://lists.w3.org/Archives/Public/public-credentials/2022Jun/0061.html)  Brent Shambaugh (Tuesday, 28 June)

I published a did:key creator at

* [https://www.npmjs.com/package/did-key-creator](https://www.npmjs.com/package/did-key-creator)

This has been tested to create did:keys from the P-256,P-384, and P-521 curves specified in [https://github.com/w3c-ccg/did-method-key](https://github.com/w3c-ccg/did-method-key) and [https://w3c-ccg.github.io/did-method-key/](https://w3c-ccg.github.io/did-method-key/) .

* [did:key DID Document generation algorithm feedback](https://lists.w3.org/Archives/Public/public-credentials/2022Jun/0016.html)  Manu Sporny (Tuesday, 14 June)

The DID Document generation algorithm for did:key is being refined to the

point that we can finish off a first pass of a did:key test suite.

* [...] [https://github.com/w3c-ccg/did-method-key/pull/51](https://github.com/w3c-ccg/did-method-key/pull/51)

## Verifiable Credentials

* [Binding credentials to publicly accessible repositories](https://lists.w3.org/Archives/Public/public-credentials/2021Jul/0297.html)  Leonard Rosenthol (Friday, 30 July)

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.

* [Re: Binding credentials to publicly accessible repositories](https://lists.w3.org/Archives/Public/public-credentials/2021Jul/0301.html) Joe Andrieu

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

* [Add Your VC-EDU Use Cases](https://lists.w3.org/Archives/Public/public-credentials/2021Jul/0296.html)  Kerri Lemoie (Friday, 30 July)

For Github users, submit your use cases as issues here: [https://github.com/w3c-ccg/vc-ed-use-cases/issues](https://github.com/w3c-ccg/vc-ed-use-cases/issues)

This template can help guide you: [https://github.com/w3c-ccg/vc-ed-use-cases/blob/main/.github/ISSUE_TEMPLATE/use-case-template.md](https://github.com/w3c-ccg/vc-ed-use-cases/blob/main/.github/ISSUE_TEMPLATE/use-case-template.md)

* [Question About Signatures & Contexts](https://lists.w3.org/Archives/Public/public-credentials/2021Jul/0290.html)  Kerri Lemoie (Friday, 30 July)

Is a VC still considered to be valid if it contains fields that are not described in its context file(s)? Does it depend on the signature type?

* [Re: Question About Signatures & Contexts](https://lists.w3.org/Archives/Public/public-credentials/2021Jul/0291.html) Manu Sporny

The short answers are "maybe" and "yes".

* [What are VCs similar to?](https://lists.w3.org/Archives/Public/public-credentials/2021Aug/0338.html) Michael Herman (Trusted Digital Web) (Monday, 23 August)

The chip in your e-passport is the analogy I’ve 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 I’ve found.  Policy makers say “ah, I see”…

Video [Using Paper-based Structured Credentials to Humanize Verifiable Credentials [Rough Cut]](https://www.youtube.com/watch?v%3DkM30pd3w8qE%26list%3DPLU-rWqHm5p45dzXF2LJZjuNVJrOUR6DaD%26index%3D2) Michael Herman (Trusted Digital Web) (Friday, 19 November)

User Scenario: ABC Grocery wants to use the Trusted Digital Web to issue a Purchase Order for 10 cabbages from David's Cabbages.

* [Any Good use case of PAM (Privileged account Management) using Vcs](https://lists.w3.org/Archives/Public/public-credentials/2021Nov/0028.html) Bob Wyman (Sunday, 7 November)

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.

One should delegate rights, not credentials.

* [Proposal: Anchored Resources and Hashlinks for VCs](https://lists.w3.org/Archives/Public/public-credentials/2021Nov/0009.html) Dmitri Zagidulin (Wednesday, 3 November)

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.

* [re: Wrapping a VC envelope around the results of a GraphQL query?](https://lists.w3.org/Archives/Public/public-credentials/2021Dec/0093.html) Michael Herman (Trusted Digital Web) (Friday, 17 December)

Apparently so… [Evaluating the Current State of Application Programming Interfaces for Verifiable Credentials](https://www.researchgate.net/publication/356195214_Evaluating_the_Current_State_of_Application_Programming_Interfaces_for_Verifiable_Credentials)

* [Blockcerts v3 release, a Verifiable Credentials implementation](https://lists.w3.org/Archives/Public/public-credentials/2021Dec/0051.html)  Julien Fraichot (Monday, 13 December)

I am excited to share with you today the release of [Blockcerts](https://www.blockcerts.org/) 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.

We have followed through with the initial [ideas established at RWOT 9 in Prague in December 2019, to align Blockcerts with the Verifiable Credential specification](https://github.com/WebOfTrustInfo/rwot9-prague/blob/master/final-documents/BlockcertsV3.md).

* [Proposal Work Item | Credential Chaining](https://lists.w3.org/Archives/Public/public-credentials/2022Jan/0235.html)  Robin Klemens (Thursday, 27 January)

* 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

* [DIF VC-JWTs look like Linked Data Proof Verifiable Credentials](https://lists.w3.org/Archives/Public/public-credentials/2022Feb/0138.html)  Orie Steele (Thursday, 24 February)

As far as I know, no other VC-JWT implementation supports this format, aka "JwtProof2020".

* [Here is a link to an issue with an example](https://github.com/centrehq/verite/issues/373%23issuecomment-1049888568)

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.

* [re: Recommendations for Storing VC-JWT](https://lists.w3.org/Archives/Public/public-credentials/2022Feb/0076.html)  David Chadwick (Thursday, 17 February)

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.

* [re: cloud-based wallet](https://lists.w3.org/Archives/Public/public-credentials/2022Mar/0285.html)  Orie Steele (Saturday, 26 March)

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

* [usage of credentialSubject WITHOUT id?](https://lists.w3.org/Archives/Public/public-credentials/2022Mar/0017.html)  Niels Klomp (Sunday, 6 March)

Indeed the use case is for so called [bearer credentials](https://www.w3.org/TR/vc-data-model/%23bearer-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.

* [Verifiable Web Form](https://lists.w3.org/Archives/Public/public-credentials/2022Apr/0115.html)  Shigeya Suzuki (Saturday, 23 April)

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.

* [Your Insights, Assumptions, & Questions About VC Governance & Registries Needed](https://lists.w3.org/Archives/Public/public-credentials/2022Apr/0107.html)  Kerri Lemoie (Wednesday, 20 April)

I’ve created a Miro board as a place to start gathering questions and assumptions:

* [https://miro.com/app/board/uXjVO8bG_9s=/](https://miro.com/app/board/uXjVO8bG_9s%3D/)

* [VC Extensions Registry updates](https://lists.w3.org/Archives/Public/public-credentials/2022Apr/0096.html)  Manu Sporny (Saturday, 16 April)

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:

* [https://pr-preview.s3.amazonaws.com/w3c-ccg/vc-extension-registry/pull/12.html#proof-methods](https://pr-preview.s3.amazonaws.com/w3c-ccg/vc-extension-registry/pull/12.html%23proof-methods)

The pull request[4] involves a few things that are worth noting

* [VC Issuance based on OAuth 2.0](https://lists.w3.org/Archives/Public/public-credentials/2022Apr/0084.html)  Nikos Fotiou (Thursday, 14 April)

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.

* [Verifiable Credentials Data Model v1.1 is an official W3C standard!](https://lists.w3.org/Archives/Public/public-credentials/2022Mar/0005.html)  Manu Sporny (Thursday, 3 March)

Verifiable Credentials Data Model v1.1 [https://www.w3.org/TR/2022/REC-vc-data-model-20220303/](https://www.w3.org/TR/2022/REC-vc-data-model-20220303/)

This was largely a maintenance release of the specification. The list of (minor) revisions since the v1.0 release can be found here:

* [VC Evidence Discussion](https://lists.w3.org/Archives/Public/public-credentials/2022Apr/0050.html)  Kerri Lemoie (Thursday, 7 April)

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.

This would look [something like this](https://json.link/21SpTf0rC4):

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.

* [Rendering Verifiable Credentials @ RWoT11](https://lists.w3.org/Archives/Public/public-credentials/2022Jul/0054.html)  Manu Sporny (Sunday, 17 July)

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.

* [https://github.com/WebOfTrustInfo/rwot11-the-hague/blob/master/advance-readings/rendering-verifiable-credentials.md](https://github.com/WebOfTrustInfo/rwot11-the-hague/blob/master/advance-readings/rendering-verifiable-credentials.md)

VC-API

* [Supporting VC-JWT and BBS+ Presentation Exchange in the VC-HTTP-API](https://lists.w3.org/Archives/Public/public-credentials/2021Jul/0313.html)  Orie Steele (Saturday, 31 July)

* [https://github.com/OR13/GNARLY](https://github.com/OR13/GNARLY)  (while we wait for a better name...)

This demo API and Spec has a number of improvements over the current

VC-HTTP-API, including tested support for VC-JWT, JsonWebSignature2020 and

BBS+ Selective Disclosure Presentation Exchange.

* [Updated VC-API diagram for Supply Chain flow](https://lists.w3.org/Archives/Public/public-credentials/2021Sep/0141.html)  Joe Andrieu (Tuesday, 28 September)

![https://www.notion.soimages/image4.png](https://www.notion.soimages/image4.png)

* [re: VC API: handling large documents client to server](https://lists.w3.org/Archives/Public/public-credentials/2022Feb/0035.html)  Manu Sporny (Thursday, 10 February)

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.

* [VC-API interoperability test suites ready for experimental integration](https://lists.w3.org/Archives/Public/public-credentials/2022Apr/0126.html)  Manu Sporny (Tuesday, 26 April)

* [The VC API test suite for basic issuer interop is here](https://w3c-ccg.github.io/vc-api-issuer-test-suite/)

* [The VC API test suite for basic verifier interop is here](https://w3c-ccg.github.io/vc-api-verifier-test-suite/)

* [The Data Integrity test suite for Ed25519Signature2020 interop is here](https://w3c-ccg.github.io/di-ed25519-test-suite/)

* [Cross-industry VC API test suite achieves first multi-vendor interop for issue/verify](https://lists.w3.org/Archives/Public/public-credentials/2022May/0041.html)  Manu Sporny (Wednesday, 18 May)

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):

* [https://w3c-ccg.github.io/vc-api-verifier-test-suite/#Verify%20Credential%20-%20Data%20Integrity](https://w3c-ccg.github.io/vc-api-verifier-test-suite/%23Verify%2520Credential%2520-%2520Data%2520Integrity)

* [https://w3c-ccg.github.io/vc-api-issuer-test-suite/#Issue%20Credential%20-%20Data%20Integrity](https://w3c-ccg.github.io/vc-api-issuer-test-suite/%23Issue%2520Credential%2520-%2520Data%2520Integrity)

* [Diagrams for VC HTTP API work [was Re: [AGENDA] VC HTTP API Work Item - August 17th 2021]](https://lists.w3.org/Archives/Public/public-credentials/2021Aug/0231.html)  Joe Andrieu (Monday, 16 August)

1. There are sequence and communications diagrams for both issuance and verification, plus a class diagram.

![https://www.notion.soimages/image3.png](https://www.notion.soimages/image3.png)

* [VC-HTTP-API new sequence diagram](https://lists.w3.org/Archives/Public/public-credentials/2021Sep/0109.html)  Joe Andrieu (Tuesday, 21 September)

![https://www.notion.soimages/image6.png](https://www.notion.soimages/image6.png)

* [Issuer API Cross Trust Boundary Scoping - VC-HAPI (f.k.a. VC-HTTP-API)](https://lists.w3.org/Archives/Public/public-credentials/2021Jul/0263.html)  Brian Richter (Saturday, 24 July)

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

* [RAR Structures for VC HTTP API](https://lists.w3.org/Archives/Public/public-credentials/2021Jul/0208.html)  Justin Richer (Wednesday, 21 July)

It seemed like a good idea when I first invented it a decade ago: [](https://blue-button.github.io/blue-button-plus-pull/%23scopes)[https://blue-button.github.io/blue-button-plus-pull/#scopes](https://blue-button.github.io/blue-button-plus-pull/%23scopes) or when it got pulled into other efforts like [](https://openid.net/specs/openid-heart-fhir-oauth2-1_0-2017-05-31.html)[https://openid.net/specs/openid-heart-fhir-oauth2-1_0-2017-05-31.html](https://openid.net/specs/openid-heart-fhir-oauth2-1_0-2017-05-31.html)… and Orie even suggested the following set of parameterized scopes for this API:

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

* [Proposals addressing discoverability issues with vc-http-api](https://lists.w3.org/Archives/Public/public-credentials/2021Jul/0192.html)  Orie Steele (Tuesday, 20 July)

See: [https://github.com/w3c-ccg/vc-http-api/issues/218](https://github.com/w3c-ccg/vc-http-api/issues/218)

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)

* [Bikeshed: Renaming the VC HTTP API](https://lists.w3.org/Archives/Public/public-credentials/2021Jul/0131.html)  Manu Sporny (Saturday, 17 July)

the fundamental issue is that stringing a bunch of consonants together ("HTTP") rarely leads to something easy to say in conversation.

CHAPI

* [VC-API Diagram for today. Focus on CHAPI](https://lists.w3.org/Archives/Public/public-credentials/2021Nov/0007.html)  Joe Andrieu (Tuesday, 2 November)

![https://www.notion.soimages/image7.png](https://www.notion.soimages/image7.png)

* [chapi.io launches, includes VC playground](https://lists.w3.org/Archives/Public/public-credentials/2022Jun/0055.html)  Manu Sporny (Monday, 27 June)

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.

* [chapi.io playground upgrades - credential selector, resident card](https://lists.w3.org/Archives/Public/public-credentials/2022Jul/0111.html)  Manu Sporny (Wednesday, 27 July)

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

* [You can try both of these new features out in the playground](https://playground.chapi.io/issuer)

* [Jobs For The Future VC added to chapi.io playground](https://lists.w3.org/Archives/Public/public-credentials/2022Jul/0031.html)  Manu Sporny (Wednesday, 13 July)

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.

## Crypto

* [FYI: Cryptography Review and Recommendations for W3C VC and W3C DID Implementations by SRI International](https://lists.w3.org/Archives/Public/public-credentials/2022Jan/0209.html)  John, Anil (Wednesday, 26 January)

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.

* [SRI-Cryptography Review and Recommendations  for W3C VCDM and W3C DID Standards.docx](https://docs.google.com/document/d/1EdCBSACtlBv2DxNZM67qi9F15Iv5uWOW/)

* [Blog on SSI and Cryptographically Enforceable Policies](https://lists.w3.org/Archives/Public/public-credentials/2022Feb/0032.html)  (Tuesday, 8 February)

I've posted a new SSI blog entitled: "[Protecting Sensitive Parts of Credentials with Cryptographically Enforceable Policies](https://blockchain.tno.nl/blog/protecting-sensitive-parts-of-credentials-with-cryptographically-enforceable-policies/)".

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.

* [Use of cryptography with W3C VCs and DIDs released](https://lists.w3.org/Archives/Public/public-credentials/2022Apr/0109.html)  Manu Sporny (Thursday, 21 April)

Cryptography Review of W3C Verifiable Credentials Data Model (VCDM) and Decentralized Identifiers (DIDs) Standards and Cryptography Implementation Recommendations by David Balenson & Nick Genise

* [http://www.csl.sri.com/papers/vcdm-did-crypto-recs/](http://www.csl.sri.com/papers/vcdm-did-crypto-recs/)

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.

* [Universal signature verifier](https://lists.w3.org/Archives/Public/public-credentials/2022May/0005.html)  Marcus Sabadello (Wednesday, 4 May)

We (Danube Tech) have a "Universal Verifier" here: [https://univerifier.io/](https://univerifier.io/)

But I don't claim that it actually supports all the credential formats  and signature suites in existence...

Especially considering that at the last Internet Identity Workshop a lot of different formats were identified:

* [https://docs.google.com/document/d/1aNHvPhFv85HHlG8Ry2etrw15KdY830oAL804rMFY9bY](https://docs.google.com/document/d/1aNHvPhFv85HHlG8Ry2etrw15KdY830oAL804rMFY9bY/)

* [Updating SafeCurves for 2022...](https://lists.w3.org/Archives/Public/public-credentials/2022May/0048.html)  Manu Sporny (Tuesday, 24 May)

* [Guidance for Choosing an Elliptic Curve Signature Algorithm in 2022](https://soatok.blog/2022/05/19/guidance-for-choosing-an-elliptic-curve-signature-algorithm-in-2022/)

It suggests updates to the [SafeCurves website](https://safecurves.cr.yp.to/)

* [Cross-vendor interop for Data Integrity and Ed25519Signature2020 achieved](https://lists.w3.org/Archives/Public/public-credentials/2022May/0034.html)  Manu Sporny (Tuesday, 17 May)

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:

* [https://w3c-ccg.github.io/di-ed25519-test-suite/#Data%20Integrity%20(verifier](https://w3c-ccg.github.io/di-ed25519-test-suite/%23Data%2520Integrity%2520(verifier)

* [https://w3c-ccg.github.io/di-ed25519-test-suite/#Ed25519Signature2020%20(verifier](https://w3c-ccg.github.io/di-ed25519-test-suite/%23Ed25519Signature2020%2520(verifier)

* [Streamlining Data Integrity Cryptosuites](https://lists.w3.org/Archives/Public/public-credentials/2022Jul/0115.html)  Manu Sporny (Sunday, 31 July)

* [2022-VCWG-Data-Integrity-Streamlining.pdf](https://lists.w3.org/Archives/Public/public-credentials/2022Jul/att-0115/2022-VCWG-Data-Integrity-Streamlining.pdf)

![https://www.notion.soimages/image5.png](https://www.notion.soimages/image5.png)

* [Publication request for Data Integrity CGFRs](https://lists.w3.org/Archives/Public/public-credentials/2022Jul/0107.html)  Manu Sporny (Tuesday, 26 July)

This is a publication request for four Data Integrity Community Group

Final Reports. Namely:

* [Data Integrity](https://w3c.github.io/cg-reports/credentials/CG-FINAL-data-integrity-20220722/)

* [Data Integrity JSON Web Signature Cryptosuite 2020](https://w3c.github.io/cg-reports/credentials/CG-FINAL-lds-jws2020-20220721/)

* [Data Integrity ECDSA Cryptosuite 2019](https://w3c.github.io/cg-reports/credentials/CG-FINAL-di-ecdsa-2019-20220724/)

* [Data Integrity EdDSA Cryptosuite 2020](https://w3c.github.io/cg-reports/credentials/CG-FINAL-di-eddsa-2020-20220724/)

## DIDComm

* [announcement: DIDComm user group](https://lists.w3.org/Archives/Public/public-credentials/2022Jan/0168.html)  Hardman, Daniel (Thursday, 20 January)

Now that the [DIDComm v2 spec](https://identity.foundation/didcomm-messaging/spec/) is nearing completion, and there are [robust libraries in multiple programming languages](https://github.com/decentralized-identity/didcomm-messaging%23implementations), 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](https://didcomm.org) and [repo](https://github.com/decentralized-identity/didcomm.org), and recommend best practices.

* [slides for DIDComm discussion on Tuesday's CCG call](https://lists.w3.org/Archives/Public/public-credentials/2022Apr/0032.html)  Daniel Hardman (Tuesday, 5 April)

application/pdf attachment: [DIDComm_v2_Primer.pdf](https://lists.w3.org/Archives/Public/public-credentials/2022Apr/att-0032/DIDComm_v2_Primer.pdf)

## Wallets

* [IETF: Secure Credential Transfer](https://lists.w3.org/Archives/Public/public-credentials/2022Apr/0025.html)  Orie Steele (Monday, 4 April)

* [https://www.ietf.org/archive/id/draft-secure-credential-transfer-03.html](https://www.ietf.org/archive/id/draft-secure-credential-transfer-03.html)

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.

* [OKTA Cloud Identity Integration with SSI wallet](https://lists.w3.org/Archives/Public/public-credentials/2021Nov/0100.html)  sethi shivam (Tuesday, 23 November)

I am successfully able to integrate Okta cloud identity with SSI agent .

* [OKTA Identity Cloud Integration with SSI agent](https://medium.com/@sethisaab/okta-identity-cloud-integration-with-ssi-agent-ea1694a833cb)

Looking for your feedback on how we can improve this more[DIF Wallet Security WG - Wallet Implementers Survey](https://lists.w3.org/Archives/Public/public-credentials/2022Jan/0063.html)  Bastian, Paul (Friday, 7 January)

I summarized our [goals and visions in this presentation](https://nextcloud.idunion.org/s/D2cbMi6w8t3nPYj), for more information check out [the Github page](https://github.com/decentralized-identity/wallet-security)

Also we ended up to initiating 2 new work items at the end of last year:

*   [Device Binding](https://github.com/decentralized-identity/wallet-security/blob/main/work_items/device_binding.md) ([kickoff doodle](https://doodle.com/poll/bttcdxcqdn9cpziu)

*   [Differential Credential Security](https://github.com/decentralized-identity/wallet-security/blob/differential-credential-security-wg/work_items/differential_credential_security.md)

* [W3C CCG Wallet Protocol Analysis (WIP)](https://lists.w3.org/Archives/Public/public-credentials/2022Mar/0241.html)  Manu Sporny (Thursday, 24 March)

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

* [https://docs.google.com/document/d/139dTcWp28LePAQjrA1uXVy4d154B22Y2d-vn5GvIaec/edit#](https://docs.google.com/document/d/139dTcWp28LePAQjrA1uXVy4d154B22Y2d-vn5GvIaec/edit%23) [updated link]

## RDF

* [Importing Verifiable Data as Labeled Property Graphs](https://lists.w3.org/Archives/Public/public-credentials/2022Jun/0022.html)  Orie Steele (Wednesday, 15 June)

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

I suspect this is solvable with a more complicated graph config: [https://neo4j.com/labs/neosemantics/4.0/config/](https://neo4j.com/labs/neosemantics/4.0/config/)

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

answer on the github issue for the standard, I raised it here: [](https://github.com/w3c/vc-data-model/issues/881)[https://github.com/w3c/vc-data-model/issues/881](https://github.com/w3c/vc-data-model/issues/881)

* [Proposed W3C Charter: RDF Dataset Canonicalization and Hash Working Group](https://lists.w3.org/Archives/Public/public-credentials/2022May/0033.html)  Manu Sporny (Tuesday, 17 May)

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.

The [announcement](https://lists.w3.org/Archives/Public/public-new-work/2022May/0005.html) is here

The [proposed charter](https://www.w3.org/2022/05/04-proposed-rch-wg-charter/) is here

* [URDNA2015 Implementation Question](https://lists.w3.org/Archives/Public/public-credentials/2022Jul/0017.html)  Daniel Petranek (Thursday, 7 July)

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?

## Quantum

* [Future-proofing VCs via multiple signatures](https://lists.w3.org/Archives/Public/public-credentials/2022Jan/0043.html)  Manu Sporny (Thursday, 6 January)

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.

* [re: New Work Item Incubating for IETF: JSON Encoding for Post Quantum Signatures](https://lists.w3.org/Archives/Public/public-credentials/2022Feb/0008.html)  Orie Steele (Tuesday, 1 February)

I look forward to continuing to work on JSON encoding for post quantum signature schemes.

In particular, support for JWS and JWK as building blocks for higher order cryptographic systems, such as DIDs and VCs.

If you are interested in contributing, please feel free to open issues here: [](https://github.com/mesur-io/post-quantum-signatures)[https://github.com/mesur-io/post-quantum-signatures](https://github.com/mesur-io/post-quantum-signatures)

* [Post Quantum and Related](https://lists.w3.org/Archives/Public/public-credentials/2022Jul/0010.html) Mike Prorock (Wednesday, 6 July)

* [NIST Announcement here](https://csrc.nist.gov/News/2022/pqc-candidates-to-be-standardized-and-round-4)

* [And a pretty good game plan from CISA with some timing implications here](https://www.cisa.gov/uscert/ncas/current-activity/2022/07/05/prepare-new-cryptographic-standard-protect-against-future-quantum)

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.

## Assorted

* [Bootstrapping a VDR-based decentralized object (credential) platform?](https://lists.w3.org/Archives/Public/public-credentials/2021Jul/0274.html) Michael Herman (Trusted Digital Web) (Monday, 26 July)

Here's an [illustration of the relationships between the initial DOMAIN and POOL txns](https://hyperonomy.com/2021/07/26/bootstrapping-a-vdr-based-decentralized-credential-object-platform-von-example/) used to bootstrap an example Aries VDR...

* [the link between biometrics and PII needs careful management](https://lists.w3.org/Archives/Public/public-credentials/2021Sep/0000.html)  Daniel Hardman (Wednesday, 1 September)

* [This is the real story of the Afghan biometric databases abandoned to the Taliban | MIT Technology Review](https://www.technologyreview.com/2021/08/30/1033941/afghanistan-biometric-databases-us-military-40-data-points/)

* [FYI: C2PA Releases Specification of World’s First Industry Standard for Content Provenance](https://lists.w3.org/Archives/Public/public-credentials/2022Jan/0207.html)  Leonard Rosenthol (Wednesday, 26 January)

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](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.

* [FedId CG at W3C and GNAP](https://lists.w3.org/Archives/Public/public-credentials/2022Jan/0065.html)  Orie Steele (Friday, 7 January)

I asked them whether they considered GNAP via slack.

* [https://w3ccommunity.slack.com/archives/C02355QUL73/p1641585415001900](https://w3ccommunity.slack.com/archives/C02355QUL73/p1641585415001900)

They are chartered here: [](https://fedidcg.github.io/)[https://fedidcg.github.io/](https://fedidcg.github.io/)

To look at AuthN that breaks when browser primitives are removed.

They are currently focused on OIDC, SAML, WS-Fed.

The reason I asked them was in relation to the questions we have discussed regarding "What can GNAP replace".

Clearly GNAP can replace OAuth, but I think you both have now confirmed that GNAP does not replace OIDC, or federated identity...

* [XMSS: Generating usable test vectors for JOSE and COSE](https://lists.w3.org/Archives/Public/public-credentials/2022Apr/0007.html)  Orie Steele (Sunday, 3 April)

We've been working on generating test vectors for: [https://datatracker.ietf.org/doc/html/rfc8391](https://datatracker.ietf.org/doc/html/rfc8391) $1$2

That we could use to register the `kty` and `alg` for XMSS such that it could be used by JOSE and COSE.

* [https://github.com/transmute-industries/xmss](https://github.com/transmute-industries/xmss)

I've reached the limits of my ability to move this ball forward, and am here to ask for help