Verifiable Credentials Working Group Telco — Minutes

Date: 2022-12-07

See also the Agenda and the IRC Log

Attendees

Present: Brent Zundel, David Chadwick, Dave Longley, Manu Sporny, Michael Prorock, Joe Andrieu, Orie Steele, Gabe Cohen, David Waite, Markus Sabadello, Jeremie Miller, Ted Thibodeau Jr., Michael Jones, David Lehn, Mahmoud Alkhraishi, Przemek Praszczalek, Brian Richter, Dmitri Zagidulin, Phillip Long

Regrets:

Guests:

Chair: Brent Zundel

Scribe(s): Gabe Cohen, Manu Sporny

Content:

Brent Zundel: starting with an agenda review…announcing the next F2F meeting. asking for status updates for work items. review PRs. bulk of the meeting: StatusList2020 as a possible work item for the group. if time..issue discussion.
… any additions or changes from the group?.

Manu Sporny: don’t know how to say this…we’ll get to it with pull requests. related to the @context discussion. as an editor, difficult to have PRs with this out there. have a suggestion for the editors to ‘get unstuck’… can talk to when we get to PRs. “how do we get to progress in the face of a big unknown hanging over the group?.

Brent Zundel: any first timers, introductions or reintroductions?.

Brian Richter: Brian Richter. have a company Aviary Tech. in the CCG + DIF. first time here as an Invited Expert..

Brent Zundel: f2f meeting for the VCWG. in Feb, 14-16 in recognition that Feb is still winter. planning to hold it in Miami.
… … please jump on if you have any questions, all details we have at this point.

1. Work Item status updates/PRs.

Brent Zundel: Work item status updates & PRs. please jump on the queue if you have an update.

Manu Sporny: https://github.com/w3c/vc-data-model/pulls.

1.1. Add nonTransferable property to credentials vocab (pr vc-data-model#969)

See github pull request vc-data-model#969.

Manu Sporny: VCDM first. two PRs - one is nonTransferrable property. do not merge is listed on it. some discussion, but need more. chances of it making it in are fairly slim. don’t know what the group should do with prs like this. can leave it open. hasn’t been much progress.

1.2. Added presentationSchema (pr vc-data-model#987)

See github pull request vc-data-model#987.

Manu Sporny: next item: 987; adds presentationSchema, by David Chadwick. good discussion. still some things being asked for. 3 people continuing to request changes. expect David to keep engaging to move it forward. Other than that, no new PRs..

1.3. Data integrity.

Manu Sporny: https://github.com/w3c/vc-data-integrity/pulls.

Gabe Cohen: VC data integrity: no new pull requests. difficult to write PRs when the topic of “make @context optional” hangs over the group. need to find consensus and move on.

Manu Sporny: other option - if no objections from the group - let’s assume we don’t have consensus on making @context optional in future PRs, at least I raise, and will run on that basis until we have consensus on that item. putting that to the group - if no objections, and assuming @context is not optional, we can get back to raising PRs.
… questions on that approach?.

Dave Longley: +1 to proceed with current PRs as if we don’t have consensus on making @context optional (as we don’t.. so just an acknowledgment of present reality).

David Chadwick: give people a heads up. a number of different issues that overlap with one. that is - what is the actual data model? what is the credential metadata? what is the proof? how are they related? quite a biggie. affects a lot of the properties, i.e. the issuanceDate - is it a property of the proof or the credential.

Orie Steele: agree with what DavidC said. have 2 components: core data model and securing the core data model formats. has big impacts on securing the core data model formats. coming back to Manu’s point. even if we proceed with making PRs in the core data model assuming the TR looks as it is today, we will still have these issues come up in the ‘securing the core data model’ for reasons DavidC mentioned..

Michael Prorock: +1 orie.

Orie Steele: helpful to have a special topic call about “where metadata is present in the core data model” and securing the core data model.

Brent Zundel: heard no one speak against your suggestion. clear to proceed as you intend.

Manu Sporny: thank you.

Brent Zundel: other work items to give status updates or PRs?.

Orie Steele: no additional prs in either of the work items that I am an editor of (JsonWebSignature2020, VC-JWT).

2. Status List 2020.

2.1. Adopt and publish StatusList2021 as an credentialStatus extension (issue vc-data-model#974)

See github issue vc-data-model#974.

Brent Zundel: move to remaining topic. StatusList2020. have an issue open ^.

Manu Sporny: providing background. the VCDM has a property called ‘credentialStatus’ purpose is to tell you what the status of the credential is – revoked, suspended, something else. this mechanism allows an issuer to issue a cred and still have the ability to say the credential is still valid or no longer valid.
… can think of something like an employeeId credential, issued to an employee - they have it in their mobile phone, at some point they change jobs away from that employer. the issuer then revokes the credential saying ‘they are no longer at the company’.

Manu Sporny: Status List 2021: https://w3c-ccg.github.io/vc-status-list-2021/.

Manu Sporny: we did not define a concrete representation to do this in v1 of the work. there is an item VCStatusList2021 incubated in the CCG link in chat. a number of implementations. people seem to be OK with the latest version of it. we do not expect drastic changes to the spec at this point. there is a test suite for the spec..
… this issue suggests adopting the status list 2021 from the CCG. suggested a month ago, more depth today.

Brent Zundel: properties in the VCDM that do not have a normative way to fulfill. do not love statuslist2020, but it is fine. people feel similarly. solid and basic way of providing what a credential status is. char hat off – in full support of us considering this as a work item. chair hat on – point of this is to decide whether it is a work item.
… what do you think about bringing it in, or what that means?.

Dave Longley: just to be clear, the issue says “StatusList2021” (not 2020).

Michael Prorock: I am in the “it’s fine” camp, it’s not ideal. have not seen anything practical, better, more widely deployed, tested. natural if we are going to bring in a status list … this is what 2021 enables. i have to reiterate my hatred for dates in titles.

Manu Sporny: Link to current test suite: https://w3c-ccg.github.io/status-list-2021-test-suite/.

Brent Zundel: apologies, it is StatusList2021.

Orie Steele: #1 - we have to define at least one of these things to keep the credential status property in the data model. been said, but it’s important. have a number of concerns with this work item. have not seen a version that supports vc-jwt or other security assertion formats.
… this item like so many other items, assumes a core data that is subject to dispute. not appropriate to bring it in at this time. expands the scope of the group, new work. not sure how to resolve issues with this suite if @context being optional is handled in a different manner. appreciate Manu’s comment, but do not feel comfortable until it’s resolved.

Manu Sporny: supportive of what Orie said. want to roll back to “it’s fine but not great.” everyone is lukewarm about it. we want a more aggressive privacy option. been viewed as ‘adequate’ not amazing. effectively good enough..

Dave Longley: +1 to StatusList2021 being “adequate, but not great” :).

Manu Sporny: we could do better in the future if we were willing to do more advanced crypto. people have not reacted violently against 2021’s herd privacy approach. just ok - but that’s fine.

Gabe Cohen: I just wanted to respond to Orie’s comment, we do have an implementation that works w/ VC-JWT and I can add an example to existing draft if that’s helpful..

David Chadwick: coming back to the point last time i spoke. big issue about the data model. credentialStatus should not be a part of the data model, because it’s bound to a proof. cannot have it bound…the status should be a part of the proof and not bound to the core data model.

Brent Zundel: the work is there for us to do regardless of whether we bring it in now. up to the working group whether we bring it in now. not bringing it in now doesn’t mean it’s not there for us to do.

Manu Sporny: to respond to DavidC: no it has nothing to do with the proof. it makes more sense…credentialStatus has to do with the credential itself, not about the proof. it is about the fact that you are issued a uni diploma, and whether it is valid or not, regardless of cryptographic protection on any of the data. business rules, not cryptography.

Dave Longley: +1 to manu.

Orie Steele: agree current interpretation is consistent with what Manu said. DavidC may be onto something. if not to be handled as business validation logic, could be handled as part of the proof. could be relevant to the proof section, not credential metadata. comes back to “what is the core data model” do we have a clear understanding of the differences b/w these things..
… current StatusList2021 - it is a property of the credential. after credential verification of the status list, a verifier can dereference and do checking. it is a business process the verifier could ignore (e.g. check signature, not status)..

Dave Longley: seems the question is: “are you revoking a digital signature … or a credential?” (or could there be both of these things? and is that too complicated?).

Dave Longley: +1 to Orie where credential status is handled the same regardless of securing format.

Manu Sporny: +1.

Orie Steele: if checking the proof/status is a part of the verification process. in Jose/cose use the crit header. … how are we going to address these scenarios if we have more than 1 core data model or security format? want credential status checking to be handled consistently. data integrity proofs and jose/cose formats around the same core data model. not clear the best path for the item.

Joe Andrieu: want to elevate DavidC’s point to a conversation we haven’t fully engaged with yet. What is a “Credential” vs “Verifiable Credential.” we have a disconnect. my sense - a credential without a proof is a “credential” it is in json and maybe a proto-vc. with a proof it’s a verifiable credential. there’s another thing in the real world called credentials that people use VCs to represent (e.g. a bachelors degree).

Orie Steele: +1 Joe.

Dave Longley: +1 to Joe.

Joe Andrieu: has nothing to with a VC. there is a weird semantic disconnect. don’t know where we should come down. in the JFF plugfest, people created the id of the cred as the real id, not the id of the digital object.

Brent Zundel: to StatusList2021 - we can decide the direction if we bring it in as a work item.

Manu Sporny: yes, it’s different in VCs – VCs aren’t x509s ….

David Chadwick: thanks Manu for point of CredStatus could be the status of the degree. want to point out in x509, revocation is entirely with the digital signed cert. says we need to have 2 different representations (David Longley hinted in chat). still needs to be a cryptographic revocation list, e.g. if a university lost its private key the cred could still be valid. need two separate revocation mechanisms.

Phillip Long: from the edu perspective Joe described. in edu, has never been an opportunity for a cred to be shared with anybody at all. if it is an “official credential.” the only source of truth has been the institution itself/registrar. any time anyone has a presentation about their degree or transcript to a 3rd party it needs to come from the institution/registrar, since they’re the only one’s considered author.

Gabe Cohen: itative.

David Chadwick: @manu it could if there is flag to say which revocation it is referring to.

Manu Sporny: That flag already exists, DavidC :).

David Chadwick: @manu. Excellent!!.

Manu Sporny: It’s called “statusPurpose” – https://w3c-ccg.github.io/vc-status-list-2021/#statuslist2021entry.

Phillip Long: credentials are making this tamper evident, which allows this interaction to change. conversation with national student clearing house. they agreed to put a signature on a degree VC which is a ‘sufficient verification of truth’ and does not need to come from an institution itself. distinction is important - verifiable means you can hand it to a 3rd party. treated as authentic and original.

Manu Sporny: To be clear, I disagree that this is something that should exist in the proof, but we can have that discussion later :).

Manu Sporny: responding to DavidC question about cred or proof. StatusList2021 is agnostic to where it is placed. just a status list. could be about a credential, proof, sheep. doesn’t matter where it shows up. it is just a bit field and you flip bits. though, I disagree you should put this in proof metadata. if the group wants to do this, it can serve both purposes.

Brent Zundel: is the work item in the scope of the charter? is it supported by at least 3 participants from different organizations? yet to poll. should we adopt it? does not require strong consensus. will not be taking a proposal today to bring it in as a work item. may do so during the next call. any other questions/comments/concerns?.

Orie Steele: we ran a proposal to adopt ecdsasignature2020 a week ago, did we follow the process then?.

Brent Zundel: 2 weeks ago. in response to the resulting conversation about that work item. resulting in the chairs establishing this process. the process just mentioned did not exist during that conversation. it came into being as a result.

Ted Thibodeau Jr.: no strong feelings on the work item. probably should be taken up. something like it will be necessary. another one will serve roughly the same purpose and we’ll have to do it. abundantly clear to me and the people in this group that we have some glaring issues with the existing data model and what is really going on.
… as we were discussing a few weeks ago re: validFrom/until attributes, we have 4 dates instead of 2, but may be 6 or 8. tracks with crypto/payload validity. don’t have a strong enough picture in my head to go down the list.
… brief back and forth with DavidC. basic stick figure diagrams of the cred metadata, the Credential, the proof, proof metadata. not the only 4 we need to talk about. need to spend some focused time on that. could be a zoom whiteboard or F2F - open to ideas. sooner we do it the better off everyone will be. the result will be breaking changes.

3. Issue Discussion.

Brent Zundel: https://github.com/w3c/vc-data-model/issues?q=is%3Aissue+is%3Aopen+label%3Adiscuss+sort%3Aupdated-asc.

Brent Zundel: next topic, issue discussion. sorted in order we will be covering them.

3.1. Representing Mutli Subject Credentials in the VCDM (issue vc-data-model#931)

See github issue vc-data-model#931.

Brent Zundel: first issue #931, representing multi subjects in the data model.

Gabe Cohen: may be better suited to have a discussion than an issue.

Ted Thibodeau Jr.: no please. discussion is arguable worse. could be more confusing than just reading a thread of an issue..

4. (Meta topic) discussions on issues in general.

Brent Zundel: completely forgot that i wanted to talk about how we wanted to start using discussions. we are planning on moving some issues to the ‘discussions’ tab and making more use of that. see how it goes to move those issues forward. the editors have the authority to make that decision (move to discussion). the issue should be a discussion/question, not proposing specific solutions. once a discussion develops to a certain point, a related issue could be raised.
… to propose specific changes to the data model. should have said that earlier. considering this as a tool. let’s talk about this for a couple minutes..

Ted Thibodeau Jr.: one of the big failures of this ‘discussion’ thing github made is that it is not easy to see the things added to the ‘discussion’ since the last time you looked at it. no useful indicator of ‘i read this but not that’.
… in order to track the whole discussion you need to scroll down slowly and see what replied have been added. i know issues don’t thread the discussion and it is challenging to keep up with that. nothing will keep up with ntp did if you had a good news reader. this is one of the worst re-inventions i’ve seen - and i’ve seen a lot. i will try to participate if things go there…will be a headache. curmudgeon out!.

Ted Thibodeau Jr.: “meta issues” == make a meta tag.

Dave Longley: +1 to TallTed, was going to suggest the same thing.

Manu Sporny: I think what Ted is saying has value. issues raised aren’t concrete issues on the spec. not exactly questions. more like philosophical conversations without changes in the spec. to boil it down - would you disagree with marking something as a “conversation” Ted? may not result in anything actionable.

Ted Thibodeau Jr.: +1 a “conversation” tag on some issue(s) would likely work.

Manu Sporny: the thread to date may not result in anything actionable, but people should talk until it is clear there is something actionable there. the editors have had a hard time looking at these issues, saying “i want that conversation to continue, but it’s so nebulous/vague, have no idea where it’s going, let them keep talking…may get to some spec text changes”.

Ted Thibodeau Jr.: or pushing that thread to mailing list instead of github.

Dave Longley: “not ready for WG review” / “discussion only” label or something..

Manu Sporny: category of a discussion. would you object to a label for conversation?.

Dave Longley: +1 to “conversation” tag.

Ted Thibodeau Jr.: no objection. some things are meant for the mailing list and not github yet.

Dmitri Zagidulin: +1 to conversation tag over github discussions.

Orie Steele: conversations should probably happen on the mailing list. from an editorial perspective. wherever conversations happen, important they happen. people should come to a shared mental model to get to concrete changes. once concrete changes then an issue should be created with a clear title and description.

Dave Longley: +1 to ensuring we can mark conversations in a way that gets out of the editors’ way somehow.

Orie Steele: if that happens midway through a 2000 comment thread it can be hard for the editors to pull that out. regardless need a clear issue that is easy an actionable. can happen on the mailing list or issue. the clear intention issue should refer to the discussion.

Ted Thibodeau Jr.: +1 concrete change suggestion might belong in an issue, or might proceed straight to PR, if there’s something like consensus on “this is the action we should try”.

Dave Longley: +1 “conversation”-tagged issues should produce other issues that aren’t conversations but real concrete issues / proposals.

Orie Steele: make sure everything is linked together and clear to the editors what the action is.

Brent Zundel: better to more strictly regulate issue creation. do folks agree? what does it mean? try out discussions? label? mailing list? some combo? let’s find agreement.

Manu Sporny: hard to police people opening issues. need criteria and judgement calls against them. let’s try to process based on what the WG feels is the priority. slight pushback on regulation and criteria. other things we need to spend our time doing..

Joe Andrieu: +1 to tracking this as github issues (email record is hard to spin-up).

Manu Sporny: also speak against putting things on the mailing list. say this as a die-hard supporter from the 90s. GitHub is great at linking and cross-linking. that has really benefitted the standards making process. don’t want to lose that. mailing list conversation is fine but feels ephemeral, even if it’s not. hard to point back to a 10yr old conversation. much easier in GitHub.

Ted Thibodeau Jr.: every message to the mailing list is archived, with a URL, so it shouldn’t be that hard to point back.

Brent Zundel: +1 to Manu’s concerns.

Ted Thibodeau Jr.: I’d be very surprised if anyone needs to point back to a 10 year old conversation relative to this group’s work.

Manu Sporny: want to make sure we keep that. can achieve all these things by having a tag ‘conversation’ and give chairs/editors leeway to tag things. we will get to a point in the WG where we can’t address every issue. we’ll have to say we’ve run out of time for some, and the issues will be shifted to the next version..

Michael Prorock: +1 orie.

Orie Steele: fine as long as there is a clearly way to distinguish issues editors will take action on vs have a discussion on. could turn the discussion feature off. if we don’t intend to use the mailing list, we should turn it off, or use the mailing list to send out issues..drive them to come to some resolution. conversations and clear actions needed.

Ted Thibodeau Jr.: the WG mailing lists will, and should, never go away..

Brent Zundel: have a question label - indicates someone should jump on and answer it. have agreement to create a ‘conversations’ label. may or may not result in a concrete representation. will move forward.

Orie Steele: +1 Joe.

Joe Andrieu: want to say the mailing list is best for announcements. Requests for feedback too. not great for long discussions.

Brent Zundel: will bring up StatusList2021 next week. please jump on issue #931 in the meantime..
… see you next week and thank you to Gabe.