Meeting minutes
Brent Zundel: Welcomes everyone
Brent Zundel: Any introductions?
mikeLinck: Says hello. From Google, working on DPP and more
Brent Zundel: Talks about the reason for the weekly all-group meeting
Brent Zundel: Goes through agenda
… with a focused render method session
… notes that Michael Shea has asked to look at classes of changes cf. the charter
Task Force Updates
Brent Zundel: Please let us know how things are going in your TF
Wesley Smith: barcodes and DI TF - now has hte forgery defence work under its umbrella
… things progressing smoothly for now
<Joe Andrieu> Nothing to report from Confidence Method
Brent Zundel: To all TF leads. We're starting a trend on the all-group call to focus on a specific TF each week
<Kayode Ezike> +1 Joe Andrieu
Joe Andrieu: Please check with the TF leads before scheduling!
Brent Zundel: Noted
Brent Zundel: Anyone from other TFs?
Kayode Ezike: We've been speed-running through issues. Some still need to be resolved. But we're making progress
Brent Zundel: If you have major issues, it's entirely appropriate to bring those to the Wednesday meetings
Process
<Brent Zundel> https://
Brent Zundel: Links to the classes of changes. 4 of the 5 apply to the docs we're working with
… the first is stylesheet/white space changes. No change to text
… class 2 is editorial changes. No effect on the function of the doc. Correcting examples etc.
… If there's any doubt that a change is class 2, then it becomes class 3.
… Class 3 doesn't add a new feature but does make a substantial change.
… Class 4 is new features. No class 4 changes are in scope for docs we're maintaining.
… Our charter lists the ones we're maintaining
… in the new work we're doing, anything goes.
<Kayode Ezike> Re VCALM update: We have also merged our first version of the threat model since the last call. We will be iterating on it shortly and regularly.
Brent Zundel: Class 3 changes may be OK in response to bugs or errata, but in general, no, we can't do those in maintenance mode
Brent Zundel: We're going from a 1.0 to a 1.1
Michael Shea: Thanks. If any change is required because of task force that is using CID, is that class 3?
Michael Shea: How does that get classified?
Brent Zundel: That's where things get fuzzy
… We are chartered to maintain. If we're chartered to work on a new item that depends on a doc we're maintaining... the delineation between specs is not that clear cut.
… We do have a good deal of leeway.
… We'd need to have a full WG agreement to make a spec change to a maintenance doc and we'd have to discuss. We're both chartered and not chartered to do that.
Render Method
Brent Zundel: Is there anything render-method specific that would benefit from the WG's attention, great. If not, we'll look at them all
Dmitri Zagidulin: Overall - there are 3 current PRs open, they're waiting on decisions.
… We have a bunch of stuff that has consensus and some we're arguing about.
… We have consensus. Time is limited of course. We have 3 categories of render method. 1) Static -at issue time, the issuer pre-bakes 1 or more rendered version. Can be a pre-rendered PDF, PNG etc.
… We def need to cover that.
… Category 2 is to do with data view/list view/item view.
<Kayode Ezike> Re render method category naming: We now have this issue to track this: w3c/
Dmitri Zagidulin: That's where the issuer says: if you're displaying these in a list, when it doesn't make sense to display the full list - here are the fields that are importantr for the cred.
Dmitri Zagidulin: The current example in the spec of a static render, is the NFC. The 2nd category, it's the JSON Card view
… But the principle is the same; select a small set of fields. This one's emphasis, bold etc.
Dmitri Zagidulin: The 3rd type - there's some disagreement in the group - that's the HTML view. That's the full-on render method.
Dmitri Zagidulin: We know that there will be fields in common. Type, subject etc.
… then we have specific details to think about.
Dmitri Zagidulin: For the HTML view, a full on JS/HMLT app sandboxed in an iframe. The other contender is a mustache HTML template
… The HTML is provided and field values are substituted (with the {{...}} notation)
Dmitri Zagidulin: This is on contrast to the iframe snadbox which boots up a full HTML/JS app that handles everything
… One of the points of contention is whether JS should be allowed. Sandboxed, but still. The other point is what to do for the print to PDF use case?
… The HTML/JS app in an iframe sandbox proposes a mechanism for the app to put together a transformed payload via a iframe POST method to the client so it can be printed.
<Kayode Ezike> Another point of contention is the fidelity (or lack thereof) of the mustache spec.
Dmitri Zagidulin: Approach 2 is the template approach. The consuming client can do some substituting
<Sebastian Schmittner> To throw an example for what Dmitri Zagidulin is talking about:
<Sebastian Schmittner> this showing an example of a rendered mustache template for an svg, which is essentially another version to sandbox html: https://
<Sebastian Schmittner> https://
<Sebastian Schmittner> {
<Sebastian Schmittner> "template": {
<Sebastian Schmittner> "id": "https://
<Sebastian Schmittner> "mediaType": "image/svg+xml"
<Sebastian Schmittner> },
<Sebastian Schmittner> "renderSuite": "svg-mustache",
<Sebastian Schmittner> "name": "SVG for web display",
<Sebastian Schmittner> "type": "TemplateRenderMethod"
<Sebastian Schmittner> }
<Sebastian Schmittner> But if this is according to this groups standard is very much under discussion as far as I can say ;)
Dmitri Zagidulin: For the static methods, we need an NFC method. Can define a PNG or whatever
Dmitri Zagidulin: We only need one JSON Card example
Dmitri Zagidulin: Main disussion is in the HTML detailed view, which oif the 2 approaches to take. That takes us into the Threat Modelling discussion.
… Other TFs are doing the same. We're hoping that the list of threats will allow us to point to the trade offs
Dmitri Zagidulin: That's the snapshot
Subtopic Issues and PRs
w3c/vc-render-method#39
Issue 39
Dmitri Zagidulin: That's the list view/item view in JSON Card
Dmitri Zagidulin: So this is the current PR that is going to collect all of the fields for the list view/JSON Card View
… Comments welcome. This one is less contentious.
Dmitri Zagidulin: The other two open PRs...
Brent Zundel: The JSOn Card render method - if I open my wallet, I'll see a card-style presnetation.
Dmitri Zagidulin: Yes, that's what we're trying to emulate, that constrained space
Dave Longley: The key feature is for the issuer to highlight the important fields
… And then the client can style it as they see fit
Dmitri Zagidulin: What's the minimum no of things we need to display. That's about it
… That's what most wallet approaches have reinvented
Other PRs
Dmitri Zagidulin: The other 2 PRs are waiting on the resolution of the HTML issue
… Hoping to unify
<Brent Zundel> w3c/
Dmitri Zagidulin: One PR 49 is waiting on the HTML discussion
Dmitri Zagidulin: Those are the main things that it makes sense to look at today.
Brent Zundel: For those on the call who don't normally join the RM TF. If that sounds interesting, please feel free to join the TF. All are welcome to look at the issues and PRs of course.
<Dmitri Zagidulin> https://
<Dmitri Zagidulin> ^ threat model brainstorm
Dmitri Zagidulin: I want to post a link to our threat model brrainstorm - we need more eyes on that
Brent Zundel: Any more comments on this topic?
VCDM 2.1
Brent Zundel: This is the maintenance of our core data model
… the first thing to look at, is PR 1629
w3c/vc-data-model#1629
Brent Zundel: This deprecates DigestSRI as an option. Several approvals but some objection bc there is an implementation that uses it.
… If you have not engaged on this and have a view, please do so.
<Brent Zundel> w3c/
Brent Zundel: In terms of spec maintenance, this is probably the major issue
Brent Zundel: I believe neither Manu or Shigeya are on the call. They're the prime people for and against
w3c/vc-data-model#1634
Brent Zundel: This one we're looking at because it's un-triaged. Terminology
… Two processing modes are mentioned. We're not proposing a re-opening of that conversation. This is asking rather than framing in terms of JSON vs JSON-LD should we use different terminology
Brent Zundel: IMo this could be addressed as a editorial change. What do others think?
<Dave Longley> +1 sounds editorial
Brent Zundel: If no objection, I'll add a class 2 label
Brent Zundel: If there's anything folks want to say, please jump on the queue
Brent Zundel: Should we rename? Makes sense to me
Dave Longley: I think the spec currently calls it general vs type-specific. We no longer call it JSON vs JSON-LD. SO is there a better name than the spec currently has? I do think it's editorial
Phil Archer: You and I talked about this. We are looking for an editor for the VCDM spec.
Phil Archer: We are looking at who has been and has been active and we could use another name. We could use another name for political reasons so we have another person working for another company on that spec. We need you, thanks!
Brent Zundel: TO be clear, there is an ask for additional editorial support for VCDM 2.1
… You can do it by telling the chairs, or you can just start writing PRs
<Dmitri Zagidulin> I'd volunteer, but I'm Invited Expert, and I suspect a member company person is needed for editor
w3c/vc-data-model#1619
Brent Zundel: In that case we'll look through the other open issues for maintenance
<Dmitri Zagidulin> ok sweeet
Phil Archer: Yay!
Brent Zundel: Reads the issue aloud
Brent Zundel: raised in Feb. It's ready for PR - maybe someone else wants to raise the PR
… Any concerns/comments?
Ted Thibodeau Jr.: I would suggest we re-ping the originator of the issue
… They may not feel the need to say "I'm working on it"
… But if they don't, then OK, we need to find an alternative
Brent Zundel: OK, I'll ping them
w3c/vc-data-model#1592
Brent Zundel: helpful comments in the intro.
… Some recommended changes to reduce confusion. Class 2 editorial changes. We have talked about this a few times. This is an ideal issue for a new editor to jump into
Brent Zundel: Dmitri?
<Dmitri Zagidulin> yesss go ahead
Brent Zundel; Awesome, thank you.
w3c/vc-data-model#1583
Brent Zundel: As en editor, you get to suggest the editorial direction that hte group can then review
Brent Zundel: This is about restructuring our security section. I think this is under way in our threat modelling
… Once that's done for the other TFs, this looks like something that can follow on
Brent Zundel: Does anyone know how that's going?
Joe Andrieu: I don't think anyone's assigned to this. Individual TFs know they have to do it in their work but no one has it assigned to them for the VCDM
Brent Zundel: Is there anyone who wojuld be willing to be assigned to this issue? The task now is "keep an eye on the the modelling in the TFs"
Joe Andrieu: I'm happy to do that
… It depends when we need to start but I can keep an eye on what's happening and when it's time, ask me again and we'll see hwo things are
w3c/vc-data-model#1632
Brent Zundel; Remove render and confidence models from the VCDM as they're being developed in separate doc. It's class 4 but we can do it within the charter as it comes from the new work we're chartered to fo.
Brent Zundel: Right now the spec talks quite a bit about these extension points.
<Dave Longley> +1 to Joe's suggestion
<Dmitri Zagidulin> +1 to what Joe is saying -- we should definitely still point to that the properties exist
Joe Andrieu: My though is that we should still clarify that the properties exist but we shouldn't define them in the VCDM and just point to the other docs for those defs
Phil Archer: +1 to Joe
Brent Zundel: Hopefully this gives Ivan the guidance he needs to raise a PR
Brent Zundel: We have talked about all the open issues that are within scope
Brent Zundel: That means we're done for this week.
… Any other topics?
Brent Zundel: thanks scribe and Dmitri Zagidulin
Brent Zundel: See you next week