Verifiable Credentials Working Group F2F at TPAC, 2nd day — Minutes

Date: 2024-09-27

See also the Agenda and the IRC Log

Attendees

Present: Ivan Herman, Manu Sporny, Kevin Dean, Will Abramson, Shigeya Suzuki, Brent Zundel, Jennie Meier, Michael Jones, Benjamin Young, David Chadwick, Joe Andrieu, Dave Longley, Gabe Cohen, Ted Thibodeau Jr., Joshua Thomas, David Lehn, Denken Chen, Brian McManus, Dmitri Zagidulin, Pierre-Antoine Champin, David Ezell, Greg Bernstein

Regrets:

Guests: Mandy Venables, Philippe le Hégaret, Sheri B-H, vkuntz, laurens, Jeffrey Yasskin, Hadley Beeman, Bert Bos, Simone Onofri

Chair: Brent Zundel

Scribe(s): Mandy Venables, Wesley Smith, Manu Sporny, Will Abramson, Benjamin Young

Content:

Brent Zundel: going over agenda, JOSE COSE discussion this morning, controller document discussion before lunch.
… after lunch hours for every other rec track document.
… I think we’re at 9, that’s insane and a lot.
… our day ends with looking at use cases doc, things have been happening there.

David Chadwick: I need a passcode to enter the Zoom meeting.

Brent Zundel: final session is joint session with security group for feedback and security reviews to see what they have to say.

Michael Jones: Jeffrey Yasskin coming this afternoon.

Manu Sporny: 3 proposals from yesterday.

Brent Zundel: during every other rec track.
… anyone who did not get to introduce themselves yesterday.

Sheri B-H: Sheri_B-H has joined #vcwg.

Mandy Venables: Josh Thomas from Ignite Retail.

Mandy Venables: Philippe, staff, Ivan told me to be here.

Joe Andrieu: From legendary.

1. JOSE/COSE Media Types.

Brent Zundel: slide deck https://docs.google.com/presentation/d/1rjt4fgajEqqQzdF72JUeh6_h4gICQanExOfcoW4l0GM/edit#slide=id.g2a8b040676_0_27.

Gabe Cohen: hoping for a fewer number of proposals, giving history on media types and considerations on what we should do.

Mandy Venables: [overview slide].

Mandy Venables: [history slide].

Gabe Cohen: media type for core data model /vc /vp are registered.
… conflict with IETF spec for ??? have their own model that wants to use a conflicting type, we cannot register the same thing without meeting with them, participating but have not reached consensus.
… currently at a stalemate.
… as things stand, core data model has /vc and /vp, when securing the data model what media types should there be, not submitted for registration yet.
… IETF JWT has been there for a long time, COSE, why not use CBOR web token? Because they use CBOR maps, would not be a good fit.
… COSE is the right media type for securing CBOR representations of the data model.
… SD-JWT, hoping to be on standards track but is not registered.

Michael Jones: the wg completed last call.

Brent Zundel: right at the cusp of it being a standard’.

Gabe Cohen: SD-JWT, no guarantee that it will be accepted or they will agree to go forward.

Manu Sporny: worth highlighting, this conflict is not new, a number of members try to use the media type and re-using the word VC to mean something different, data models are incompatible and causing confusion.
… customer believe IETF work is compatible with W3C VC.
… discussion with people on internet draft, please differentiate from W3C work, but instead it looks like the plan is to push VC + SD-JWT and retroactively say it is in production.
… I view that as problematic behavior, coordination is needed between WGs and editors.
… this issue has been happening for a year.

Dave Longley: +1 that the confusion extends far beyond media types because of the use of “VC” to mean something other than what this group has created and produced.

Gabe Cohen: is it formal objection Friday?
… current state of VC JOSE COSE, use static types, was proposal before types were accepted in IANA, if we do not find consensus this is the state of things.
… dave longley suggested using vc-env to represent a enveloping format, no consensus, but wanted to ensure it was brought up.

Michael Jones: I blocked it, but I will support it.

Gabe Cohen: we could not issue any new types, diplomatic world.
… easy to implement, devs already know these, no new media types, this is not an obvious choice.
… in a perfect world, if there was no IETF, we could register the types we think are best and make the most sense.
… JWT, SD-JWT, COSE.
… clear and unambiguous, gives good foundation to secure core data model, best estimate is 2 formal objections and tension.
… add note that we should not be afraid of formal objections, “what merit does their objection have?”.
… imperfect world, where we try to do the previous proposal, we could register the types that are not in conflict, puts ??? in awkward spot, but gives us time to move forward to figure stuff out with IETF folks.
… we are able to register the types we know are best, enable us to leave CR sooner, cons are if we go forward and cannot resolve conflict, we are in a bad spot.
… in summary, we want to comply with best practices, avoid formal objections, if we get them we want to have thought through how to respond, good relationship with IETF, and move out of CR asap.

Brent Zundel: goal is group consensus around a proposal.
… will any of the proposals be acceptable, will you formally object, and if none are acceptable, come with a new proposal.
… gabe did a good job outlining all of the options.

Dave Longley: would -1 that :).

David Chadwick: propose a meta-level proposal, everywhere it says VC or VP, we pre-fix with W3.
… differentiates that we are not part of the IETF.

Manu Sporny: -1 for prefixing with “w3c”.

Joe Andrieu: -1.

Manu Sporny: We don’t put “w3c” in front of any other media type that W3C has registered, to my knowledge.

Philippe le Hégaret: prior to CR, send email to media-types@iana.org, my guess is that did not happen.

Philippe le Hégaret: See Register an Internet Media Type for a W3C Spec.

Manu Sporny: it did happen.

Brent Zundel: not for new media types.

Manu Sporny: supportive for 3 and 3.5, although 3.5 kicks the can down the road a bit.
… strong opposition to 2, it avoids the more fundamental problem of misbehavior in the ecosystem.
… it will harm work at W3C and IETF, confusion around VCs and such will lead to business and devs being confused.
… proposal 1 is just avoiding having that discussion.
… media type is a thing now in the wg at IETF, it does not convey the same semantics as the W3C spec does.
… proposal 3 is the ideal way forward, it’s not incompatible with what IETF wants to do, we will share the media type with them, content type will be different but typ and media will be the same.
… 3 is workable,.

Michael Jones: respond to comment about others are using the term VC, it’s become a generic term, mdoc and jwts are VCs, family of specifications in open ID foundation that use VC as generic.
… using in EU wallet deployments, whether or not it only applies to this work is a ship that has sailed.
… we should declare victory and not say people are misbehaving by using the VC term.
… next topic, to brent, I would support option 0, leaving things the way they are.
… option 1, using envelope, I think VC-LD is better than VC-ENV, willing to drop objection.
… finally, I would oppose conflict with OAuth wg.
… we were proposing VC+LD + ?, there was no conflict, we changed our mind to not continue multi+ media types, the reason there is conflict is we changed our mind.
… finally there is no concept of base media type, we can use any prefix and + we want.
… even if there were a base media type notion there is not a conflict.

Dave Longley: -1 to helping other groups use our branding, we don’t control others surely, but that doesn’t mean we have to help other groups that attempt to reuse our branding and efforts to do something else – that confuses the market; it would be fine if our work was compatible with it.

Philippe le Hégaret: -1 to not registering media types.

Michael Jones: finally I am against proposal 2, as the author of JWT best practices doc, we would not know what is being secured.

Dave Longley: my understanding is that cty says what is being secured (content type).

Brent Zundel: with my chair hat I have used the words regrettable that if we cannot come to an agreement with IETF that are intending to register ???, that would be a failure of diplomancy.
… personal view is, in light of possibility to different using the cty value, I would be fine moving forward with registering VC+ as the base media type for JOSE COSE.
… in conflict with chair self.

Dave Longley: +1 to brent, and sorry your selves are in conflict.

Joe Andrieu: in support of 3, IETF is transparent and intentional to grab a term that W3C coined.
… we found VC term to be the right solution.
… some people took the work and the name to go venue shopping to get other features they wanted.
… W3C will not maintain a trademark on VC.
… we should not endorse this behavior, it’s undermining our work.
… it is damaging to our collaborations. We’ve reached out and have not had success moving the needle.
… endorse 3.

Dave Longley: +1 to Joe’s comments.

Manu Sporny: respond to selfissued, you said when `application, we were doing something different, we had direct interactions and told people it was the same base media type. The base media type exists, there is consensus,.
… +1 what JoeAndrieu just said, this is blatant misbehavior, we are being ignored, where we are being taken advantage of, mdocs are not VCs, they are called mdocs, people are not confused, there is clear separation.
… we have asked IETF to create separation by using different language and media types.

Juan Caballero: cough cough PLENARY cough cough.

Manu Sporny: technical argument, proposal 3 is fine from a technical perspective, it has the benefit of letting us share the base media type with IETF.

Ted Thibodeau Jr.: Noting that IETF has declared that one + is all that is allowed, “base media types” are the part to the left of the +. “structured suffixes” are the part to the right of (and indluding) the +.

Philippe le Hégaret: meeting with IETF with lunch yesterday, folks that help with IETF relationship, will bring this issue up with the IETF liaison.

Philippe le Hégaret: See W3C Trademarks and generic terms.

Philippe le Hégaret: on subject of trademark, we claim generic terms, I don’t see VC there.
… lastly, the wiki page on VCs says it’s W3C.

Joe Andrieu: @Plh Ralph Swick had told me the organization would not defend verifiable credentials as a generic.

Joe Andrieu: @plh (when he was acting CEO).

Gabe Cohen: speak to VC usage, open ID has re-named to digital credentials.
… +1 what brent said about cty.
… I would like to see us find consensus on proposal 3.

Michael Jones: on VC brand, discussion will not help us move to consensus, we should celebrate people using the term.

Brent Zundel: not hearing clear consensus, but 3 has gotten most comments in it’s favor.
… poll for moving forward with proposal 3.

Brent Zundel: poll: Proposal 3?

Will Abramson: +1.

Manu Sporny: +1.

Dave Longley: +1.

Joe Andrieu: +1.

Michael Jones: -1.

Wesley Smith: +1.

Jennie Meier: +1.

Dmitri Zagidulin: +1.

Kevin Dean: +1.

Gabe Cohen: +1.

Brent Zundel: +1.

Benjamin Young: +1.

Ted Thibodeau Jr.: +1.

Denken Chen: +1.

Brian McManus: +1.

cc: +1.

Michael Jones: knowingly stepping on what others are doing is not collaborative behavior and I cannot support that.

Brent Zundel: before going back to q, having a conversation with Brian Campbell, editor of SD-JWT, he helped come up with proposal 3,.
… objected with cty cavet.

Ted Thibodeau Jr.: I am pleased to hear selfissued does not support the current IETF behavior of stepping on our work by diluting the meaning of “Verifiable Credential”.

Brent Zundel: drafting proposal.

Ivan Herman: I did not fully understand what you said about Brian Campbell’s reaction.
… why is he ok with that when it goes against what the group does?

Dave Longley: +1 to just go on record to say that i believe we are pushing back against the very behavior Mike has described.

Gabe Cohen: BC’s comment here https://github.com/w3c/vc-jose-cose/issues/282#issuecomment-2289946119.

Manu Sporny: it would allow the IETF to use the same top level media type but they would pick a different value for the cty value.

Ivan Herman: are they ready for that?

Manu Sporny: we don’t know.

Michael Jones: I’ll look at the spec and see what cty value they’re currently using.

Manu Sporny: the technical argument is it allows both groups to use the same media type.
… the only thing that would change between the 2 groups is the cty value.

Ivan Herman: unless they want to claim our cty values.

Michael Jones: https://www.ietf.org/archive/id/draft-ietf-oauth-sd-jwt-vc-05.html currently has no “cty” value.

Joe Andrieu: +1 to continuing communications.

Gabe Cohen: frame that is this proposal passes, we should proceed with trying to register this, but also have a conversation with IETF.

Manu Sporny: Agree with decentralgabe.

Michael Jones: They would naturally use application/sd-jwt as their “cty” media type, if they add one.

Philippe le Hégaret: we will have to elevate the issue to our IETF contacts,.

Ivan Herman: for outsiders, for the second part, making it clear that this wg intends to use application/vc and application/vp for the cty value.

Dave Longley: +1 to ivan’s suggestion.

Manu Sporny: +1 to ivan.

Denken Chen: +1 to ivan to make it clear.

Proposed resolution: For VC-JOSE-COSE, we will proceed with a request to register application/vc+jwt, application/vp+jwt, application/vc+cose, application/vp+cose, application/vc+sd-jwt, and application/vp+sd-jwt. We will note in particular that the cty property is the point of differentiation for others that may wish to use identical media types. This group intends to use application/vc and application/vp as the cty values. (Brent Zundel)

Manu Sporny: +1.

Gabe Cohen: +1.

Joe Andrieu: +1.

Ted Thibodeau Jr.: +1.

David Chadwick: 0.

Dave Longley: +1.

Denken Chen: +1.

Michael Jones: -1.

Dmitri Zagidulin: +1.

Brent Zundel: +1.

Benjamin Young: +1.

Shigeya Suzuki: 0.

Will Abramson: +1.

Jennie Meier: +1.

Ivan Herman: +1.

Wesley Smith: +1.

Brent Zundel: selfissued: will you formally object.

Brian McManus: +1.

Michael Jones: I am undecided pending discussion with others.

Joshua Thomas: +.

Resolution #1: For VC-JOSE-COSE, we will proceed with a request to register application/vc+jwt, application/vp+jwt, application/vc+cose, application/vp+cose, application/vc+sd-jwt, and application/vp+sd-jwt. We will note in particular that the cty property is the point of differentiation for others that may wish to use identical media types. This group intends to use application/vc and application/vp as the cty values.

Brent Zundel: calling this resolved.
… who will be the voice of the group?

Gabe Cohen: I can do that.

Brent Zundel: decentralgabe will serve as the voice of the group, talk to him about it.
… comments have been made that have not facilitated consensus, individuals can use their voice, but make it clear they are not speaking for the group.

Shigeya Suzuki: +1 brent (for record).

Brent Zundel: I appreciate the calm and sensibility, it is valuable that we can have differences of opinion and still be civil,.

2. VC JOSE COSE issues and PR-s.

Michael Jones: we should merge a PR: https://github.com/w3c/vc-jose-cose/pull/292.

Michael Jones: .

Brent Zundel: is there more you would like feedback from the group on.

Manu Sporny: looking at vc-jose-cose spec, thought I requested language around selective disclosure and things you have to keep a look out for, one thing being commentary around, if you use sd-jwt and the issuer uses things it wants to make sure the verifier always checks, things like related resources for contexts are always selectively disclosed.
… I think we do need a vc-jose-cose spec.
… I didn’t see those statement in the spec, can the editors speak to that?

Gabe Cohen: see https://github.com/w3c/vc-jose-cose/pull/288/files.

Dave Longley: +1 to tell issuers to consider what needs to be mandatory to disclose and highlight some important items from the VCDM.

2.1. Add a requirement on SD-JWT that credentialStatus should always be visible (plain). (issue vc-jose-cose#285)

See github issue vc-jose-cose#285.

Brent Zundel: let’s talk about this issue.

Gabe Cohen: I might have missed something when addressing this issue, we should re-open it to add language.

Brent Zundel: I will re-open the issue.

Gabe Cohen: preparing PR for that.

Manu Sporny: to add detail, I think the things that need to be considered are: we need special language about selectively disclosing the @context field, whether or not to expose type value, changes around credential status.
… our org is not looking very closing at this stuff, we have not done an implementation, hopefully someone else is paying really close attention.
… sd-jwt is a framework and it makes assumptions about the data model.
… sd-jwt by itself is unaware of the things that should always be selectively disclosed.

Dave Longley: +1 to Manu’s general concerns.

Manu Sporny: it feels like there is more work to be done, but because we’re not doing an implementation we cannot see the trip wires.

2.2. related resource.

Ivan Herman: my memory is that all related resources must be checked, what must be used if all?

Ted Thibodeau Jr.: https://github.com/w3c/vc-jose-cose/pull/304#pullrequestreview-2334075128.

Ted Thibodeau Jr.: link to comment in a PR that was merged, it says the jwt claim names vc and vp must not be present in JWT claim set, this doc is jose-cose, not jwt, so we can’t be making that restriction.

Dave Longley: respond to ivan: this issue with selective disclosure is not about if they are using related resources, but if the issuer wants to use them they need to make it mandatory,.
… since jwt does not sign the quads, it is important that issuers are aware of it and make it mandatory.

Manu Sporny: response to TallTed: putting CA DMV vendor hat on, we use vc and vp claim types in ca dmv implementation, we had to make the decision 2 years ago, we have a plan to upgrade, removing that in vc 2.0 is ok.
… I believe CA DMV wants to move away so removal is ok.

Michael Jones: not new language, this was in first CR, the reason it is there is vc-jwt 1.1 which defined the use of claims.
… that caused duplication of data model contect into the envelope, editorally this showed up as new text, but it’s because it was moved.

Michael Jones: Our first CR https://www.w3.org/TR/2024/CRD-vc-jose-cose-20240425/ includes “The JWT Claim Names vc and vp MUST NOT be present.”.

Ted Thibodeau Jr.: I don’t care how long ago it was approved, it is putting a restriction on jwt in sd-jwt, you cannot restrict jwts within sd-jwts.

Michael Jones: This is not new text.

Michael Jones: as the author of jwt (with others) and many spec that profile jwt, it is fully the intent of the jwt spec to be profiled, it is up to profile specs such as this one, it is up to the spec to say what claims must be used, what are optional.

Brent Zundel: what TallTed said cleared this up, he said you can’t limit things, but he clarified that it’s not limiting for sd-jwts, but jwts ???

Ted Thibodeau Jr.: if I have to object I will.

Brent Zundel: next step is for selfissued to raise a PR.

2.3. Detached payloads can be used (pr vc-jose-cose#292)

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

Brent Zundel: PR raised by selfissued, comments by decentralgabe,.

Gabe Cohen: spec was unclear about detached payloads, this PR adds that language,.
… they allow for detached payloads, so should we.
… my company makes use of detached payloads, it’s more efficient to store the signature separately.

Michael Jones: as discussed in the issue, the jwt spec and the cose spec permit detached payloads and we are using them normatively, if we do nothing they are allowed, if we merge this PR it doesn’t change the meaning but it does explicitly say detached payloads are allowed.
… ok to close or merge, would object to change that would try to inhibit the use.

Manu Sporny: this came about because the default example changed, will note that I oppose this because it’s the first time we’re talking about using detached payloads for VCs.
… I have an opinion but want to see what the group has to say.

Mandy Venables: as selfissued said, if it’s allowed then it’s allowed, and find decentralgabe use case compelling.

Manu Sporny: concerned about hexadecimal signature in example, would rather follow the same format as other examples.
… waiting on feedback from decentralgabe.

Gabe Cohen: feel like there was regression in code, example should show full payload, it may be useful to show examples for attached and detached.

Manu Sporny: concerned about detached payloads were viewed negatively and used as an example of the group not knowing what it is doing.
… not technical concern, but do we want to invite criticism back in?
… incubate in a group. Alternative is to write it up now, but concern without implementations.

Brent Zundel: proposal is to close this PR now, raise another one where the examples are only attached payloads.

Manu Sporny: clear up the example to show full payloads.

Michael Jones: if we close the PR we should close the issue.
… if we get other criticism about detached payloads I will take it on, they fail safe because of crypto.

Brent Zundel: but you are not disagreeing.

Michael Jones: yes.

Dave Longley: +1 detached payloads are fine, signatures fail safe if the payload doesn’t match.

Brent Zundel: anyone who would disagree about closing this PR and issue?
… no opposistion.
… let’s get started, we will start by talking about controller document.

3. Controller Document.

Brent Zundel: in controller document we have gotten feedback from PING and TAG, Jeff Yasskin will be here to discuss TAG, we can discuss the privacy review now.

3.1. privacy review / questions (issue controller-document#93)

See github issue controller-document#93.

Brent Zundel: the issue that was raised is issue 93.
… this is a response from Nick Doty of the privacy group, going to have it on the screen for folks to read through.
… this is the privacy review, as you read, think about what specific issues need to be raised in order to address the concerns that were brought up.
… additionally, what are we going to do to address those issues.
… for those of you just joining us, we are looking at issue 93, the PING review of the controller document spec.
… a question for the group is, what issues should be raised to track the concerns here, and what are we going to do about them.

Manu Sporny: I worked on an editor’s response to PING, in general PING had good feedback, at a high level there was a concern about the specification being fairly generic, they did not understand the need for something like this. They said it was so abstract it was hard to understand use cases. The use cases here are similar to DID use cases, just with URLs instead of DIDs.
… Pointing to the DID use case could help. The review mentioned that it would be a lot of work to profile this document, and it’s kind of hard to reason about the privacy properties of the document. We did mention that the document is largely about publishing crypto keys, there is a new PR that adds service descriptions to the document, but we.

Wesley Smith: mention that the main reason controller document exists is because vc-jose-cose spec wanted something that did what DID documents did but without DIDs.

Manu Sporny: we mention that DID core WG is planning on using this document as well.
… Largely the response was that the privacy concerns are fairly limited based on the limited set of things that the document is supposed to be doing, as it is largely around crypto key communication, extensions largely out of scope.
… they mentioned they were interested in pairwise identifiers, might be good to couple that with W3C language around the origin model of the web, I noted that we do talk about it but could expand the section around identifier-based correlation risks to talk about the Web’s origin model. This has been a regular request from groups to talk about the Web’s origin based security/privacy model.
… They also noted that we say you shouldn’t store personal data, but PING suggested that crypto keys are personal data, so a clarification that we meant name, address, etc, rather than crypto material.
… Finally, there was a question around the difference between “id” and “controller”, we have 2 issues open to discuss that.
… A lot of the commentary was editorial in nature, I think that we’re going to wait to hear from Nick or PING on exactly what he would like to see done.
… We can raise issues on additional language, modification of existing language, etc. I didn’t see a request for a fundamental design change in here, will want to clarify that. I did ask about these being largely editorial changes and for PING to let us know if that is not the case.

Manu Sporny: Nick and the PING will look at this, do another round of comments, and either raise issues or we will raise issues on their behalf.

Ivan Herman: I must admit, when we started to work on this document, I really had difficulty getting my head around the naming. “Controller Document” does not fit what is there, as the emphasis of this document is to store references to crypto key material and metadata. That’s all we are doing. I wonder whether we should rename the document to make it clear what the document is talking about. I know there is a PR on the service. We will come back to this.

Brent Zundel: A couple more minutes on this topic then will move to another issue.

Joe Andrieu: Advocating taking the time for bike shedding, at one point this was called something else, it was framing the conversation around something that should be separated into VCs, we already have the idea that controller name is problematic, but we haven’t taken the time to fix it.

Manu Sporny: we have talked about renaming it before and failed to find a better name, I suggested that this was a resource on the web, everyone hated that.
… it is expressing key information but could be expressing anything else.

Ivan Herman: let’s not go there.

Manu Sporny: just saying we had that discussion, in the DID WG we discussed how it did not have service descriptions in it, based on a request by that WG I raised a PR to add service descriptions into controller document, no longer just a bag of keys, now more general tool to engage with the subject.

Michael Jones: yeah, we have tried to change the name before, I am repeating Manu, but nobody has come up with a better name, people know this name, it is a done deal.

Brent Zundel: moving to issue 94.

3.2. TAG review for v1.0 (issue controller-document#94)

See github issue controller-document#94.

Brent Zundel: which is our TAG review issue.
… I am happy to frame this convo however you would like.

Jeffrey Yasskin: I’m Jeffrey Yasskin, on the TAG, ready to talk about issue 94.

Manu Sporny: first of all, thank you very much for the review, really appreciate it, I think that at a high level the TAG had a number of concerns around the document and some of the functionality in there. Some of it seemed to be more general uneasiness around some of the stuff that we are doing, and there were some very specific questions towards the end. At a high level, the TAG acknowledged that it was useful to express a more generalized form of this.
… Going through the comments, again with an editorial hat on I attempted to provide feedback on the review, there are some items we will need to discuss as a WG today.
… The first concern was - this seems like a bag of keys specification, so a spec for expressing a set of keys, and there was a little doubt that it’s not clear that other systems will find use in profiling this thing.
… It would take considerable effort to profile it, and there is a question around that.
… The response was that the reason we created the spec was that some WG members wanted it profiled, did not want to normatively refer to DID core, Data Integrity, we had to create a Switzerland specification that people could refer to. The DID core and DI specs as well as VC-JOSE-COSE will profile here.

Jeffrey Yasskin: the worry that it might not be widely usable is not an argument against publication, maybe only against generic naming.

Manu Sporny: the group has struggled with if this is worth it, we are now committed to getting it out there as we have dependencies in other specifications.

Pierre-Antoine Champin: I think that the linked web storage WG should probably try to reuse part of this, this needs to be discussed by the WG but I will encourage this.

Manu Sporny: some of the activity pub community would like this, BlueSky is using DID documents and would look at this.
… next item up, there was concern in the TAG that defining a generic format could introduce security vulnerabilities, citing things like alg:none, there is agreement that generalizing a security format can add vulnerabilities, at present we do not know of any, the only counteraction we can think of is to be in a position where we can actively.

Wesley Smith: modify or errata the spec to clean those up.

Jeffrey Yasskin: That seems reasonable, security considerations to warn people about past vulnerabilities when they did this sort of thing.
… one example: VC work has needed a feature from json-LD to add a feature, that WG has not been quick to add that, it would be nice for this group to have a quicker response.

Manu Sporny: There was also a note that said that you were happy to see that the document does not try to add a format that could be interpreted as JSON/JSON-LD at the same time, however there is discussion around using context parsing documents as JSON-LD using hash ??? values.
… concern around implicit interoperability that is not in the spec.
… and attackers may try to exploit the complexity of JSON-LD processing.
… This one wasn’t as clear about what we could do, it sounded like the TAG wanted more language in the spec to clearly document how you can safely process a controller document.
… I will note that in the VC spec, we have gone to great lengths to tell people what the processing model is and what they should be aware of.
… Would langauge like that be helpful?

Jeffrey Yasskin: would like to introduce hadleybeema, also on the TAG.
… for this specifically, more strict instructions on how to process it would help.
… the next couple paragraphs are questioning if this should be JSON-LD at all.
… if that goes back to JSON it solves some of this worry.

Ivan Herman: I do not know which version of the document you looked at, because there was a fairly extensive discussion on the JSON-LD presence in the document, it is now much more isolated than before, the document speaks about the vocabulary in general, it is much more concentrated now.

Jeffrey Yasskin: another thing that I saw in the discussion after we wrote this comment is that json-ld implementations are expected to internally inject the context instead of expect it to be present, that helps with the interoperability concern about mixing JSON/JSON-LD.

Manu Sporny: high level, the desire is to make sure that no matter if you do JSON/JSON-LD, the outcome is the same, the meaning of all of the fields doesn’t change between those two mechanisms.
… we do need to write some more language to make that very clear.
… to insist that you cannot get a different result with JSON/JSON-LD.
… if you think you are in that situation you should throw an error immediately.
… we could add text to the specification that conveys that more clearly, that the semantics between the two versions are the same when it comes to how you should operate.
… “authentication” means “authentication” regardless of JSON/JSON-LD forms.

Jeffrey Yasskin: I think that the TAG is likely to stay uncomfortable with this sort of document, but putting something in the specification to say it is a specification bug if you can get different results with JSON/JSON-LD.
… that would help.

Manu Sporny: we can certainly put that language in there.
… speaking to the longer discussion with the TAG, the alternative is to force a format, which will lead to objections in the group, in VCs we did that and it resulted in the group splitting and people going to IETF, now we have a market problem on our hands.
… what was holding everyone together was this dual mode thing, the experiment in the VC group did not result in a good outcome, I would expect the same result here.
… If the TAG has any suggestion on how to navigate that, it is not a tech problem, it is a political thing, the TAG, this group, and the VC group should engage more on the guidance for future groups.

Jeffrey Yasskin: We could write something about when it is appropriate to use JSON-LD, we may not have time or expertise to do this, but it would be good to be clear about the technical reasons to pick one or the other.

Manu Sporny: That would be helpful. Moving on to the next comment, skepticsm that JSON-LD is necessary for controller document, extensibility could be achieved through registries. You recognize that the DID WG sees registries as decentralized but the TAG disagrees.
… Removing JSON-LD would lead to formal objections, we are moving forward with everyone unhappy, that is the state we are in.
… moving on to the inclusion around multihash and multibase, the TAG believes it is best to mandate that implementations align on base encodings and cryptographic digests.
… I mentioned that there are good reasons to pick different base encodings and hashes.
… the best way to encode data into a QR code is base45, for example.
… if you were to use base64url you pay a nasty price. The same is true for crypto digest algorithms, we are finding that in some of the newer selective disclosure and unsinkable disclosure technologies, using things like cryptographic circuits, certain hashing mechanisms are easier to implement in a cryptographic circuit than others by orders of magnitude.
… Demonstrated by the European digital identity work, we could pick a specific hashing format and have it create negative consequences.
… The point is taken, if we could pick one digest algorithm and encoding that would improve interoperability, but at the cost of harming some of our use cases.
… Given that we know that the market has several different mechanisms, can we encode that in a different field. The cryptographic specifications do make a choice of mechanism. The choice is made at the crypto suite/key expression layer, and not controller document.

Brent Zundel: maybe the controller document spec should strongly recommend or say that, when you profile this, pick one. That would be a step closer.

Jeffrey Yasskin: I had a couple thoughts. The first is that the base encoding is implied by QR codes or a couple other situations, but in controller document, it doesn’t seem like you have to use the same base encoding as you might need for a QR code, you are conveying bits that you can re-encode or switch encodings on. I think I still prefer one base encoding. The argument about hashes is interesting, and I wonder if the document could explain the benefit of hash choices.
… it might make sense to have each crypto suite specification pick one specific hash, even if the controller document is more generic.

Hadley Beeman: I wonder if you have considered standardizing for use case, it would make a big step towards standardizing for interoperability. For example, for QR codes, standardize for base 45, you would have done the hard work for the implementers.

Manu Sporny: The reason multibase and multi hash are in the controller document is historical, ideally they would be totally different specifications, they are in there because the implementation community was using multibase/multihash, not just controller documents that could use them, long history of different use cases. That said, the reason it is there is we needed normative documentation. I believe that work should be done, but I don’t know if the right place is the controller document specification, for example nothing we are doing has anything to do with QR codes.
… In the future, these specs should probably be pulled out into their own specifications. In the meantime we could write that language in there, not opposed to that.

Hadley Beeman: we are regularly reminding ourselves that we have no power, you can do what you like, I will say that we have had this conversation before regarding interoperability around crypto, and that will continue to come up as a stumbling block. We will continue to say there are opportunities here. I was imagining per-use case profiles for the ecosystem.
… That then makes it easier for implementations to be interoperable.

Manu Sporny: wes-smith: Wanted to speak to point about specifying pros/cons of differen hashing mechanisms. That can be difficult to do wrt. cryptographic circuit stuff, new set of requirements and tradeoffs, difficult to note that sort of stuff ahead of time.

Kevin Dean: as someone from the supply chain and barcodes, I would strongly recommend against aligning anything with an encoding mechanism for a specific barcode format. There is work underway to add support to other formats with different compression and encoding algorithms.

Hadley Beeman: Is it complex enough to not write up that nuance?

Shigeya Suzuki: +1 KevinDean.

Kevin Dean: if you knew ahead of time you could, but from experience at GS1 with QR codes, we found that the compression algorithms built into the barcode format was about as good as anything we could come up with ourselves, not worth the extra effort.

Jeffrey Yasskin: The TAG has not come to consensus on if multibase/multihash is good to use, have already talked about how the spec profiles to only a few of the options therein, the TAG will continue discussing that.

Ivan Herman: as someone who is pretty much a newcomer in crypto related things, I have the impression that doing something like what you refer to goes beyond the scope of W3C. The crypto community is huge and has an enormous amount of work going at various organizations. Not up to W3C to make judgement calls on key formats, hash functions - the only thing we can do is give the possibility for various things to be used, up to various implementations to decide what to use. Not W3C’s business.

Michael Jones: Ivan I was once in a W3C WG that called itself Web Crypto that made choices about what algorithms and formats to use/deprecate.

Manu Sporny: jyasskin this is about your comment on the TAG continuing to think about it. There is a common misconception around the multi formats that they suggest that you could use any of them in an application. What we are trying to say is no - you should pick one. The reason the multiformats exist is that the reality is that we have many different formats, and applications are using them without using any kind of header.
… The problem with base encodings is that you cannot tell the difference between them.
… The multiformats are an attempt to encode that into the data itself, so the data is self describing, so if you know they are using a multiformat, interoperability is increased because the first byte tells your application how to process the rest of the data.
… The multiformats exist because specs/application developers have picked wildly different things, we are trying to put a header on those things and unify how to recognize a byte stream. The TAG has that deliberation, please convey that this is not the Wild West, we are saying to please pick one thing, but across applications we can increase interop.

Jeffrey Yasskin: We’ll make sure that’s part of the TAG discussion in the future.

Manu Sporny: One of the feedbacks is that it seems risky in some cases - this has to do with who can make changes to a controller document. We have a field that can point to something else in the world, controller doc not always self contained, other authorities can have the ability to change a document.
… That doesn’t make sense on the web, it was designed for decentralized ledgers, blockchains, DHTs, things where you can point to other things in the world and the ledgers have rules about document updates.
… The commentary from the TAG is that it can be dangerous to point to an external resource without pinning that resource.
… And it’s true, there is a risk there. The first question is, the controller document can choose to take on that risk or not. There are use cases where external pointing is useful, e.g. parent child relationship, this document has a guardian that is external. Or, an account recovery service that is external to your document. That’s where we are conveying that external parties might need ability to change a controller document. It is possible to create a hash for that, we have a digest property that allows you to pin external data to your document. However, if you do this, you don’t support key rotation on the other side. You can get to a place where the external party cannot make changes.
… We could add language to describe how to pin external data, but it would remove the ability for external key rotation.

Jeffrey Yasskin: This was not a request for a particular change, just to add text to security considerations.

Manu Sporny: agreed, but we should raise an issue about digest pinning.

Dmitri Zagidulin: +1 Joe.

Joe Andrieu: Just want to be a voice against digest pinning, DIDs unique ability to have indirection between identifier and crypto material.

Brent Zundel: I think the group would oppose mandating digest pinning, maybe would support language making it optional.

Manu Sporny: Last set of feedback from the TAG has to do with a potential caching attack against keys. Currently in the spec we use a full URL to identify key information in the document (or you can), the question from the TAG is, if you have a full URL for Key A, and the attacker sees Key A, uses the same URL as the other person, and we have dmitriz over there, we know that the good actor wants to interact with dmitriz, we will interact with dmitriz first with Key A.
… There is some kind of confusion attack where dmitriz caches the bad actor’s Key A not the good actor’s Key A.
… The question from the TAG is, have you thought about this, how does it work.
… dlongley responded and said that the algorithm explicitly says not to cache, but if there is a misimplementation there could be caching.
… suggestion from the TAG was to use local identifiers.

Jeffrey Yasskin: I did get this in the issue, it seems like a complication that arises because you are using JSON-LD where local names don’t really exist where you wind up with names that look global but are only usable if they are in the requested document.

Manu Sporny: just to clarify, local names do not exist, but fragments do, fragments could achieve what you are suggesting. We could also say that URLs are invalid if they do not align with the base of the document and add tests to a test suite to test that. The concern is that we would have to be careful about how we do that, as there are use cases we have explored where you may keep key information that’s yours external to the document. We would have to work through details, the controller is an example where you point outside of the document, and that is part of the security model. As a result of that feature, we have to care about external links, need to assume that is part of the core operating model.

Joe Andrieu: manu answered my direct question, which is that in DID document A, I can define a verificationMethod that is defined in another DID document/controller document.
… you are saying we have always had that feature. If we believe that the VDR controls the state of the DID document and the resolver is correctly executing, a bad actor would not be able to act on the threat you described.

Manu Sporny: they can, it’s a confusion attack, meaning that you have DID doc A,B, DID doc B uses same identifiers as DID doc A, I could see there are variations of the attack where small misimplementations make the attack work, people need to defend themselves. I want to note this has nothing to do with JSON-LD and exists because we are using URLs so our security model is more complex.

Joe Andrieu: either I don’t understand who is referring to who or I disagree. If DID document A is pointing, say attestation method, refers to a verification method in Document B, the listing of that in DID A is entirely under the control of DID document A, not DID document B.

Manu Sporny: that’s not the attack. DID A has a URL that is Key A. DID B, the bad actor, will use the same URL that’s in DID A for the purposes of confusing someone what the proper key is.

Joe Andrieu: +1 to describe this conundrum.

Jeffrey Yasskin: don’t need to solve this right now, can put it in security considerations.

Hadley Beeman: please do!

Brent Zundel: thank you for the time and review, anything else you want to express to the group from TAG, are we on the right track?

Jeffrey Yasskin: there are likely to be some concerns that the WG decides not to address, that is fine, you are on track to address the rest of the concerns.

Manu Sporny: jyasskin, you and I had a nice brief chat about continuing engagement with the TAG as we mature the work, the TAG will continue to have concerns about the work that the DID and VC WGs are doing, this is not resolvable in 6 months. Everyone being aware of that is good, I don’t know what the engagement mechanisms is other than horizational review, but some discussion here goes beyond horizationtal review comments, e.g. the discussion on multibase. What is the venue there?

Hadley Beeman: you can always open a TAG issue/TAG review, we would love to have discussions there other than “here is a done spec, please check it”. We can offer help at the architecture stage, share our experience, connect you to people, etc.
… Similarly, TAG issues don’t have to be “this is a particular feature”, they can be “let’s talk about this big question”, whether that is broad or use-case specific.
… We are happy to discuss it, and the way we do that is by beginning the discussion on Github as an issue and can continue the discussion in multiple ways.
… we are here to help, genuinely, as trite as that sounds, and are not a rubber-stamping “you are finished” body.
… The more we can have discussions around what we can help the better off we will be. We have had exchanges with other WGs that have brought finished specs to us seeking rubber stamp, we can look at it, but we don’t want to be in the position where we are checking other people’s homework.

Kevin Dean: Just would like to add a big +1 to that, I am still a member of the GS1 architecture group where we have the same model helping groups progress standards and ensure alignment, I would reiterate, as with the TAG, we don’t bite.

Ivan Herman: We don’t have to go into the details here, but what you say is something that should be better reflected in how the process works. The way current transitions go, and staff contacts communicate with the people in charge of these things, is different than what you said.

Hadley Beeman: There was some discussion of that this week.

3.3. Other CD issues.

Brent Zundel: we have about 20 minutes before lunch and could spend that time in any number of ways, we could bike shed a name for the spec, we could dim the lights and have a relaxing time, we could jump back into issue 93 which is the privacy review, although I feel like we covered that, or we could jump into other issues or PRs.

Michael Jones: If we can finish the privacy review and propose something.

Manu Sporny: agreed that would be useful, I also went through and marked a large number of issues as editorial that we could do in CR, with a goal of measuring how close to CR we are.

3.4. next topic?

Manu Sporny: I think that the vast majority of the remaining issues are editorial, so we could handle them in CR, which would accelerate us into CR, the TAG and privacy reviews have added things for us to do, but they are largely editorial. I feel we could transition to CR after we do the TAG/privacy things, we could discuss that.

Ivan Herman: I don’t know how crucial it is, but I put in some comments this morning about the PR for the service thing, I don’t know if we want to discuss that here or leave it for the usual channels.

Brent Zundel: Timeboxing a 10 minute conversation about issue 93.
… We will then spend the rest of the time looking at the issues in general to see how close we are to CR. Should that wrap up before lunch, we will go into the PR, but that can be during our normal calls.

3.5. privacy review / questions (issue controller-document#93)

See github issue controller-document#93.

Manu Sporny: I think these are largely editorial, the things that have specific things we could write are editorial, the other things we need PING to respond on, I didn’t see any massive design changes we need to make. In some cases they have the same questions we do, e.g. difference between subject and controller.

Brent Zundel: my recommendation is to reframe them, instead of saying “is this right”, say “here is our interpretation of what you said and how we are moving forward, let us know if that is incorrect”.
… we are operating in good faith and making the best assumptions we can, where we absolutely need a response I can reach out as chair to PING.
… for the most part we have a decent idea of what we are looking for.
… anything else on 93?

Michael Jones: sounds like a plan.

Brent Zundel: next topic, how close are we to CR.

3.6. Controller to CR?

Brent Zundel: looking at those issues, as we can see we have our horizontal review, we have self reviews and responses we have talked through, we will have a number of changes in response to what we heard from TAG and what we believe PING is looking for, other than that these are the issues. They have been triaged, you can see the labels here. All of them.

Wesley Smith: are marked as during CR except for 67.

Brent Zundel: which is marked both discuss and “pending close”.

Manu Sporny: we can talk about it now, we just need selfissued’s eyes on it.

3.7. (issue controller-document#67)

See github issue controller-document#67.

Manu Sporny: We had duplicate content on the spec between Data Integrity and controller document. Ivan raised a PR to remove the content that was merged. selfissued suggested that we move a line from the controller document to the Data Integrity spec, but that text already exists in the DI spec, so that’s why I have marked it pending close.

Brent Zundel: selfissued, we believe we have addressed your concern, need your feedback.

Michael Jones: so we did delete the hash of the data integrity URL, if that is the case I will agree to close this.

Brent Zundel: that was the only issue marked as not during CR, except another one, role of the subject.

3.8. What is the role of the subject when the controller property is present? (issue controller-document#33)

See github issue controller-document#33.

Manu Sporny: that one is during CR as well, I believe JoeAndrieu has language for that that will be PR’d, in theory we can address that, one option is to mark it at risk and change the defn during CR, which is appropriate, or we can handled it now.

Ivan Herman: I will repeat what I said on the DID working group, the whole discussion of controllers that took place on Tuesday at the DID WG should in fact take place here.
… the DID spec only refers to the controller document.
… I must admit I was a bit lost with the discussion so cannot go into details, but there are some issues from the DID WG that should be transferred here.

Manu Sporny: that’s only pre CR if JoeAndrieu believes there is some kind of huge normative change that we are going to make that is going to change… I don’t know why we couldn’t deal with it in CR if we mark it “at risk”. I don’t think it would change an implementation, whatever we end up doing.

Ivan Herman: It’s difficult to say that, you put a feature at risk, not the definition of a feature.

Manu Sporny: then it’s not at risk, it’s just going to maybe change.

Ivan Herman: if the defn now is acceptable for everyone, if JoeAndrieu gets to the point that something need to be fundamentally reengineered, that needs to happen now.

Joe Andrieu: not sure why putting it “at risk” is not good enough, we have the issue where dlongley, selfissued, and I went back and forth about what you prove and how this document lets you evaluate proofs created by the controller, that is an editorial cleaning up. What is at risk is the property “controller”, and what text is in the spec right now nobody supports. The language will probably trend towards “should, and if you do, you must”.
… That feels like cleaning up that is close enough to consensus that we will get there.

Ivan Herman: As a reminder, the “at risk” thing is used when you go to CR with a property but you are not sure it will be implemented. It’s not questioning the definition itself, it is whether it is implemented or not, you reserve the right to ignore that term. What you are discussing is not that, it is the definition of the controller. You are not removing controller altogether.

Joe Andrieu: removing controller is on the table.

Ivan Herman: In CR you can remove it without further ado if it is not implemented. The CR needs to prove that the spec can be implemented. At risk shows that something can or may not be implemented. Leaning too much on at risk in this discussion.

Joe Andrieu: You have convinced me Ivan, I will get something on this this week, will get us to CR hopefully soon.
… This brings in issue 75.

Ivan Herman: need to liaise this back to DID, this is where the two WGs are related.

Brent Zundel: any other issues that the editors feel the group should discuss?

Manu Sporny: the name of the document.

Ivan Herman: no >:(.

3.9. Find another name (issue controller-document#100)

See github issue controller-document#100.

Brent Zundel: I will queue up the conversation, we are stopping at 12:30, folks can continue to talk about it over lunch.
… this conversation is strictly time boxed to 6 minutes.

Joe Andrieu: just want to say that a lot of my confusions around what a DID document has or should have was clarified when I understood how verification methods and relationships worked, so why not verification document.

Manu Sporny: that’s a good candidate. We are potentially going to add services into this, modulo concerns, if we do that it is about engaging with an entity, so an option is an “engagement document”, verification methods and services. I am not saying we do this, but someone could use this for expressing their social media accounts, things like that. “How to get in touch with and authenticate an entity”.

Gabe Cohen: would make sense to call it an “identifier document”. All these docs have identifiers, seems like an obvious name.

Brent Zundel: I added myself to talk a bit about the services thing. Controller document as we conceived of it came from ??? specs which were taken from the DID specs, there was a question around “where are our services”, the assumption during the DID call was that there was a common document, after thinking about it I think that services should not be pulled up into controller document.

Ivan Herman: two things, what you just said, from a general POV, is the same as what I was saying in my comment on a technical POV, and I don’t want to go into the details now but would also favor not to have the services. The other point is that, for you guys certain crypto things are natural, that is not true for outsiders. For me, the fact that you have a document that can combine crypto information with identifiers is a central element that an outsider understands. The crypto element is central to the whole thing, and I would like that to be reflected in the title.

Pierre-Antoine Champin: I don’t like “engagement document”, maybe “entity document”?

Wesley Smith: [general laughing].

Ted Thibodeau Jr.: “cryptomogriphication document”.

Brian McManus: With that we’re done (Joe gets the last word) =).

4. Every Other Rec Track Document.

Brent Zundel: Welcome to the final VCWG session before the joint session with the security group.
… This session focuses on all other rec track docs.
… our main goal has been to understand what we need to do to get these documents done.
… We will hopefully pass some resolutions to move these rec track documents to their next phase of existence.
… additionally we will be talking test suites.
… This will take up the next 90 minutes.
… subtopic: security specs to CR.
… beginning with the proposals.

Manu Sporny: there are three proposals that are very similar to publish VC data integrity the ecdsa and eddsa cryptosuites as CR2.
… these are in pretty good shape with at least 2 impls of the features.
… for data integrity there is 8 impls. Ecdsa has 6 implementations and eddsa has 8 implementations.
… We dont expect to see any features with less than 2 implementations, if we do we will add feature at risk markers.
… where necesssary.

Brent Zundel: https://docs.google.com/presentation/d/1rjt4fgajEqqQzdF72JUeh6_h4gICQanExOfcoW4l0GM/edit#slide=id.g302b406d124_0_31.

Manu Sporny: The proposals are at the above slide.

Ivan Herman: in the proposal text we should not put the explicit URL.
… as they can get outdated.
… also, we have not talked about bbs yet.

Brent Zundel: changes to the proposal, get rid of the links from the text.

Ivan Herman: Suggest adding one resolution for all three documents.

Manu Sporny: makes sense, reworking the proposal.
… 3 outstanding issues on data integrity. 2 are ready for P.R, the other has been discussed and resolved.

Brent Zundel: Any suggestions or modifications to the proposal?

Michael Jones: Why is vc-jose-cose not on the list?

Brent Zundel: We are going to do that, I didn’t know vc-jose-cose was ready.
… Is this proposal okay, selfissued?

Michael Jones: This does not include vc data model?

Ivan Herman: That was resolved yesterday.

Proposed resolution: Publish the latest VC Data Integrity, ECDSA Cryptosuite, and EdDSA Cryptosuite specifications as a 2nd Candidate Recommendations with a 30 day review period after PRs for AT RISK features and all current open issues have been addressed. (Brent Zundel)

Brent Zundel: Not hearing any change requests.

Ivan Herman: +1.

Manu Sporny: +1.

Greg Bernstein: +1.

Denken Chen: +1.

Gabe Cohen: +1.

Will Abramson: +1.

Wesley Smith: +1.

Dmitri Zagidulin: +1.

Benjamin Young: +1.

Ted Thibodeau Jr.: +1.

Jennie Meier: +1.

Paul Dietrich: +1.

Kevin Dean: +1.

Resolution #2: Publish the latest VC Data Integrity, ECDSA Cryptosuite, and EdDSA Cryptosuite specifications as a 2nd Candidate Recommendations with a 30 day review period after PRs for AT RISK features and all current open issues have been addressed.

Brent Zundel: Hearing no opposition, we are resolved.
… manu anything else to discuss related to data integrity, lets talk about bbs.

4.1. BBS.

Manu Sporny: We are not ready to go to CR2 with BBS. GregB has done a great job finishing off the base specification at the IETF.
… There are two new specs added to do with pseudonyms.
… The review is not yet complete at IETF (cryptographic review).

Greg Bernstein: This is different from general cryptographers. There is an assigned person. This has been outstanding till January.
… We are trying to get ready for last call, but waiting for the person for the review panel.

Manu Sporny: A number of other IETF groups also depending on BBS and pushing for this to get done.
… Also bringin in other folks with specializations in BBS to get this throrugh the IETF.
… We have two interoperable implementations that meet all the features.
… Had the review at IETF been done, we would have been ready to move this to CR2. But since it isn’t we are waiting on IETF for this.

Ivan Herman: There was a comment on BBS in the charter that mentioned the timing challenges with IETF. I will reply telling them we are aware of these challenges and the document might remain in CR a bit longer.
… I also said there is no normative dependencies on other specifications to BBS so it does not hold up any other specs.

Brent Zundel: Are there no other things left to do on the BBS data integrity spec?

Greg Bernstein: There are two key features that we are getting demand for: Anonymous holder binding and pseudonyms.
… The API on the IEFT is getting cleaned up, this will affect our spec.
… Pseudonyms allow remembering parties who use BBS with anon holder binding and unlinkability.
… Other places need these features.

Brent Zundel: Any further questions?

Manu Sporny: There is very little that needs doing.

Brent Zundel: Right, but there may be normative changes due to changes in the base ietf spec that are holding us back.

4.2. VC JSON Schema.

Gabe Cohen: We are missing another implementation for the test suite.

Brent Zundel: No normative changes require a second CR phase?

Gabe Cohen: No.

4.3. VC Bitstring Status list.

Manu Sporny: vc bitstring status list is not ready for CR2. But, it is doing pretty well.
… It has been held up, due to us focusing on other specifications.
… There are 8 open issues, a number are editorial.
… There are 5 normative issues that could use some discussion.
… Because of those issues being normative, we are not ready for CR2.
… Additionally, we are lacking the implementations against the test suite.
… We are waiting on these issues being resolved.

Brent Zundel: Mesur is intending to demonstrate an implementation of the bitstring status list.

Manu Sporny: Great. We are expecting many more.

Brent Zundel: Okay. lets look at some issues.

4.4. Align bitstring structure and IETF Token Status List structure? (issue vc-bitstring-status-list#93)

See github issue vc-bitstring-status-list#93.

Manu Sporny: First issue is aligning the bitstring structure with the token status list structure at IETF.
… We all agree alignment would be great. I do not know the status of this alignment.
… At this point, we are either aligned or not. I don’t know how much energy there is to change the structure of the statuslist.
… Be great to hear from the group.

Brent Zundel: The associated issue tracking this on IETF side is still open, but the last I heard was there was too great a drift. There i no IETF appetite for alignment.
… So we either do extactly what they did, or we continue with what we have.
… Option A: is to do nothing.
… Option B is to do a lot of work to align with IETF. But no gaurantee that their spec is stable.

Joe Andrieu: +1 to option A. the effort feels unnecessary and likely unproductive.

Brent Zundel: For B we would be effectively having a normative reference of their specification.
… I am fine if this issue would be closed.

Manu Sporny: As DB, we have implemented what is currently in the spec. We have no interest in changing this.
… So +1 for option A.

Brent Zundel: Marking it with pending close.
… Any additional issues?

Manu Sporny: 2 issues 175 and 176.
… Around status messages and status size.

4.5. The BitstringStatusList.statusMessages and statusSize properties are still being referenced (issue vc-bitstring-status-list#175)

See github issue vc-bitstring-status-list#175.

Manu Sporny: There is maybe only one implementer for this feature at this point.

See github issue vc-bitstring-status-list#176.

Manu Sporny: Dont think it is currently marked as at risk.
… Actually it is already marked at risk.
… So we are waiting for implementations.

Brent Zundel: My understanding is mesur implements these features.

Manu Sporny: Great. I think Spruce may also be using it, so leaving it in awaiting implementations.

4.6. TTL is mandatory 5 hour period if not specified (issue vc-bitstring-status-list#174)

See github issue vc-bitstring-status-list#174.

Manu Sporny: Moving on. The next issue has to do with the time to live (TTL) feature.
… The spec currently states TTL default is 5 hours.
… The status list becomes invalid after 5 hours. Some implementations do not want to do this. Retail stores sometimes go offline for a week at a time.
… They still want to be able to process things after a 5 hour timeout.
… An option here would be to state TTL is completely optional with no TTL default. This would allow others to profile this and constrain TTL per their use case.

Joe Andrieu: +1 TTL optional.

Brent Zundel: Do we know the reasons it was not wrote optional in the first place.

Manu Sporny: MikeProrock wrote this language. We should ask him.

Brent Zundel: I can do that.

Joe Andrieu: What does the language say should happen after TTL has been passed.

Manu Sporny: See https://w3c.github.io/vc-bitstring-status-list/#bitstringstatuslistcredential.

Brent Zundel: See https://w3c.github.io/vc-bitstring-status-list/#:~:text=credentialSubject.ttl.

Joe Andrieu: I have issues with this language. It feels like an application related thing. That the Verifier should refresh the cache.
… Sometimes they will not be able to. So saying that they MUST NOT use cached data is an overreach.

Manu Sporny: I agree, but the problem with weakening it makes the TTL kind of irrelevant.
… many of us do not like the TTL at all. Potential for conflicting representations with HTTP headers.
… Additionally there is the validFrom and validUntil fields.
… This is a questionable/problematic feature.
… A few implementations plan on just ignoring it anyway.
… For those that want it, they can use it but there are dangers.

Kevin Dean: Wondering if it would not be acceptable to state that if the target is unreachable, the Verifier may proceed with the older cache of the status list.
… I think TTL is an important parameter in some cases.
… It should be the application can decide what to do if it is unreachable.

Brent Zundel: I would be in favor of Kevin’s suggestion.

Dmitri Zagidulin: Puzzled why we are discussing the valid issues of TTL. This is a direct redundancy of validUntil.
… two problems. 2 fields that do the same thing. Secondly, should we make the TTL property optional.

Paul Dietrich: +1.

Joe Andrieu: I agree with dmitriz.
… It feels like if we enshrine it as a property that is optional we are giving people the option to advertise something that is confusing and optional.
… It introduces the wrong mental model.

Gabe Cohen: Fine with removing it. Wondering if there is some aspect of this property that is useful though.

Kevin Dean: +1 to that.

Will Abramson: wes-smith: Adding some nuance. The TTL and validUntil are not the same thing. TTL is around how long the cache of the status list. Wheras validUntil is on the core credential.

Brent Zundel: +1 to Wes.

Gabe Cohen: They are different but conflicting.

Manu Sporny: The use case around TTL is, you want to set a long expiration time for your status list. But tell the verifiers that you may make changes within a certain window.
… TTL is around caching semantics.
… That said, http caching headers are about this too.
… A counterpoint is that you might not have access to the system that fetched the status list. This is where TTL on the status list itself may be useful.

Joe Andrieu: reputing the usecase. because this is MUST it says that the status list is not valid after the TTL.
… Therefore you would have to expire.

Will Abramson: wes-smith: Responding to JoeAndrieu. I agree if TTL has expired you can’t use it. The verifier would fail to verify because the status list has expired.

Joe Andrieu: This still does not make TTL and validUntil the same.
… Does that make sense?
… You can use an expired credential. Validation happens after verification.
… This language says I cannot use it in conformant software.
… This prevents the usecase that manu mentioned. If it is a MUST that the list is no longer valid then it excludes this usecase.

Manu Sporny: concrete proposal to shift the language to a MAY. This makes the semantics different from validUntil. You can continue to use it past the TTL.
… Any objections to this change to the TTL field.
… This will make the TTL field a purely optional thing.
… If it is there, then you should check.

Will Abramson: Are we saying the TTL will have no default value there?

Manu Sporny: I would suggest it doesnt have a default value. Because it is usecase specific.
… e.g. a trading floor might have microseconds.
… I dont think picking a value makes sense.
… applications can profile it.

David Lehn: The issue says 5 hours, but the spec currently says 5 minutes.

Brent Zundel: Sounds like there is enough input for someone to raise a PR.

Manu Sporny: yep, I can take that.

Brent Zundel: Any other issues.

4.7. Describe decoy entries as a privacy mitigation (issue vc-bitstring-status-list#150)

See github issue vc-bitstring-status-list#150.

Manu Sporny: We still need to discuss decoy entries.
… Waiting on nick doty to let us know if we addressed his concerns.

Brent Zundel: We are acting in good faith. If this ends up holding us up, lets close it.

Manu Sporny: The PR that got merged was an issue marker stating that in general decoys reduce the privacy of the status list.
… We haven’t talked about it since then.
… We need to say if we think decoy values are harmful. say nothing. Or recommend decoy values.
… I think decoy values are harmful, because adding decoys shrinks the set size.
… Reducing privacy.
… The argument here is that you should set bits in the list randomly. Don’t waste any bits in the list for decoy values.
… We could also say you can use decoy values if you want. Seems conterintuitive though.

Joe Andrieu: I am not convinced on this argument.
… The k-anonymity argument is how many people can I be confused with. I think with decoys I can be confused with a decoy. That is a good thing.

Kevin Dean: I agree with JoeAndrieu. It is possible to create a properly randomised list. And one that is expandable over time.
… I can drop a link to this.

Will Abramson: wes-smith: I am confused with what manu said about decoys cutting the group privacy of the set.

Kevin Dean: Is the idea over time that verifiers can learn which entries are decoys in the list.

Manu Sporny: Yep that is one attack. The other argument is why don’t you just use a much larger set.

Kevin Dean: Fisher-Yates shuffler Python code: https://github.com/KDean-Dolphin/Python-Shuffler. IIW presentation: https://drive.google.com/file/d/1wtT2GUQrl7lKCarHYkWvyPbcRmm1Dvji/view?usp=sharing..

Manu Sporny: Otherwise you have to perfectly model the rate of issuance to real people to decoys then you can statistically determine which entries are likely to be decoys.
… e.g. if someone is issuing decoys at 4am (a bad example) then you can easily detect when decoys are being added.
… This is how the reduction of privacy occurs.
… The language says in general it is harmful to add decoys. Because it requires expertise to add decoys. It is a roll your own crypto type thing.
… Easy to do the wrong thing.

Denken Chen: +1 to the security best practice.

Brent Zundel: In general, is it possible to start the bit string status list with a randomised string.
… Then every entry could be a decoy.

Manu Sporny: Yes, but if you know the issuer always issues inactive things. You know the k-size.

Brent Zundel: It sounds like a way to address this issue might be. Perfect deployment of decoy values would increase the privacy protections of the set. However, the degratdation that occurs though improper use of decoys leads us to not recommend this approach.

Will Abramson: wes-smith: Thanks for clarifying. The language that we started with is not the best language. Decoys do not harm privacy, BUT it is hard to use the correctly.

Gabe Cohen: Thanks this makes sense now. We should add language around updating status lists and the risks around eroding privacy.
… I agree you can use decoys in a safe manner, but not sure it is worth talking about in the sepc.

Joe Andrieu: The language around not rolling your own is on point. But there might be tools written by experts that people can use.

Manu Sporny: I am concerned that this does not exist yet.
… People will try to do this, but may not do it well.

Brent Zundel: I think that is all the CR normative issues for bit string status list.
… Any notion of the timeline for this.

Manu Sporny: This wont be ready by january. Because of the other specs that are in need of attention.

Ivan Herman: I would prefer to keep the goal of January. We are not that far away.
… The result from the discussion with jeffery today was that there are 3 or 4 editoral changes required to the controller document.
… The only outlier is BBS spec.
… I believe it is still possible to aim for January.

Manu Sporny: Reminding everyone it could go fast if people did a PR.

Ivan Herman: This is true. Many things are independent PRs that can be done in parralel.

Brent Zundel: I think we have a solid idea for all our specs and next steps.
… We had a great conversation with vc-jose-cose. We know what is left.
… At what point do we anticipate a second CR from vc-jose-cose.

4.8. VC JOSE COSE timing.

Gabe Cohen: After the media types PR goes in there a no other normative issues to resolve.
… we should go to a second CR after that.

Brent Zundel: Any issues passing a resolution to talk to that.

Manu Sporny: During that conversation I raised there is still no language around mandatory reveal of contexts. We should address that before CR2.

Ivan Herman: My understanding is Phillipe has already contacted IETF after our discussion this morning.
… If we have a positive response that I agree we can go to second PR. This may take a couple of weeks.

Brent Zundel: Talking timelines for vc-jose-cose. decentralgabe has raised a PR to address the resolution passed this morning.
… After the review period the PR will be merged.
… Our first meeting back we may have a conversation about advancing jose-cose to CR2.

Ted Thibodeau Jr.: The text I flagged in 305 is no longer what I expected. It makes me concerns with the git history throughout the spec.

Michael Jones: I am about to create a PR to address this. It turns out a PR that did exist has been deleted. I will flag you as a reviewer to the PR.

Ted Thibodeau Jr.: That is all good. However, I cannot find the commit that shows the change removing language that I raised my comments against.

Brent Zundel: Please continue to look at the history for us TallTed.

Gabe Cohen: this is it? 41b73cca80ebfee7b221087414681504275e9b7c.

Ted Thibodeau Jr.: This should not be possible in git.

Manu Sporny: This is why we always do rebase commited so as not to confuse git in these ways and loose git history.
… If you do merge commits you can point to alternate histories.

Dmitri Zagidulin: rebase commit turns git into a blockchain.

Manu Sporny: Yes, this is why you dont do merge commits.

Gabe Cohen: I posted the commit in, it was a result of the squash commit i used.

Gabe Cohen: I have disabled squash and the repo it won’t happen going forward.

Ted Thibodeau Jr.: Sorry, the commit you found decentralgabe is not quite right.
… There is disclaimer test that includes test that I added.

Michael Jones: If you approve the PR I just sent that language will come back.

Ted Thibodeau Jr.: That is good. I am still concerned with how this came about.

Paul Dietrich: Have to drop off gang. Great to see the progress.

5. Use Cases and Requirements update.

Kevin Dean: Reminder the UseCase document can be found at https:.
… Some material may move the the VC-overview document.
… We are still looking for some new usecases.
… The short usecases are small simple usecases. These exist already. They are self contained and generally unrelated to other usecases.
… There are 30 currently, not generally looking for more. But if there are good ones we may consider replacing.
… The extant use case are from usecase that exist in the market. Either in production, or proof of concept. Looking for a title and very short description and URL.
… Finally, focus use case is a deeper diver into a VC application. This is highly detailed. With title, background, list of actors, validation requirements and threat model.
… We proposed a timeline, but did not get much contributions.
… We would like to close this by the end of 2024.

Joe Andrieu: One major addition in this version of this usecase was the GS1 usecase. Particularly that deals with delegated authorization.
… Thanks KevinDean.

5.1. Exchange of Electronic Certificate of Origin to facilitate Cross Border Trade (issue vc-use-cases#157)

See github issue vc-use-cases#157.

Joe Andrieu: There is another trade supply usecase that we are working to unpack. This aims to make a concrete case for selective disclosure in products going through the supplychain.

Kevin Dean: This is issue 157.

Joe Andrieu: I want to mine the test suite for implementers to find people using VCs in the wild.
… Right now the extant usecases is empty.

Manu Sporny: Do the tradetrust folks(issue 157) want to speak to their usecase.

SinYong: If I issue an invoice to you, you may want to hide your name from me. To obfuscate from the invoices. This applies to suppliers of products.You have to pay to ship you product from point a to point b. You do no want your downstream parties to know how much you paid.

Kevin Dean: That is true in many supply chain cases. I may need proof that I am a retailer, without knowing exactly who I am.

Manu Sporny: This is a really important usecase, because it signals we do not have a cryptosuite that is capable of this yet.
… This use case is, I get a VC and want to selectively redact information on that VC without violating the signature.
… Each point in the supply chain can redact additional data from the VC.

Joe Andrieu: Is this possible? There is innovative/novel cryptography that can do this.
… I just want to know it is possible.

Manu Sporny: Yes, it is possible.

SinYong: When we do our project, the holder ???, We do not want to issue VCs to every party along the supplychain. We use the VC to represent a tree structure. It does not issue the VC to any particular holder.

Kevin Dean: interesting. In redaction you still have the same public key to identify the issuer. This can’t go with the credential. It may still give the opportunity to identify who the supplier might be.

cc: Our merkle proof signatures are going to bepublished and made into an extension.

Denken Chen: We are starting to explore an open ecosystem of VC and DIDs. We could contribute our research back to the community.
… Our first focus is on the threat model. Do we need to deal with the W3C threat modelling group here?

Brent Zundel: I think yes.
… We will be meeting with the security people after the break.

Manu Sporny: +1 to brent. Simone is putting together a threat modelling approach for multiple groups to go through.
… There is going to be collaboration in the future.

Joe Andrieu: We do have a section about threats in the use case document. But this is not based on any of the work. What we have is closer to a risk analysis.
… A much simpler model.
… It would be great to use whatever Simone is producing.

Denken Chen: I know in W3C the threat modelling is an overview. In our work, we have a more detailed threat modelling of specific usecases. We are focused on threat modelling for issuers, holders and verifiers. We may be able to contribute this.

Brent Zundel: Any additional comments?
… Not hearing anything. meet back here in 1 hour.

6. Meeting with Security colleagues.

Brent Zundel: Welcome to the final VCWG session of TPAC 2024, this is our joint session with Security. This is scheduled for 90 minutes.
… The goals of this session: first, find actionable feedback for us to take on the specs, second, for us to know what the process should be moving forward as far as specs moving into CR and PR and onward.
… as that relates to further security review.
… first, does the Security group have anything they would like to share with the VCWG as far as the review specs?

Simone Onofri: happy to be here, there are some volunteers that have already started working, people you already know such as jaromil.
… there is a long list of documents to be reviewed, my idea is to move forward together into threat modeling to put security risks + threats as well as privacy issues together, to kill two birds with one stone.
… the threat model in this case should only be the start - we are already testing information leakage in BBS.
… if the implementation and test vectors are ready we can do this testing.
… working with ETH Zurich to find researchers to do this analysis.
… also will talk with IETF to discuss the BBS work.
… we also need to work with the CG for post-quantum tools.
… next steps involve ZKPs for post-quantum, we do not have that capability yet.
… initial feedback, the threat model is already 50 pages, there is more work to be done on credential formats.
… we can organize a meeting structure to better understand what we are working on together, reading the spec is nice but it’s easier to discuss with the WG.
… we should also try to better understand what collaboration with other entities is needed, e.g. IETF.
… there was an idea to have Security Directorate support for our standards, there is joint work potential there as well.

Manu Sporny: just to note interest in participating in the threat model work, especially as it relates to VCs and their securing specifications.
… as far as timeline is concerned, we are going into second CR phase, we are hoping to go into proposed recommendation realistically by January, so not a lot of time.
… I am wondering if we could split the review up into two passes, we have another 2 years in the group and can maintain the documents, I am wondering if we could do a high-level review to find major concerns from a security perspective as soon as the group has started.
… then move into a work mode where we do longer term analysis. Quick review before PR then continuous review.

Simone Onofri: you have in the charter that you will update the spec if a security issue is found.
… that’s a nice approach. thank you.
… if there are some blockers, I don’t think there are.
… what we have now, I don’t see any imminent issues.

morimori: what did you mean using ZKPs to deal with post-quantum.
… why is ZKP being used for post-quantum.

Simone Onofri: it’s a long-term objective.
… when we were thinking about these security sections.
… we wanted to note that there was future work to do.
… it’s good to point to things that need addressing in the future.
… they’re notes to address later.
… each time we do a review, we can update it with the latest info.

morimori: maybe PKC could attack the recent crypto in ZKP.
… maybe I’m wrong…but this is interesting.

Simone Onofri: it’s OK. these were just notes.
… sorry for the confusion.
… this is really to keep it on our radar.

Will Abramson: Here is an example of people looking at ZKP in lattices. In particular they are trying to achieve the same properties as BBS I believe https://web.archive.org/web/20220428172452id_/https://eprint.iacr.org/2022/509.pdf.

Simone Onofri: the approach we are trying to implement is to start from the threat model.
… and note areas of possible concern.
… and security is always a trade-off.
… so we work to keep an eye on the future.

Brent Zundel: to recap.
… there isn’t any outstanding issue that would prevent us from moving the specs forward.
… so when we submit CR2 requests we should be able to say “security review has been done so far”.

Simone Onofri: yes. we can stay in touch as the threat model document develops.

Brent Zundel: but we can move forward, correct?

Simone Onofri: yes. the threat model document is general.
… and we want to do it together.

Brent Zundel: not a problem.

Ivan Herman: we need a yes or no…

Brent Zundel: we need to know if we’re waiting on this work.

Simone Onofri: we should organize a 2-4 hours about answering this question.

Manu Sporny: so, you’re saying we should meet with the group for 2-4 hours and at that point we should have an answer?

Simone Onofri: yes.

Manu Sporny: maybe the editors can commit to that.
… can we do it in the next couple of weeks?

Simone Onofri: yes.

Manu Sporny: so, we can do CR2, then this meeting, and hopefully go to PR after.

Ivan Herman: the transition request takes 1-2 weeks.
… so for us, getting through this is our top priority.
… at this moment, this has a higher priority than working on the threat model.
… with all the timing and delays from the security review, we need to move forward without waiting on the threat model document.

Simone Onofri: the threat model has existed since march.
… so it’s already been worked on.
… but now that I am working alone…it may take longer to review.

Ivan Herman: is the plan that the review will be done by the new group?

Greg Bernstein: More up to date paper: Practical Post-Quantum Signatures for Privacy (https://eprint.iacr.org/2024/131).

Simone Onofri: yes, but the group is not formed yet.

Ivan Herman: then I withdraw all my optimism :-).
… with all the overhead of setting up the new group…we will be waiting for weeks…if not longer.
… the soonest we could meet at the soonest early November.
… it’s almost October.
… and then there’s a review meeting…
… we cannot submit the publication request without the review being done.
… so mid-November would be the soonest it could be on the Web.
… adding 30 days review…we’re essentially in January…because holidays.

Simone Onofri: I am sadly working alone.
… I can check with others who can possibly contribute.

Manu Sporny: I think the timelines are reasonable.
… given all the constraints.
… it would not be healthy to have a single reviewer, so waiting makes since.
… as long as it can be one of the first things that this new group works on.

Brent Zundel: we were supposed to be done in July.

Manu Sporny: I get it…but…
… this is where we are.
… everyone’s doing the best we can.
… and the things we can do is to help find contributors to the security group.
… so they can start sooner.
… we’re also throwing a lot of documents at them.
… and it’s not a walk in the park…there’s a lot going on in our group.
… the editors are happy to help.

Brent Zundel: in recognition, there is no security group.
… our request has consequently timed out.
… we will move forward with our documents.
… because there’s not security group, we are not able to wait on this group to do it’s job since it doesn’t exist.
… I’m not saying it should have somehow been done by one person.
… but we’re in this transition where we need a review and there’s no one to do it.
… and it’s needed in the past…but here we are still needing it.
… my preferred course of action is to not continue to wait.
… let’s transition our documents.
… with the plan to continue to do security review as this group becomes available.
… our charter covers security changes.

Ivan Herman: staff hat on, I’m happy to do what you say.
… but I fear we will be asked to wait for at least the PR publication.
… whether the delay happens on CR2 or PR is a technicality.
… so we can just submit it and see what happens.
… this delay will happen at some point, and this is the last minute that we can do this.
… so I will submit the request for the new charter to be accepted.
… and I will propose to delay the publication of new docs by a month–so February.
… so that’s one more month of delay.
… which should give simone more time to construct the security group.
… is that OK?

Manu Sporny: I don’t think there’s any issue with going to CR2 unless simone feels differently.
… we could be delayed at PR or TR later.
… but I do feel it would be very bad to go to TR without some sort of strong security review.

Ivan Herman: that won’t happen.

Manu Sporny: good. because I don’t think we should go to Rec without a security group review from this new group.
… we picked a somewhat arbitrary date in the charter for publication.
… can we remove that?

Ivan Herman: no…there has to be a timeline.
… hence my proposal to delay.
… it hopefully gives us the margin we need to acknowledge the difficulties of the security review.

Manu Sporny: so, we can still do CR2 and maybe go to PR?

Ivan Herman: the big transition is going to PR.
… so I expect the management to wait for CR2.
… or maybe we can convince them we can publish CR2 knowing the security review will happen during that phase.

Brent Zundel: we will try to go to CR2.

Michael Jones: I see ivan’s change to the target date is no risk at all.
… it should give some of us more time.
… if we can publish it earlier in January, having that breathing room won’t hurt.

Manu Sporny: simone, what can we do to prepare for the 2-4 hour security review?
… can we provide info for review ahead of time?
… what can we do to prepare?
… just bring the specifications? and maybe point to specifics we feel my need scrutiny?

Simone Onofri: one useful thing.
… it would be good to create kind of a schema.
… and a list of the kind of requests made with a VC.
… I don’t see many issues because we have already been thinking about this.
… hopefully that will help us make a quicker approach.
… my main concern is the level of testing of the cryptography.
… that can’t really be speed up.
… maybe we can take more time there.

Manu Sporny: so, maybe GregB and I can work on a sort of primer on the reviews done to date.
… so that when the group is created, we have something to help you do the review.

Simone Onofri: that sounds useful.

Ivan Herman: simone what do you mean by level of testing of the cryptography?
… we do not do anything with cryptography.
… we use “off the shelf” crypto.
… we do not define anything new in that sense.

Simone Onofri: the first thing were the test vectors.
… that they need some implementation to get around.
… analysis of the use case. not just what crypto but how it is used is important.

Greg Bernstein: VC threat modeling is unique. We have a 3 party model unlike others who only have 2 parties.
… we also started listing what crypto operations are happening in a specific spec.
… EDDSA does things differently from ECDSA.
… sometimes the hashing is manual prior to crypto.
… like the hashing in canonicalization.
… we’ve tried to make that clear for horizontal review.

Simone Onofri: I agree with you.
… the stuff we have now is for the generic data model.
… we need to customize the meta model.
… to have tiny sub-models based on which crypto and proof is in use.
… I don’t see any major issues.
… we would review the text you already have written.
… since this is already done, that would be our first thing to review.
… we’d mostly look for missing threat model scenarios.

Manu Sporny: you’ve mentioned test vectors.
… GregB’s done a great job with making test vectors.
… they cover all the steps.
… we also have several open source implementations.
… and we can make sure these have covered all those scenarios.

Simone Onofri: it can be strange to use an implementation to find issues, but it is a common approach.

Brent Zundel: simone sorry for the grilling.
… we appreciate the w3c review efforts real.
… sorry about my personal frustrations with the timing.

7. closure.

Brent Zundel: thank you everyone! it was great.
… I really appreciate all y’all have done.
… and for the amicable conversations.
… reminder: there is no working group meeting next week.

Manu Sporny: and thank you to the chair!

room: [applause].

Brent Zundel: folks online, goodbye.
… everyone else, safe travels.

8. Resolutions