Verifiable Credentials Working Group Telco — Minutes

Date: 2024-02-14

See also the Agenda and the IRC Log

Attendees

Present: Ivan Herman, Ted Thibodeau Jr., Brent Zundel, Paul Dietrich, Michael Jones, Gabe Cohen, Manu Sporny, Dave Longley, Dmitri Zagidulin, David Lehn

Regrets:

Guests:

Chair: Brent Zundel

Scribe(s): Gabe Cohen, Dave Longley

Content:

Brent Zundel: agenda for today is to go over work status updates, look at PRs, then go for issue processing on the core data model.

Michael Jones: there are a few vc-jose-cose issues that would be good to discuss.

Brent Zundel: sounds good as a part of our 2nd topic.
… happy valentines day! let’s jump into work status updates.

1. Work Item Status Updates.

1.1. Fix algorithm misalignments using new cryptosuite interface. (pr vc-data-integrity#244)

See github pull request vc-data-integrity#244.

Manu Sporny: processed a number of PRs across VCDM, DI, cryptosuites. need to talk about Jeffery Yaskin’s PR (#244) to create an interface for all DI specs.

See github pull request vc-di-ecdsa#57.

Manu Sporny: that broke interfaces b/w DI specs. trying to get them re-aligned. 2 PRs - 1 for DI, 1 for ECDSA-SD. heads up to the group we’re trying to align these interfaces.
… some misalignment on how they would work. have a plan forward to address this. plan is for an interface in all DI specs that all have ‘functions’ each cryptosuite executes to create/verify proofs. a standard interface.
… the functions to expose was under debate. based on discussion we will only define 2 functions on the interface: create proof and verify proof.
… will require changes to algorithms across these specs. pushing more details into the cryptosuite specs. less in DI the spec. should not impact implementations. we know we will go through a 2nd CR. the interfaces are changing, not the algorithms.
… are there any concerns/guidance before I start making those changes?

Dave Longley: +1 to those changes.

Ivan Herman: presume that ECDSA then EDDSA and then BBS?

Manu Sporny: correct.

Michael Jones: think it takes us down a bad path to build interfaces that no one will build. we should not be creating APIs, that is out of scope.

Manu Sporny: agree that APIs are out of scope, but that’s not what we’re creating here.

Michael Jones: that is what you described.

Manu Sporny: have discussed this before. we’re discussing interfaces, which is what the w3c does, not in web IDL which would define an API. implementations are implementing in this way. they are abstract, not concrete web IDL interfaces.

Michael Jones: I am missing context. what else are you planning to do?

Manu Sporny: changing the interfaces that we had months ago, which Jefferey asked for. that PR had weeks of review and already went in.

Brent Zundel: any other comments?

Manu Sporny: no - that’s the major PR I need feedback on.

1.2. vc-jose-cose.

Gabe Cohen: We merged a number of PRs that were open for review and had approvals the past few days, mostly editorial.
… There are 6 PRs open, a few opened yesterday, a few long standing around examples. There is a problem with some rendering Orie had worked on. The editors discussed and found a path forward. We will remove Orie’s custom logic in the meantime and unblock some issues.
… We’re making progress on the pre-CR list and we have 13 open that have 4-5 PRs.
… That’s it unless Mike has anything to add.

Michael Jones: created an easy PR yesterday. appreciate Brent adding some PRs. see some suggestions were merged, need to take another look.

Brent Zundel: yes, this is on conformance classes. fixing a build issue. would appreciate feedback on #231.

Ivan Herman: agreed to bring JWT back into the mix. haven’t seen that yet.

Michael Jones: yes, that’s assigned to me and I will work on it this week. I have been traveling but now am domestic for a month.

Ivan Herman: thanks.

1.3. Add guidance around using JWK (pr vc-jose-cose#220)

See github pull request vc-jose-cose#220.

Gabe Cohen: One thing I forgot to mention – there’s some outstanding discussion around 220 … around the JsonWebKey text that we should discuss to get clarity around some confusion that came up.
… This PR is clarifying language on the JsonWebKey spec on how to use the JsonWebKey type. There was discussion on a call a few weeks ago on whether we should add language on including properties like alg and kid and at first there was agreement to add back normative guidance on those properties.
… But then Mike and I agreed we didn’t want to repeat language from another RFC – and so we removed that. Ted said he wanted the language back.

Ted Thibodeau Jr.: the language that was removed was removed during misunderstanding of what was being discussed…point being the four words were added with intent and removed without that intent, which is why I’ve asked them to be re-added.

Manu Sporny: the language being modified is normative language that is significant. need to update the title of the PR, since it’s broader than the example. somewhat confused…had said we’d have explicit guidance on iss, kid, etc. that guidance was not provided…may be a different issue. if we’re talking about keys and just a JWT, and if we’re just repeating what’s said in the other spec we don’t need to repeat it here. somewhat confusing…since kid matters.

See github pull request vc-jose-cose#226.

Gabe Cohen: The changes you’re referring to Manu, went into 226. The changes we’re talking about … the PR is unfortunately named. The language I moved was originally in an example.
… The issue was to move it to normative guidance, outside of the example.
… The PR adds some guidance around using the JsonWebKey.

Ted Thibodeau Jr.: On Jan 18th, I said optional or required should be clearly stated for all properties, that’s generally true what’s happening but not true for the couple that were added with this PR.
… Those changes went in and were merged but then Mike said that some requirements were wrong.
… alg is optional in JWKs – and that’s what I want put back.

Michael Jones: Are we talking about a change to header params or JWKs?

Gabe Cohen: JWKs.

Michael Jones: It’s optional there, what does it say now?

Gabe Cohen: Nothing.

Michael Jones: It’s fine to say that.
… This is one of the PRs I was trying to get a sense of … is this one controversial or is that another one?

Gabe Cohen: It sounds like we’re clear on this one, I’ll apply Ted’s suggestion and then we’re good.
… The other has a rendering script problem.

Michael Jones: Ok, 220 should be ready once we get the suggestion in.

2. VCDM Issue Processing.

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

Michael Jones: moving on to issue processing.

2.1. Remove the at risk issue marker for Evidence (issue vc-data-model#1303)

See github issue vc-data-model#1303.

Michael Jones: looking at 1303 first Remove the at risk issue marker for Evidence.

Manu Sporny: See section in the spec.

Manu Sporny: question for the group: Jefferey Yaskin asked for a mini-registry and to be done with this. we could do that. w.r.t tests what did we say we would do? I have two recollections.
… have to demonstrate there is a spec using the property. there are multiple impls. 1EdTech have an evidence property. thought the tests we were writing were just testing the ‘type’ for evidence. need to ask what are we testing for these extension points.
… normative guidance we give is : it can’t be empty, have to specify it’s type, id should be a URL, … 1EdTech has multiple impls. at what point do we remove the at risk marker? when we create tests?
… is that the bar we’re trying to hit?

Ivan Herman: from a practical point of view, the only obligation we have is to remove these markers and feature itself when we go to PR. at this point there is no rush. at some point we’ll have to look at the whole test suite report and then risk markers.
… issue was raised before CR. why bother at this point? went to CR with marker in.

Brent Zundel: less a post-CR and then a pre-PR?

Ivan Herman: yes.

Manu Sporny: https://github.com/w3c/vc-data-model/pull/1295#pullrequestreview-1657956871.

Manu Sporny: agree, but still need clarity. Orie said the example needs to be updated and covered in tests. what does ‘covered’ mean? … having input/output that looks like the example. then we can remove the at risk flag. concretely we update the example to use the IMS Global evidence property.
… there will be a test for that in the core data model. to make sure there’s a type and to make sure nobody throws an error (or at least 2 don’t.) and then at if at the end of CR two impls are doing this, we remove the issue marker.

Gabe Cohen: +1 to that proposal.

Manu Sporny: does anyone disagree with that proposal?

Manu Sporny: +1 for it being for how we evaluate /all/ properties.

Manu Sporny: (all “at risk” properties).

Ivan Herman: fine with that. need to be clear this is not for the evidence property only. what’s being described is ‘how do we accept that a given property/term stays in the spec as a normative thing’ need a general approach to do that.

Brent Zundel: labeled as before-PR. manu has outlined a clear course of action. no one assigned yet.

Ivan Herman: Manu has outlined … but needs to be documented somewhere.
… will there be some document that says this is the way we remove the markers?

Brent Zundel: do you have a proposal?

Ivan Herman: at the end of the CR process we need a report. to say whether we are fine or not. criteria may differ, this is not in the same category as other issues. my proposal is to have a document and record this in it.

Manu Sporny: I have raised an issue to track this (#1437), will add details. to remove at risk issue markers & properties. will be a before-PR thing. will document the process and track at risk properties.

See github issue vc-data-model#1437.

Brent Zundel: can anyone take the issue?

Manu Sporny: yes, I will.

2.2. Include credentialSubject examples that use URLs rather than DIDs (issue vc-data-model#1309)

See github issue vc-data-model#1309.

Brent Zundel: Include credentialSubject examples that use URLs rather than DIDs #1309. some agreement by manu, raised by selfissued. who can be assigned?

Gabe Cohen: I can take it.

Dave Longley: notably, a DID is a URL … but i presume this means “HTTPS” URLs.

2.3. Non-normative changes from Jeffrey Yasskin’s review (issue vc-data-model#1348)

See github issue vc-data-model#1348.

Brent Zundel: Non-normative changes from Jeffrey Yasskin’s review #1348. currently assigned to manu.

Manu Sporny: I will do this one. in theory all editorial changes. will take me a while since there are so many of them.

2.4. phrasing and/or punctuation for input “inputBytes or inputDocument and inputMediaType” needs work (issue vc-data-model#1402)

See github issue vc-data-model#1402.

Brent Zundel: first, #1402 phrasing and/or punctuation for input “inputBytes or inputDocument and inputMediaType” needs work.
… raised to and assigned to TallTed. how is it going?

Ted Thibodeau Jr.: on my list. not a complex thing, just needs to be done. hope to get it done in the next couple days.

2.5. EnvelopedVerifiablePresentation missing in data model (issue vc-data-model#1431)

See github issue vc-data-model#1431.

Brent Zundel: next is #1431 EnvelopedVerifiablePresentation missing in data model.

Gabe Cohen: prevents consistent RDF interpretation of presentations secured without data integrity proofs.

Manu Sporny: today we have this concept of an enveloped verifiable credential, with a presentation inside of it. this would add a presentation. should be fine to do this. it is something that is missing. it is a normative change. saying “if you want to, you can wrap it in multiple b64 payloads” to get a blob that secures the entire data model using any media type.

Brent Zundel: clarifying…the enveloped cred was ‘I want to use vc-jose-cose to sign a credential’ this is ‘I want to use vc-jose-cose to sign a presentation’.

Manu Sporny: yes correct and I can take it.

Ivan Herman: I will take the vocab part.

Brent Zundel: thanks to both. time for at least one more…#1408.

2.6. reconsider @id for mediaType term (issue vc-data-model#1408)

See github issue vc-data-model#1408.

Brent Zundel: reconsider @id for mediaType term. looks like this was addressed?

Ivan Herman: my impression is that this was solved, we can close it. we are sticking here to what schema.org does.

Brent Zundel: proposal to close with no action?

Manu Sporny: currently there is a conflict b/w activity streams and verifiable credentials. activity pub wants to use VCs. they will be blocked/have a bad experience with things as-is. we have the easiest ability to change this. shouldn’t just close. we should do something about it.
… easiest for us to rename the term from mediatype to ianamediatype or similar. then a question of whether we should re-use the schema.org term for it.
… or create our own. then it gets complex.

Ivan Herman: don’t want to get into the weeds of defining/creating types. we can change the term we use to map to schema.org, but would leave this to schema.org, they are already doing this. we can use whichever term we want in our vocab.

Manu Sporny: let’s rename our term to ‘IANAMediaType’ and keep the schema.org URL the same.
… we should do this and then be done, and we will be fine.

Ivan Herman: change to be made is in the spec text and context file, right?

Manu Sporny: yes.

Ivan Herman: never touched this but should be able to do it.

Dave Longley: do we want to use encoding format as the term? since we’re using it as the schema.org property? avoid inventing a new term.

Manu Sporny: I’m fine w/ “encodingFormat”.

Ivan Herman: perfectly fine.

Brent Zundel: any opposition?

Manu Sporny: Only argument against would be: “People don’t call these things “encoding format” usually? They say media type?

Dave Longley: they also don’t say “ianaMediaType”.

Manu Sporny: true story.

Brent Zundel: none heard. Ivan is assigned. that is our meeting for today.
… please jump on PRs that need feedback in vc-jose-cose and others. if you are assigned in the data model please get a PR in for that.

Manu Sporny: “iana” -> “I Am Not A” Media Type.

Brent Zundel: getting to the point where we could mark things as ‘future’ … people will need to be assigned to address them.
… thank you everyone, we could not do this without you. see you next week.