Meeting minutes
Brent Zundel: Welcome everybody, this is the VCWG, we are meeting under the patent policy and all the policies of the W3C. If you're not a member of the WG -- I don't see anyone I don't recognize though. If anyone wants to introduce themselves, please say hello.
Brent Zundel: We're going to move forward.
Brent Zundel: Time change is upon us. Some of change the clocks biannually -- in order to attempt to alleviate the pain where the US and the Europe switch at different times and others around the world have already switched -- we will include a time and date link in the agenda.
Brent Zundel: In theory, it should give you the time and date in your local timezone.
<Joe Andrieu> fwiw, the US changes time Nov 1
Brent Zundel: The official time for this meeting is set to the US Eastern Time, which will become Eastern Standard Time.
Brent Zundel: The funkiest week for clocks will be at TPAC.
Brent Zundel: FYI, things are going to be strange, we apologize.
Joe Andrieu: I think I might have started an unfortunate rumor with when the time switch happens. It's Nov 1 in the US.
Brent Zundel: Yes, it's a week earlier in Europe though.
<Michael Shea> depends on the time of year
Joe Andrieu: Ah, thank you.
TPAC Agenda
<Brent Zundel> https://
Brent Zundel: We have a draft agenda being built for TPAC.
Brent Zundel: Let us know if you don't have access to it, you should.
Brent Zundel: If your task force is slotted in this task force when no one from your task force can lead, let us know, that would be a problem. We think we have arranged things so it will work out for everyone but would love to hear for sure if not.
Brent Zundel: At this point this is the plan; we're focusing as much time as possible on the task forces.
Brent Zundel: Giving the task forces the remit to arrange their given time however they see fit and the chairs will be there to support and run queue and run admin stuff.
Brent Zundel: The task force time slots are your time.
Brent Zundel: Questions, comments, concerns?
Brent Zundel: I do not anticipate anything drastically changing the agenda at this point. Minor adjustments can still be made up until we're literally in the meeting.
Brent Zundel: If you are unable to join us in person you should be able to join us remotely.
Brent Zundel: If you have any trouble getting on remotely, let us know. We will be in this IRC channel.
Brent Zundel: Feel free to join us here and let us know you can't join if you have trouble.
Brent Zundel: I'm pretty sure it's not this same zoom channel, but a special one for TPAC.
Brent Zundel: We would love to have you even if you can't be there in person.
Brent Zundel: It will be a good couple of days.
Brent Zundel: The final topic for today -- we usually do a round table for task forces, but we want to do a deeper dive today.
Brent Zundel: Please jump on the queue or we can go in order if preferred, but what I'd like from each task force is not just a rough status of how things are going but give this group a PR or an issue to discuss. What should we know about?
Brent Zundel: What controversies are you facing, let's get a bit more deeply into it.
Task Force Deeper Dive
Brent Zundel: This is the topic for the rest of the meeting. Let's look at PRs and issues for the task forces -- because not everyone can go to every task force.
Carolynn Bernier: So, we've run into a problem in the DPP vocab work. Because we're trying to create an example for the Recognized Entities recommendation and we're run into a problem -- but maybe that RE task force has discussed it.
Carolynn Bernier: The question to them is -- how do you limit the scope of a Recognized Entity VC / Entity?
Carolynn Bernier: The spec doesn't say how to limit the scope it just says how to list recognized actions.
Carolynn Bernier: Where is the scope defined? Is the scope defined in the credential itself or is it defined elsewhere? Can someone from the RE task force answer me, have I been clear?
Manu Sporny: Yes, you have been very clear. We just so happen to have been talking about that issue over the past couple of weeks. There are 4-5 issues covering this item.
Brent Zundel: Whichever one would be most useful for this conversation to end up in.
Manu Sporny: All of them would enjoy that.
w3c/vc-recognized-entities#140
Manu Sporny: Here's issue 140 -- it's an existential question about what we're actually doing. Good news is that we made some good forward progress on this yesterday. We're getting more interest in the RE spec from different market verticals.
Manu Sporny: Initially it was education and vital records and UNTP and supply chain stuff, GS1, brought in use cases. Now we also have DPP and people from Switzerland.
Manu Sporny: Lots of great uses of this -- the group is struggling with how big the scope ought to be for the work and can we provide a minimum set of primitives for use across all these different verticals.
Manu Sporny: So the question came up -- how does one say that you recognize a particular entity under a particular scope -- and say that it's limited to say, Australia or Japan or whatever.
Manu Sporny: We're going to raise PRs to try and answer that question over the next week or two and that we have a handle on the problem now too. It might be through a simple property like "registration" that talks about the regulation, scope, and those types of things -- without breaking existing use cases.
Manu Sporny: We have consensus in the group to address this we think and the plan is to define a property for this and test against the use cases from groups that have raised this or asked about it.
Manu Sporny: I think that's where we are right now and it's the last big issue in the spec before CR.
Carolynn Bernier: You aren't trying to model scope?
Manu Sporny: We are trying to do that -- we will have a solution to your problem, we believe we will be able to express scope with some of the future PRs.
Carolynn Bernier: Ok, thank you.
Brent Zundel: Awesome, that was a fun little deep dive. Thank you, Carolynn Bernier for starting us off.
Brent Zundel: Kayode you're next on the queue.
Kayode Ezike: Quick update first -- we've been going through outstanding issues these last few weeks. We have been making sure we have a handle on them and figuring out which we want to address before CR.
Kayode Ezike: One of them we've made good progress on but there's still an ask for this group that is around BBS support and another that is around enabling the holder in the three party flow -- to enable an exchange to be explicitly terminated by them rather than just abandonment.
Kayode Ezike: We filed an issue in the VC data model issue tracker for this.
w3c/vc-data-model#1649
Kayode Ezike: The context here is that we wanted to start to have to have a mechanism to request for data that isn't a credential during an exchange. We use VPR (Verifiable Presentation Request) to request information but there isn't a way to return information that isn't a credential.
Kayode Ezike: We want to be able to request zcaps or BBS data and we'd like to receive data about those things.
Kayode Ezike: A PR landed a week or two ago in the VCALM spec where we added a property for this into a standalone context so it can be attached to 2.0, but we'd also like to add it to the 2.1 context so it would be included.
Kayode Ezike: We'd like to include the `exchangeData` plain JSON field to add this kind of data that needs to be transmitted during a particular exchange.
Kayode Ezike: We'd like to review this issue and see if we can get it into the 2.1 context.
Brent Zundel: Let's talk about this issue. If you have comments about this issue 1649, please jump on the queue.
Manu Sporny: Kayode I may have missed if you said this, but one reason we need this feature is to support this feature is for BBS -- there are things you need to ask for that are modulations on the cryptography but not about the VC directly.
Manu Sporny: There are potentially other use cases -- I want to see a VC and, if you have a PDF for this too, please send that. There are fringe use cases like this, but in some of these exchanges people want data that isn't really a VC but it would be disruptive to take them out of the wallet to do completely different flows, it's an extensible field.
Brent Zundel: I see the issue is labeled "allowed class 4", can someone tell me the reasoning for that -- no challenge, just want it stated for the record.
Manu Sporny: The charter states that we can make class 4 changes to the data model if another spec asks for it and especially if it is for security purposes. BBS won't work without it, VCALM needs this for the response portion of an exchange.
Brent Zundel: Thank you.
Brent Zundel: Folks, please jump on 1649 if you have comments/opinions, it sounds like a reasonable idea.
Manu Sporny: Just to add to general VCALM -- we did do a review of how close to CR we think we are. It seems like we have only two issues left before the group feels like we can say we're feature frozen as far as we know. Of course, we haven't received the vast majority of horizontal reviews on our spec so there's blockage there.
Manu Sporny: But we think by the end of the year we could make it into CR if we get the horizontal reviews in.
Manu Sporny: In addition, the FedID working group, EMVCo, Conexxus, and some other groups have been asked to meet to talk about VCs, the DC API, and so on -- this is a heads up to the group that Wes Smith and Dave Longley have largely been putting together a slide deck that I'll be talking to.
Manu Sporny: About where VCs are being used in the ecosystem and where some parties have struggled with using credentials and the DC API and so on where the goal is to talk about some concrete changes we'd like to see to help with those challenges.
Manu Sporny: These will be raised by our company and customers. This will be at a separate meeting on Tuesday afternoon at TPAC.
Manu Sporny: I can circulate slides and talk about this more with folks.
Brent Zundel: Any comments, concerns, questions, on the things Manu Sporny has said?
Brent Zundel: Kayode -- is there something else you wanted to cover?
w3c/vcalm#686
Kayode Ezike: This is an issue that's relevant to more than just our group. How do we reference jsonata? Other specs in the VCWG are also using it.
Kayode Ezike: My understanding is that there is a conversation that needs to happen between the chairs and Ivan to give general guidance on how we should reference it. The general question is "what's the final say on how we ought to be referencing it?"
Kayode Ezike: It's fine if it's not a normative reference, but we want to know how to refer to it and how the task forces should refer to it.
<Brent Zundel> https://
Brent Zundel: There is a page in the W3C guide which talks about normative references.
Brent Zundel: This is the guidance -- this page outlines the considerations that the team makes when looking at references.
Brent Zundel: What it comes down to is that there needs to be some indication of stability, knowledge of who the external organization is, what the dependency, are there implementations -- no one thing either guarantees or forbids a reference from being normative but it's a high bar.
Brent Zundel: If an informative reference is possible for this one that's easy, you can do that for anything.
Brent Zundel: In the issue it seems like you're talking about a normative reference.
Manu Sporny: There is a heavy dependency in VCALM and it seems that the Recognized Entity specification will have it too -- I don't think that we can get around with a non-normative reference, we can play with spec language, but it's a pretty core feature to rely on.
Manu Sporny: The jsonata tech does meet a number of bars: patent free, royalty free, multiple implementations. There are primarily two people in charge of the project, IBM/Red Hat/something. I doubt they plan on going to IETF with it, it's like JSON schema. It has a similar history to JSON schema which also isn't going to IETF or anything. We were able to reference JSON schema normatively.
Manu Sporny: We might reach out to them and ask them about it.
Brent Zundel: To summarize the key factors: stability, licensing, and availability. It's freely available on the Web, that's covered. Stability -- how do we point to the exact version of this? And then triple ensure there are no patents or infringements in it.
Brent Zundel: Take that link to the guide and go forth and best of luck.
Brent Zundel: As an aside, I heard a European Commission person say how much they like VC JSON schema being done so as soon as there are implementations we could publish it as a REC.
w3c/vc-data-model#1653 (VC Render Method TF)
Brent Zundel: Thank you! Dmitri you're up, other task forces prepare yourself.
Render Method
Dmitri Zagidulin: Quick update on the VC render method and discuss issue 1653.
w3c/vc-data-model#1653
Dmitri Zagidulin: This was opened on the VC data model as a result of a discussion in the render method task force.
Dmitri Zagidulin: VC render method task force has defined 3 main suites for rendering VCs for anything that will render VCs, a digital wallet, a website, whatever it is.
Dmitri Zagidulin: We don't want every renderer to have to reimplement or customize rendering.
Dmitri Zagidulin: To that end, we have a notion of a static render suite that is for an NFC payload, or a PDF, etc.
Dmitri Zagidulin: This quite is fairly basic.
Dmitri Zagidulin: The second suite is codenamed "Summary" and is likely to change. The TF still has to finalize the name. It's a set of field labels and other metadata that helps with displaying the VC more generically.
Dmitri Zagidulin: The third suite is a full one JS and HTML and CSS application that can be embedded in a sandboxed iframe.
Dmitri Zagidulin: You don't have to come up with your own view but just directly show what the issuer wants.
Dmitri Zagidulin: Those are the three that have been finalized for a while and that you can expect in CR. Names might change, ideas are the same.
Dmitri Zagidulin: One of the main features we want to address before CR is i18n and multilanguage VCs.
Dmitri Zagidulin: This is the case for VCs in general and why it touches on the core VC spec and it's especially relevant for displaying information in different languages.
Dmitri Zagidulin: So issue 1653 came out of the discussion from the last task force call. There are 3 levels of internationalization. One is value level, we have a VC that's a bag of claims, the values of the claims themselves can be translated.
Dmitri Zagidulin: We have that ability from the VC data model spec which comes from JSON-LD.
Dmitri Zagidulin: You can have a language map, you can have a default language for the whole VC, you can apply individual languages for different values, all inherited from JSON-LD.
Dmitri Zagidulin: It doesn't apply to the field labels though.
Dmitri Zagidulin: I honestly haven't seen too wide of an implementation for these and the European wallet uses something else -- but values are handled.
Dmitri Zagidulin: Level 2 is translating on a field label level. Picture a diploma -- that might have a field level for a title and description of a course.
Dmitri Zagidulin: In English and some other languages it's just "Computer Science 101"
Dmitri Zagidulin: The values here we get for free from JSON-LD.
Dmitri Zagidulin: The problem kicks in with a third level of localization.
Dmitri Zagidulin: That is that we need to able to translate not just the field labels, but the layout.
Dmitri Zagidulin: This medical certificate looks different depending on the local, the layout and colors, date time, might all change.
Dmitri Zagidulin: Even though it's the same RFC date string under the hood, the display must be different.
Dmitri Zagidulin: That's where the argument came in -- one of the proposals was to add an "inLanguage" property.
Dmitri Zagidulin: There's some current objection in the group for adding that.
Dmitri Zagidulin: The issue 1653, on the core data model was opened. What's that issue about? Hey can we use an HTTP mechanism the Accept-Language mechanism?
Dmitri Zagidulin: So we have this notion of external resources.
Dmitri Zagidulin: You can link and secure with digest multibase.
Dmitri Zagidulin: Some related resources such as the HTML app used to display a VC, is hosted externally.
Dmitri Zagidulin: When requesting that external resource, that display for the iframe, we can say "I would like it in the English language or the French language, etc." and let the language negotiation take care of it.
Dmitri Zagidulin: There's division on the group on whether that's an appropriate mechanism and I wanted to bring that up here with the main group.
Dmitri Zagidulin: The are considerations, implementation requirements, the server side aspect, whether it fits the use cases, especially those in Europe, Canada, other multilanguage locals.
Michael Shea: Sharing something from the UNTP side. I know that there are interests in the UNTP folks being able to participate -- but the 2am time for key individuals -- is there any flexibility on the time for the call? Some of the sandboxing restrictions it's not usable by UNTP.
Michael Shea: They'd like to participate in the call but the time is a real obstacle.
Dmitri Zagidulin: Thank you for letting me know, let's get an Australia-friendly time for a call and invite them over.
Michael Shea: Thank you.
Brent Zundel: Go ahead Joe.
Joe Andrieu: We need a solid review, we've got a threat model, we're looking to kick of horizontal review at TPAC.
w3c/vc-confidence-method#41
Joe Andrieu: So, our topic: How do we want to treat constraints for biometrics?
Joe Andrieu: Some verifiers say you have to come into our company do it here. Others might say you can provide any biometric that satisfies any abstract requirements.
Joe Andrieu: On a real level we can't prevent verifiers to make the same requirements via some other means. It's hard for us to restrict the request language -- like saying you can't say the specific provider, because verifiers can go around it.
Joe Andrieu: We want good ideas for what to put in the spec and what kinds of requests to support in the spec.
Joe Andrieu: And we may want to say things about potential privacy or security considerations. So we talk about what we know we like and then tag some others with risks.
Joe Andrieu: Many of us favor decentralization but we also need to enable very specific types of biometrics.
Brent Zundel: Thank you, Joe, any comments or questions?
Manu Sporny: Question for you, Joe. Where would you think this would be surfaced? Would this be surfaced in the query that comes into the digital wallet or where would these restrictions be placed or where would the language be built around?
Joe Andrieu: Good question. We do have some of the confidence method -- as currently defined relies on the VPR -- and that you're part of the loop there and that it would be in the VPR.
Joe Andrieu: A VPR is pretty flexible so you can ask for anything.
Joe Andrieu: If you're not in a VPR loop, we haven't talked about that, if you're doing a biometric challenge outside of a VPR loop then we'd have to figure that out, so the short answer is that it's in the VPR.
Brent Zundel: Any other questions or comments?
Brent Zundel: Then we will move to Manu Sporny.
Manu Sporny: Thanks, Brent Zundel. This is for Recognized Entities.
w3c/vc-recognized-entities#138
Manu Sporny: Carolynn Bernier actually covered the main topic of discussion at the beginning of the call so I'll jump to a PR that we're unsure about. This came in from a security review on the specification.
Manu Sporny: That review said that in the RE spec you have organizations that recognized other organizations to do certain things like issue a DL. However, the algorithm doesn't say -- if there are multiple hops in the chain, like a Global Authority that delegates to a National Authority and then to a Regional Authority, etc. -- you don't have anything in the spec that scopes that delegation down.
Manu Sporny: There's nothing to say that something at the end of the chain can't just issue something for another country or whatnot.
Manu Sporny: There's this question around -- "what are you allowed to do" per the RE spec. And that kicked off a fairly in depth discussion about that spec. Some people's mental model about the RE spec is that it says what an organization can and cannot do.
Manu Sporny: And that is a bad mental model for what that spec is about. It's not about that at all.
<Joe Andrieu> +1 for redressing that mental model mistake
Manu Sporny: VCs are about model world data models, anyone can say anything about anything.
Manu Sporny: You can say that you recognize that something someone issues, but you can't restrict them.
Manu Sporny: What someone can do, a Recognized Entity Credential issuer can say they'd recognize certain VCs from a University, but they can't stop that University from issuing whatever they want.
Manu Sporny: So we're figuring out the proper language to use to respond to the security review here to make it clear how to prevent certain types of scoping attacks, but that the technology is not capable of preventing orgs from issuing other types of credentials.
Joe Andrieu: +1 to everything you just said, I really appreciate the continuing efforts to shift away from the allowance language.
Joe Andrieu: When I talked with Simone about this -- the language currently is about chain of authority and applies the legitimacy of transitive trust and that's a problem. I could choose to trust both AAMVA or AAA for some VCs.
Joe Andrieu: That pattern -- "I'm only trusting the list maker" follows a coherent trust model, but if we're creating a certificate hierarchy then you have to independently evaluate what it implies.
Joe Andrieu: The DNS architecture for TLS in particular, started out with an ambition about what it meant to get a green lock on a URL -- that turned out to be more burdensome than it was worth than to just secure the endpoint.
Joe Andrieu: Let's Encrypt just makes sure you can secure the traffic but no longer checks you as a company, etc.
<Manu Sporny> Agree, Joe :)
Brent Zundel: Awesome, thank you, Joe, Manu Sporny, everybody. We're at time. If any task force has questions for the TAG, the TAG has made themselves available to join our VCWG meeting, so let us know if you'd like them to be there.
Brent Zundel: Thanks everyone, Dave, thanks for scribing.
Dave Longley: You're welcome!