VVerifiable Credentials Working Group F2F at TPAC, 1st day, 2023-09-14 - Minutes

Date: 2023-09-14

See also the Agenda and the IRC Log

Attendees

Present: Ivan Herman, Brent Zundel, Kristina Yasuda, Phil Archer, Shigeya Suzuki, Andres Uribe, Gabe Cohen, Hiroyuki Sano, Pierre-Antoine Champin, Manu Sporny, Jay Kishigami, Ted Thibodeau Jr., David Chadwick, Geunhyung Kim, Hyojin Song, Sebastian Crane, Kevin Dean, David Ezell, Amy Guy, Michael Jones, David Waite, Dmitri Zagidulin, Joe Andrieu, Dingwei, Benjamin Young, Laurens De Backere, Dave Longley, Greg Bernstein, Kaliya Young, Oliver Terbu, Paul Dietrich, Jean-Yves Rossi

Regrets:

Guests: Laurens De Backere, y-sakuma, helen

Chair: Kristina Yasuda, Brent Zundel

Scribe(s): Andres Uribe, Joe Andrieu, Manu Sporny, Gabe Cohen, Sebastian Crane, Kristina Yasuda, Brent Zundel

Content:

1. VCDM PRs.

Brent Zundel: Currently 12 open PR in the vcdm repo. We’ll go through all. If we can’t get consensus, we’ll mark as pending-close.

Brent Zundel: https://github.com/w3c/vc-data-model/pulls?q=is%3Apr+is%3Aopen+sort%3Acreated-asc.

Brent Zundel: first one is 1199.

1.1. (pr vc-data-model#1199)

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

Brent Zundel: Raised by orie. Good review and a number of comments. 1 open request for changes from TallTed. Are you’re changes unaddressed?

Ted Thibodeau Jr.: Haven’t had the chance to review.

Brent Zundel: If it meets your approval, we can merge.

1.2. Add Verification Method types to v2 context (pr vc-data-model#1260)

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

Brent Zundel: Next one is 1260.
… Raised by Orie. Open for some time. Currently 1 pending change request from manu.

Manu Sporny: It’s a general objection to the PR. We have a use case where expressing public and private keys in the context. It would change if we had something like confidence method to the base context. -1 until that’s the case.

Brent Zundel: Since no approvals, there is no consensus and one objection. We plan on closing.

Ivan Herman: the secret is already in the vocabulary. Just noting that.

Manu Sporny: We might want to look at that, it might be a mistake.

Brent Zundel: We need an open issue to track a possible change to the vocab. We intend to close this PR due to lack of consensus.

1.3. updated entity to include abstract nouns (pr vc-data-model#1269)

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

Brent Zundel: Raised by JoeAndrieu, suggesting changes to terminology.
… Few approvals, one request for changes from TallTed.

Ted Thibodeau Jr.: If changes are done, I’m ok merging.

Brent Zundel: not merging yet, close to being merged. We’ll move on.

Joe Andrieu: FYI edits for #1269 accepted. https://github.com/w3c/vc-data-model/pull/1269.

1.4. Explain JSON-LD further. (pr vc-data-model#1270)

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

Brent Zundel: Explain json-ld further. A section that was widely asked for. Has had comments back and forth, no approvals. More work to be done. We’ll time box to 10 minutes what changes are needed from folks.

Michael Jones: This PR is a lot of philosophy and not a lot that helps implementers.

Manu Sporny: The group asked us to write this. They asked for “we want to see a section that explains json-ld”. We have other places in the spec that explain why some choices were made.

Sebastian Crane: It looks good on a first impression. I would prefer for it to be cut back. Not because it is incorrect, but it includes some things that sounds like opinions. This makes folks uncomfortable. I would suggest som word smithing. I would object to merging now, but ok in the future.

Brent Zundel: Suggestion is to make concrete suggestions.

Michael Jones: There are 14 new paragraphs. Please cut it down accordingly.

Ted Thibodeau Jr.: The entire section is informative. It might be better as an appendix.
… It doesn’t talk about JSON, but its use. That’s the way it is.
… If Mike really thinks it could be said in a single paragraph, please suggest how to concretely do it.

Kristina Yasuda: we need something in main text as opposed to appendix.

Shigeya Suzuki: +1 kristina.

Brent Zundel: Happy to hear thought about the appendix suggestion.

Manu Sporny: +1 what TallTed said. It’s really difficult to understand the changes requested without suggested changes. Please either write a PR, or make concrete github suggestions.

Kristina Yasuda: Re: moving to appendix. I do believe we need a few short and sweet paragraphs in the main text. More details can go in the appendix. Doesn’t need to be pre-cr. Bottom line, the goal is to give folks some background on JSON-ld before sections that work off of it.

Manu Sporny: +1 kristina, keep shorter section in the main spec… but don’t feel super strongly about it.

Brent Zundel: Since this PR is non-normative, it’s not urgent to merge this PR.

1.5. Add guidance to not use JSON-LD keywords in @context value. (pr vc-data-model#1271)

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

Brent Zundel: Raised 4 days ago. Within window of review.

jose-gataca: jose-gataca has joined #vcwg.

Brent Zundel: Some approvals already, one change request.

Sebastian Crane: Issue 1264, which this PR quotes, doesn’t need to be merged for this to be merged.

Manu Sporny: BigBlueHat just wants some rewording. Can be done and merged after that.

Ted Thibodeau Jr.: just to note – I have not reviewed this PR yet.

Brent Zundel: PR is on course to be merged soon.

1.6. Add base classes and fragment identifiers for vocabulary. (pr vc-data-model#1272)

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

Brent Zundel: primarily editorial, raised a few days ago.

Manu Sporny: Yes to all of that, just need to merge TallTed’s changes.

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

Ivan Herman: For the record, I did 1278 yesterday.
… it’s on top of 1272.

Manu Sporny: agree to merge on top of it.

Brent Zundel: merged, back to 1272.
… still have 3 more days for reviews.
… manu to look at suggestions made, anticipating that the PR will be merged soon.

Sebastian Crane: What I was saying is that the ease of merging Ivan’s PR illustrates how useful it is to push to a ‘personal’ branch within the W3C repository, not to your GitHub fork. It is not possible to push to someone else’s GitHub fork, so that discussion would have involved lots of git commands if Manu hadn’t pushed to the main repository.

1.7. Provide guidance to use compact terms/types instead of full URLs (pr vc-data-model#1276)

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

Brent Zundel: Few requests for changes from TallTed. Not a lot of review yet, raised 2 days ago.
… We’d like to see how to move this forward.

Manu Sporny: This is in response to an issue that DavidC raised.
… We’re suggesting to people that they do not use full URLs for things that have json-ld terms. Doing so would harm interop. Not illegal, just a suggestion to not do it.

Brent Zundel: Please review folks.

1.8. Fix markup, typos, and a small fix. (pr vc-data-model#1277)

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

Brent Zundel: This is a cleanup PR. Much appreciated. Don’t expect it’s open long before it’s merged.
… Editorial, thanks DavidC. Looking forward to merging.
… Next is 1279.

1.9. Add links to static copies of vocabulary files and hashes (pr vc-data-model#1279)

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

Brent Zundel: PR was raised 16 hours ago. Manu clearly is bored.
… Can you give us an intro?

Manu Sporny: We’ve made a decision to be more strict about how we specify the json-ld context and vocab documents used.
… I believe it’s because we want to be more strict about what a VC is.
… We now are very specific for the semantics for all terms. And the contents of the files that describe it.
… This PR does it in the vocabulary files themselves.
… This PR points to the DI vocab and the VC vocab. This is us being very specific about which vocab documents are used.

Ivan Herman: I’ll just repeat here the same comment I made earlier.
… If we start putting hash values in schema, then we’ll have to put them everywhere. There is no chance that people will change existing items in some of these vocabularies. Getting to calculate the hash for a vocabulary is unnecessary.

Kristina Yasuda: +1 ivan.

Ivan Herman: It overcomplicated our lives to do so.
… It’s different for things we control. But for schema.org, we shouldn’t do so.

Manu Sporny: +1 to ivan. I wasn’t a fan to use crypto hashes for vocab files. I wrote it because it was requested. Trying to be consistent. But where should we draw the line?

Kristina Yasuda: i am ok drawing the line whether this wg controls or not.

Manu Sporny: Definitely not for SSD, but let’s not include schema.org from there.
… I don’t think it matters (?). I don’t know if it matters that much.
… Anyone using them can always decide to ignore the guidance.
… I’m fine if we remove schema.org from the list, and only refer to vocab documents that this group is publishing.
… Just noting that we are picking an arbitrary line.

Ivan Herman: The way I would formulate it is that there are vocabs which are part of the core system/infrastructure. schema.org is one of them, along others. It’s already part of the infrastructure.

Brent Zundel: We have a path forward. Please others give feedback.

1.10. Add definition of Verifiable Credential Graph and why it exists (pr vc-data-model#1280)

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

Manu Sporny: Giving some background. Orie requested that we document what a VC graph is, and why it’s in the spec. This PR does this. The short of it is that when you have a VP, you can include multiple VC within it.
… We want to make sure the data within the VC is not merged.
… It’s important when you have multiple objects that looks the same.
… the problem is that in JSON-LD you cannot be sure that objects are talking about the same thing.
… This PR prevents that, so data isn’t merged.
… If you aren’t doing json-ld processing, you should not merge information unless you are absolutely sure.

Ivan Herman: I made some comments already.
… One is that if we take this PR, then something similar has to be done for the context integrity (which is a different repo).
… Second is that, manu, you may want to change additional vocab files.
… There is one question about being precise: a VC graph must contain a single VC. It’s a restriction about VC within a proof.

Manu Sporny: Agree on doing a parallel PR on the proof graph in the data integrity spec. Agree on making additions to the vocab file.
… Agree on the restrictions and limitations as well.

Brent Zundel: Who will raise that issue in DI?

Manu Sporny: I’ll do it.

Brent Zundel: Down to our last PR, open 13 hours ago.

1.11. Add normative requirements related to context processing (pr vc-data-model#1281)

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

Manu Sporny: Orie requested that, because context is normative, we explain what that means.
… this PR says that if you utilize the context when doing full json-ld processing, and it results in an error, then all further operations should also result in an error.
… In other words: if there is an error, you should bubble it up.
… We know exactly what the contents of the context should be, so errors should be detected and raised across the stack.

Sebastian Crane: From a security perspective you don’t want to have errors leaking through. What is the difference between the context and any other validation?

Manu Sporny: One example is the date-range validFrom and validUntil. E.g. a validFrom value that said use “validFrom tuesday”. It has nothing to do with context. It’s a non-context based error. Validation would fails.
… We do have that throughout the spec. they have nothing to do with the context.
… That’s separate from the context file. It comes into play when doing full json-ld processing. But it’s something that’s optional.
… not sure if that answers your question. Just noting that we have places in the spec where we expect errors to be raised.

Joe Andrieu: I think your question is the difference between verification vs validation. I don’t think you can verify with an invalid context.

Sebastian Crane: Why is it so specific to the context file?

Manu Sporny: I think you are correct in suggesting “any validation errors should be bubbled up”.
… Some orgs may keep processing the VC even if an error happens.
… the reason this PR doesn’t call this out is because this is only about what @context should have.
… To Joe’s point, the context comes into play when you’re verifying, but only when you’re doing full JSON-ld processing. When you’re not doing it, you assume that the context is correct.
… This means that you might miss point in time errors for a VC.
… Validation is similar in this case.

Joe Andrieu: I want to disagree when the processing you’re suggesting to do when you’re not doing json-ld processing.
… My understanding was that you should fails if the context is something you don’t expect to understand.

Manu Sporny: the full json-ld processor will utilize the full extent of the @context file.
… Without full processing, you presume that someone has done that elsewhere.

Joe Andrieu: I understand that nuance. You still need to understand that context even if you aren’t doing full processing.

Manu Sporny: that does not happen. You presume it’s valid.

Joe Andrieu: we are talking past each other.

Joe Andrieu: I’m not talking about processing in a JSON-LD manner, I’m talking about processing of the context property. If MUST be checked to confirm that you think you understand it. Not that you apply those contexts.

Manu Sporny: ah, yes ^.

Manu Sporny: It’s happening in the web right now. the same file may yield different results depending on whether full processing is doing.

Brent Zundel: the VCDM already states that context needs to have certain values.

Joe Andrieu: yep.

Manu Sporny: I think Joe, you’re saying that the @context property is always checked, even if you’re not looking as the contents of the dereferenced file (or all the values).
… What changes do you think should be made, in order to address your concern?

Joe Andrieu: Not sure yet, but I think we need to still look at the property. Will look at the PR and make suggestions.

2. VCDM before-CR Issues.

Kristina Yasuda: https://github.com/w3c/vc-data-model/issues?q=is%3Aissue+is%3Aopen+label%3Abefore-CR+-label%3A%22pr+exists%22+.

Kristina Yasuda: This link has all issues labeled before-cr, without the label pr-exists.
… We need to agree how to proceed with 9 of them.

Brent Zundel: Goal is to know who is going to raise a PR, and by when.
… We want to go into CR by the end of this month.
… That will be the primary focus. Ideally PRs within the next week, maybe 2.

David Chadwick: Will take one, doing so already.

Kristina Yasuda: this issue, DavidC? https://github.com/w3c/vc-data-model/issues/1010.

Brent Zundel: Thanks, noted.

2.1. Allow string values in JOSE properties in base JSON-LD context (issue vc-data-model#1275)

See github issue vc-data-model#1275.

Brent Zundel: manu can you comment on this issue?

Manu Sporny: This came up when we were processing fix ups to the base context. We were getting it in the proper shape to go into CR. We noticed that Orie had set some of the jwk properties to let them be URL, where the JWK doesn’t allow that.
… An example is “kid”. It’s currently defined as “it must be a URL” in the base context.
… JWK says that it’s a string.
… We shouldn’t deviate, we should align.

Michael Jones: I agree with manu that “kid” needs to be able to be any string.

Manu Sporny: I can take it. It will likely be objected, though. Can someone from the vc-jose-cose world do it?
… We should align. That’s what I’d like to see.

Michael Jones: I can review the PR.

Brent Zundel: Assigning to both manu and selfissued.

Michael Jones: manu, please ping me out of band.

Brent Zundel: Any more comments? (silence).

2.2. Add relatedResource to VerifiablePresentation (issue vc-data-model#1265)

See github issue vc-data-model#1265.

Brent Zundel: Raised by Orie, who isn’t able to attend today.
… Is it a good idea? Why?

Manu Sporny: we. have the concept of relatedResource.
… It allows us to refer to files outside a VC using a cryptographic hash.
… E.g. instead of embedding an image, you can refer to it with a cryptohash.
… We have that capability in VC, we don’t have it for VPs.
… Unclear to me what the use case is for this. But sounds like a generally useful thing to have.
… I don’t think it causes any harm having that feature. I’d be interested in hearing from the group on whether it’s useful to have.

Joe Andrieu: Sounds like a new feature after the feature freeze. There are other ways of doing this by adding it to a presented VC.

Sebastian Crane: I would like to raise a potential issue that this means that a VP cannot be understood fully offline.

Joe Andrieu: just make a VC that says here’s a related resource.

Manu Sporny: that’s correct. This also happens if you haven’t cached the context.

Joe Andrieu: holders can issue VCw.

Joe Andrieu: VCs.

Brent Zundel: +1 that handling this differently than the way additional data about the VP is handled would be inconsistent.

Manu Sporny: related to what JoeAndrieu said, we don’t have a way for the holder to do that.

Brent Zundel: we agreed on the mechanism in which the holder can make statements about the presentations.

Manu Sporny: yes, that’s a good point. Had forgotten about that.
… that’s a mark against this feature.

Ivan Herman: We have an open issue to look at all the properties that we have in the VC, to see which ones can be applied to VPs as well. This is related.
… I just translated what is in the spec to the vocab.

Brent Zundel: We’ll get to it as some point today.

Joe Andrieu: If we had a good use case, it would be a different convo. Agree with Sebastian that we need a way to comm images. Will be tough with feature freeze.

Brent Zundel: Wrap up, thanks all. Back in 30 min.

Eric Siow: Thanks. I was about to ask.

Kristina Yasuda: I looked at the issue. Its a bit different than what we talked about before break.
… there’s a broader application of a common feature, then that’s viable.

Manu Sporny: looking at it again, I think Kristina is right. The intention is to do something different from what linkedResource does in DIDs.
… this is badly titled.
… This points to graphs by id. So that’s problematic.
… still struggling to understand the use case.

Kristina Yasuda: +1 to ask Orie for clarification.

Dmitri Zagidulin: use case-wise I think I understand.
… not sure about the graph node. its the ability to include non VC resources in a VP.
… like here is PDF that is a part of something.
… and bind that to the same authentication.
… the same thing that linkedResources does.

Manu Sporny: each time I re-read the issue, my understanding changes.
… What you said Dimitri suggests it is related to relatedResources.

Dmitri Zagidulin: yes! attachments!

Brent Zundel: another interpretation? Gen has been discussing how to add attachments to credentials and presentations.
… the primary response is that we need more clarity from Orie.

Manu Sporny: plus one for the attachment use case.
… we can do that with the VC.

Dmitri Zagidulin: the binding time is different, for a VC vs VP.

Joe Andrieu: I think the attachment use case is more problematic w/ feature freeze, we should table this for the next version.

Brent Zundel: any objection to adding this as future.

jose-gataca: jose-gataca has joined #vcwg.

Brent Zundel: chairs will have a conversation about feature freeze.

2.3. are domain and range correct for all properties in data model? (issue vc-data-model#1263)

See github issue vc-data-model#1263.

Brent Zundel: domain & range question.
… In addition to the JWk properties and the context, there are a lot of properties that have a domain and range expressed. some might not be correct.

Ivan Herman: let’s put the RDF issues aside.
… just looking at the current document, there are a number of properties, such as issuer, that are described in the spec only in VCs.
… There is no line between what is only in VCs or VPs and what are usable in both.
… This manifested when I translated the spec into the vocab and created a diagram. it became very visible.
… What I need as a vocab expert is for each of them a clear statement in the specification, somewhere, that says it is usable in a VP as well as VC or not.
… The rest would be me doing editorial work.

Dmitri Zagidulin: it would be incredibly useful to also allow termsOfUse in a VP, in addition to VC.

Ivan Herman: The range is similar, but there aren’t many specified in the spec.
… I’d propose that someone looks at all the properties defined and does a triage to identify what needs more work.

Brent Zundel: would folks be opposed to, in general, saying any property in the data model could be used in either VCs or VPs.

Dmitri Zagidulin: +1 to that :).

Ivan Herman: I would. we have some like credentialSubject should not be in the presentation.

Manu Sporny: Correct, we definitely don’t want to do that.

Ted Thibodeau Jr.: for those, it seems we need parallel presentationSubject, etc.

Brent Zundel: so the answer is no. ;).
… so we need a volunteer to do the triage, AND we’ll need it added to the spec.

Ted Thibodeau Jr.: concern: credentialSubject suggests maybe there’s a parallel for PresentationSubject.

Manu Sporny: this sounds like… the scope of this is rapidly expanding and we’re going into CR. so big -1.
… too hard to consider this late in the game.
… for example, presentationStatus wouldn’t make same. Issuer for VPs, etc.
… the idea that VCs and VPs are the same thing is a bad path to go down.
… Yes, we need to look at the domain range.

Brent Zundel: then lets limit this to makes sure the … this issue is seeking reconciliation between the vocabulary and the specification.

Ivan Herman: at the moment, there is no reconciliation needed. They are in sync. TODAY.
… the question is whether or not thats ok.

Ted Thibodeau Jr.: my concern is that what’s in the spec may not be correct/as intended. I trust that Ivan has accurately reflected in the spec, in the vocab and diagram.
… that revealed my concerns. With sympathy for the can of worms, that’s when things come up.
… some properties make sense on both VCs and VPs.
… Some don’t. We should state that clearly.
… just because their named in a particular way isn’t enough.

Brent Zundel: so the scope of this issue is, this is what the scope says looking at the vocab. we need to make sure it is what we meant. Not an increase in scope.

Ted Thibodeau Jr.: +1 to brentz’s understanding and restatement.

Ivan Herman: +1 to what Brent said.

Joe Andrieu: The can of worms to avoid is not what we just talked about, we have to do the work that you clarified Brent… trying to harmonize VCs and VPs is problematic, they are different things… we shouldn’t even assume that any properties are common.

Manu Sporny: that sounds right. +1 that we need to make sure the vocabulary expresses what we meant to express.
… if implementers are telling us we need property x or y, that’s one thing. but if we start doing that to add new properties to one or the other.

Brent Zundel: the action now: we need a number of volunteers to go through the spec and compare it to the diagram and see if it says what we meant it to say.
… I’m willing to assign myself and work on it on Saturday.

Juan Caballero: i can do it with you this weekend, brent.

Manu Sporny: I’m happy to be added to that list. I’ve gone through, I do think it says what the spec meant.

Brent Zundel: for those who have signed up to review. let’s get those in no less than a week from today so Ivan can act on that feedback.

Ivan Herman: I will be out from next Sunday.

Brent Zundel: so less than a week, so Ivan has a chance to review before next week.

2.4. Add revoked and expired to verification method classes (issue vc-data-model#1262)

See github issue vc-data-model#1262.

Brent Zundel: next issue: 1262. add revoked and expired to verificationMethod classes.
… been conversation, but no one assigned. can anyone give a summary.

Manu Sporny: there was a misalignment in the data integrity between multikey and jsonwebkey.
… we’ve added those properties to json web key. now the same properties.
… so that’s fixed in DI, but we think Orie wanted that change reflected into the base context.
… it is unlikely that that PR is going to be merged. The one that defines those keys.
… as a result, this issue is a bit moot.
… If we don’t define the RDF classes for JWK and multikey in the base context (and we aren’t), then we don’t need to do anything with this issue.
… and the misalignment has been fixed in data integrity.

Brent Zundel: sounds like once that PR is closed, this issue should be closed.

Manu Sporny: i believe so, but we need to check if Orie agrees.

Brent Zundel: having closed that PR. we should close this one. (after checking that we did in fact do that).
… any opposition to adding Pending-Close on this issue?
… hearing none. I’m going to add the tag.

2.5. Addressing Verifier Stored Data Vulnerabilities and Legal Compliance (issue vc-data-model#1247)

See github issue vc-data-model#1247.

Brent Zundel: next up 1247. Verifier stored data vulnerabilities.

Sebastian Crane: there’s a lot here.
… we wanted to discuss the needed storing of PII.
… one of the requirements for that… the W3C has … something about age verification and we have Zero Knowledge Proofs that can do verification without exposing the PII.
… so this is not a technical issue, but a political one.
… Not all of the VC users want to minimally implement this. They will take this as an opportunity to exploit this.
… not necessary to correlate the age verification with the identity. all they need to know if their users are old enough, as required by law.
… to accomodate that with the identity of the user is very invasive of privacy.
… services that want to harvest data are going to use this as a justification for correlating individuals.
… the issue here is that the normative requirements for data processing are currently limited in our spec.
… Governance can… guarantee that verifiers maintain a record of age verification. we, as W3C, have to decide what we want to say about data processing.
… we have to communicate to regulators the state of the latest technology.
… There hasn’t been enough communications with governments around the world.

Kristina Yasuda: i don’t think we should overcomplicate this. a privacy consideration to say verifier must be very careful when storing PII is pretty standard and not too political.

Kristina Yasuda: something like this: https://datatracker.ietf.org/doc/html/draft-ietf-oauth-selective-disclosure-jwt-05#name-storage-of-signed-user-data.

Manu Sporny: yes ^.

Brent Zundel: as far as the scope about what we can make recommendations for, we can make recommendations for those who are users of our data model.
… we do not define processes (and cannot by our charter).

Brent Zundel: we can add something in the privacy considerations sections, but its not in our scope to normatively address processing concerns.
… the data model is our cutoff.

Manu Sporny: +1 to Kristina put into chat.
… we shouldn’t overcomplicate this.

Kristina Yasuda: i am ok being assigned to this.

Manu Sporny: What PING did in the review is that we say something about it. Not that we need to fix it, but add something to the privacy considerations.
… We already talked about data minimization, selective disclosure, and other mechanism to reduce data collection.
… This new sections should just speak to that.
… and it should say verifiers shouldn’t ask for anything more than you need.
… only collect the minimal.
… PING just wanted us to cover that situation when VC data stores are compromised.

Sebastian Crane: I agree with you. This is something the PING group is not asking us to address. So tentatively, we could mark this as Ready for PR.
… however, I’m concerned the privacy guarantees of VCs are going to be compromised by how we share this data.
… most web users understand the privacy risks of uploading a DL or passport.
… VCs are less visible than that, and we need to make sure we can communicate to end users the risks of what is happening.

Brent Zundel: it sounds like you could introduce a PR that would address this issue. So, if that’s right, let’s label it ready for PR.

Sebastian Crane: that’s ok. but to take advantage of this meeting, we need to do as much as possible within this charter to help privacy.
… we aren’t allowed to create normative statements about what processing happens, but look at cookies.
… Outside this group, we need a venue to address this.

Brent Zundel: what’s the timeline for a PR.

Sebastian Crane: I can make it a priority to get it by the end of next week.
… The sooner we can have that text, the sooner we can realize if there might be objections later in the Process.

Kristina Yasuda: Are you going to object?

Sebastian Crane: no. but I’m concerned there may be.

Brent Zundel: next step: PR. Sooner is better.
… next issue is 1232. Revisit validations versus verification.

2.6. Revisit validation vs verification (issue vc-data-model#1232)

See github issue vc-data-model#1232.

Brent Zundel: Raised by Orie on behalf of Joe… what do you need to write a PR here?

Joe Andrieu: We have text in use cases document now, if people can look at the use case document, that would be helpful.
… PR 149 use cases has that document.

See github pull request vc-use-cases#149.

osamu-n: osamu-n has joined #VCWG.

Manu Sporny: (The group reads through PR 149…).

Joe Andrieu: +1 to Phila and DMV. Please comment and I’ll work on it.

Brent Zundel: To summarize – verification checks syntax and cryptography checks out, validation has to do with business logic, and that’s how verification and validation are different from one another.
… If there was a PR in the core data model, that aligned with the use cases text, would that be appropriate to those in the WG?

Manu Sporny: The only thing that jumps out is the use of normative language in the use cases document.
… it’s a bit confusing.

Joe Andrieu: is it normative language or not?

Manu Sporny: The core seems correct and is a clarification the VCDM would benefit from.

Brent Zundel: any other comments from folks?

Shigeya Suzuki: +1 on reference to DMV.

Brent Zundel: I hear concern about normative language, much broader concern about use cases document – issue on use cases document would be a good way to track that.

Manu Sporny: I’d be fine w/ an issue to track that ^.

Brent Zundel: the normative language is bigger than just this PR. so a separate issue on the use cases document is probably the right place to go.
… With that, Joe, do you feel like issue 1232 – do you feel confident moving forward with a PR at this point?

Joe Andrieu: Yes, sentiment feels like this is the right direction. Would like to hear from others on the queue. Challenge with normative language is that this is requirements for the spec, that’s why we use normative language.

Ted Thibodeau Jr.: We might want to use requirements language instead of normative statements.

Brent Zundel: PR within the next week?

Joe Andrieu: +1 manu I agree we should add that. A note on this PR or in a new issue would tag it for me to follow up on.

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

See github issue vc-data-model#1155.

Manu Sporny: Let’s clarify that normative statements for use cases document is requirements on VC Data Model.
… there was a conversation about this issue because other issues track those concerns more directly, then more conversation happened here.
… so what needs to happen to say that we have addressed this issue.

Sebastian Crane: this is a traffic issue so its convenient to keep it open.

See github issue vc-data-model#1264.

Manu Sporny: i agree with Sebastian. The other data point is that conversation started here, but moved to 1264.
… specifically that issue. We do have an outstanding concern.
… Namely what are we telling people to do about language strings.
… I’ll put a link to the options.
… we can close or open. This issue: just one more item we need to resolve before CR.

Shigeya Suzuki: +1 on keeping this issue open.

Manu Sporny: the way we sorted the issues we have a PR, but it doesn’t address all the language options.
… so we need to talk about this still.

Brent Zundel: if we need to talk about this in this phase, we should have it now.

Manu Sporny: thanks. The internationalization group asked us to specify how a default language for a document is specified.
… we responded by saying we have name & description in the base context, so we can use that as an example.
… we explain that in the spec today.

Manu Sporny: https://github.com/w3c/vc-data-model/issues/1264#issuecomment-1712807665.

Manu Sporny: They came back and said that he felt uncomfortable because we were not specifying a default language for the VC.
… That led to different proposal, each with different tradeoffs.
… options A, B, C, D, and E.
… I don’t think we have time to go over all of these today.
… I think what we are doing in the spec is the best that we can do.
… but that depends on what the i18n group feels.

Dmitri Zagidulin: what is the difference between options A and C?

Brent Zundel: I don’t know that we can avoid talking about the options.

Sebastian Crane: thank you manu for creating the issue with the clear options.
… option C is what I proposed a resolution for.
… I think we are close to consensus on this issue.

Manu Sporny: I can go through the options …

Brent Zundel: since Sebastian thinks C might be a winner, let’s start there.

Manu Sporny: Option C uses JSON-LD language features.
… @value for value of a string.
… @language and @direction.
… benefit is already in JSON-LD.
… drawback is that people who don’t like JSON-LD might not like this option.
… So we need to hear back from people who want to use something else.
… also Option C doesn’t set a base language for the document. That’s not clear if the international WG will go for that.

Ivan Herman: I have a comment on the tech. but a practical comment first: Addison is around, so let’s try to talk to him.

Brent Zundel: That’s right. We can take advantage of TPAC.

Ivan Herman: on the technical side, the title is misleading because the JSON-LD language features are more than what is in option C.
… we can use JSON-LD features the way its used in 1.0 and we can set the direction for the whole file if we want (using JSON-LD).
… But I think we should not spend to much on this. JSON-LD has gone to great efforts to work out language with the i18n group.

Pierre-Antoine Champin: https://www.w3.org/TR/string-meta/.

Ivan Herman: So we should not cherry pick.
… There are not thousands of ways to do that in JSON either. We may have a long conversation (with some beer) wether to include an @ sign or alias that out.
… That’s the only question for me that’s really relevant (the aliasing).
… We know (from HTML) in many actors in countries where people will ignore these language features.
… That’s life.

Sebastian Crane: I’d like to agree. Two things: we are providing the option to do language support correctly. We can’t force it, but we can enable it.
… second, the idea of a JSON-LD only idea. There’s nothing in JSON-LD that requires “full JSON processing” for these language features.
… So for those here with no interest in RDF, this shouldn’t add any complexity.

Manu Sporny: this comes about because some implementers look at the @sign and freak out.

Dmitri Zagidulin: well so wait, why dont we alias out the @ sign?

Manu Sporny: so if no one is complaining about that, we can just adopt it.
… If we alias out the @ sign and we apply that against all VCs everywhere, then nobody can have a property named “language”, which is prolematic.
… The other thing.. Ivan said we could just depend on the JSON-LD properties.
… there are examples where that would clearly be wrong.
… if we allow @language in the context, e.g., @langauge="es" at the top. That would apply that language to every text string in the document, including base64 encoded values, etc.
… so we need to provide guidance that doesn’t lead to meaningless decoration.
… If people are good with @value, @language, and @direction we’re good. Aliasing is ok, but not great.

Brent Zundel: If we were to proceed as mentioned, if we go with those @values, is there anyone who would be opposed to that?
… I’m not seeing any opposition, so I think this is read for PR.

Ivan Herman: JSON-LD scares the hell out of people sometimes because they are nervous about RDF. I have to emphasize what is in JSON-LD for the language has nothing to do with RDF.
… The features themselves, these are generic features that can be used for ANY JSON vocabulary.
… No magic or hidden RDF.
… We can haggle around the @ sign.
… Personally I prefer keeping it, but that’s me.
… we have done that for id & type.

Dmitri Zagidulin: re: alias. I’d argue we have a better way than flipping a coin. We know there is significant pushback on @s.
… can we have a poll.

Manu Sporny: two things. If we decide to use JSON-LD keywords, we’ll have to change the way name & description work.
… two: I’m concerned about aliasing “value”. I’d feel better if we had that for a while, I’d feel better.

Andres Uribe: Is it possible to alias "lang_value" to "@value" ?

Manu Sporny: I do agree with dmitriz that there is an allergic reaction to seeing @ signs in JSON.
… Don’t think its an easy answer. We should be ready to trigger another CR later.

Ivan Herman: I forgot to react to Manu about setting global language. From the JSON-LD point of view, that’s not really a problem. Because we can specific that language doesn’t apply for the datatype in the range of that specific property.
… for JSON only users they would ignore it.

Brent Zundel: POLL: we will use keywords @language, @direction, and @value for language and alias them to ‘language’, ‘lang_direction’ and ‘lang_value’.

Andres Uribe: +1.

Gabe Cohen: +1.

Dmitri Zagidulin: +1 (though would much prefer ‘direction’ and ‘value’).

Sebastian Crane: +1 for one option, +1 for the other. I think that counts as abstaining, but I will definitely not oppose either option :).

Ted Thibodeau Jr.: +0.5.

David Chadwick: +1.

Ivan Herman: +1 (like dmitriz).

Joe Andrieu: 0.

NickLansleyGS1: +1.

Manu Sporny: +0.5 (with severe trepidation wrt. stomping on existing data models out there) – also, language/direction/value (not what was mentioned).

Shigeya Suzuki: +1.

Phil Archer: -1.

Paul Dietrich: +1.

Juan Caballero: +1.

Jay Kishigami: +1.

osamu-n: osamu-n has joined #vcwg.

Dmitri Zagidulin: can Phil and Manu explain why dangerous? and what holes?

Phil Archer: I agree with Manu’s comments, it’s dangerous. but my participation here is minimal, so I understand.
… this could impact things in unintended ways.

Dmitri Zagidulin: ‘id’ and ‘type’ are also very common words.

Phil Archer: using a common word like value to mean something that other people don’t use it for.

David Chadwick: I would be -1 if the alias was ‘value’ and not ‘lang_value’.

Brent Zundel: clarification the proposal is for lang_value and lang_direction, not “value”.

Andres Uribe: ditto to what DavidC said above.

Phil Archer: Ah… that’s much better.

Paul Dietrich: agree DavidC.

Manu Sporny: also, let’s not use underscores since none of our other properties have underscores :).

Manu Sporny: langString <– would be better.

Sebastian Crane: The aliasing of @ to something else simply makes the @sign is implicit.

Manu Sporny: ivan said some stuff I didn’t understand. I’d like to.

Dmitri Zagidulin: +1 camel case vs snake case.

Manu Sporny: If we alias to lang_string, lang_direction, then that’s probably fine.
… it would be nicer if people didn’t get all bent out of shape about @ signs.

Ivan Herman: +1 to camel, to be aligns with the style used for other properties in VCDM.

Manu Sporny: Also, what Phil said: there’s a lot of data out there that already uses value and it would trigger a lot of confusion.
… The problem is @value means something more than just language.
… That means … it’s not a straightforward decisions.

Brent Zundel: we can keep going it.

Sebastian Crane: I’m happy to help with PR.

Pierre-Antoine Champin: manu, people can still use @value when lang_value does not make sense. But you can’t always prevent them to shoot themselves in the foot if they want to.

Dmitri Zagidulin: to clarify, if we alias value to something else. It’s the other direction. Aliasing from lang_value to @language, but you can still use @language elsewhere.

Manu Sporny: if you compact using the VC context and you have @value throughout your JSON-LD, all those @value will be changed.

Ivan Herman: if you make the alias an embedded context for a property.
… for every property that is potential language and you scope the context.
… That’s what we suggesting is to not make it scoped.
… Option C is global, unscoped.

Pierre-Antoine Champin: oh, yes, compaction will mess it up :-(.

Dmitri Zagidulin: so why not use option A?

Ivan Herman: so for the other properties, you can make it null.

Manu Sporny: we need a deeper conversation and I don’t know if we can get through this in 20 minutes.

Manu Sporny: option A /is/ what we’re doing in the spec today :).

Brent Zundel: this is a before CR issue. Is that because there will be normative changes to the spec?

Dmitri Zagidulin: ok. and what is the problem with it today? just the @ signs?

Manu Sporny: yes. this has normative impact.

Brent Zundel: so we will add time for this during TPAC.
… Break for lunch! Back in 80 minutes with or without Brent.

Manu Sporny: no, it doesn’t provide a language for the entire VC and it requires context authors to do scoped language stuff.

Dmitri Zagidulin: @manu - what do you mean by scoped language stuff? what will it require them to do?

this: https://github.com/w3c/vc-data-model/blob/main/contexts/credentials/v2#L122-L127.

Manu Sporny: (which, btw, I think is fine ^).

Dmitri Zagidulin: interesting.

3. Data Integrity - Core Spec.

Manu Sporny: Slides here: https://docs.google.com/presentation/d/1a2T1gEuJvgPXsuWaniM8k4jJtu0nbsqsxRGpYrjKzJs/edit#slide=id.p.

jose-gataca: jose-gataca has joined #vcwg.

this: data integrity is close to CR. manu will walk through the status & scope of remaining work for CR & beyond.

Manu Sporny: slides in chat. VC Data Integrity - 3 passes: 1 - base spec, 2 - ecdsa suites, 3 - eddsa suites.
… proposals for each to transition to CR. first some background to catch everyone up. what does the spec do? ensure authenticity and integrity of a VC.
… secures a VC using a digital signature and related proofs. 3 usages today. 1 truage in the US, 150k retail stores, 50M age checks per day. using W3C VCs.
… sharing to establish this is used in the real world today, will get to open issues shortly.
… CR is ready for the base spec, no pre-CR issues left.
… any questions on status/state? want to request publication to go to CR.

Jay Kishigami: re 2nd slide, result can be valid/invalid … from verify -> valid/invalid, how do you understand the result?

Manu Sporny: meant to speak directly to the verification process. should change to say verified/failed verification. validation is something different that happens in the VC process after verifying the digital signature.

Dave Longley: language should say “verified” / “not verified” or “success” / “failure”, not bring in “valid/invalid” language.

Manu Sporny: should change the diagram so it says verified / not verified.

Michael Jones: https://github.com/w3c/vc-data-integrity/issues/191 should be tagged pre-CR but I don’t have the rights to do it.

Phil Archer: from canonicalization/hash wg, we resolved monday to take it to CR. Sebastian pointed out something not so great. Should be able to go to CR in 2 weeks time, so we are aligned.

Michael Jones: filed issue 191 and 192 which should be considered pre-CR, don’t have the rights to tag since not an editor.

Manu Sporny: they were just filed, can you elaborate?

Brent Zundel: will take an opportunity to look at issues on data integrity, then go into the sub specs.

3.1. Remove normative dependencies on multibase (issue vc-data-integrity#191)

See github issue vc-data-integrity#191.

Michael Jones: in doing due diligence on IETF standardization on mutlibase I discovered a normative dependence on multibase in DI, even though it’s not a standard. we shouldn’t be doing that. we shouldn’t take normative deps on non-standards. requesting in #191 the definition of proof be changed to not use multibase.

Dave Longley: https://w3c.github.io/vc-data-integrity/#resource-integrity <– see “At risk” on what selfissued just said.

Sebastian Crane: been discussing a lot on how to proceed. one option is to include the definitions inside the specification, since multibase is not a complex format and it is stable. can be in DI itself.
… in the future can add an IETF normative dependency.

Dave Longley: as seabass said, we have a feature at risk in the spec for exactly this reason. don’t think it’s a pre-CR issue. we can change the current CR to fix this language as necessary.

Manu Sporny: to Mike - was your objection to the normative reference or the use of multibase at all? it is marked at risk. currently all implementers we have are using multibase. asking them to change their implementations would be problematic. would like to understand your concerns more.

Michael Jones: I have objections to both. procedurally, normative reference is a stronger argument for the working group since we agreed to not normatively use non standard features - so it has to go. many of you are aware, I wrote a piece ‘multiformats are considered harmful’ and asked it not be a candidate for IETF standardization. currently being discussed on the mailing list.

Andres Uribe: Details in https://self-issued.info/?p=2408.

Michael Jones: philosophically against multiformats since it does not make a choice. different impls may make different choices - base10, 32, 58, 64… they won’t interoperate. interoperation is facilitated by making a choice, multibase is a failure to make a choice. make a choice!

Brent Zundel: appreciate that there’s a feature at risk tag. is the intention, should multibase not be standardized by the time this moves from CR to REC, would the current link be moved to a non normative reference?

Sebastian Crane: (responding to Mike) the more choices the more interop you get … need to facilitate ease of interop. having metadata is useful. would it be acceptable, if in data integrity, we limited which encodings would be used? e.g. saying you must use base64, but encode with the right multibase header.

Manu Sporny: 3 things. Mike said that WGs can’t cite things that are not at the same level of maturity from a standards perspective - not correct. if a WG can demonstrate that a normative dep wont change, then it’s fine to cite it. we’re doing that with JSON Schema - not an IETF RFC, but we have a specification, went through a lot of discussion at the W3C, has way more dependencies which could be changed.
… don’t think this is a reason to not have normative dependencies. we use 2 multibase values: z and u, that’s it. we could get rid of the normative link, define the headers in our spec to address it, but the normative dep is defensible since those values haven’t changed in years and wont change since they’re used in other production systems.
… as Ivan notes, schema.org is used. allowed to normatively reference it if its not expected to change and this isn’t.
… you asked for a single base encoding on what we’re using, not allow any random base encoding…this is what we do in our suites. a different crypto suite may choose a different encoding. limiting what every cryptosuite can do seems problematic. in this WG we have picked one base encoding format. the basis for your objection is unfounded.
… (to Brent) … can we remove the ref at a later date if it doesn’t surface at IETF? yes we can do that, and we can specify the ‘z’ and ‘u’ values in our specification.

Michael Jones: you could remove the reference now and not break uses of b64 encoding if you said the value is the character ‘u’ + b64 proof value. I could live with that, but think its unnecessary. choosing one is making a choice, then won’t need the ref at all.

Manu Sporny: I am hearing you would not object to us using a header, and pick b64 for everything. the reality for the implementations is not that. implementers have gone another way. we provide a header so people know what the base encoding format is. we could remove the normative ref to multibase and then have a header as a compromise.

Sebastian Crane: if that satisfies Mike I am happy to make that compromise myself and make it an informative reference. we are waiting for the spec to catch up.

Dmitri Zagidulin: Is b64url itself an RFC?

Brent Zundel: answer is yes.
… are you and Sebastian as editors ok with addressing this issue?

Gabe Cohen: manu/seabass: yes.

Sebastian Crane: not sure the comparison to b64url …

Michael Jones: you can read about it in RFC 7515.

Ivan Herman: vocab has to change as well, since multibase is in the vocab now.
… you don’t have to answer now, tell me when you go to change the PR.

Sebastian Crane: +1 then.

Manu Sporny: I will think about you Ivan.

Ivan Herman: :-).

Dave Longley: +1 to run proposal inclusive of the changes being discussed.

Manu Sporny: let’s run a proposal and then given that…advance to CR.

Sebastian Crane: (to summarize) - we are going to, in the cryptosuites, to have a specific encoding, for the spec text we are using a format compatible with multibase, so that if it becomes a standard we will use it normatively. we won’t publish a normative ref if it’s not ready by REC.

Manu Sporny: yes matches my understanding.

Benjamin Young: +1 to seabass’s summary.

3.2. Correct statements about standardization of multibase and multihash (issue vc-data-integrity#192)

See github issue vc-data-integrity#192.

Michael Jones: the spec includes a note saying multibase/hash are being standardized at the IETF in a multiformats WG. for the record, there is no multiformats WG, there is a mailing list. it is up to the IESG to create a group. we should be accurate in what we’re saying.

Sebastian Crane: +1 to these changes for clarity. Happy to be assigned.

Michael Jones: change to say ‘it may be standardized’ and another to correctly cite its a mailing list not a wg.

Manu Sporny: +1 to those changes.

Brent Zundel: can continue on with manu’s presentation and move towards proposals.

3.3. CR proposals.

Manu Sporny: (resuming @ slide 13).

Antony Nadalin: what about test suite?

Ivan Herman: I would propose to not write the final URL, do not commit ourselves in the proposal to a specific date. it will depend on changes that were just mentioned, and myself - has to go through me. and I have some time off in 10 days. editors and I can agree on a final date.

Sebastian Crane: nadalin_: we have a test suite ready for all the mandatory features.

Andres Uribe: this proposal references that the implementations must each implement each mandatory MUST feature, can you comment on the state of the test suite which will be used?

Manu Sporny: this is standard language at the w3c, for the test suites we have … for each crypto suite we are already testing each normative statement. have a bit of work to do, and need to find out things through implementations that we need to fix.
… to be clear we have many implementations at this point. need to make sure each one is accurate. did that answer your question?

Andres Uribe: yes…will the test suite change during the process?

Manu Sporny: yes, it’s expected to change based on implementer feedback.

Ivan Herman: process wise, we can go into CR without the tests themselves, if we know how we want to test. tests can change up to CR.
… when we submit the CR request, and put a minimum time for outside review, within which we’re not allowed to go to PR.

Manu Sporny: believe text reflects what Ivan wants (text updated).

Proposed resolution: Request the publication of the Verifiable Credential Data Integrity 1.0 specification, with resolutions to issues 191 and 192 integrated, as a Candidate Recommendation with a CR period ending two months after publication and with exit criteria requiring two independent implementations of each mandatory (MUST) feature in the specification. (Brent Zundel)

Manu Sporny: +1.

Sebastian Crane: +1.

Dave Longley: +1.

Phil Archer: +1.

Paul Dietrich: +1.

Ivan Herman: +1.

Gabe Cohen: +1.

Dmitri Zagidulin: +1.

Andres Uribe: +1.

Benjamin Young: +1.

Brent Zundel: 0.

Joe Andrieu: +1.

Greg Bernstein: +1.

Ted Thibodeau Jr.: +1.

Shigeya Suzuki: +1.

Michael Jones: 0.

Jay Kishigami: +1.

David Chadwick: +1.

Hiroyuki Sano: +1.

Antony Nadalin: 0.

Resolution #1: Request the publication of the Verifiable Credential Data Integrity 1.0 specification, with resolutions to issues 191 and 192 integrated, as a Candidate Recommendation with a CR period ending two months after publication and with exit criteria requiring two independent implementations of each mandatory (MUST) feature in the specification.

Manu Sporny: moving onto the crypto suites.
… (back to presentation).

osamu-n: osamu-n has joined #vcwg.

Proposed resolution: Request publication of the Data Integrity EdDSA Cryptosuites v1.0 specification as a Candidate Recommendation with a CR period ending two months after the publication date and with exit criteria requiring two independent implementations of each mandatory (MUST) feature in the specification. (Kristina Yasuda)

Antony Nadalin: is there a wide review before a CR?

Kristina Yasuda: horizontal review was done.

Antony Nadalin: for what manu is suggesting?

Manu Sporny: all horizontal reviews have been completed. i18n, a11y, privacy, security, TAG, believe that’s all.
… going to CR is a way to get further review, implementer feedback, and more review.

Proposed resolution: Request publication of the Data Integrity EdDSA Cryptosuites v1.0 specification as a Candidate Recommendation with a CR period ending two months after the publication date and with exit criteria requiring two independent implementations of each mandatory (MUST) feature in the specification. (Kristina Yasuda)

Manu Sporny: +1.

Dave Longley: +1.

Gabe Cohen: +1.

Paul Dietrich: +1.

Greg Bernstein: +1.

Ivan Herman: +1.

Dmitri Zagidulin: +1.

Ted Thibodeau Jr.: +1.

Phil Archer: +1.

Benjamin Young: +1.

Andres Uribe: +1.

Sebastian Crane: +1.

Michael Jones: 0.

Antony Nadalin: 0.

Hiroyuki Sano: +1.

Joe Andrieu: +1.

Jay Kishigami: +1.

Kristina Yasuda: resolved!

Resolution #2: Request publication of the Data Integrity EdDSA Cryptosuites v1.0 specification as a Candidate Recommendation with a CR period ending two months after the publication date and with exit criteria requiring two independent implementations of each mandatory (MUST) feature in the specification.

Manu Sporny: moving on to the last cryptosuite, ECDSA.

Paul Dietrich: title on this slide is also incorrect.

Proposed resolution: Request the publication of the Data Integrity ECDSA Cryptosuites v1.0 specification as a Candidate Recommendation with a CR period ending two months after publication and with exit criteria requiring two independent implementations of each mandatory (MUST) feature in the specification. (Brent Zundel)

Andres Uribe: +1.

Manu Sporny: +1.

Sebastian Crane: +1.

Ivan Herman: +1.

Dave Longley: +1.

Ted Thibodeau Jr.: +1.

Phil Archer: +1.

Greg Bernstein: +1.

Gabe Cohen: +1.

Jay Kishigami: +1.

Paul Dietrich: +1.

Brent Zundel: 0.

Benjamin Young: +1.

Hiroyuki Sano: +1.

Joe Andrieu: +1.

Dmitri Zagidulin: +1.

Michael Jones: 0.

Resolution #3: Request the publication of the Data Integrity ECDSA Cryptosuites v1.0 specification as a Candidate Recommendation with a CR period ending two months after publication and with exit criteria requiring two independent implementations of each mandatory (MUST) feature in the specification.

3.4. BBS+ Cryptosuite.

Kristina Yasuda: have not talked about the BBS+ cryptosuite for data integrity. it is unlikely it will make CR.

Brent Zundel: we have 10m left in your allotted time, we can put forward a conversation about BBS, and whether we, as a group, have interest to see it through to CR and whether it is a practical effort.

Manu Sporny: we have a little less than a year left in the group. the primitives we’ve created are applicable to BBS. people are working on it. I know the current editors haven’t made much progress. achieving BBS still feels doable, since we were able to take DI specs to CR. those editors can now work on BBS.
… still think its very doable, but cutting it close. depends on IETF progress. feels like a missed opportunity to give up on the work item given the progress we’ve seen today. I suggest we keep it open and see if there are implementations before the EOY.
… then we could pick it up. [Digital Bazaar] is interested as long as the IETF work continues to progress and review happens. the GSMA request asked what we intended to do, having some BBS+ mechanism is desirable given the primitives for ecdsa, we should not close the work item off.

Greg Bernstein: going to re-iterate what Manu says. I have been working on impls for BBS+ with DIF and IETF. know it is making very good progress, and going to last call soon. new set of SD primitives helped a ton. not an LD person, and I used them with BBS. very helpful. the folks working on BBS know you have to keep things unlinkable, even within BBS…many other things which can make things linkable on top of base signatures.
… will add more guidance with the IETF spec, which we’ll add to the W3C spec. depending on the structure of the cred, what’s in it, you’ll be able to get unlinkability or not. the new primitives that came out make life easy for us doing the crypto, so I think it’s doable.

Brent Zundel: want more clarity on what the plan will be. which interpretation - (1) wait and see if anything happens, if nothing by december we’ll stop (2) editors focusing on prior specs will now focus on BBS and get it into shape by December. which is more correct?

Kristina Yasuda: have been saying BBS+ is still a draft in CFRG - highly doubt that a new cryptographic scheme will go to last call after only 3 iterations in CFRG. even if it goes to last call now it will take more than 6mo with review and publishing.
… when the fundamental piece the draft depends on is still in review, I have concerns. I know it’s a work item. not sure it’s a question of editors on other work items switching. the problem is not only # of people, but the underlying scheme not being final in IETF.
… when we adopted we agreed we wouldn’t take it to final unless it progressed through CFRG.

Greg Bernstein: how quickly it gets through the IETF I can’t say. the cryptography is well establish, goes back many years, most recent was from 2016 in the cryptography community. have 4 impls, full set of test vectors in the IETF, if it doesn’t make it through as a standard that’s that. nothing doubtful about the cryptography itself. well established, for many years.

Brent Zundel: no one suggesting otherwise, pointing normatively is the question.

Sebastian Crane: could still create a wrapper format. have not been directly involved with BBS in the W3C, see no reason to stop.

Brent Zundel: Is the goal to get to CR and then hold it until underlying specs are ready?

Manu Sporny: no one is saying if BBS is not an RFC we would proceed with the DI/BBS suite. if there’s no RFC we can’t use it. let’s not push it faster than IETF…it’s a fundamental thing that needs to happen. does it have value for us to front-load and make sure we’re ready?
… last I heard from Tobias the format’s pretty much done. continuing the work in this group, advancing through WDs would be a fine thing to do, even CR may be OK. but clearly not beyond that. this WG is approved to work on BBS, we said we’d do it, have been working on it.

Kristina Yasuda: when we chartered, we were very clear that being chartered to do something does not mean we have an obligation to work on it.

Manu Sporny: . if it turns out BBS will take 6-8+ months, at least we have made progress and would just be waiting on IETF approval, not starting the work in general. if IETF will take more time we could always do a charter extension…know none of us really want to do that, but it’s an option.
… killing off the work item is premature.

Michael Jones: have been following somewhat because of JWP work. Tobias tells me representations of BBS proofs have changed between CFRG drafts multiple times. not stabilized. not debating that it may be worth getting volunteers. but still in flux.

Brent Zundel: want to see that by october, a group of people willing to be assigned as editors, want to see a solid plan that covers likely eventualities. what are possibilities and plans dependent on them?
… we will move to the next topic which is json schema.

4. VC JSON Schema.

Gabe Cohen: Going to give an overview of work done and going to CR – makes use of credentialSchema in data model… two types, JsonSchema type – expresses a JSON Schema.
… second type, JsonSchemaCredential – if you care about authorship of schema, expose status, anything else credential might offer, spec is in good shape, addressed all but one pre-CR issue – Block and Transmute working on implementations.
… If there are no major blockers or concerns, we could go to CR today.

4.1. Address normative references issues (pr vc-json-schema#216)

See github pull request vc-json-schema#216.

Brent Zundel: PR 216 - can you walk us through this, Gabe?

Gabe Cohen: Manu had gone through normative references, suggest reducing some JSON Schema references… we only want to normatively refer to the most recent one. Make other refs non-normative, cleans up some other language.

Andres Uribe: manu: Went through the spec, looks good.

Andres Uribe: … as to the changes suggested in the PR.

Andres Uribe: … The goal here is to reduce the number of normative references to ease going into CR. Happy with it.

Gabe Cohen: Open to other questions on the spec, other than that, looking forward to proposal.

4.2. CR proposal.

Sebastian Crane: Wanted to clarify, will test suite be publicly available? Reproducible by an individual?

Gabe Cohen: https://github.com/w3c/vc-json-schema-test-suite.

Gabe Cohen: Yes, that’s already the case.
… There is the link to the test suite above. We have a number of test vectors for each normative statement.

Proposed resolution: Request the publication of the Verifiable Credentials JSON Schema specification, after merging PR #216, as a Candidate Recommendation with a CR period ending two months after publication and with exit criteria requiring two independent implementations of each mandatory (MUST) feature in the specification. (Brent Zundel)

Ivan Herman: +1.

Manu Sporny: +1.

Jay Kishigami: +1.

Dave Longley: +1.

Andres Uribe: +1.

Gabe Cohen: +1.

Paul Dietrich: +1.

Shigeya Suzuki: +1.

David Chadwick: +1.

Brent Zundel: +1.

Phil Archer: +1.

Ted Thibodeau Jr.: +1.

Joe Andrieu: +1.

Benjamin Young: +1.

Dmitri Zagidulin: +1.

Hiroyuki Sano: +1.

Manu Sporny: +1.

Sebastian Crane: +1.

Resolution #4: Request the publication of the Verifiable Credentials JSON Schema specification, after merging PR #216, as a Candidate Recommendation with a CR period ending two months after publication and with exit criteria requiring two independent implementations of each mandatory (MUST) feature in the specification.

Ivan Herman: practical things – can you sync w/ Manu to make sure 4 CRs are published at the same time. Manu, you prepared advanced CR submissions, but CR submission reviewers prefer to have 1 issue submitted for several documents instead of 4 separate issues submitted.
… Everything should go together.

5. more VCDM Issue triage.

Brent Zundel: we have 4 more before CR issues to process today.

Sebastian Crane: scribe_.

5.1. (issue vc-data-model#1152)

See github issue vc-data-model#1152.

Brent Zundel: Mike Prorock cannot continue, so we need another volunteer.

Ivan Herman: I believe there are multiple ongoing discussions. I cannot make a PR, because I don’t see a consensus here.

Manu Sporny: There are multiple places we could put this. I would suggest the Data Integrity vocabulary, as that can be re-used by non-VC formats.
… The first decision that we need to make, therefore, is whether this is exclusive to VCs.

Ivan Herman: The current vocabulary there is a multibase value in the document and the diagram. There was an open question as to whether to add a reserved term for SRI. The range of that digest should be a special datatype, referencing the SRI specification. I don’t know whether we want one or both.

Brent Zundel: I’m remembering opposition in discussions about whether to have this in Data Integrity or the VC data model.

Manu Sporny: There have indeed been concerns on both sides. I’m not sure whether it matters much where the vocabulary lives. I think that the least-friction way is to define this in the VC data model, and let Data Integrity redefine them.

Ivan Herman: If I get clear statements, I am happy to make the required changes. It is not my decision to make.
… The only downside to putting it into Data Integrity is that’s supposed to be going to CR. But then again, the multibase datatype is defined in the security vocabulary.

Manu Sporny: I don’t think we’re going to easily make a decision on this. Thus I don’t want to delay CR for an indeterminate amount of time.

Paul Dietrich: Can vc-json-schema use digestsRI? or would I put a signed json+schema into a relatedResource?

Manu Sporny: If we want these to be general, they should go into Data Integrity, but if we want it to be specific to VCs, they should go into the data model.

David Chadwick: both digests should be in the same place.

Manu Sporny: agree ^.

Ivan Herman: Ideally, the SRI specification should define a term. If it did, it would be much cleaner.

Benjamin Young: +1 to ivan’s framing.

Manu Sporny: agree with ivan, this is a general feature.

Paul Dietrich: I agree with ivan as well. a general feature.

Brent Zundel: In my own capacity, both are adequate.

Sebastian Crane: missed a previous comment from andres.

Andres Uribe: Important to separate conversation of related resource in VCDM… digestSRI vs digestMultibase.

Brent Zundel: Am I correct that Digest SRI is ‘looking for a home’?

Manu Sporny: +1 that it should go into Data Integrity.

Manu Sporny: +1 to note gate-keep DI on this.

Dmitri Zagidulin: +1 from me.

Dave Longley: +1 to not gate keep, but noting it seems to be the right thing to do to put it into the same vocab.

Dmitri Zagidulin: @dlongley - that’s a good point. let’s put it in both.

Brent Zundel: Let’s attempt to move the vocabulary item into Data Integrity. If it is controversial, we will not block Data Integrity’s CR.

Andres Uribe: Media type is something that isn’t part of Data Integrity, which could be a problem.

Brent Zundel: OK, let’s move it back.

5.2. NIST defines “credential” differently (issue vc-data-model#1047)

See github issue vc-data-model#1047.

Manu Sporny: seabass: What is this PR supposed to be for?

Manu Sporny: Orie suggested that we added an informative section to disambiguate the terms.

Brent Zundel: I’ll mark this as ready for PR with that.

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

See github issue vc-data-model#1010.

David Chadwick: The Terms Of Use should be automatically processable, and it should be more general. I’ve added some draft text. If there is agreement on that, I’ll create a PR.

Manu Sporny: seabass: I know I haven’t done background reading on this… would like to discuss w/ DavidC on this topic.

Manu Sporny: DavidC: Waiting on hearing more from you.

Brent Zundel: We’ll look forward to feedback, and move on now.

5.4. Evidence extension point (was: Improve tests for Evidence) (issue vc-data-model#870)

See github issue vc-data-model#870.

Brent Zundel: Everyone please read this issue.

Dmitri Zagidulin: The issue of stating domain and range for all vocabulary items is not relevant to this GitHub issue, in my opinion.

Dmitri Zagidulin: that’s my recollection as well.

Brent Zundel: I recollect that we would keep it as a reserved term even if the specification text is dropped.

Ivan Herman: I recollect us deciding that the corresponding item in the vocabulary would not have an explicit domain. It’s very easy to implement, but it is a recursing point of disagreement.

David Chadwick: I think that if there are two interoperable implementations for it, it should stay.

Manu Sporny: I think we could just close this issue, because we have a default situation: if there is no normative document, we’ll reserve the property and drop the text.

6. VC-JOSE-COSE.

Brent Zundel: https://github.com/w3c/vc-jose-cose/pulls?q=is%3Apr+is%3Aopen+sort%3Acreated-asc.

6.1. Add support for DIDs (pr vc-jose-cose#144)

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

Michael Jones: very discussed PR to-date. some requested changes - many addressed. manu is the person requesting changes now.

Joe Andrieu: could we get the github URL again?

Manu Sporny: one of the concerns are it duplicates content from DID-Core and data integrity specification and rewrites some of it. uses normative statements from did-core and puts DI content on top of it. DI spec is clear on the reason.
… since this PR is about DIDs to the specification, adding a normative dependency on DID-Core makes sense.
… request is to make clear that the content is largely copy past from other 2 documents, explain what is being changed from those text and why.
… or just copy paste.
… redefining DID-Core might be out of scope of the charter.

Michael Jones: normative change to DID-Core. subsetting normative statements in DID-Core. if you want to use controller doc with JOSE-COSE, refer to jwks and should not use multibase part, it is not a breaking change to did-core.

Brent Zundel: is it profile of DID controller section of did-core?

Michael Jones: yes.

Brent Zundel: manu, does clarifying that alleviate your concerns?

Manu Sporny: no, because the profile makes normative changes to did-core.
… if we were just to subset, putting a normative reference to did-core and clearly state what subsetting is.

Benjamin Young: +1 to normative references + subsetting.

Manu Sporny: completely disagree that the PR is ready to be merged today.
… if this is a profile with subsetting - great, but please say so.

Michael Jones: could you state that in the PR?

Manu Sporny: I think I said it in the PR comment.

Kristina Yasuda: looks like we have a way forward.

Ivan Herman: there is currently no normative reference to did-core Rec, which should be from your description.

Michael Jones: i will consult other editors.

6.2. Remove JWT references (keep SD-JWT) (pr vc-jose-cose#149)

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

Michael Jones: given that in ietf, there is work on sd-jwt that both allow an option with and without selective disclosure. editors felt that just using sd-jwt covers only jwts.

Manu Sporny: this feels like a significant change in direction.

Manu Sporny: using JWTs to secure has been a thing for a while. but now it looks like now using sd-jwts will be a must if one is trying to secure VCs using JOSE stack.
… then the whole point of a stack does not match the purpose.
… please clarify if the point is not to support regular JWTs and how using SD-JWT enables CWT or CBOR based securing mechanisms.

Brent Zundel: i had a similar thoughts. comments in this PR seemed that SD-JWT is a superset of a JWT so it is possible to have a JWT with or without SD components.

Dave Longley: +1 to hear more about the state of SD-JWT in the standards process.

Dave Longley: and where it is relative to something like where BBS is.

Brent Zundel: my concern with this concern is similar to the concerns for BBS - whether sd-jwt is in a state where we can refer to it normatively.

Michael Jones: what we a doing is changing a media type, there is no normative reference to sd-jwt ietf draft.

Manu Sporny: that does not answer the question. in order to use sd-jwt, you have to put normative changes to it.
… we need to understand where in the standardization process sd-jwt is.
… understand that editors want to move away from jwts and focus on sd-jwt.

Ted Thibodeau Jr.: There’s a whole lot more than media types changed in https://github.com/w3c/vc-jose-cose/pull/149/files.

Manu Sporny: several implementers using vc-jwt as defined in vcdm 1.1 who might be surprised with this change.

Brent Zundel: +1 with JWTs still being in scope according to my understanding.

Michael Jones: disagree with the characterization that we are taking away the option to use JWTs that is in scope - we are only removing largely duplicative option, since one is a superset - trying to reduce the number of media types.

Dave Longley: notes the PR is called “Remove JWT references (keep SD-JWT)” … it would be good to change that if that’s not what’s happening.

Ted Thibodeau Jr.: to be clear there is more text change than media types.

Oliver Terbu: agree with what was said: sd-jwt is superset of jwt. agree with using sd-jwt, the rest is redundant.

Sebastian Crane: understand that it is subset. why it is called sd-jwt?

Manu Sporny: this PR removes a media type for regular JWTs - understand that sd-jwt is a superset. it feels like we are removing support for JWTs.
… you can take a subclass of jwts and point to jwt processor, but that is not the case with sd-jwt.
… we are telling people that we are telling people to support sd-jwts.

Brent Zundel: respond to sebastian - sd-jwt is considered a jwt because it adds functionality to jwts, but does not remove.
… my understanding is that i can take a normal library, generate a JWT, append ~ and call it an sd-jwt.
… so using regular jwt libraries to do sd-jwts is possible. that was all chair hat off.

Dave Longley: regular JWT lib gets a JWT with ~ at the end … not a major problem but it does sound like we need a normative reference to SD-JWT?

Oliver Terbu: agree with brent. can use regular jwt libraries. one need to upgrade to v2.0 from v.1.1 anyway. no reason to maintain vc-jwt as in 1.1.

Sebastian Crane: question to mike. any change to cbor support?

Michael Jones: no change to cbor support.

Kristina Yasuda: I think the direction is correct. We experimented a lot with the best way to secure a payload that enables switching selective disclosure on and off.
… we first tried JWT and SD-JWT switching off. But having experimented and implemented, they are not different, it is just appending a ~ to a regular JWT. Those who are currently using JWT and want to continue and those who want to use SD with JWT both are there (chaIR HAT OFF).
… however PR could explain more, happy to help with that.

Benjamin Young: question around media type declarations. is sd-jwt a superset of json processing?
… and that is expressed in this PR?

Manu Sporny: this have to do with multiple suffixes thing - current formulation is a correct formulation based on what is happening in the ietf.
… multisuffixes WG in IETF.
… I did not say it is impossible to use. it is different enough and it is dangerous to say sd-jwt is a jwt.
… fine if the PR made it very clear that you should be using a library sd-jwt that can process media type.
… suggesting that jwt library can be used as-is is not ok.
… not clear if the group wants to abandon jwts and focus on sd-jwt.

Dave Longley: +1 to manu, fine to do SD-JWT, but normative reference and stability required.

Manu Sporny: need to add normative reference to sd-jwt.

Kristina Yasuda: I don’t disagree.

Manu Sporny: +1 to kristina – add a validation/processing section that tell people they should use SD-JWT libraries to do the processing.

Kristina Yasuda: all the SD-JWT implementations I’ve seen use JWT libraries, but adding something to make it clear would be good. I don’t think we’re abandoning JWTs. Correct framing is moving on we’re enabling using JWT with or without selective disclosure.

Kristina Yasuda: not sure the validate section should talk about libraries, but yes.

Sebastian Crane: concerned about adding sd-jwt.
… agree with manu’s concerns and proposed path forward.

Paul Dietrich: you can create an sd-jwt to add a ~. easy for the issuer. how does the verifier know when it is the same media type whether there is SD or not?

Kristina Yasuda: You would need to look at the number of tildes. The processing section could clarify. If a verifier gets something with no selective disclosure there one tilde at the end. with SD there are more tildes at the end. The verifier would need that logic to determine.

Paul Dietrich: a way to ask something without a SD?

Kristina Yasuda: depends on the protocol used to request a credential. presentation exchange would allow to request a thing without SD wihtout using media types.

Michael Jones: given we’re trying to move toward CR. There’s 6 approvals and minor call for suggested changes. Can we raise an issue for the remaining concerns?
… can we merge this PR and open issue on the path forward we agreed upon.

Benjamin Young: sd-jwt has to be a normative reference.

Manu Sporny: raising another issue that will have to be tagged pre-CR.
… would be nice to fix in this PR.

Brent Zundel: noting that mikeJ’s way forward is not manu’s favorite, we can do merge that PR.

6.3. explain the usage of exp and iat jwt claims (pr vc-jose-cose#151)

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

Kristina Yasuda: please open issues before merging that PR.

Michael Jones: this PR clarifies how iat/exp should be used. very small.

Manu Sporny: +1 to this PR. makes good distinction between dates associated with proof and VCs. +1 to merge.

Brent Zundel: no objections. open for more then a week - merge it.

6.4. add guidance on kid (pr vc-jose-cose#153)

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

Michael Jones: similarly simple. this simplifies one sentence and adds another one. kid must be present when issuer is expressed as a DID.
… 6 approvals no objections.

Manu Sporny: i think current text as-is is probably ok, except 2 things - we still have an issue in core data model. does not say what is the value of kid, tho seems to assume it is a DID. some assume it is a relative DID. other implementers put absolute DIDs. probably need to specify which one.
… this seem to assume absolute DID with an entire DID.

Michael Jones: from a conversation earlier where we agreed that kid is a string. so intentionally not making a decision.

Kristina Yasuda: there is a separate issued on absolute vs relative DID.
… the purpose is to address the issue in another PR.

Joe Andrieu: calling it DID URL is better. will make a suggestion.

6.5. Tighten “cnf” claim description (pr vc-jose-cose#155)

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

Michael Jones: the deletion is removing sentence that never made sense.

Brent Zundel: just a day old, please review. adds a normative reference to 7800. not normative.

6.6. Use Correct Names for Things (pr vc-jose-cose#156)

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

Michael Jones: last PR. editorial. fixes things that should have been fixed.

Brent Zundel: action is to review.

Manu Sporny: PR looks good, in general, good to call things by the right name.

Brent Zundel: nothing controversial, expect to go in in few days.

Joe Andrieu: Also, Kristina, I’m not sure I answered your earlier question correctly. A purely relative component would only make sense if the base is set to the DID. “#key1” would only make sense if you’re in a context where the base is well-defined and hence maps to a fully qualified URL. So, if the fragment is in a DID Document, we’re all good.

Manu Sporny: yes, what Joe said above ^ relative URLs only work when you’re in a DID Document.

Manu Sporny: but it’s not clear if that works for everywhere we’d find a kid.

Kristina Yasuda: thank you, Joe!

6.7. Describe SD-JWT as an alternative for selective disclosure (issue vc-jose-cose#118)

See github issue vc-jose-cose#118.

Michael Jones: this issue will be closed when the PR is merged.

6.8. Accept or Dismiss the guidance provided by DIF on kid / iss (issue vc-jose-cose#30)

See github issue vc-jose-cose#30.

Michael Jones: PR that clarifies kid is merged, this issue can be cosed.

Kristina Yasuda: this is the issue that talks about using vs absolute DID URLs. DIF was recommending something there.
… If we incorporate Joe’s suggested language and close this issue after the PR is merged, then that means we’ve agreed consciously to do that.

Manu Sporny: need to understand better where these kid values exist.

Joe Andrieu: you could specify a base.

Dave Longley: -1 to using relative, just do absolute and avoid all the trouble.

Manu Sporny: in the controller documents? if we have relative kid value, that kid value will be interpreted might be wrong, because the base of the document lives in the domain. you will end up with an https value.
… give clear guidance when to use one over the other.

Andres Uribe: +1 to dlongley.

Benjamin Young: +1 it’s unclear how the absolute URL of the document (on which the relative URL will be calculated) will actually be know and calculated against and (as manu’s stated) will shift around based on retrieval…and completely lost when stored.

Manu Sporny: need to prevent interop issues.
… concerned that the way you are approaching kid and giving guidance is not looking at all places where kid can be used.
… -1 to choosing one over the other, but need clear guidance.

Brent Zundel: merging the PR does not close this issue.

Michael Jones: from cose/jose perspective kid is an opaque string.
… there might be profiles that give more guidance.
… but it is not role of this spec to give guidance.

Oliver Terbu: +1 mike.

Michael Jones: will make a comment on this.

Joe Andrieu: is there a way to say that the base is a DID.

Michael Jones: there is not standard that says what is the base.

Kristina Yasuda: two things happening. 1 PR clarifies how kid is used in general. There is a key that can be a key set where kid can pick one. 2 there can be a DID and within the DID Doc you use a kid to find a reference in there.
… the second topic is: what is the key that is expressed when the kid is a DID. Mike’s comment that kid is okay and opaque is true, but when used as a DID needs to be clarified more.

Manu Sporny: +1 to what kristina said. not talking about just a general kid properties. have very specific usage in controller documents - where it is ok and where it is not ok.
… when you are expressing information within a DID Doc. if you are expressing a key outside a DID Doc, using relative DID url is highly problematic.
…
… we need to be more specific here.
… please remove the has-PR label from this issue.

Michael Jones: we should not make a decision of the format of kid. if DID spec makes a decision, we should reference that, but let’s not profile DID spec.

Manu Sporny: you said you are opposed to profiling DID spec, but you have another PR that does that.
… failing to provide this kind of guidance might result in rejection of the document.

Kristina Yasuda: question, is there a place where that guidance now sits? Where are the best practices for this?

Manu Sporny: When his has come up before I recall the JOSE space being opposed to defining it.
… I don’t think it exists.

Manu Sporny: yes, what Joe said.

Benjamin Young: https://www.w3.org/TR/did-core/#did-syntax.

Joe Andrieu: DID Core references a spec.

Benjamin Young: https://www.w3.org/TR/did-core/#did-url-dereferencing.

6.9. About the optionality of the “kid” field in JWT-formatted VCs/VPs (issue vc-jose-cose#31)

See github issue vc-jose-cose#31.

Michael Jones: looks similar to a previous issue, but this one is actually addressed by a PR.

Manu Sporny: agree with selfissued analysis of this issue and having a PR.

6.10. JWT exp claim (issue vc-jose-cose#39)

See github issue vc-jose-cose#39.

Michael Jones: this one has a PR too, we agreed to merge that.
… already.

6.11. Describe how cnf is allowed to be used for “binding” (issue vc-jose-cose#52)

See github issue vc-jose-cose#52.

Michael Jones: this issue has PR too? closing once merging that one.

Manu Sporny: rfc7800 defines how to use cnf claim for proof of possession.
… is that what you are saying/.

Michael Jones: yes.

6.12. Should we comment on “principle”? (issue vc-jose-cose#35)

See github issue vc-jose-cose#35.

Michael Jones: this is terminology. we already done a good job in the specs on terminology.

Manu Sporny: +1 to close this issue :).

Brent Zundel: this one is post-cr.
… any objections to close?
… no objections, closing after script has been generated.

6.13. Explain relationship between controller documents and JOSE headers (issue vc-jose-cose#106)

See github issue vc-jose-cose#106.

Michael Jones: overtaken by the decision to re-do controller doc PR.

6.14. how is kid to be useful to distinguish the specific key used? (issue vc-jose-cose#117)

See github issue vc-jose-cose#117.

Michael Jones: has PR.
… gets closed after the PR is merged.

Paul Dietrich: this issue asks to define that it is more than a hint.
… so the PR is not enough.

Kristina Yasuda: .

Brent Zundel: when writing the PR I realized there was an additional ask, so I tried to express that a kid isn’t just a hint, but a hint for a hint, checking that wasn’t enough?

Paul Dietrich: yes.

6.15. Clarify relationship between validity times (issue vc-jose-cose#133)

See github issue vc-jose-cose#133.

Brent Zundel: matching PR has been merged. this issue can be closed.

Joe Andrieu: validation section references VCDM.
… , correct?

Michael Jones: yes.

6.16. Can registered JWT claims be used only in the JOSE header?? (issue vc-jose-cose#135)

See github issue vc-jose-cose#135.

Michael Jones: my new PR has correct names for the things. implicitly that answers the question.

Kristina Yasuda: .
… I don’t think that PR addresses this issue, and it changes what Orie originally intended.
… There are claims like kid that can only exist in Header, but claims like iss where the optionality was intentionally left, whether header or body.
… I was asking for clarification . If both are possible the processor will need to know what to expect.
… If addressed byt eh PR, then iss can only exist in claim, so we need more than open PR.

Michael Jones: understand what you are saying. will note that you can optionally put JWT claims in the header. that’s why I felt the PR answers the issue.

Manu Sporny: https://github.com/w3c/vc-data-model/blob/main/contexts/credentials/v2.

Michael Jones: . defined by an RFC.

Manu Sporny: +1 to what kristina is saying. if you look at the context, iss, exp, etc. can be present in both places (header and the body). ).
… this has been an issue for a while. I have been objecting for it for a while because the optionality will hurt interop.

Paul Dietrich: +1 manu. I though we were fixing this.

Manu Sporny: not even sure there is issue for this. might lead to the problem that we had with an approach in vcjwt 1.1 that duplicated fields in “in addition to” approach.

Manu Sporny: +1 to correcting things in the way that selfissued proposed.

Michael Jones: agree that clarification is needed, can do a simple PR.

Kristina Yasuda: .

Brent Zundel: I don’t think this is ready for PR. I don’t think we have an agreement. I’m leaning toward those claims can be present in the header. If now we believe we have enough implementatiion experience that puts them in the header, that’s where we shoudl say they should be.

Manu Sporny: agree with kristina, we need to make a decision here.

Manu Sporny: here is the issue: https://github.com/w3c/vc-data-model/blob/main/contexts/credentials/v2#L9-L58.

Michael Jones: no place says JWT claims can be in the header. We shouldn’t start that.
… my PR says follow JWT spec guidance.

Kristina Yasuda: I think Orie will object to that but we will see.

Michael Jones: It deprecates the practive of duplicating them.

7. closing.

Manu Sporny: thanks all!

Manu Sporny: Thanks a ton to Chairs and scribes! :).

Brent Zundel: thank you all! especially those who stayed up weird hours.
… take a note that agenda has slightly changed. we have some guests coming.

Sebastian Crane: :) and, I think, stayed up really really late, in the case of shigeya.

Brent Zundel: we are in a different room tomorrow.
… we are in magnolia tomorrow.

8. Resolutions