[wg/vc] Verifiable Credentials WG recharter

[iherman]

New charter proposal, reviewers, please take note.

Charter Review

Charter

Diff from previous charter

diff from charter template

chair dashboard

• Existing WG recharter
• If this is a charter extension or revision, any issue discussion:

The current charter ends in June '24. By then, all Rec track documents should be in CR (the main ones have been in CR for a while already), and the WG is confident to be able to publish the Recommendations in January '25. The original thought was to ask for a simple charter extension. However, the WG has already agreed to set up a maintenance WG once this WG runs out, hence the idea to create a new charter which is, mostly, the same as the current charter, but with the following addition to the scope:

Once all the planned Recommendations have been published, the Working Group will continue in maintenance mode to handle errata. No new Recommendations are planned. Class 4 changes for Recommendations published by the Working Group are out of scope, except if serious security issues come to the fore that require changes in a Recommendation.

I.e., this proposed charter update would save us, and everybody else, an extra administration in 6 -7 months.

Although the diff file shows more changes, they are not substantial. The only other major difference is that the list of rec track deliverables has been updated to reflect the current status. All other changes are administrative, updating some links, etc.

I am not sure that we really need horizontal reviews on the charter. It had been reviewed before the AC vote, and nothing has changed; as emphasized above, there is no intention to do further specification work under this charter.

Comments are preferred on https://github.com/w3c/vc-wg-charter

cc: @brentzundel @pchampin

[iherman]

Just wonder where we are with this... Could TiLT make a decision on this to go forward?

[iherman]

Per the latest WG meeting (https://www.w3.org/2017/vc/WG/Meetings/Minutes/2024-05-15-vcwg#section2-1) the WG did not get to a consensus to go with this charter proposal. As a consequence, I was instructed by the WG to stop this rechartering process and ask for a 6 months extension instead.

@plehegar @brentzundel

[iherman]

@plehegar, the consensus issue at the WG has been resolved. The new, and consensus based, charter proposal is now the one on the relevant repository, i.e.,

[Charter:] https://w3c.github.io/vc-wg-charter/

[Diff from previous charter:] https://w3c.github.io/vc-wg-charter/diff.html

I believe the feedback we received indicates that there is indeed no need for a formal set of horizontal reviews, taking into account the fact that the changes v.a.v. the old charter are minimal. The quote in the original issue above, which is the only relevant (i.e., non-administrative) change now says:

Once all the planned Recommendations have been published (see list of deliverables below), the Working Group will continue in maintenance mode to handle errata. No new Recommendations are planned. Class 4 changes for these Recommendations are out of scope, except:

• Features that had been listed as "At Risk" during the CR phase of the Verifiable Data Model specification, had been removed from the final document due to missing the CR Exit Criteria, but have been developed further by the community providing a possibly adequate consensus and support to be added to the Recommendation. At the time of writing this charter, these terms are: the refreshService, evidence, confidenceMethod, renderMethod, and termsOfUse properties (and related classes like RefreshService, ConfidenceMethod, etc.).
• Serious security issues that arise, requiring changes in a Recommendation.

Can we move to the AC vote on the charter asap? It would be good to have the results available by TPAC?

cc @brentzundel @pchampin

[iherman]

@plehegar any news on #455 (comment) ?

[plehegar]

This charter draft needs to go through horizontal reviews, at least giving an opportunity but we could look at moving forward quickly.

[plehegar]

Unless we hear otherwise, we could move to get TiLT approval to start AC in early July.

[iherman]

Just to be clear, you meant "start AC Vote" early July, right?

[himorin]

• performance HR no longer exists in Coordination section
• better to list added (or extracted / escalated from incubation) normative specification in history table??

[iherman]

• performance HR no longer exists in Coordination section

I am not sure what you mean. The coordination section begins with:

For all specifications, this Working Group will seek horizontal review for accessibility, internationalization, performance, privacy, and security with the relevant Working and Interest Groups, and with the TAG.

B.t.w., this text was in the old charter and has been reused unchanged.

• better to list added (or extracted / escalated from incubation) normative specification in history table??

Just to understand what you mean: there was one spec in the original charter which was listed as a possible candidate for a rec-track document, but was conditional on the advancement of incubation. This is the BBS cryptosuite. This document has indeed been taken up by the WG after all (it is currently in CR) and has been added to the list of formal deliverables. All the other documents are editorial consequences of restructuring larger documents by branching off parts into standalone documents.

With that in mind, do you propose to add the acceptance of the BBS spec into the history table? I have no problem with that, I am just trying to be sure I understand.

Thanks

[iherman]

@himorin, I have created the PR w3c/vc-wg-charter#120 to add the missing entry to the history table.

cc @plehegar

[himorin]

note: not HR hat, but rather from tilt points...

• performance HR no longer exists in Coordination section

I am not sure what you mean. The coordination section begins with:

For all specifications, this Working Group will seek horizontal review for accessibility, internationalization, performance, privacy, and security with the relevant Working and Interest Groups, and with the TAG.

B.t.w., this text was in the old charter and has been reused unchanged.

ah, missing details, sorry.
charter template has been updated to remove non-existing performance HR while ago. So, copying from several old one could have that.

For all specifications, this (Working|Interest) Group will seek horizontal review for accessibility, internationalization, privacy, and security with the relevant Working and Interest Groups, and with the TAG.

• better to list added (or extracted / escalated from incubation) normative specification in history table??

Just to understand what you mean: there was one spec in the original charter which was listed as a possible candidate for a rec-track document, but was conditional on the advancement of incubation. This is the BBS cryptosuite. This document has indeed been taken up by the WG after all (it is currently in CR) and has been added to the list of formal deliverables. All the other documents are editorial consequences of restructuring larger documents by branching off parts into standalone documents.

With that in mind, do you propose to add the acceptance of the BBS spec into the history table? I have no problem with that, I am just trying to be sure I understand.

sorry for unclear. I also not sure how to handle these specs while these additions are actually allowed by clause mentioned at the last part of deliverables section in running charter, but I suppose we need to add to history table in some way (= which I am not sure, on how to do)...

[iherman]

sorry for unclear. I also not sure how to handle these specs while these additions are actually allowed by clause mentioned at the last part of deliverables section in running charter, but I suppose we need to add to history table in some way (= which I am not sure, on how to do)...

Can you look at w3c/vc-wg-charter#120 to see if that works? As I said, BBS is the only spec that has been brought in by the WG.

[simoneonofri]

Hi everyone,

from Security Point of View, as we already talking about it.

1. Thank you for adding the exception for the Security

Once all the planned Recommendations have been published (see list of deliverables below), the Working Group will continue in maintenance mode to handle errata. No new Recommendations are planned. Class 4 changes for these Recommendations are out of scope, except:

• Serious security issues that arise, requiring changes in a Recommendation.

2. If possible I would add the meta Threat Model/joint deliverable collaboration, along the lines of what we did in FedID joint work on rights-respecting digital credentials #458 and Threat Modeling for Decentralized Identities WICG/digital-credentials#115

3. While I'm at it, do we have any news on BBS test vectors? BBS Cryptosuite v2023 2023-12-15 > 2024-01-15 security-request#61

Thank you,

Simone

[iherman]

Hi everyone,

from Security Point of View, as we already talking about it.

1. Thank you for adding the exception for the Security

You are welcome :-)

2. If possible I would add the meta Threat Model/joint deliverable collaboration, along the lines of what we did in FedID joint work on rights-respecting digital credentials #458 and Threat Modeling for Decentralized Identities WICG/digital-credentials#115

I understand but I am not sure what changes this requires on the (new) charter. I looked at the FedID WG charter but I did not find any explicit reference to this. I noticed that the coordination section includes references to the WebAppSec WG, but I am not sure if that is relevant for this WG.

Please advise

3. While I'm at it, do we have any news on BBS test vectors? BBS Cryptosuite v2023 2023-12-15 > 2024-01-15 security-request#61

I will forward this question to the relevant persons in the WG, but I will ask them to respond to you separately (by email); this should not hold up this charter's evolution and therefore it should not be discussed in this issue.

Cheers

Ivan

[himorin]

no comment or request from i18n

[ruoxiran]

no comment or request from APA.

[iherman]

From #455 (comment):

3. While I'm at it, do we have any news on BBS test vectors? BBS Cryptosuite v2023 2023-12-15 > 2024-01-15 security-request#61

For the record, there is an answer in https://lists.w3.org/Archives/Public/www-archive/2024Jun/0003.html. The possible continuing discussion on that should not be relevant for this issue.

[svgeesus]

B.t.w., this text was in the old charter and has been reused unchanged.

So, this charter is not starting from the current charter template but instead, merely alters a copy of the original charter?

That explains a bunch of changes and omissions, like incomplete testing policy, no mention of following TAG Web Platform Design Principles, and so on. It also explains the lingering "performance" in the Coordination section, which @himorin already mentioned, and the mention of Positive Work Environment (which is now simply called Code of Conduct). And explains why it still mentions "the Director".

Which in turn means that the AC will see agreed-upon changes for all charters, reverted in this one.

It would honestly have been simpler to start with the current template but please, look at this diff and back-port the current wording to this proposed charter.

[simoneonofri]

Hi everyone,
from Security Point of View, as we already talking about it.

1. Thank you for adding the exception for the Security

You are welcome :-)

:)

2. If possible I would add the meta Threat Model/joint deliverable collaboration, along the lines of what we did in FedID joint work on rights-respecting digital credentials #458 and Threat Modeling for Decentralized Identities WICG/digital-credentials#115

I understand but I am not sure what changes this requires on the (new) charter. I looked at the FedID WG charter but I did not find any explicit reference to this. I noticed that the coordination section includes references to the WebAppSec WG, but I am not sure if that is relevant for this WG.

Please advise

It is included in the updated version as:

A Threat Model of Digital Credentials-related technologies concerning security, privacy, and human rights. These findings will be used as input for any of the group's Digital Credentials deliverables. This will be developed in collaboration with W3C's Technical Architecture Group (TAG), Privacy Interest Group (PING), Verifiable Credentials Working Group (VCWG) and other relevant groups.

3. While I'm at it, do we have any news on BBS test vectors? BBS Cryptosuite v2023 2023-12-15 > 2024-01-15 security-request#61

I will forward this question to the relevant persons in the WG, but I will ask them to respond to you separately (by email); this should not hold up this charter's evolution and therefore it should not be discussed in this issue.

Thank you, received the mail from @Wind4Greg and synched with @jaromil and @andrea-dintino. When the new test vectors are ready, we proceed.

Cheers

Ivan

Cheers,

Simone

[iherman]

2. If possible I would add the meta Threat Model/joint deliverable collaboration, along the lines of what we did in FedID joint work on rights-respecting digital credentials #458 and Threat Modeling for Decentralized Identities WICG/digital-credentials#115

I understand but I am not sure what changes this requires on the (new) charter. I looked at the FedID WG charter but I did not find any explicit reference to this. I noticed that the coordination section includes references to the WebAppSec WG, but I am not sure if that is relevant for this WG.

Please advise

It is included in the updated version as:

Ah! That's clear now. I have created a separate PR, including the FedID WG on the list of external coordination: w3c/vc-wg-charter#122.

Does that work for you?

[simoneonofri]

Does that work for you?

Thank you, yes.

I don't know about including the deliverable among the group deliverables as well. If you take how it's done now I used as a basic template precisely that of VCDM.

What do you think?

[iherman]

Does that work for you?

Thank you, yes.

I don't know about including the deliverable among the group deliverables as well. If you take how it's done now I used as a basic template precisely that of VCDM.

What do you think?

I would prefer not to add this as an explicit deliverable. If there is a common deliverable with FedID, it will not be a Rec-track document, so it can be published without too many problems anyway. On the other hand, this charter is, essentially, for a maintenance WG, i.e., a low-key activity, and this may raise some eyebrows unnecessarily...

[plehegar]

I see that IETF is mentioned in the external organizations from a security perspective, but nothing is mentioned related to SPICE. Do we desire or expect some coordination (and review) with that Group ?

[iherman]

Such entry in the charter represents some sort of obligation; in view of history, that may be problematic. Some level of coordination will happen in any case, if for no other reason than the overlapping membership of the groups. But obligation is a different matter.

I will check with the chair but, strictly personally, I do not think it is a good idea to add it to the charter.

[brentzundel]

I agree with Ivan's assessment

…

On Fri, Jul 12, 2024 at 12:53 AM Ivan Herman ***@***.***> wrote: Such entry in the charter represents some sort of obligation; in view of history, that may be problematic. Some level of coordination will happen in any case, if for no other reason than the overlapping membership of the groups. But obligation is a different matter. I will check with the chair but, strictly personally, I do not think it is a good idea to add it to the charter. — Reply to this email directly, view it on GitHub <#455 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACPFKP4M4QWRJQPINNMJZHDZL54OPAVCNFSM6AAAAABGLS7SGCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEMRUHE2DEMJYGI> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[npdoty]

For coordination on privacy, I wanted to make sure collaboration on the joint work regarding privacy, security and human rights was explicitly reflected in this text. I believe this merged PR addresses that: w3c/vc-wg-charter#122

[plehegar]

Thx @iherman @brentzundel . Let's wait for the first SPICE meeting to happen to see if we want to revise the assessment. In the absence of new information, we'll move forward as-is.

[simoneonofri]

Hello everyone, back from IETF120.

In general, the goal of SPICE is to do profiles/credentials formats (aka Securing Mechanisms).

They are starting with Selective Disclosure of the CBOR/COSE binary format, then SD-CWT along the lines of SD-JWT which is the JSON/JOSE one, also taking care of discovery aspects and with a focus on non-human credentials but winking at Human ones as well and, finally, some identifiers.

[plehegar]

Proposed W3C Charter: Verifiable Credentials Working Group (until 2024-09-18/19)