Priorities for next W3C VCWG charter

[brentzundel]

What of w3c-ccg/community#250 (or otherwise) would folks be interested in working on for the next charter?

[iherman]

Adding some comments to the list items from w3c-ccg/community#250

Specifications Ready For Promotion

• Verifiable Credential Barcodes - https://w3c-ccg.github.io/vc-barcodes/

  • Depends on CBOR-LD (via JSON-LD WG) - https://json-ld.github.io/cbor-ld-spec/

At first glance, this CCG documents is a fairly straightforward extra vocabulary to VC provided the CBOR representation is specified.

However, the rechartering of the JSON-LD WG, that should also handle CBOR-LD, is at its initial steps; realistically, I would not think that WG would even start before the end of the year. I.e., I would not expect a CBOR-LD specification to be finalized before mid-2027. That would mean our document would have a pending normative reference. It is doable, but the new VC charter should be carefully crafted to set the expectations right.

Independently of CBOR-LD, there may be another issue, though. This document handles a barcode representation of a VC with embedded proof, a.k.a., DI. Shouldn't the WG also handle the case of enveloping proofs?

• Verifiable Credential Rendering Method - https://w3c-ccg.github.io/vc-render-method/

Per https://www.w3.org/2024/10/vc-wg-charter.html#scope this does not require a new charter; it is doable right away.

• Confidence Method - https://w3c-ccg.github.io/vc-confidence-method/

Same as before, per https://www.w3.org/2024/10/vc-wg-charter.html#scope this does not require a new charter; it is doable right away.

• Verifiable Credentials Over Wireless - https://w3c-ccg.github.io/vc-wireless/

That sounds like a specification to be handled with/by IETF. I do not think it is a W3C topic, and would lead to a turf war with IETF, which we do not need.

• VC API (active refinement work continues until adoption) - https://w3c-ccg.github.io/vc-api/

What is the relationship of this spec to the work on Credential APIs done elsewhere at the W3C? Shouldn't we, at the minimum, coordinate with that WG on how and what and where?

Specifications Not Yet Ready For Promotion (but will be by end of Summer 2025 at the latest)

• Quantum-Safe Cryptosuites (1 month of further work needed) - https://w3c-ccg.github.io/di-quantum-safe/

I am not sure about the NIST terminology/jargon. The spec refers to https://csrc.nist.gov/pubs/fips/204/final as the crypto approach itself (aside from that, and after an absolutely cursory scan, it looks like a relatively straightforward sister to the current ECDSA or EDDSA cryptosuites). Is that NIST algorithm a standard? If not, don't we get ourselves in the BBS situation, meaning that we have a spec that we cannot finalize and publish due to a missing normative specification?

A different aspect which, in today's climate, may become an issue. Is there a quantum safe algorithm, of a comparable quality, that does not depend on a 100% US organization? That may become a source of contention or may become a touchy issue if we are not careful. Or are there plans to move that NIST algorithm to ISO, to give it an international credential (sic!)?

• Verifiable Issuers and Verifiers (1 month of further work needed) - https://w3c-ccg.github.io/verifiable-issuers-verifiers/
• Credential Refresh (1 month of further work needed) - https://w3c-ccg.github.io/vc-refresh-2021/
• Authorization Capabilities - ZCAPs (??? months of further work needed) -- https://w3c-ccg.github.io/zcap-spec/

I cannot really comment on these three documents, not having the right background for it.

[iherman]

A more general comment. This proposal contains 9 recommendations-to-be, and additional proposals may come from others. I think we should be very careful on what we should accept and go for. The manpower problems are real, a number of people from the original VC group has left, the limits of the W3C staffing have been reached, etc. Whatever the final list of documents is, we should make a very strict and hard prioritization, listing not more than 3-4 documents that we charter for recommendation in the next round (reflecting the documents' readiness, maturity, user needs, etc). We can list the others as "tentative" items, but not as items that we commit ourselves to publish at that round.

We should be realistic. The VC2.0 round was exhausting for many; we made an amazing job in publishing all that we published, but we should avoid dictating the same rhythm again.

[dlongley]

Independently of CBOR-LD, there may be another issue, though. This document handles a barcode representation of a VC with embedded proof, a.k.a., DI. Shouldn't the WG also handle the case of enveloping proofs?

No, I don't think there's any requirement that the WG expand the scope of the specification in that way.

Notably, the specification above leverages the fact that there is no envelope (that wraps the underlying format with a new one and prevents transforms) to enable transforms and semantic compression of VCs for use in optical codes. People are, of course, welcome to take on some other approach, but none of that should act as an impediment to the above work item.

What is the relationship of [the VC API] spec to the work on Credential APIs done elsewhere at the W3C. Shouldn't we, at the minimum, coordinate with that WG on how and what and where?

We should summarize that relationship more in writing in the appropriate places, but, in short, the DC API essentially allows for credential/wallet selection -- and the exchange of credentials is then handled by some protocol as defined by other specifications. The VC API defines components and APIs for the whole lifecycle of VCs, not just the delivery or exchange of VCs, but it also does the latter, including enabling multiple protocol access, therefore integrating nicely with the DC API.

A high-level description:

1. A website uses the VC API to create an "exchange" resource, intended to issue or receive VCs, which a digital wallet can access by one or more protocols.
2. The website requests one or more VCs (or requests to issue one or more VCs) by calling the DC API and passing query/protocol information (based on what the exchange supports).
3. The DC API handles this request by allowing the user to make a choice of wallet application to respond to the request on their existing device, or potentially on another one.
4. The DC API forwards the query/protocol information to the wallet of choice.
5. The wallet selects the desired protocol, interfaces with the user, and communicates with the exchange to complete the transaction.

[iherman]

Thanks @dlongley. I believe the DC vs. VC API-s relationships will have to be documented (not necessarily as part of the charter, but possibly in a separate document referred to from the charter; much as we did for the RCH charter back in the days). This question, quite understandably, will come up during the AC review; better address it upfront imho.

[msporny]

@iherman wrote:

Verifiable Credentials Over Wireless - https://w3c-ccg.github.io/vc-wireless/
That sounds like a specification to be handled with/by IETF. I do not think it is a W3C topic, and would lead to a turf war with IETF, which we do not need.

The vc-wireless specification is built to be compatible with WebNFC and WebBluetooth, which are incubated at W3C and are in production in a variety of Web browsers:

https://w3c.github.io/web-nfc/
https://webbluetoothcg.github.io/web-bluetooth/

It also is focused on delivery of W3C VCs, and uses the render method specification to do so, which is also a W3C thing. NFC nor Bluetooth is an IETF thing. NFC is a NFC Forum thing (but only the low-level protocols). Bluetooth is a BluetoothSIG thing (but only the low level protocols). Protocols at our layer are viewed as application layer protocols and are not expected to be standardized at either NFC Forum or Bluetooth SIG. None of these things are IETF things, so it would be strange for a "turf war" to break out since none of these things are "IETF's turf".

[msporny]

Whatever the final list of documents is, we should make a very strict and hard prioritization, listing not more than 3-4 documents that we charter for recommendation in the next round (reflecting the documents' readiness, maturity, user needs, etc). We can list the others as "tentative" items, but not as items that we commit ourselves to publish at that round.

Yes, I agree. The current goal is to prioritize as best we can, but list tenative items in case the WG gets around to them. People come and go from WGs, and everyone has different priorities; the work that gets done will be a matter of who shows up to do the work.

[msporny]

@iherman wrote:

https://w3c-ccg.github.io/di-quantum-safe/
it looks like a relatively straightforward sister to the current ECDSA or EDDSA cryptosuites).

Yes, that's the expectation.

Is that NIST algorithm a standard? If not, don't we get ourselves in the BBS situation, meaning that we have a spec that we cannot finalize and publish due to a missing normative specification?

The NIST algorithms are national US standards, and most every country on the planet supports NIST cryptography standards. I have not heard of Europe planning to NOT implement the NIST algorithms. Sometimes Europe does add their own cryptography standards to the mix, but it still recognizes and uses NIST algorithms as well.

A different aspect which, in today's climate, may become an issue. Is there a quantum safe algorithm, of a comparable quality, that does not depend on a 100% US organization? That may become a source of contention or may become a touchy issue if we are not careful. Or are there plans to move that NIST algorithm to ISO, to give it an international credential (sic!)?

I don't disagree with you regarding today's climate. That said, just about every major NIST cryptography standard is used by almost every major nation on the planet. It's certainly the case that every browser supports NIST cryptography standards. The standards are open, published, patent-and-royalty free, etc. IOW, unless there are serious issues w/ the math, and these specs underwent years of public scrutiny and attacks, I doubt many countries will go a different way unless it's politically motivated (which does happen). In any case, there are no post-quantum alternatives that I know of that achieve what you say, @iherman, but I will admit that I don't know where Europe or China's cryptography standards process is wrt. post-quantum cryptography.

Fundamentally, though, the work is intended to be a fairly lightweight application of formally published and accepted cryptography standards as applied to Data Integrity. The same upgrades can be performed to vc-jose-cose with a relatively equal amount of effort.

[msporny]

I've started a poll to gather community feedback on specifications, priorities, and Editor's here:

https://forms.gle/4CVa62jSWUaU7V6R8

I expect that we might need a second ranked choice poll (which Google Forms does not do) to finalize the priority list before sending the revised charter out for an AC vote.

[iherman]

@msporny:

Verifiable Credentials Over Wireless - https://w3c-ccg.github.io/vc-wireless/
That sounds like a specification to be handled with/by IETF. I do not think it is a W3C topic, and would lead to a turf war with IETF, which we do not need.

The vc-wireless specification is built to be compatible with WebNFC and WebBluetooth, which are incubated at W3C and are in production in a variety of Web browsers:

https://w3c.github.io/web-nfc/
https://webbluetoothcg.github.io/web-bluetooth/

Well, for the time being these are CG drafts, and it is not yet clear whether they would ever go over to a WG and whether they would pass the scrutiny of an AC vote. As for their implementation in Web Browsers: they also implement a bunch of IETF standards, I presume...

It also is focused on delivery of W3C, and uses the render method specification to do so, which is also a W3C thing. NFC nor Bluetooth is an IETF thing. NFC is a NFC Forum thing (but only the low-level protocols). Bluetooth is a BluetoothSIG thing (but only the low level protocols). Protocols at our layer are viewed as application layer protocols and are not expected to be standardized at either NFC Forum or Bluetooth SIG. None of these things are IETF things, so it would be strange for a "turf war" to break out since none of these things are "IETF's turf".

Yeah well… my adage is "we know the jungle, and therefore we should be afraid of the jungle". Ie, We'll have to have clear arguments why this should be part of a W3C WG work.

(Remember: my role as a possible charter facilitator is also to play devil's advocate:-)

By I also see a timing issue here. Scanning through the CCG draft, I see it may have normative dependency on rendering method (which is fine, it is handled by the VC WG) but also CBOR-LD; see my comment on the barcode stuff. What this tells me that, at the minimum, both this spec and the barcode spec must be timed towards the end of this WG's life; we will not be able to publish these specs quickly…

[iherman]

Whatever the final list of documents is, we should make a very strict and hard prioritization, listing not more than 3-4 documents that we charter for recommendation in the next round (reflecting the documents' readiness, maturity, user needs, etc). We can list the others as "tentative" items, but not as items that we commit ourselves to publish at that round.

Yes, I agree. The current goal is to prioritize as best we can, but list tenative items in case the WG gets around to them. People come and go from WGs, and everyone has different priorities; the work that gets done will be a matter of who shows up to do the work.

B.t.w., the latest charter template allows for a new section:

3.2 Tentative Deliverables
Depending on the incubation progress, interest from multiple implementers, and the consensus of the Group participants, the > Working Group may adopt the following documents as Rec-track specifications:

Web [spec name]
This specification defines [concrete description].

Draft state: Proposal in [other name] Community Group

We should probably make use of this for the lower priority items.

[iherman]

I don't disagree with you regarding today's climate. That said, just about every major NIST cryptography standard is used by almost every major nation on the planet. It's certainly the case that every browser supports NIST cryptography standards. The standards are open, published, patent-and-royalty free, etc. IOW, unless there are serious issues w/ the math, and these specs underwent years of public scrutiny and attacks, I doubt many countries will go a different way unless it's politically motivated (which does happen).

Ok, thx. This answers my first concern: we will not find myself in the BBS case.

In any case, there are no post-quantum alternatives that I know of that achieve what you say, @iherman, but I will admit that I don't know where Europe or China's cryptography standards process is wrt. post-quantum cryptography.

We may want to explicitly reach out to (international) experts. That might also lead to other additional specs beyond the post-quantum world, e.g., adding a cryptosuite for SM2 (or whatever the right denomination is) as an equivalent to, say, the ECDSA suite.

@siusin @lianqi @simoneonofri ?

Fundamentally, though, the work is intended to be a fairly lightweight application of formally published and accepted cryptography standards as applied to Data Integrity. The same upgrades can be performed to vc-jose-cose with a relatively equal amount of effort.

I think the right balance would be to do something similar with vc-jose-cose. That is also a spec to maintain.

[simoneonofri]

@iherman thank you for the pointer.

on national Chinese algorithms there is an interest for VC and for DID of adding SM2/SM3/SM4, I pointed the person I talked to [cc'ing @ruoxiran ]

on post-quantum cc'ing @andrea-dintino and @jaromil

[ruoxiran]

@iherman thank you for the pointer.

on national Chinese algorithms there is an interest for VC and for DID of adding SM2/SM3/SM4, I pointed the person I talked to [cc'ing @ruoxiran ]

on post-quantum cc'ing @andrea-dintino and @jaromil

@xicilion worked on SM2 on w3c/cid#131. Could you help look into this issue?

[xicilion]

Thanks to @ruoxiran for the heads-up.

Last year, I submitted the definitions of SM2's public and private keys to https://github.com/w3c/cid. However, to use them in VC, we still need to define separate SM2 Cryptosuites.

We have an experimental implementation in our own project:
https://github.com/Instun/sm2-2023-cryptosuite
https://github.com/Instun/sm2-multikey
However, we haven't submitted a related Cryptosuites proposal to https://github.com/w3c/vc-wg.
This work is definitely needed.