Meeting minutes
manu: A five minute request on meeting records and moving over to the new auto-transcription thing as a part of the new charter -- wanted to get a request out and see what the group felt and then we can move on.
brent: Sure, I'm ok with that, take it away.
recordings?
manu: We have been ... for the spec refinement calls, we've been trialing this new infrastructure that uses Google Meet and recordings and auto-transcription.
manu: We've been using new infrastructure, it also generates HTML minutes for archival at W3C. I think it's been working fairly well, I'd love to hear Ivan if you think it's been ok. We can auto-check in the minutes as well. This is a request to move to that new infrastructure when the new WG starts up.
manu: Thank you, Brent, for sending out the new process ... and I think this all aligns, and this saves people scribing which can also take people who scribe out of conversations.
manu: I don't feel super strongly about it, if we want to keep scribing in IRC we can, but I wanted to make the suggestion and see if anyone would fiercely object.
brent: No one on the queue, I think it's fine. The only thing the process requires is making an announcement about it before the meeting saying we'll be recording and auto-transcribing -- and if we get objections we'd have to fallback to the traditional manner.
<denkeni> related discussion: https://
<denkeni> https://
<denkeni> https://
ivan: I am a bit doubtful about this to be honest. Because the spec refinement meeting is very different. It's an informal meeting. In the case of the WG calls, this is cases where there are disputes this is the reference to review things. This is about management of resolutions, voting of resolutions, etc.
ivan: The auto-transcription sometimes makes hilarious mistakes.
ivan: I have to review those a little bit before I have to put it on the website, it does mean less work on my side but not zero work.
ivan: What I see coming out of the meetings, it's questionable, it's just the way things are not the tech ... things in the text say "you know whatever, etc." informal language noises that go into the minutes unnecessarily.
ivan: I'm not opposed but not in favor.
phila: There were two issues about this. The other sentiment I agree with for goodness sake. The scribe is typing away and I can sympathize with that. I wonder if running the output through an AI could take out the "ums". I've seen some astonishing stuff in just the last week from Gemini. I'm pretty sure tightening up minutes can be done and voice recognition improves all the time.
phila: If someone wants to type or say something in IRC that doesn't get recorded, put it into the zoom chat. Is it possible to pause transcription and then recommence? That would be great, we could tell it to stop recording and then restart it.
manu: It's possible to do it in the transcription, it's not possible to do it in the video and audio recording. They haven't gotten there yet, unfortunately. As far as telling it to be more terse ... the mode it's in right now is to write everything down. It can be more terse but it might misunderstand. We can also tell it to read the specs and use those to be better.
manu: The general question is "At what point is it good enough?" I would strongly assert that the machine is better than 50% of the scribes we pick.
manu: So, Ivan, I'm challenging your assertion ... yes, it does put some bad things in there with acronyms and so on, but the general gist of what's happening is accurate.
manu: +1 to what I think Brent is going to say, I'd love to know what needs to be fixed so we can move to something that's easier than what we do now.
<pdl_asu> +1 in that I think the AI can be trained (prompt sequence structuring). to get the terminology much more accurately.
brent: I know which 50% I belong in as far as scribing goes. I want to literally read what the process says about meeting minutes. "Groups should take in an retain minutes of their meetings and MUST make any official decisions. Details aren't required as long as the rationale for the decisions are clear".
brent: As long as we record all decisions and enough of the context prior to the decisions so the rationale is clear then we're clear, we don't need word for word minuting.
brent: The summary version of what Gemini can do would be sufficient as long as the decisions carry through.
brent: We're a little over time on that but glad we had the conversation.
ivan: I will be more specific on the things I'd like to see.
ivan: One is a proper section of the discussion. In the WG call we have to screen for the 15 different sections/topics that we discuss, the auto minutes gets it wrong.
ivan: That's a need.
ivan: Second we need very clear references to resolutions that we can refer to with a URL ... this is what I have to do.
ivan: We should have a way to combine it with the tool of Pierre-Antoine that leads to the github issue; I've seen the chair of the meeting sometimes typing into github issues for this and that shouldn't have to happen.
<manu> Yes, on each of those things -- I'll try to figure out how to accomplish each one of those using the AI infrastructure, ivan.
ivan: But those things being solved would go a long way for me for this.
<denkeni> Is it possible to have realtime transcription that can be reviewed during the meeting? That's one of the reason scribing helps.
Possible F2F
brent: The chairs were discussing the likelihood of the new charter being approved and in place sometime this spring and when it would be best for the group to get together.
brent: We are preliminarily looking one of the first couple of weeks of May in Brussels, for a 3-day meeting.
phila: I thought it was June, not May.
phila: But I think that would be possible.
phila: Do we want to talk about venues/hosting?
brent: Yes, June. Sorry. And Brussels, GS1, is offering to host.
<pdl_asu> June is better for the EDU crowd ;-)
phila: I got full greenlight on that, so if it would be helpful we can host this group any days in those first two weeks in June. Can't be the third week, first two weeks any 3 days there.
brent: Yes, and thank you for correcting it to June.
brent: We'll keep you updated as things progress there and it's very likely to happen given the current state of charter things.
Charter update
<ivan> charter draft
brent: As folks are probably aware we have a charter that we're moving through the W3C process to recharter the group to have a broader set of deliverables that we can work on.
brent: We've gotten good review.
brent: The charters go through a horizontal review process and all of those reviews have come back with "looks good to me" except the privacy review where there was a longer set of requests.
<ivan> Brent's answer
brent: A number of folks responded to that review, culminating in my response to the review, which was to summarize: thanks for the review but we don't think we need charter text changes in response, but the requests were about liaisons and adhering to proper principles, these things are in the charter already. There was also a request to bring in use cases to the charter and no other charters have done that.
brent: I think the boilerplate charter text covers all the concerns and no pushback on that so far.
<ivan> original comment
brent: So I don't know that we're in the clear, but I do know that steps are being made to move to the next stage. We've gotten review, we've responded to it, we're in the refinement phase and it will soon go to the AC, is my understanding.
ivan: Almost. This is the refinement phase that we're in.
ivan: The refinement phase goes until Feb 1.
ivan: That's how we announced it to the community. I will probably submit a request to the internal group that decides yay or nay for the charter sometime before the first of Feb 1, probably in 10 days ish.
ivan: So we can get everything done. We have one missing review, for which we have no reaction so far which is the TAG.
ivan: If they answer we will see what happens, if they don't answer in 10 days then I will submit.
ivan: To the internal group saying that the TAG had its timeout.
ivan: It would be nice if the TAG reacted somehow.
ivan: That's the timing and if everything goes that way then sometime in the first week of February it can go to the AC to see what happens.
brent: Thanks for that additional input, Ivan.
brent: If there are no other comments then we'll move on.
Confidence Method update
brent: We should have just enough time ... I plan to pretty strictly timebox to 15 minutes each, maybe 16 each thing and if one has less time to talk then we'll get more time, we'll start with confidence method.
brent: Confidence method editors, here is your time to share with the group on what issues to look at, if there's anything for this group call, I'm happy to handle queue while this conversation goes on.
JoeAndrieu: Thanks.
JoeAndrieu: I was going to queue up Denken, I can fill in the space. We only had one meeting between holidays and Japan. I still have the sense that I have to do a first draft to get to the DIDAuth inclusion and Denken is primarily focused on biometric support. We're trying to flesh out additional content there that's not there yet.
denkeni: We are trying to understand with the community wants to include more confidence methods, if there are any strong needs, please tell us or join the conversation. We have been discussing what to put in the evidence field vs. confidence method and we'll continue the discussion during the next call, that's it.
brent: Thank you. Any issues or PRs that would benefit from the broader group?
manu: This is regarding an issue I saw Brent comment in ... around adding Passkey support somehow. I just wanted to +1 that and I hope our first draft covers that ... basically being able to include a Passkey as a confidence method in a VC. I don't know what that looks like but sounds good.
dlongley: +1 to a passkey confidence method
manu: Yes to DIDAuth, yes to biometric stuff, yes to Passkeys ... those seem like good features for 1.0.
ivan: I think this is one of the documents where reaching out to the accessibility folks would be very beneficial because each of these methods will affect accessibility so we'll want to get that going as early as possible for feedback.
brent: Thank you, Ivan, that's good guidance.
brent: Joe and Denken you are good to reach out to them when you feel it's ready for their feedback.
<Zakim> JoeAndrieu, you wanted to say we'll need authors who understand passkey
JoeAndrieu: That's a great suggestion, thank you and I agree sooner is better than later. I agree Passkeys would be good and we need an author who understands that. We need to start with a limited set (feedback from TPAC) and then get a first draft.
JoeAndrieu: Denken has a use case and he wants to drive biometrics, but it's a PR accepted world and I'm worried about the resources on that.
<manu> agree with Joe completely.
brent: I am taking as an action item to interface with those at my company who know this area better than I do.
brent: It was an idle comment and I keep hearing Passkey everyday now and I was wondering if or how it would fit, I'm not sure if it fits, but there may be a way. We would need to be able to define the role and fit the FIDO2 protocols into this and I'd be on the hook for raising those PRs and adding that text.
<JoeAndrieu> +1
brent: It's good to hear that other folks would support it and the action is on me.
brent: That's the queue, we still have a little more time if there's anything else to discuss on confidence method.
manu: I heard Joe.. you say that you still need a first pass to get some stuff in there. Heard, good. I am also wearing of kicking off horizontal reviews so we can do those sooner than later knowing how long those can take.
manu: Do you or Denken have an idea of when we'd ask for horizontal review.
<Zakim> JoeAndrieu, you wanted to mention coordination about side meetings
<phila> +1 to manu
JoeAndrieu: I do want to do it sooner rather than later, but I think we need to get at least the DIDAuth bit written up and Denken's first pass on the biometric method because the specifics of those methods will be where the conversation will be with privacy/security, etc.
<brent> +1
JoeAndrieu: Once we have those things we can release to wider review.
JoeAndrieu: I also wanted to mention; we had have challenges with side meetings and logistics, meeting/not meeting, some of that was because of the holidays. Can we have a separate channel via something like Signal to figure that out -- it's been a little chaotic.
brent: There is an official W3C chat and there's a VCWG channel in the W3C chat to communicate those things if you'd prefer.
brent: There's an official informal channel that's available to use for these kinds of discussions.
JoeAndrieu: Do you mean in IRC?
brent: I mean on Slack.
brent: There's a W3C community slack instance where there's a VCWG channel that is available for us to use.
JoeAndrieu: Great, that is a fine solution and I'll use that in the future.
Render Method update
brent: If there's nothing more for confidence method we'll move to render method.
brent: So, render method editors can you give us the status of the group, etc.?
manu: So for Render Method, we had a proposal during this last call to do some unification around the HTML rendering method.
manu: And that was proposed on the call and there seemed to be some general consensus that we should create a PR and Benjamin has created that.
brent: You talked about unification around the HTML render method and for folks not on the call could you talk about that?
<bigbluehat> PR w3c/
manu: When the group adopted the Render Method spec there was SVG rendering, a Mustache render method, several types of rendering with HTML and other ways. Some of the implementation learnings that we've gotten from that were that the path we were on with SVG and PDF were going to be quite a bit of work.
manu: To define a templating language, the functions we could call in there, lots to define. Meanwhile, there was a clear desire of some kind of HTML rendering method -- that you could take the VC data, put it into an HTML page and do some magic and get one or more graphical versions of the VC.
manu: That's where we were. More recently there was a more unified design for an HTML rendering method. It wouldn't have to be the only one, but it would cover most of the use cases covered by SVG/PDF -- and that's what the discussion was about to see what that would look like.
manu: So that's kind of where we are, the PR is raised, we're looking for input and feedback. There is already an implementation (and demo), I think it's pretty nice and works.
manu: Number 1 with this, we can sandbox the entire rendering, we didn't think we could do this before, but we can through the Web platform now and it can't call out and phone home.
manu: So we can sandbox from network traffic and reporting back and sniffing and snooping.
manu: If we use HTML and JS we've got a great specification for this the Web platform.
manu: If we do this, then all the templating is up to whomever issues the VC. They can do whatever they want to and we don't have to specify that.
manu: You have to bundle it in your template, but those are common tools today.
manu: For the HTML render method then -- we wouldn't have to get into debates about the templating language, what the runtime looks like, etc. And because we use HTML you can output to SVG, PDF, etc.
manu: You can get the output we were looking for, you can get a scalable vector graphic or PDF and so on.
manu: So we've got a PR and once that's in we plan to deprecate the SVG and mustache stuff and so on and simplify the spec.
manu: At that point, we've got 3 different rendering mechanisms in the spec, maybe we can whittle down to just one at that point as well ... or we can keep all three for reasons.
manu: I think that's where we are, hopefully in the next couple of weeks I think we'll be ready for horizontal review.
manu: The other positive thing about this new HTML rendering method is that it has a very solid accessibility and internationalization mechanism there. You can just use the Web platform for those things.
manu: I think that's the high level, I don't know if I missed anything.
<phila> w3c/
phila: Just wanted to briefly say -- thanks for the folks working on this. I wanted to tell you about this issue. Sebastian Schmidt raised, he's in the CCG, not this group. We were talking about this on a previous call and this is related to our company's work.
phila: He has just opened an issue about the Mustache thing and said this might not be needed anymore and it would be ok to close it if this handles it, Sebastian won't mind.
ivan: This is more of a question ... this effectively means that to build a wallet for VCs that uses this, that wallet should internally use WebViews or different engines.
ivan: This is the direction that we're going?
manu: It's fair to say that that's the direction we're going. It's restricted in that it's iframe with a sandbox, etc. and that's in general the direction we're going.
ivan: Isn't it a possible a problem that the Web engine ... that WebViews aren't properly standardized and those are slightly different from each other and do we care about it?
manu: I think the current approach is leave that to implementers, we believe can define this very clearly using W3C specs.
manu: The way to think about this is that this isn't just about Wallet vendors. Websites can also render this. Anyone who wants to provide a graphical (or otherwise) depiction of the VC.
<denkeni> We have WebView Community Group in W3C, and they have some information for it.
<denkeni> https://
manu: It would be good to get inputs from wallet implementers but also verifiers, etc. Not limited to wallets. These Web engines are available on every platform that we know that would want to display a VC.
<ivan> yes, denkeni , but I am not sure how active they are
manu: If it's on Android or an iPhone it's got access, a website has access, etc.
manu: We think that the infrastructure is broadly available, interfaces aren't always the same, but good luck getting them to agree on an OS-level interface.
manu: That's it.
<Zakim> brent, you wanted to ask about liaising with wallet vendors
<denkeni> They had a meeting in TPAC 2025 Kobe, and very active from that meeting.
brent: Thanks, Manu, you partially answered the question I had -- I know that Apple and Google and Microsoft and other folks are meaning to engage with Verifiable Digital Credential-like things and have interest in displays that is consistent across platforms and things like that.
brent: My question is -- is anyone in contact with people in those orgs about this at all?
brent: I believe we are producing something that we believe will be useful but have we asked them about rendering? We produced our data model and it's amazing and useful and now we're saying "here's how it should show up on the Web" and do we have enough people there?
manu: The short answer there is "yes, for certain kinds of ecosystems". We're talking to gov'ts with their own wallets, the education industry, the retail industry and those industries see this as a fine path to go down. Haven't always gotten a clear answer in other places necessarily.
manu: The answers we've gotten back sometimes are "Big company wallet is in full control of how we render credentials and if there are other ways to do it we will consider it". Remember that render method is optional -- and that's up to the displayer to use it or not.
manu: Wallet providers might decide to have its own primary display and then fallback or even not use render method.
brent: Thank you Manu.
ivan: Is it necessary or useful to have something in the coordination section on other groups and referring to this core area of concern or we can forget about it?
ivan: We have a reach out to the FedID WG but it's only on the threat model, etc. Do we want to add something there? Was that the group or some other group?
brent: I didn't have any particular group in mind. I'm not opposed to adding any particular group to the charter.
<Zakim> manu, you wanted to say "rather not" to "wallet vendors" or other things that broad review should cover.
manu: We (Digital Bazaar) are working with at least three different industries that will almost certainly ship this HTML renderer to production. If we had concern that we would build something that wouldn't ship, I don't think we need to worry about that.
manu: I think one of the challenges with the HTML thing -- and the other rendering thing we've been discussing is a "Card summary rendering mechanism" that could address this belief that you have to lockdown the "allowable credentials" in an ecosystem because if you don't then there's no way to know what to show or present, etc.
manu: It is a legitimate concern: "How do we show the user what they are getting ready to share?" I don't know if the HTML render method can help there, but I do think we should reach out there. I think that's good and positive and we should do that. Understanding that the specific problem with, for example, DC API sharing, telling people what they will be getting ready to share in a generalized way where the person understands what they are
sharing is difficult. Especially if a VC has something like a 100 fields in it.
manu: That's it.
phila: I share concerns there, but that process or idea does occur in other places. Verifiable trade documents and UN transparency protocol -- see Steve Capell on this -- there are some global bodies and accreditation orgs belong -- existing thought processes almost match, "here are the credentials we trust and know" and there's a registry that can be added to and no single org or mega corp should decide what that list is.
phila: Edging around this and these discussions ... registries might be able to help deal with this in a more decentralized way.
brent: We have a few minutes left possibly if we have anything else -- grateful for the updates we got. I think we're done but open for not being done if there's something else for a minute.
brent: Thanks, Dave, for scribing, thanks everyone for being here, see you next month, hopefully more clarity on timeline for the charter and can make some more decisions, keep up the good work, thanks all!