Verifiable Credentials Working Group Telco — Minutes

Date: 2023-12-13

Attendees

Present: Brent Zundel, Ivan Herman, Andres Uribe, Benjamin Young, Dave Longley, Manu Sporny, Ted Thibodeau Jr., Dmitri Zagidulin, David Chadwick, Will Abramson, Nicholas Steele, Orie Steele, Sebastian Crane, Joe Andrieu, Paul Dietrich, David Lehn

Regrets:

Guests:

Chair: Brent Zundel

Scribe(s): Orie Steele, Manu Sporny

Brent Zundel: Agenda for today: status updates, prs, issue triage, discussion.
… any agenda bash?

1. Work Item status updates/PRs.

Manu Sporny: please review the special topic call minutes… seems the outcome is to publish CR drafts for data integrity specs, and integrating feedback that will trigger second CR.
… we are going to try to close issues aggressively.
… we will try to close PRs that are not going to make it.
… with that said, data integrity specs have some changes, that will be merged this weekend.
… we should publish vc specs directory, because its blocking the data model from entering CR.
… vc data model PRs are progressing.
… greg is adding a bunch of content on privacy and security considerations for bbs.
… we will request horizontal review for that spec in prep for CR for BBS.
… we just started test suites for data integrity bbs.

Brent Zundel: any PRs you want to include in the minutes?

Orie Steele: There are two PRs open, one of them is regarding our media types and I don’t think that’ll go in. 186, removes registrations for multiple suffixes… WG seems to believe multiple suffixes is safe enough to not block publication… I expect 186 to close soon.
… There is pull 190, placeholder PR to marry to other verification PRs. This is an attempt to align w/ verification algorithm defined in core data model so core data model doesn’t need to talk in detail about things that are in securing specifications.

2. Issue Discussion

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

2.1. Define algorithm for verification (issue vc-data-model#1337)

See github issue vc-data-model#1337.

Brent Zundel: some have PRs exist.

Manu Sporny: this one needs to be closed, we merged related PRs, and filed follow up issues.

2.2. Make validation normative (issue vc-data-model#1328)

See github issue vc-data-model#1328.

Brent Zundel: make validation normative, unsure of status.
… seems we had some PRs.

Orie Steele: I think we’ve done about as good as we can do w/ verification algorithm PR. I think this issue can be potentially closed. I’m happy w/ the way validation is described, doing more is probably difficult and not helpful.

Joe Andrieu: +1 to closing. better to handle in verification.

Brent Zundel: suggestion is that this is addressed and can be closed.
… we will close after the call.
… I enjoy closing issues.

2.3. Add mechanism to cryptographically secure non-credential VP properties (contexts etc) (issue vc-data-model#1360)

See github issue vc-data-model#1360.

Brent Zundel: add mechanism to secure presentation metadata, related to related resource stuff.
… separated from enveloped credentials.
… seems like we tried, and now its time to decide to close the issue… if it stays open, it will be labeled future work.

Dmitri Zagidulin: I recommend we label future work.
… this seems important, but we should leave a roadmarker for the future us.

Brent Zundel: unless there is objection, I will label as future work.
… I will remove the before CR label, and unassign manu.

2.4. Update 4.9 Securing Verifiable Credentials (issue vc-data-model#1316)

See github issue vc-data-model#1316.

Brent Zundel: update securing verifiable credentials section.
… seems there is disagreement on if its necessary, last suggestion was to wait for verification algorithm PRs to land.
… is there anything left for this issue?

Manu Sporny: i propose we close the issue, there does not seem to be consensus here.
… we could make it more clear that there are extension points, and proof is used by data integrity, not the other way around.
… perhaps more non normative text, about how proof is an extension point, used by securing mechanism.

Brent Zundel: seems like labeling post CR would be ok.

Manu Sporny: I can try to address the one normative part related to proof.
… let me try to take a shot at it.

Brent Zundel: I am also going to label it post CR’.

2.5. Do VCs still need Media Types with Multiple Suffixes? (issue vc-data-model#1364)

See github issue vc-data-model#1364.

Brent Zundel: do VCs still need media types with multiple suffixes.
… short answer is yes.
… comments on this? seems we are ready to close this issue.

Manu Sporny: I think we still need media types with multiple suffixes.
… the only thing that is in question now are the media types for the securing formats such as jose-cose.
… I think I agree with the existing media type registration requests.

Ted Thibodeau Jr.: yes, pretty strongly, application/sd-jwt.

Manu Sporny: this group will need to decide what media types to request.
… ted, please open your PR before the next IETF meeting.
… if we fail to get into last call again, everything will be very sad.

Dave Longley: +1 to Manu’s position, I think Ted is right but relying on Ted.

Ted Thibodeau Jr.: doing my best to get it done this week.

Brent Zundel: any other IETF PRs we want to discuss?
… labeling pending close, we think we need what we currently request.

2.6. Rewrite verification algorithm in a way that does not cause layer violations (issue vc-data-model#1377)

See github issue vc-data-model#1377.

Brent Zundel: rewrite verification algorithm in a way that does not cause layering violations.
… can we close this issue.

Manu Sporny: I think the text in the spec is not optimal, and it needs to align with the new interface langauge to align with the securing mechanism, and its done.
… I could not figure out how to write that text, you orie, please propose some text.

Orie Steele: Yes, seems like we’re in the process of addressing follow-up PRs on verification algorithm. I expect those follow up PRs to resolve this. I’m not sure I have special text to add. Current language isn’t acceptable, heading in a good direction.

Brent Zundel: Can you make a concrete suggestion that would make the text acceptable?

Orie Steele: Yes, I think Mike Jones is planning to do that already? I’ll leave it to him.

Brent Zundel: can you make a suggestion for text?

Manu Sporny: I prefer to explicitly assign mike jones to this.

Brent Zundel: Mike is assigned, orie, hopefully you can communicate to mike that he is assigned.

2.7. Add mechanism to embed externally secured VCs in a VP (issue vc-data-model#1352)

See github issue vc-data-model#1352.

Brent Zundel: add mechanism to secure VPs.
… first PR failed, second PR was raised, can we get an update.

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

Manu Sporny: seems it will land.
… we seem to have a solution for securing verifiable presentations without using proof.

2.8. Remove repetition of normative statements in verification algorithm (issue vc-data-model#1375)

See github issue vc-data-model#1375.

Brent Zundel: labeled with PR exists, manu can you give an update?

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

Manu Sporny: lots of approvals, some unaddressed changes and questions, does not seem to have anything blocking.
… it would remove a large chunk of duplicated normative statements.
… seems this will merge over the weekend.

2.9. Request profile parameter from `application/vc` (issue vc-data-model#1363)

See github issue vc-data-model#1363.

Brent Zundel: request profile parameter for application/vc+ld+json.

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

Orie Steele: see this recent cg draft using profile: https://www.w3.org/community/reports/json-ld/CG-FINAL-yaml-ld-20231206/.

Brent Zundel: not sure about the course this is taking.

Orie Steele: I think that PR is on a good track, Manu’s attempting to address ambiguity, forbid profile parameter. From a design perspective, bad to say extensibility for profile is internal to media type. For awareness of the group, JSON-LD CG just published for YAML-LD that also registers profile parameter. I think it’s a best practice to inherit the profile parameter the way all the other media types tend to support it and then say, when it’s present, it has to be interpreted in some way and if you don’t have a need for it, don’t use it. That would be my recommendation. This will impact registration of media types, since we’re first through the door on multiple suffixes, it would be wise of us to be explicit about profile parameter.

Ted Thibodeau Jr.: I am very confused by orie’s comments.
… the PR is titled forbid use of media type parameters.
… I take issue with forbidding parameters, media type parameters should not be forbidden’.
… some content still needs to be changed.

Manu Sporny: seems you are missing context from the special topic, there was pushback forbidding media type parameters.
… you seem to want to address profile, not forbid media type parameters.
… we had too many objections to forbidding the profile parameter.
… we tried to resolve to say nothing.
… i believe orie wanted us to provide guidance on the profile parameter.
… in case the media type parameter is inherited from the suffix.

Dave Longley: IMO, it still seems clear that we don’t know what we want to say and so we should say nothing at all.

Ivan Herman: +1 to dlongley.

Dave Longley: to me, it seems like we don’t as a group know what to say here, so we should say nothing.

Orie Steele: I am fine closing all these.

Brent Zundel: if nobody is opposed, lets do that.

Manu Sporny: we have to remember to account for media type parameters.
… in the verification algorithm’.
… not clear how to verify if parameters are present.
… good to close it, but we will need to update the verification algorithm.

Brent Zundel: we have a path forward.

2.10. Separate verification from validation in verification algorithm (issue vc-data-model#1376)

See github issue vc-data-model#1376.

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

Brent Zundel: separate verification and validation, PRs exist.
… we have discussed, seems it is on a good trajectory.
… comments?

2.11. Update algorithms section to normatively depend on the INFRA specification (issue vc-data-model#1378)

See github issue vc-data-model#1378.

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

Brent Zundel: add infra to algorithms, PR exists.
… seems to be on a good track.
… seems this will merge, and things will close.

2.12. Clarify section on verifiable credential graph (issue vc-data-model#1365)

See github issue vc-data-model#1365.

Brent Zundel: clarify section of verifiable credential graph.
… what needs to change to address this?

Manu Sporny: there is a clear concern, which i think I can address.
… for the avoidance of doubt, the following values are not allowed in a verifiableCredential.
… I list raw text strings, and URLs.
… it has to be an object of some kind that creates that graph structure.
… and I won’t make it exhaustive… its strange to point out, what you cannot put in the field.

Dave Longley: “MUST be an object and can’t be something else, such as…”.

Andres Uribe: works for me, thanks manu!

Brent Zundel: do you want to mix that into 1379?

Manu Sporny: seems to make sense to put it in 1379.

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

Brent Zundel: then it will address that issue as well.
… not hearing anyone opposed to this path.

2.13. Specify guarantees that all securing mechanisms must provide. (issue vc-data-model#1374)

See github issue vc-data-model#1374.

Brent Zundel: specify requirements for securing mechanisms.
… a PR exists.

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

Brent Zundel: there is a request for changes from oliver.

Manu Sporny: seems we are on a good trajectory, one thing that is concerning, he is saying verifier needs to know who the issuer of a VC is.
… that sounds like validation.
… I will try to make that a part of it, but I don’t want to cover trust frameworks, or trust lists.
… the current text can be made clearer… the securing mechanism should not need to understand our data model.
… I will try to address oliver’s suggestions.

2.14. Allow extensions to ProblemDetails object (issue vc-data-model#1384)

See github issue vc-data-model#1384.

Manu Sporny: its a misread of the text.
… the problem details can be exposed in production interfaces, additional problem details objects can be added to improve developer experience.

3. misc.

Orie Steele: We made really great progress on the call today. I’ll be stepping down as Editor. Transmute is going to be adjusting our strategic focus in calendar year, specs are on an excellent track. Transmute plans to implement these specifications, though can’t contribute in Editor/Author capacity in the new year. Looking forward to implementing final Technical Recommendations after CR. They seem to be on a good track.

Manu Sporny: Thank you for all the work you’ve put in, Orie!