From 7bb807195360453f08812f276c618790da26cf6b Mon Sep 17 00:00:00 2001 From: Ivan Herman Date: Fri, 15 Sep 2023 10:17:43 +0200 Subject: [PATCH] Attempt to handle utf issues --- _minutes/2023-09-14-vcwg.md | 538 ++++++++++++++++++------------------ 1 file changed, 269 insertions(+), 269 deletions(-) diff --git a/_minutes/2023-09-14-vcwg.md b/_minutes/2023-09-14-vcwg.md index ed19183..e457de1 100644 --- a/_minutes/2023-09-14-vcwg.md +++ b/_minutes/2023-09-14-vcwg.md @@ -1,7 +1,7 @@ --- layout: minutes date: 2023-09-14 -title: Verifiable Credentials Working Group F2F at TPAC, 1st day — 2023-09-14 +title: Verifiable Credentials Working Group F2F at TPAC, 1st day, 2023-09-14 json-ld: | { "@context": [ @@ -20,7 +20,7 @@ json-ld: | ], "@type": "CreativeWork", "url": "https://www.w3.org/2017/vc/WG/Meetings/Minutes/2023-09-14-vcwg", - "name": "Verifiable Credentials Working Group F2F at TPAC, 1st day — Minutes", + "name": "Verifiable Credentials Working Group F2F at TPAC, 1st day, 2023-09-14", "about": "Verifiable Credentials Working Group F2F at TPAC, 1st day", "dateCreated": "2023-09-14", "irc": "vcwg", @@ -237,7 +237,7 @@ json-ld: | --- -# Verifiable Credentials Working Group F2F at TPAC, 1st day — Minutes +# VVerifiable Credentials Working Group F2F at TPAC, 1st day, 2023-09-14 - Minutes {: .no_toc .draft_notice_needed} @@ -300,7 +300,7 @@ _See github pull request [vc-data-model#1260](https://github.com/w3c/vc-data-mod **Brent Zundel:** Next one is 1260. -… Raised by Orie. Open for some time. Currently 1 pending change request from manu. +... 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. @@ -322,7 +322,7 @@ _See github pull request [vc-data-model#1269](https://github.com/w3c/vc-data-mod **Brent Zundel:** Raised by JoeAndrieu, suggesting changes to terminology. -… Few approvals, one request for changes from TallTed. +... Few approvals, one request for changes from TallTed. **Ted Thibodeau Jr.:** If changes are done, I'm ok merging. @@ -352,8 +352,8 @@ _See github pull request [vc-data-model#1270](https://github.com/w3c/vc-data-mod **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. +... 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. @@ -412,13 +412,13 @@ _See github pull request [vc-data-model#1278](https://github.com/w3c/vc-data-mod **Ivan Herman:** For the record, I did 1278 yesterday. -… it's on top of 1272. +... 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. +... 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. @@ -432,10 +432,10 @@ _See github pull request [vc-data-model#1276](https://github.com/w3c/vc-data-mod **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. +... 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. +... 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. @@ -449,8 +449,8 @@ _See github pull request [vc-data-model#1277](https://github.com/w3c/vc-data-mod **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. +... 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) {: #section1-9} @@ -462,31 +462,31 @@ _See github pull request [vc-data-model#1279](https://github.com/w3c/vc-data-mod **Brent Zundel:** PR was raised 16 hours ago. Manu clearly is bored. -… Can you give us an intro? +... 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. +... 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. +... 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. +... 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. +... 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. @@ -502,19 +502,19 @@ _See github pull request [vc-data-model#1280](https://github.com/w3c/vc-data-mod **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. +... 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. +... 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. +... Agree on the restrictions and limitations as well. **Brent Zundel:** Who will raise that issue in DI? @@ -532,33 +532,33 @@ _See github pull request [vc-data-model#1281](https://github.com/w3c/vc-data-mod **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. +... 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. +... 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. +... 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. +... 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. +... 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. @@ -577,7 +577,7 @@ _See github pull request [vc-data-model#1281](https://github.com/w3c/vc-data-mod > *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? +... 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. @@ -611,14 +611,14 @@ _See github issue [vc-data-model#1275](https://github.com/w3c/vc-data-model/issu **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. +... 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. +... We should align. That's what I'd like to see. **Michael Jones:** I can review the PR. @@ -638,14 +638,14 @@ _See github issue [vc-data-model#1265](https://github.com/w3c/vc-data-model/issu **Brent Zundel:** Raised by Orie, who isn't able to attend today. -… Is it a good idea? Why? +... 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. +... 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. @@ -666,10 +666,10 @@ _See github issue [vc-data-model#1265](https://github.com/w3c/vc-data-model/issu **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. +... 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. +... I just translated what is in the spec to the vocab. **Brent Zundel:** We'll get to it as some point today. @@ -680,31 +680,31 @@ _See github issue [vc-data-model#1265](https://github.com/w3c/vc-data-model/issu > *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. +... 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. +... 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. +... 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. +... 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. +... 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. +... we can do that with the VC. > *Dmitri Zagidulin:* the binding time is different, for a VC vs VP. @@ -726,19 +726,19 @@ _See github issue [vc-data-model#1263](https://github.com/w3c/vc-data-model/issu **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. +... 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. +... 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. +... 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. @@ -751,26 +751,26 @@ _See github issue [vc-data-model#1263](https://github.com/w3c/vc-data-model/issu > *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. +... 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. +... 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. +... 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. +... 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. @@ -781,10 +781,10 @@ _See github issue [vc-data-model#1263](https://github.com/w3c/vc-data-model/issu **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. +... 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. +... I'm willing to assign myself and work on it on Saturday. > *Juan Caballero:* i can do it with you this weekend, brent. @@ -806,23 +806,23 @@ _See github issue [vc-data-model#1262](https://github.com/w3c/vc-data-model/issu **Brent Zundel:** next issue: 1262. add revoked and expired to verificationMethod classes. -… been conversation, but no one assigned. can anyone give a summary. +... 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. +... 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. +... 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) {: #section2-5} @@ -836,17 +836,17 @@ _See github issue [vc-data-model#1247](https://github.com/w3c/vc-data-model/issu **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. +... 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. @@ -855,45 +855,45 @@ _See github issue [vc-data-model#1247](https://github.com/w3c/vc-data-model/issu > *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). +... 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. +... the data model is our cutoff. **Manu Sporny:** +1 to Kristina put into chat. -… we shouldn't overcomplicate this. +... 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. +... 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. +... 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. +... 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. +... 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. +... next issue is 1232. Revisit validations versus verification. #### 2.6. Revisit validation vs verification (issue vc-data-model#1232) {: #section2-6} @@ -907,7 +907,7 @@ _See github issue [vc-data-model#1232](https://github.com/w3c/vc-data-model/issu **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. +... PR 149 use cases has that document. _See github pull request [vc-use-cases#149](https://github.com/w3c/vc-use-cases/pull/149)._ @@ -922,10 +922,10 @@ _See github pull request [vc-use-cases#149](https://github.com/w3c/vc-use-cases/ > *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? +... 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. +... it's a bit confusing. > *Joe Andrieu:* is it normative language or not? @@ -940,7 +940,7 @@ _See github pull request [vc-use-cases#149](https://github.com/w3c/vc-use-cases/ **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? +... 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. @@ -960,8 +960,8 @@ _See github issue [vc-data-model#1155](https://github.com/w3c/vc-data-model/issu **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. +... 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. @@ -972,106 +972,106 @@ _See github issue [vc-data-model#1264](https://github.com/w3c/vc-data-model/issu **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](https://github.com/w3c/vc-data-model/issues/1264#issuecomment-1712807665). -… we can close or open. This issue: just one more item we need to resolve before CR. +... 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](https://github.com/w3c/vc-data-model/issues/1264#issuecomment-1712807665). +... 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. +... 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. +... 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](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. +... 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. +... 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. +... `@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. +... 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/](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. +... 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. +... 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. +... 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. +... 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. +... 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. +... 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. +... 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. +... 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. +... 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'. @@ -1110,7 +1110,7 @@ _See github issue [vc-data-model#1264](https://github.com/w3c/vc-data-model/issu > *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. +... this could impact things in unintended ways. > *Dmitri Zagidulin:* 'id' and 'type' are also very common words. @@ -1137,13 +1137,13 @@ _See github issue [vc-data-model#1264](https://github.com/w3c/vc-data-model/issu > *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. +... 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. +... 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. @@ -1156,9 +1156,9 @@ _See github issue [vc-data-model#1264](https://github.com/w3c/vc-data-model/issu **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. +... 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 :-(. @@ -1177,7 +1177,7 @@ _See github issue [vc-data-model#1264](https://github.com/w3c/vc-data-model/issu **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. +... 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. @@ -1199,11 +1199,11 @@ _See github issue [vc-data-model#1264](https://github.com/w3c/vc-data-model/issu **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. +... 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? @@ -1237,7 +1237,7 @@ _See github issue [vc-data-integrity#191](https://github.com/w3c/vc-data-integri > *Dave Longley:* [https://w3c.github.io/vc-data-integrity/#resource-integrity](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. +... 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. @@ -1254,10 +1254,10 @@ _See github issue [vc-data-integrity#191](https://github.com/w3c/vc-data-integri **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. +... 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. @@ -1268,7 +1268,7 @@ _See github issue [vc-data-integrity#191](https://github.com/w3c/vc-data-integri **Dmitri Zagidulin:** Is b64url itself an RFC? **Brent Zundel:** answer is yes. -… are you and Sebastian as editors ok with addressing this issue? +... are you and Sebastian as editors ok with addressing this issue? > *Gabe Cohen:* manu/seabass: yes. @@ -1277,7 +1277,7 @@ _See github issue [vc-data-integrity#191](https://github.com/w3c/vc-data-integri **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. +... you don't have to answer now, tell me when you go to change the PR. > *Sebastian Crane:* +1 then. @@ -1328,14 +1328,14 @@ _See github issue [vc-data-integrity#192](https://github.com/w3c/vc-data-integri **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? +... 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. +... 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). @@ -1386,7 +1386,7 @@ _See github issue [vc-data-integrity#192](https://github.com/w3c/vc-data-integri {: #resolution1 .resolution} **Manu Sporny:** moving onto the crypto suites. -… (back to presentation). +... (back to presentation). > *osamu-n:* osamu-n has joined #vcwg. @@ -1400,7 +1400,7 @@ _See github issue [vc-data-integrity#192](https://github.com/w3c/vc-data-integri **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. +... 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)* {: .proposed_resolution} @@ -1496,17 +1496,17 @@ _See github issue [vc-data-integrity#192](https://github.com/w3c/vc-data-integri **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. +... 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. +... 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. +... 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. @@ -1517,24 +1517,24 @@ _See github issue [vc-data-integrity#192](https://github.com/w3c/vc-data-integri > *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. +... 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. +... 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. +... we will move to the next topic which is json schema. ### 4. VC JSON Schema. {: #section4} **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. +... 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) {: #section4-1} @@ -1565,7 +1565,7 @@ _See github pull request [vc-json-schema#216](https://github.com/w3c/vc-json-sch > *Gabe Cohen:* [https://github.com/w3c/vc-json-schema-test-suite](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. +... 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)* {: .proposed_resolution} @@ -1610,7 +1610,7 @@ _See github pull request [vc-json-schema#216](https://github.com/w3c/vc-json-sch {: #resolution4 .resolution} **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. +... Everything should go together. ### 5. more VCDM Issue triage. {: #section5} @@ -1633,7 +1633,7 @@ _See github issue [vc-data-model#1152](https://github.com/w3c/vc-data-model/issu **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. +... 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. @@ -1642,7 +1642,7 @@ _See github issue [vc-data-model#1152](https://github.com/w3c/vc-data-model/issu **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. +... 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. @@ -1760,10 +1760,10 @@ _See github pull request [vc-jose-cose#144](https://github.com/w3c/vc-jose-cose/ > *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. +... 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. @@ -1774,12 +1774,12 @@ _See github pull request [vc-jose-cose#144](https://github.com/w3c/vc-jose-cose/ **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. +... 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. +... if this is a profile with subsetting - great, but please say so. **Michael Jones:** could you state that in the PR? @@ -1805,8 +1805,8 @@ _See github pull request [vc-jose-cose#149](https://github.com/w3c/vc-jose-cose/ **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. +... 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. @@ -1819,8 +1819,8 @@ _See github pull request [vc-jose-cose#149](https://github.com/w3c/vc-jose-cose/ **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. +... 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](https://github.com/w3c/vc-jose-cose/pull/149/files). @@ -1839,12 +1839,12 @@ _See github pull request [vc-jose-cose#149](https://github.com/w3c/vc-jose-cose/ **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. +... 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. +... 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? @@ -1855,18 +1855,18 @@ _See github pull request [vc-jose-cose#149](https://github.com/w3c/vc-jose-cose/ **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. +... 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? +... 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. +... 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. @@ -1881,7 +1881,7 @@ _See github pull request [vc-jose-cose#149](https://github.com/w3c/vc-jose-cose/ > *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. +... 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? @@ -1892,12 +1892,12 @@ _See github pull request [vc-jose-cose#149](https://github.com/w3c/vc-jose-cose/ **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. +... 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. +... 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. @@ -1928,15 +1928,15 @@ _See github pull request [vc-jose-cose#153](https://github.com/w3c/vc-jose-cose/ **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. +... 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. +... 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. +... the purpose is to address the issue in another PR. **Joe Andrieu:** calling it DID URL is better. will make a suggestion. @@ -2002,7 +2002,7 @@ _See github issue [vc-jose-cose#30](https://github.com/w3c/vc-jose-cose/issues/3 **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. +... 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. @@ -2011,21 +2011,21 @@ _See github issue [vc-jose-cose#30](https://github.com/w3c/vc-jose-cose/issues/3 > *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. +... 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. +... 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. +... there might be profiles that give more guidance. +... but it is not role of this spec to give guidance. > *Oliver Terbu:* +1 mike. @@ -2036,23 +2036,23 @@ _See github issue [vc-jose-cose#30](https://github.com/w3c/vc-jose-cose/issues/3 **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. +... 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. +... 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. +... 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. +... I don't think it exists. > *Manu Sporny:* yes, what Joe said. @@ -2085,7 +2085,7 @@ _See github issue [vc-jose-cose#39](https://github.com/w3c/vc-jose-cose/issues/3 **Michael Jones:** this one has a PR too, we agreed to merge that. -… already. +... already. #### 6.11. Describe how `cnf` is allowed to be used for "binding" (issue vc-jose-cose#52) {: #section6-11} @@ -2099,7 +2099,7 @@ _See github issue [vc-jose-cose#52](https://github.com/w3c/vc-jose-cose/issues/5 **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/. +... is that what you are saying/. **Michael Jones:** yes. @@ -2117,8 +2117,8 @@ _See github issue [vc-jose-cose#35](https://github.com/w3c/vc-jose-cose/issues/3 > *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. +... 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) {: #section6-13} @@ -2141,10 +2141,10 @@ _See github issue [vc-jose-cose#117](https://github.com/w3c/vc-jose-cose/issues/ **Michael Jones:** has PR. -… gets closed after the PR is merged. +... 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. +... so the PR is not enough. **Kristina Yasuda:** . @@ -2164,7 +2164,7 @@ _See github issue [vc-jose-cose#133](https://github.com/w3c/vc-jose-cose/issues/ **Brent Zundel:** matching PR has been merged. this issue can be closed. **Joe Andrieu:** validation section references VCDM. -… , correct? +... , correct? **Michael Jones:** yes. @@ -2180,10 +2180,10 @@ _See github issue [vc-jose-cose#135](https://github.com/w3c/vc-jose-cose/issues/ **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. +... 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. @@ -2192,7 +2192,7 @@ _See github issue [vc-jose-cose#135](https://github.com/w3c/vc-jose-cose/issues/ **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. +... 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. @@ -2211,7 +2211,7 @@ _See github issue [vc-jose-cose#135](https://github.com/w3c/vc-jose-cose/issues/ > *Manu Sporny:* here is the issue: [https://github.com/w3c/vc-data-model/blob/main/contexts/credentials/v2#L9-L58](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. +... my PR says follow JWT spec guidance. > *Kristina Yasuda:* I think Orie will object to that but we will see. @@ -2225,12 +2225,12 @@ _See github issue [vc-jose-cose#135](https://github.com/w3c/vc-jose-cose/issues/ > *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. +... 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. +... we are in magnolia tomorrow. ---