W3C

– DRAFT –
Verifiable Credentials Working Group Telco

15 January 2025

Attendees

Present
bigbluehat, brentz, DavidC, dlongley, dmitriz, hsano, ivan, JennieM, JoeAndrieu, kevin, KevinDean, mandyv, manu, Phil, Phil-ASU, Przemek, selfissued, smccown, TallTed, wesley, will, Wip
Regrets
-
Chair
brent
Scribe
Wip

Meeting minutes

<ivan> Date: 2025-01-15

brentz: Agenda today is, open PRs and at risk features for the data model, cids, status list and data integrity
… any changes or additions?

ivan: The cr submission for the CID spec has started its official journey. The first opportunity for feedback is on friday

VCDM - PRs and at-risk features

<brentz> https://github.com/w3c/vc-data-model/pulls

w3c/vc-data-model#1581

brentz: This is about fixing the JSON schema of the verifiable credential. Does what is described. Makes minor changes to the JSON schema
… has three approvals. No objections. Should be uncontroversial
… Please review

w3c/vc-data-model#1580

brentz: This rewords the self asserted VP test to remove the MUST. The test suite determined that this statement was untestable
… This is a normative change that fixes a bug. Has lots of approval, expect it to be merged after review time passed

manu: process question for ivan, this has been determined unimplementable even though it is normative. Is this change going to be okay

ivan: yep should be fine

ivan: I don't think the normative label on the PR is justified. It isnt changing a feature it makes things more precicse

manu: I can change to editorial

w3c/vc-data-model#1579

brentz: This PR updates the authors and editors list based on how folks have contributed the the spec
… other than minor fixes from TallTed, the PR is straightforward. please get reviews in

ivan: Never know what the right thing to do for former editors and authors and their affiliations
… What is the right direction

brentz: For former editors, it makes sense to me to keep affiliation when they were editors

manu: I agree with that
… For VCDM I was on the fence around the authors. There are people who have contributed a lot to the conversation and we acknowledge that. But wondering if they should be authors
… What about where content has been removed
… Would appreciate the thoughts of the group on this

<Zakim> brentz, you wanted to respond

selfissued: I am surprised to see a proposal to remove myself as an editor. I am going to make a change request to the current PR to add me back in

brentz: Chair hat off, the habit of maintaining a list of former authors and editors to the spec isnt something I think we need to do. I don't mind if my name goes

manu: On selfissued taking offence to the suggested changes. We try to make this data driven. selfissued did not contribute as much as others on the basis of the data
… You are given acknowledgments in that section
… I think this should be a data driven effort, to reward those who have submitted PRs and engaged in the commentary etc

selfissued: I understand desire to be data driven. But this doesn't include in the important ways that people contribute. Including attending calls and TPAC to contribute to the discussion etc.
… I feel I have behaved as an editor making contributions, that are not always in github. This is the false narrative. Github contributions are not the only way to contribute to the spec

manu: one last thing. The job of an editor is to edit. To raise PRs. To modify the document. To make changes to the document. The other types of contributions are valid, they are made as working group participants.
… Acknowledgements are made
… I strongly disagree with the idea that if an editor just shows up to calls, while not contributing to the document, then they should not be an editor. These things are earned.

selfissued: I want an apology.

brentz: not going to come to a conclusion on this call. lets have a conversation privately with selfissued and manu

manu: I would like this to be a public discussion

<Zakim> manu, you wanted to say one last thing and then I think we can move on.

brentz: spending 5 more minutes on this

DavidC: In my own case, not objecting to being listed an author. But the count of PRs for myself is less than it could have been as manu did some of my PRs

dlongley

dlongley: Just want to make the point that the group agreed to follow this data driven process to decide whose name would be on the spec as authors and editors. I think it is unfair to put the burden of that onto manu
… He is just executing what the group wants
… We are talking about names in the editor section of the spec, this is about editing

brentz: that matches my recollection

selfissued: That does not match my recollection to sign up to be an editor
… I have been doing some of this largely on my own time. I consider myself a consistent intellectual leader in this spec
… This doesnt always result in PRs
… Feel this is unfair to have assumed to be an editor for all this time, then as we are approaching the finish line to change this

brentz: making a suggestion. manu, selfissued and gabe regularly attended the editor call for an hour each week. Has this time commitment been taken into account

manu: No, it hasn't been taken into account

brentz: wondeirng if we can account for this time. The editor call is work

manu: I don't have an opiniob on this, the group needs to figure this out

selfissued: thanks for raising that point brent. I agree it was a substantial time commitment to be on the editor calls. I engaged in these calls
… Maybe the resolution to this is to put the working group on record that those who participate in the group should be listed as editors

ivan: for the last issue it is more complicated. There are many documents that we are editing. The editors call covers all of them, this discussion is just the VCDM
… In this case selfissued is already issued for other documents produced by this group

<dlongley> +1 to run a poll on whether joining editor calls is sufficient to be on the editor list for a specification

ivan: Whats the judgement on the rule around adding authors
… For my understanding selfissued could perhaps be listed as an author

<dlongley> +1 that intellectual contributions to the specification and not direct typing into the spec sounds more like authorship than editing.

bigbluehat: This is just for the VCDM. The editors call is general. selfissued is still and editor on other documents where his editorial contributions have been recognised.

<dlongley> +1 to bigbluehat that the "edits" were made in other specs and the editorship reflects that

bigbluehat: I don't see this as a personal affront. Just edits where not made to the VCDM, so in that sense selfissued would not be listed as an editor but still be acknowledged

selfissued: yes, editors call was a union of editors of all the specs. I went to that assuming that those listed as editors would remain so
… My time is not free, yet I gave my time to work on the VCDM spec

<Zakim> JoeAndrieu, you wanted to support that editors gotta edit

selfissued: willing to clarify resolution to say that editors that participated in calls will remain listed as editor to those specs

<dlongley> +1 to Joe -- much time and money have been spent by many individuals and companies.

JoeAndrieu: I dont find the arguments that those who commited personal time and wealth should be an editor or author. An editor in my opinion should be editing. They should be actually making edits to the spec.

<Zakim> manu, you wanted to answer the "Author" justification.

manu: Answering around what makes an author. Historically it has been significant contributions to the specifications that resulted in new sections to the document
… e.g. brentz and his contributions around the ZKP section
… significant intellectual contributions to the specification, e.g. foundational concepts integrated into the specifcation
… Another example is DavidC in the 1.0 spec added a section about subject vs holder
… as for everyone getting credit. Please look at the PR, everyone who contributed to the spec is getting acknowledgements

DavidC: question to manu, in the PRs on the commits person A raises the PR. Person B makes a lot of comments. Who gets the credit?

manu: No person B gets the credit. When person B makes a change suggestion, we make separate commits that make them get the credit for it
… That is how TallTed ended up at the top of the list, he regularly provides suggestions to text
… again linecount does not mean everything. But we also take into account comments etc. To get a good sense of contributions to the spec

<brentz> Proposal: those listed as editors on the specifications who attended the weekly editors call will be listed as editors

<selfissued> +1

<dlongley> -1 (attending a weekly editor call is insufficient to be listed as an editor, significantly more work is required to actually edit the documents themselves for them to become specs, which is the job of an editor)

<JoeAndrieu> -1 for documents they didn't edit

<brentz> Proposal: those previously listed as editors on the specifications who attended the weekly editors call will be listed as editors

<brentz> Proposal: those already listed as editors on the specifications who attended the weekly editors call will continue to be listed as editors

<manu> -1 if they didn't do measurable changes/edits to the documents the were editor's for.

<selfissued> +1

<DavidC> 0

<brentz> +1

<bigbluehat> -1 editing should result in edits

<JoeAndrieu> -1

<Wip> -1

<ivan> 0

<dlongley> -1 (attending a weekly editor call is insufficient to be listed as an editor, significantly more work is required to actually edit the documents themselves for them to become specs, which is the job of an editor; if they did this then no issue)

<smccown> 0

<hsano> 0

<JennieM> -1

<Phil-ASU> -1

brentz: not leading to resolution

w3c/vc-data-model#1566

brentz: spending the remaining time looking at the other prs

brentz: This PR update refreshService

manu: this was initially to address using real examples in the specification
… This was done mostly accept for refreshService
… We dont have a v2.0 example
… I think there is pushback to using an 2.0 example

w3c/vc-data-model#1560

brentz: this PR is about making the abstract abstract

manu: TallTed I think you objected because the content matched the introduction.
… I think I objected to your proposed text because it was too wordy. It would be good to make an attempt at it.
… I think the current PR is not going to go it. I marked it pending close

TallTed: As I put on the PR. The abstract that chatgpt helped me make is an abstract of the entire document
… The current abstract is introductory. And is not an abstract
… I don't see value having the current paragraph as an abstract
… I suggest dropping it an not having an abstract

brentz: One path would be to modify it to remove the paragraph. The other path would be to make it more concise

manu: I dont think it improves the document in its current shape
… I dont think we can delete the abstract, because respec complains
… I would be fine with keeping the abstract and reworking the introduction spec
… Typically the W3C abstracts dont follow the academic abstract pattern
… They aim to give folks a paragraph concise understanding of the spec
… Suggest we try to keep reworking it until it is acceptable

manu: I will make another attempt

ivan: dropping the abstract is not an option due to the publishing rules

brentz: Those are the PRs in the VCDM
… manu do you have the set of at risk sections

manu: bigbluehat might have those, I dont think we have any more

bigbluehat: Yep, not in the VCDM
… bitstring has a few things

<brentz> https://github.com/w3c/controller-document/pulls

brentz: moving to controlled identifiers

Controlled Identifiers

w3c/cid#144

brentz: This pr attempts to adjust the title of the document, to call is controlled identifiers and drop the document following the DID spec
… At the time everyone was happy with this
… selfissued who wasnt on the call has since raised an objection

<dlongley> +1 to Ivan

ivan: I think selfissued is right, we should have passed a resolution. However this is a minor change. I would prefer to make the change

manu: I agree with ivan, lets run a resolution for this change

<DavidC> +1

selfissued: We argued over this already. We eventually got to something with consensus and made that change
… Then at the last minute we are changing our minds again
… furthermore, linguistically controlled identifier document is not suprisingly different from controller document
… wheras controlled identifiers and controller document are not that closely linked
… people in the community know the work as controller document
… not in favor of changing our mind in the last minute

brentz: First, apologies for not running a proposal last week. We should have
… While I see the sense in unifying CIDs with DIDs
… I also see that maybe controlled identifier documents is talking about the format of the document that is returned when you acces a controlled identifier
… I do not have a strong opinion either way
… Will run the proposal from dlongley

<brentz> PROPOSAL: Make the title in the controlled identifiers document specification "Controlled Identifiers (CIDs) v1.0"

<brentz> 0

<manu> +1

<dlongley> +1

DavidC: just to say that everything we produce is a spefication and a document. We could add document to all our specs

<ivan> +1

<selfissued> -1

<JoeAndrieu> +1

<smccown> +1

<DavidC> +1

<JennieM> +1

<Wip> +1

<bigbluehat> +1

<TallTed> +1

<hsano> +1

<Phil-ASU> +1

brentz: selfissued noting you are the only one objecting, would you formally object if this was resolved over your objections

selfissued: no I would not, however belive this is a bad idea and was rushed at the last minute

RESOLUTION: Make the title in the controlled identifiers document specification "Controlled Identifiers (CIDs) v1.0"

ivan: Don't know when the PR went in, if the one week is not over then I would ask for this to be merged as quickly as possible

brentz: chair hat on, the informal decision last week with a review period plus the resolution today means we can merge the PR today

<manu> agree with brentz's justification on merge window.

Summary of resolutions

  1. Make the title in the controlled identifiers document specification "Controlled Identifiers (CIDs) v1.0"
Minutes manually created (not a transcript), formatted by scribe.perl version 242 (Fri Dec 20 18:32:17 2024 UTC).

Diagnostics

All speakers: bigbluehat, brentz, DavidC, dlongley, ivan, JoeAndrieu, manu, selfissued, TallTed

Active on IRC: bigbluehat, brentz, DavidC, dlongley, hsano, ivan, JennieM, JoeAndrieu, KevinDean, mandyv, manu, Phil-ASU, Przemek, selfissued, smccown, TallTed, Wip