Verifiable Credentials Working Group Telco — Minutes

Date: 2023-05-10

See also the Agenda and the IRC Log

Attendees

Present: Ted Thibodeau Jr., Gabe Cohen, Andres Uribe, Kevin Griffin, Brent Zundel, Dave Longley, Chris Abernethy, Phillip Long, PhilF, Michael Prorock, Manu Sporny, Orie Steele, David Waite, Samuel Smith

Regrets:

Guests:

Chair: Brent Zundel

Scribe(s): Phillip Long

Content:

Kevin Griffin: kevingriffin-gleif has joined #vcwg.

Brent Zundel: begin with Agenda review, work item status updates and PRs primarily in the VC data model, others if there is time etc.
… proposed agenda changes?
… can handle changes to the JWT PR in the first agenda item.
… Intros?

Phillip Long: Greg Bernstein working getting signature suites test vectors together including BBS.

Brent Zundel: Greg recently joined as an invited expert and warmly welcomed.

1. Pull Requests

1.1. Add confidence method to VCDM (pr vc-data-model#1054)

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

Manu Sporny: Confidence method PR - there seemed to be consensus to merge last week but Orie had some objections. Wondering what we’re doing with it?

Orie Steele: concerned with this PR - calling it confidence methods is confusing and invites degraded security characteristics but doesn’t work across industries. There aren’t yet two independent implementations yet.
… tangled up into the table registry at this point which add a bunch of defs to the core spec. It’s a valuable thing to look at but not helpful to focus on right now.

Brent Zundel: other comments?

Manu Sporny: To untangle things, one reason to put reserved property in the spec is to acknowledge important work. While Orie is the -1 in the voting but these objections need to be addressed.
… we’re listing everything that doesn’t have 2 independent implementations, but we don’t tell people how to implement the feature -no normative language etc.

Orie Steele: +1 the approach being taken for render method, that seems to be making progress.

Manu Sporny: in the render method spec made it its own specification and defined the normative property of render method in that separate text. Could follow that path for this confidence method mechanism, without txt in the core spec.

Orie Steele: lets use the ccg to do incubation work, not the W3C TR.

Manu Sporny: what specific things will break if we put this into the specification? Need more details beyond concerns to understand how to respond.
… if we get 2 independent implementations we could move that text into the spec in the CR phase.

Michael Prorock: likes manu’s approach to create an independent spec. This gets it out of the core spec, do the work in CCG, and bring it back when it’s ready.

Orie Steele: Also folks should beware to of the english language issue with “confidence”… https://en.wikipedia.org/wiki/Confidence_man.

Brent Zundel: concerned that we sounded like agreement last week and now we sound differently.

Orie Steele: I objected, outside of the call time.

Orie Steele: sorry I could not make the call.

Orie Steele: I am supportive of reserving terms, and then not working on them in the working group.

Dave Longley: fine with the approach manu has suggested making it a separate spec. The new argument is combining it with confidence associated with “man” but we should proceed with Manu’s plan.

Brent Zundel: clarifying which plan?

Michael Prorock: I would note, as i noted on the last call, i am likewise not a fan of confidenceMethod vs confirmationMethod for the technical reason of alignment with cnf and other existing use of this concept.

Michael Prorock: but lets keep work moving.

Orie Steele: +1 to most of what dlongley said.

Dave Longley: add property to reserve table and can add it to the main spec later. If the group doesn’t want that at risk text in the spec he could live with it as well.

Orie Steele: I am supportive of the text being developed in ccg.

Brent Zundel: “At risk” has a specific meaning. It’s not common to use “at risk” in specifications at this stage.

Orie Steele: +1 to brents comment regarding adding “at risk” to things that are not yet developed pass the ccg draft phase.

Manu Sporny: based on the minutes from the last call we had agreement to bring the defs into the spec. We could poll to see if preference is to include in the spec as “at risk” or move it out to an external thing.
… Manu not sure if polling is useful at this point.

Michael Prorock: not a fan of this at this point. But he’s not going to block this at this stage. Strong preference to do the work elsewhere an not a fan of “at risk” in the language.

Orie Steele: I agree that at risk does rightly apply to the existing terms that shipped in v1 without concrete support.

Ted Thibodeau Jr.: last week we did take into account the W3C meaning of “at risk”. We were going to list both in table of reserve terms and in the implementation section. whichever one won out would stay in the spect the other removed.

Dave Longley: +1 to TallTed.

Orie Steele: status list and credential schema are in good shape.

Dave Longley: +1 to what TallTed being the best way forward as well.

Ted Thibodeau Jr.: same is true in reverse. Could lie fallow for a period of time and be addressed later.

Gabe Cohen: +1 @TallTed well said.

Dave Longley: +1 to TallTed’s comments on the naming.

Ted Thibodeau Jr.: the use of confidence man should not impact the meaning of confidence. That objection has no utility for me.

Shigeya Suzuki: .

Orie Steele: clarifying why confidence is problematic -it’s a predicate in JSON-LD. It’s an open RDF cookie and could allow adding a confirmation type of sending a person to a home (physically). Not a good idea to have any RDF type.

Ted Thibodeau Jr.: There still is no binding happening here.

Orie Steele: legit to have a technical means to have a binding, but a vocab that invites people to do whatever they want isn’t appropriate. Dislike word “confidence” he’s amenable for a separate path forward.

Phillip Long: dlongley - in an open world model there will be objections. Confidence is better than confirmation. Terminology is the best we have now and works with an open world model.

Brent Zundel: let’s do some polls.

Orie Steele: In some sense it is better that we not use “confirmation” if it does not provide strong security characteristics unless used with a specific RDF type.

Manu Sporny: asks Brent to craft something.

Brent Zundel: poll: we will add confidenceMethod to the reserved table and add the language to the spec with a note that it will be removed if there are not two implementations.

Manu Sporny: +1.

Dave Longley: +1.

Andres Uribe: +1.

Gabe Cohen: +1.

Brent Zundel: +1.

Greg Berstein: +1.

Brent Zundel: poll open.

Samuel Smith: 0.

Andrew Whitehead: +1.

Orie Steele: -1.

Michael Prorock: -0.5.

Phillip Long: +1.

Shigeya Suzuki: -0.5.

Chris Abernethy: 0.

Ted Thibodeau Jr.: +1 “removed from the spec and left in the reserved table”.

PhilF: 0.

Ted Thibodeau Jr.: clarification “removed form the spec and left in the reserved table”.

Brent Zundel: Orie’s -1 is noted.

Shigeya Suzuki: wondering if this method may increase confusion. People in this call understand there are different camps. The people who lead this spec might confuse this with the “confidence method”.

Brent Zundel: poll makes it clear we don’t have consensus and we’ll continue talking about it.

Manu Sporny: should it be marked as “do not merge” and move on?

Orie Steele: can we try a resolution to do what we did with render?

Brent Zundel: label it “discusss”.

1.2. update json schema to accurately reflect context defn (pr vc-data-model#1064)

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

Manu Sporny: continuing with other PRs: next item “update json schema to accurately reflect context definition”.

Gabe Cohen: this is blocked by a PR that’s now been merged, which fixed the example context, which should reserve opposition.

Michael Prorock: +1.

Orie Steele: Manu opened a PR an example context that makes it no longer return a 404.

Brent Zundel: The PR has been merged that makes it a 404.

Michael Prorock: i have approved.

Orie Steele: changing to no objection.

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

Gabe Cohen: can this be merged with 1111?

Michael Prorock: please!!!!

Orie Steele: can be merged this.

Michael Prorock: yes to merge this and with 1111.

Brent Zundel: 1064 should be merged? No opposition. Merge it.

Gabe Cohen: it’s merged.

1.3. Add “Getting Started” section (pr vc-data-model#1111)

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

Manu Sporny: next is 1111 and the one that Orie wish it to merged.

Brent Zundel: Objections? None - merged.

Manu Sporny: merges 1111.

Gabe Cohen: manu: is rebase and merge our practice? I have been squashing and merging.

1.4. Add issuer dependent term handling (pr vc-data-model#1083)

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

Manu Sporny: 1083 manu is good with if Tallted’s suggestions are addressed. Move on to another PR.
… 1100 and 1101.

Kevin Dean: the discussion of these will merit more time to see if we can get through others.

Manu Sporny: special topic call needed for 1100 and 1101.

1.5. Clarify relationship bx securing mechanisms and media types (pr vc-data-model#1107)

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

Manu Sporny: PR 1107 - topic clarifying relationship between securing mechanisms and media types.

Orie Steele: needs to review recent changes.

1.6. Add new v2.0 reserved properties. (pr vc-data-model#1108)

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

Manu Sporny: PR 1108 - Add new v2.0 reserved properties.
… 4 objections with change requests from Orie, David Chandwick, Oliver and Kristina.

Orie Steele: FWIW i think https://github.com/w3c/vc-data-model/pull/1107 can be merged outside of call time, I was the only objector.

Manu Sporny: think Oliver and Kristina wanted to see confidence method merged before this PR is merged, which we’re not doing today.
… what are you thoughts on this Orie?

Orie Steele: seems like render method would go in by itself. there’s work going in the CCG and people would agree with this.
… would approve render method and has presentation schema reservations.

Samuel Smith: In the academic literature the word confidence is extremely common in expert systems and automated reasoning to provide a measure of uncertainty on a given predicate.

Samuel Smith: See https://www.ncbi.nlm.nih.gov/pmc/articles/PMC5378479/#:~:text=Nevertheless%2C%20there%20is%20a%20fundamental,commitment%20is%20overt%20or%20covert)..).

Orie Steele: today Orie is ok with the confidence method in the table. Not a fan of it in any format and prefer to have it reviewed for terms independently.

Manu Sporny: refactor PR to only refer to render method - any objections to that?

Brent Zundel: no objections heard.

Shigeya Suzuki: I share same thought on presentationSchema and renderMethod with Orie.

Orie Steele: I would be a +1 to reserving render method, since their is a ccg spec which I can read that might eventually get 2 independent implementations.

Dave Longley: SamSmith: (and that’s a match for its usage in VCs).

Phillip Long: Manu wil redo 1108 to only include render method.

1.7. Add note to describe use of credentialschema with selective disclosure (pr vc-data-model#1112)

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

Manu Sporny: Add note to describe use of credentialschema with selective disclosure #1112 Ready to merge?

Brent Zundel: no objections heard.

Manu Sporny: tiny cleanup but will merge thereafter.
… that concludes those over a week old.

1.8. Feature/editorial expansions (pr vc-jwt#77)

See github pull request vc-jwt#77.

Brent Zundel: handing things to VC JWT editors vor pull 77.

Michael Prorock: only one open change request from Kristina and outdated at this point. Has been asked several times. Feel it is ready to merge.
… can adjust things with other language later as needed.

Orie Steele: has asked Kristina several times with a warning recently if no feedback in a week we’d move forward. Not a nice to do for a chair we need to move on.

Michael Prorock: “There are three classes of JWT Claim Names: Registered Claim Names, Public Claim Names, and Private Claim Names.”.

Dave Longley: has outstanding change request - think we’re asking for trouble if we don’t do it. Use the work payload for JSON-LD in the text. The use of the term “claim set’.
… highly recommend using “payload” in this spec.

Orie Steele: have talked about this exact issue of “claim set”. When we say this is a ‘private claim’ one of the understandings is to look at if there is a private claim in the context file.

Michael Prorock: +1.

Orie Steele: previously tried to refer to claim sets as payloads and has been chastised. RFC call this a “claim set”. We should use what the RFC defines.
… Any JSON object is a valid json payload and valid as a claim set as a token.

Michael Prorock: notes david’s concerns and should be understood. Claim set is about public and private claims which is the word used.

Phillip Long: mproprock if we shift this to a more JWS approach the problem would arise.

Samuel Smith: As can be imagined to avoid conflicting reasoning paths, complex sets of rules require precedence or weight to be assigned. This method, which helps establish the level of certainty of the expert system’s predictions and recommendations, is referred to as the confidence factor.

Orie Steele: Worth noting that using JWS would also support securing content types that are not JSON-LD… it might be nice to secure payloads that are not JSON… JSON Web Tokens, assumes json claimsets…. JSON-LD is sadly also JSON.

Phillip Long: dlongely note that private claims should not conflict nor with registered claims– recommend shifting to more JWS language that problem would go away.

Orie Steele: I appreciate the concern, please be clear if you will formally object.

Michael Prorock: appreciate dave’s approach on this.

Michael Prorock: very much.

Brent Zundel: heard that dave wouldn’t block this if we move this to a more JWS approach but he’ll leave that to be resolved by the JWS editors.

Dave Longley: no formal objection, just raising concerns for VC-JWT editors to figure out how to resolve to avoid potential problems.

Brent Zundel: assuming Kristina’s issue isn’t further discussed it should go to the JWS editors.
… PR in status list we should look at.
… PR 46 or PR 60.

Orie Steele: +1.

1.9. Ensure that statusListCredential can be dereferenced. (pr vc-status-list-2021#46)

See github pull request vc-status-list-2021#46.

Manu Sporny: handle 46.
… This PR46 need to make sure status list should be dereferenced. This is a data model spec, not related to the protocol used. Can open an issue to consider adding language around HTTP and maybe merge thereafter.

Orie Steele: This PR is an improvement, and should be merged, over the objections… Manu is correct, dereferencing might happen in a document loader that makes not network requests.

Manu Sporny: Without Mike or Kristina on the call we can’t make progress.

Orie Steele: +1 dlongley, the objections don’t make sense, the document loader seems to not be understood.

Manu Sporny: yes, also what dlongley said.

dlongely: the actual recommendations from Mike don’t make sense here. We’re saying when a client fails to deference something it generates a validation error. It doesn’t make sense to have a client return an HTTP error, that’s a server’s job.

Orie Steele: complete agreement. A lot of confusion around the fundamentals. This is the same data model as in the core data spec.

Dave Longley: +1 to Orie.

Orie Steele: confusion over how dereferencing works is close to things that cause formal objections. If it’s not clear how dereferencing works then there is a security problem.

Michael Prorock: agreement with the above comments. Need to get this merged.