Verifiable Credentials Working Group Telco — Minutes

Date: 2023-11-01

See also the Agenda and the IRC Log

Attendees

Present: Ivan Herman, Kaliya Young, Brent Zundel, Manu Sporny, Andres Uribe, Benjamin Young, Ted Thibodeau Jr., Joe Andrieu, Hiroyuki Sano, Paul Dietrich, Dmitri Zagidulin, Will Abramson, Gabe Cohen, Dave Longley, Przemek Praszczalek, David Chadwick

Regrets:

Guests:

Chair: Brent Zundel

Scribe(s): Paul Dietrich

Content:

Brent Zundel: review minutes from yesterday.. progress on a number of PRs.
… we are now 1 month overdue for CR on core data model. We are going to be more aggressive on closing or deferring issues that we would otherwise love to work on.
… propose additions to agenda?

1. Work Item status updates/PRs.

Manu Sporny: VCDM. We went through all PRs yesterday. check minutes. ECDSA and EDDSA have no active PRs. Waiting for CR publication next tuesday.
… Data integrity BBS specification… getting ready to align with the other specs that Greg did. Thanks Ted for 85 updates.
… VC Bit-string-status-list. The renaming has been redone on the repo. A new PR on media types.

Ivan Herman: To be precise: the 4 related data integrity specs have been requested for CR next Tuesday. Hopefully approval will come in time.

Gabe Cohen: For jose/cose: Changes and updates hopefully coming next week.

Manu Sporny: Working group decided to create a controller document work item vc-controller-document. Mike Jones and Manu will edit. Manu will pull content from Data integrity. This will be done over the next couple weeks. My intention is the group to go to a draft quickly. We need to move it to CR quickly. Thoughts?
… We need: vc-controller-document repository.

Brent Zundel: to the question of how soon for CR for this document. As soon as we can, but its premature to say. When we get a better feel for the scope we can make that determination.
… originally planned to discuss core data model 1271 but Orie is not here. His is the outstanding request for changes. Not fruitful.
… we will be merging 1295 and 1297 when they get cleaned up. Avoiding discussion of post-CR PRs until we get into CR. So if you have one, that’s great. but we won’t be taking group time until after CR.

1.1. Add comparison to NIST definition (pr vc-data-model#1332)

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

Brent Zundel: there are two recently opened to take a look at now.
… Adds a comparison to the NIST definition of credentials. Adds a sentence that says its different than the NIST definition. Comments?

Manu Sporny: +1 to straightfoward PR – would like some editorial changes there, but nothing blocking.

1.2. Improve the explanation of using graphs in VCDM (pr vc-data-model#1326)

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

Ivan Herman: There is one PR 1326 last week that is labeled as Post-CR, but I wonder whether this is not a Pre-CR PR. It does include a more precise and normative definition on which part of a credential representation the proof property applies to.

Brent Zundel: I am happy to make that change.

Ivan Herman: Maybe Dave Manu and Ted have already looked at it.

Manu Sporny: The PR needs to be re-based. There are a whole bunch of changes which makes it difficult to review.

Ivan Herman: I put a separate preview into the instance.

Manu Sporny: I can try to rebase to see which normative language is modified.

Ivan Herman: Extremely grateful if you did that.

Manu Sporny: Do you which normative text?

Ivan Herman: There is a terminology change and the definition of the proof property both for a credential and a presentation.

Manu Sporny: we need to deal with this pre-CR.

Ivan Herman: As an answer to Henry raised issue. So that issue can be closed if this PR gets accepted.

Brent Zundel: I will change from Post-CR to Pre-CR. Only outstanding requests for changes are from Ted. Welcome to speak on changes.

Ted Thibodeau Jr.: My concern is the reference to the default graph. Its used for the first time in this document. I don’t think it has the meaning intended.

Ivan Herman: I think we do disagree on that.

Brent Zundel: This conversation can continue in the PR. Manu has agreed to rebase and cleanup.

1.3. Add comment on localizing vocabulary terms. (pr vc-data-model#1333)

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

Brent Zundel: Add comment on localizing vocabulary terms. Raised in response to issue 1289. This is a before CR PR. Its a relatively minor change. Comments?

Dave Longley: +1 not to merge because the example won’t be what we do.

Manu Sporny: The second part of the change is fine except that it is not what we will end up doing. We can’t alias value because schema.org uses it. Queued for a future call. The commentary around the vocab is weird. Not sure why we are saying that. Suggest that we don’t put that language in there. Its a low level detail we are raising.

2. Issue Discussion.

Brent Zundel: Moving to discussion of issues. Talking about issued labeled before CR.

Brent Zundel: https://github.com/w3c/vc-data-model/issues?q=is%3Aopen+is%3Aissue+label%3Abefore-CR+sort%3Aupdated-asc+-label%3A%22pr+exists%22+-label%3A%22ready+for+PR%22+.

2.1. Pre-CR review from Jeffrey Yasskin (issue vc-data-model#1285)

See github issue vc-data-model#1285.

Brent Zundel: This is a long review received from the AC rep for google. My understanding that there are only one or two things requesting that could lead to a formal rejection if not addressed. Specifically, he is looking for an algorithm that a verifier should run to verify claims from an issuer.
… a number of things have been extracted into individual issues. The intention is for that to continue.

Manu Sporny: I got up to his comments on section 4.1. Still need to go to section 8.2. Kristina has done a pass as well. This is in process. I have the PR where he wants to see the verification algorithm half worked up, but there will be a PR in the next two weeks.

Brent Zundel: not seeking to assign a person to this issues because it will be broken into individual issues.

2.2. Cross-check the domain/range statements in the vocabulary with the VCDM spec (issue vc-data-model#1319)

See github issue vc-data-model#1319.

Ivan Herman: Originally people should have reviewed domain and range statements for vocab. There was an issue where these were incorrect. Proposal to close 1319 and if there is a specific issue with a property, raise a separate issue.

2.3. Internationalization Review for VCDM 2.0 (issue vc-data-model#1155)

See github issue vc-data-model#1155.

Brent Zundel: this is the generic internationalization. Now that it points to 1264, we can close this one. Do I remember correctly>.
… 1155 is now closed.

2.4. Clarify what conformance means to the issuers/verifiers (issue vc-data-model#1300)

See github issue vc-data-model#1300.

Brent Zundel: clarify what conformance means to issuers and verifiers. Assigned to Manu and Joe. What is the status?

Manu Sporny: Still needs a PR written. I intend to do this, but cannot give a timeline. We should try to address this. Maybe someone else can get to it before I do.

Brent Zundel: thank you. Agree we should not close and it should have a PR.

2.5. JSON-only processors and VCDM 2.0 conformance (issue vc-data-model#1290)

See github issue vc-data-model#1290.

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

Brent Zundel: JSON only processor and VCDM 2.0 conformance. Raised by Oliver and not assigned to anyone. He brings up good points about how we define it in the spec. If no one gets assigned it can’t move forward.

Dave Longley: “credential specific” is another to use if application-specific is too broad.

Manu Sporny: I’m wondering if we can get direction from the group. Its clear that people don’t like the term “json processing”. There have been two alternative terms proposed. We stop calling it JSON processing because certain workgroup members feel its misleading. Do we want to call it status versus dynamic or application specific versus generalized. Can we get feedback?

Dave Longley: or “context specific”.

Ivan Herman: application specific is better than dynamic versus static. I think that application specific is really very broad. In our case what is relevant is that its credential specific. Its what we should do.

Brent Zundel: we do have a somewhat related PR open 1302 which is marked post-CR. Maybe it doesn’t apply? Does it apply to this issue? How? As far as context specific, I agree that application specific doesn’t tell me much. Credential specific might be better. But that begs the question that if there is credential specific processing, why haven’t we defined it. I would expect that question to be asked.

Ivan Herman: +1 to be relevant to 1302.

Joe Andrieu: I think limited might be what we are talking about. We should do ranked poll and pick.

Manu Sporny: We could debate endlessly but a ranked choice poll would be a good option. I can put this out this week and run it for a week and we can review what comes back.

Dave Longley: some choices i heard: credential-specific, context-specific, application-specific, static vs. dynamic, limited, restricted.

Manu Sporny: Need to get all the options down. Please put your options into the minutes so it shows up in the poll.
… The other question was “is 1302 relevant”. It is relevant but 1302 does other change beyond what we call these two things. By naming these two things the rest becomes easier to talk about.

Joe Andrieu: I think what we are trying to name is not application specific. Its the choice of the verifier what processing they want to do. I think we put the choice at the verifier. Its not a choice of the issuer, application or credential. Thats why they didn’t resonate with me.

Dave Longley: Agree with Joe. We can fall into a lot of pitfalls if we specify the type of processing. Its really about the specific set of document that you accept. We don’t want to confuse people into thinking that data would be understood in a different way. Its whether you accept a lot of things or just what you understand in your context.

Brent Zundel: We have another PR and poll going out. But no one is assigned to the issue.

Manu Sporny: I could pick it up once the poll is done and its clear what people want it to be changed to.

Ivan Herman: can we do it now.

Manu Sporny: Not sure over IRC. We have a ranked choice poll tool and I suggest we use it.

Brent Zundel: Look forward to seeing the poll. Moving on to the next issue.

2.6. termsOfUse is insufficiently specified (issue vc-data-model#1010)

See github issue vc-data-model#1010.

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

Brent Zundel: may just need a has-PR label. My understanding is it has a PR.
… Question for the group is, Does PR 1295 address this issue?

Manu Sporny: I don’t think it does because of Kristina’s comment.

Manu Sporny: Kristina is pointing out that there remains an issue: https://github.com/w3c/vc-data-model/issues/1010#issuecomment-1751586092.

Manu Sporny: The note talks about delegating a credential. That is the only mention of delegation in the document. What does this mean in terms of use. David would have to address this in the PR and I don’t think he addresses it.

Phillip Long: I don’t recall delegation being relevant to this PR.

Brent Zundel: I think it the concern is relevant. Its currently assigned to you, david and Kristina. Question is what action is going to be taken to address that concern.

David Chadwick: There is something wrong with the timing. Missed yesterdays.

Ivan Herman: There are changes with the clock.

David Chadwick: Apologize for being late. On terms of use, I did put changes in this morning to address all of Ted concerns except one which we should discuss. Regarding delegation, I removed from the terms of use, so there is no mention now.

Brent Zundel: That answers the question. This issue is now addressed fully by PR 1295.
… Can we jump back to 1295 and get to a point to merge this.
… David, can you point to the changes requested by TallTed that you did not accept.

David Chadwick: He added a big long paragraph about relationship between issuers and verifiers. I disagreed with this. The whole point is that the verifier can get an credential from an issues, but the trusted third party can vouch for it. So I think the text was not correct.

Ted Thibodeau Jr.: On this particular sentence, its editorial and advisory text, so it doesn’t need in depth processing. However the explanation just given is the minimum needed. That is approximately what I had added. I dont think we will get this processed through oral conversation. I did respond to the latest change to the PR this morning.
… There were numerous editorial changes. The line before my modification said the terms of use property should be automatically processed by the verifier. But there is no language to describe how. Its just insufficient.

Joe Andrieu: +1 for removing automated requirement.

Manu Sporny: +1 to remove the automated requirement.

David Chadwick: Im happy to remove that sentence because we dont have this language around other properties. Its implicit in all the properties.

Ted Thibodeau Jr.: Unless we are expecting humans to process, the intent is for automated processing.

David Chadwick: +1 JoeAndrieu

Ted Thibodeau Jr.: also in my addition: “Future enhancements of this extension may include defining values and/or structures of termsOfUse property values such that any verifier may understand termsOfUse property values without prior relationship or communication with the issuer.”.

Phillip Long: +1 to the type telling you what is or is not automatable. And +1 to remove the automated statement.

Ted Thibodeau Jr.: TermsOfUse being an extension point makes it “not like all the other properties”, it’s only “like all the other extension points”.

Manu Sporny: +1 to Joe. We should remove the statement. I think we do intend this to be automatically processable, we just don’t have an example today. Saying we should and not providing a mechanism is problematic. Lets just stay silent.

Dmitri Zagidulin: Similar to what manu said. This is not about whether the field should be manual or automatic. This is an extension point so the processing should be part of the extension spec. Not the main spec.

David Chadwick: We already implemented automatic processing of the ToU in the NGI Atlantic project.

Brent Zundel: thanks for involvement.

3. Meeting schedule.

Brent Zundel: A note. Next weeks meetings are cancelled. I apologize.
… no meeting next week. Please continue progress on PRs and issues.