Meeting minutes
Phil Archer: Lets get started
… I am Phil Archer, I work for GS1. Brent has been chairing this group for a while. I am joining him.
… The first thing we will be talking about is the conversation on rechartering
… The current charter ends at some point
… We need to discuss what we want to work on in our charter
… After the break we will talk about confidence method and render method
<Joe Andrieu> charter end date: 2026 October 11
Brent Zundel: Explains that there will be a 10 min discussion about the process just before the break
Brent Zundel: We'll talk about the proposed new charter
Phil Archer: There is a list of possible work items at https://
recharter
Manu Sporny: I have 2 other links. The CCG has bene incubating a number of specs over years
… some over 5 years+
… so we may want to bring those into the charter
Manu Sporny: We ran a poll in August to get feedback to see who thought what was important
Manu Sporny: We have results from that poll (39)
<Manu Sporny> Results of community poll: https://
Manu Sporny: Good number of people said they wanted to be in the VCWG
Manu Sporny: Shows graph of results
Brent Zundel: The results for the top two - render and confidence - have already been adopted and are being worked on. So the question is how much more do we want to adopt
Manu Sporny: Render method is about how do you visualize a VC. You can also render to audio, an image, braille, NFC etc.
… Convert a cred into some form. It's about giving issuers control over what their cred looks like in a wallet. A gov ID card, for example, will want their logo etc.
<Brent Zundel> render method will be of interest to the Accessibility folks
Manu Sporny: Confidence method helps you as a verifier understand who originally received the cred.
Manu Sporny: You want confidence that the person showing you the cred is the right person. A crypto challenge might be one way. I'm sending you a challenge, you send a reply
Manu Sporny: But a confidence method might be a biometric match, account access etc.
Joe Andrieu: I'm an editor working on this now. The current charter limits us to one method. I want us to have the freedom to have separate docs for each type of confidence method
Manu Sporny: +1 to that
Manu Sporny: Next one if the VCALM - Life Cycle Management
Manu Sporny: if you're an issuer, what API do I call, revoke, etc
<Joe Andrieu> btw, the "limit" on confidence methods is about timing not scope
Manu Sporny: We find vendors doing a lot of proprietary APIs for this. So we want to avoid vendor-lock
Manu Sporny: Basically, this is all about HTTP APIs for VCs
Manu Sporny: VC barcodes. This is about taking a VC and putting it into a QR Code or PDF417
… California currently putting a VC on the back of every physical licence they're printing
Manu Sporny: So this is already in production. We can still change the spec but they're being used on paper docs to help make them more trustworthy
Manu Sporny: Birth certs in the US is another use case
phila q+
Manu Sporny: So VC barcodes are about compressing them and putting in a doc and printing
Brent Zundel: It concerns me that this has been deployed but hasn't been specified yet. Even in the CCG it hasn't had much attention
… That's a concern
Phil Archer: for me the use case is conformance certificates, waybills, etc.
… however, in the realm of conformance testing, there are folks who say, even a barcode isn't enough.
… wish someone from singapore was here as well
Joe Andrieu: A modest push back on Brent's concern. Implementation is an important aspect of standardization
Manu Sporny: I hear what Brent says. It didn't get a lot of attention in the CCG. It's come mostly from the SVIP/DHS in the US
Manu Sporny: The California DMV saw the value and knows it's not yet standardized and that this group may change it and they'll be able to adapt accordingly
Manu Sporny: Yes, it would have been ideal to standardize before adoption in some ways but we are where we are
Denken Chen: Printed cards can't be bound to holder
Denken Chen: Is it reasonable to keep an image on a physical card?
Brent Zundel: Now that we're looking at specs not yet in our charter - shall we go through the spreadsheet now or go back later
Brent Zundel: VCALM - string indication of importance. Some people saying they'd be happy to be editors
Manu Sporny: Gives names of two people who are not currently here for VCALM
Manu Sporny: We already have 11 config files in the test suite
Denken Chen: Was asking about why the DMV was so interested in the barcode stuff
Manu Sporny: It's fairly trivial to create a fraudulent licence today. Including a barcode that can provide an illusion of veracity.
Manu Sporny: You can verify it but a lot of people don't. California DMV wanted to try and avoid that kind of fraud. There's an active illegal market for them.
Elaine Wooton: I'm an IE. I retired at the end of March from the DHS. Expert in fighting counterfeiting. Something digitally signed, printed on the doc is important
Elaine Wooton: Original plan was secure printing. But now the forgeries are as good. So we want something cryptopgraphic
Denken Chen: Is the portait included?
Elaine Wooton: There are some clones that just swap the photo. [Talks more about the problem, details missed]
Elaine Wooton: Possible to include low-res image
… Not 100% but better than nothing
Brent Zundel: Jumping back to VCALM
Brent Zundel: Who *in the WG* is likely to be an editor from the WG membership
Manu Sporny:
<kmoon> When we would like a thing, e.g. product, to have a sort of information, it kind of makes sense to using verifiable credentials in the barcode format. (Though I understand it is not the best way to do so.) We actually did some PoCs with some companies like that.
Brent Zundel: Goes through needs for VCALM and fills in the spreadhseet
[Discussion of filling in the spreadsheet for barcodes]
Brent Zundel: Back to the poll - VC over wireless
kmoon: From NTT. Talked about an insect-based snack. Looking for proof of certification
kmoon: It's a use case
Phil Archer: I'll put you in touch with GS1 Japan
Manu Sporny: VC over wireless - use case is first responders
… Want to be able to tap into a secure zone. Keep people not supposed to be in the zone out.
… need to be able to transmit VCs without internet connection
Manu Sporny: Some challenges to the spec. Not much incubation, but there's not a lot to do. NFC tap will do it. Bluetooth looks fairly easy
… There is Web NFC as a W3C spec
… some implementation but not all browsers
… so there would be work to go beyond pure NFC. Use case is important
Brent Zundel: How does this work relate to OID4VP over bluetooth.
Manu Sporny: AFAIK, it hasn't made much progress in the last few years
… The NFC portion is very different from the Bluetooth
Manu Sporny: NFC max payload is limited to under 1K, Bluetooth can be MB
Brent Zundel: But the Bluetooth part - is it approx the same capabilities?
Manu Sporny: Theory is that the protocol will be based on VCALM
… but there's a question about the params in Bluetooth
Brent Zundel: This spec in particular - the family - looks like a departure from what the WG has done. We've done data models, not protocols. Exciting but it might create pushback
Brent Zundel: This would be a biggish shift and we need the right people
Manu Sporny: We have some volunteers but will have to check if they're WG members
Manu Sporny: VC Refresh
… What does the wallet do if the VC is approaching expiry.
… Want to avoid manual process if it's not necessary. Hope is that the wallet can do the entire refresh process itself
Manu Sporny: Demand fairly high. Decent number of people saying they'd implement but no volunteers to edit
Manu Sporny: It's not a difficult spec. Would be a good training ground for new editors!
… This is what TruAge uses today and California DMV uses
Manu Sporny: So we have good experience and implementations
Manu Sporny: It's really Connexxus and truAge who have the experience
[Discussion about TruAge/Connexxus being editors]
Manu Sporny: Quantum-safe DI Suite
Manu Sporny: How do we create crypto that is resistant to quantum computing
Manu Sporny: We are a good way towards this with existing work [Names some]
Manu Sporny: Some post-quantum signatures are thousands of times larger than current ones. Some work on a small-footprint (Ski-Sign?) looks promising
Manu Sporny: I don't think we'll get there in the next charter. We could poss do a FIPs/Two FIPs.
… There is draft spec and some editors but they're not in the WG. At least three implementers
[Some details added to spreadsheet]
Manu Sporny: It's important to us to get that work done. We get asked about it by our customers.
Brent Zundel: The JOSE capabilities that are already a Rec will automatically make use of the IETF specs so we're already covered (it can be argued)
Manu Sporny: Verifiable issuers and verifiers is about verifiers being able to check issuers of credentials against some authority
… For example in the US there are 56 jurisdictions able to issue drivers licence. As a verifier of licences in the US you would be able to refer to some list and check the issuer against that list
… There are many other such examples of known entities able to make specific attestations
… This spec is about how you make these lists, how you publish them
Manu Sporny: In the EU there is going to be lists of organisations able to ask specific info from issuers
Joe Andrieu: We need to be able to layer on other authorities. E.g. for the driving licence case, it wont just be the US jurisdictions but it might include international entities too
Joe Andrieu: We need a mechanism to layer this on
Brent Zundel: I wanted to ask if folks in the group are following the ToIP and the trust framework work going on there
Manu Sporny: I dont think we are tracking that well at all. DavidC and Dimitri is working on this
Manu Sporny: +1 we should look into this
Brent Zundel: A lot of work went into this, lots of consensus and diagrams in that group. We should learn from them
<kmoon> I've working on verifiable issuers with some research institute and organization. I think this one is especially important for cross ecosystem use cases.
Manu Sporny: dmitriz you have a set of use cases about verifiable issuers and verifiers. Brent mentioned the TOIP folks have been working on similar stuff for a while
… Have you had any contact with TOIP
Dmitri Zagidulin: I have a bit. There was a join project around comparing issuer registries that looked at the TOIP spec
… We can reach out specifically and coordinate with those groups to see where the intersections are
Phil Archer: That sounds positive
… Yesterday we had a conversation around trusted verifiers and issuers
… I think this is not enough on its own. It does not scale
… The talk yesterday about cross border trade includes millions of credentials a day. There isn't always a list of issuers, but many entities can add evidence to your claim
… One VC is often not enough
… You want to present a bundle of VCs together from different issuers.
… The ask from me is to possibly add a class 4 change to the data model so a generic verification model could check multiple VCs
… This spec looks like the closest thing we have on the list to doing that. Maybe it fits in here
Kevin Dean: Expanding on Phil Archer, we looked at the verifiable issuer through the lens of the issuer having a specific credential
… Because I have this credential, I am authorized to issue these other types of credential
… E.g. in the case of a diploma from a university, this implies that you know who the university is. This is not scalable. You don't always know all the universities that exist
… But, an accreditation body could issue credentials to universities. This could be included in the diploma credentials they issue. Creating a chain back to the source accreditation body
… Allowing verifiers to tell that a diploma was issued by an authorized education body
Dmitri Zagidulin: Phil Archer, your description sounds like a verifiable presentation to me
Brent Zundel: Lets not get too into the details in relation to the verifiable issuers and verifiers spec
Phil Archer: I understand your point Dmitri Zagidulin, but I think there are potential issues
Shigeya Suzuki: We are working on the originator profile. One part of this is securing documents from the originator, which is the signer
… The other side of this is annotating about originator attributes from certified parties
… We use this related to news. Some newspaper organisation belongs to a specific group
… We are looking into the use case of applying this technology into banking
… In this case, end users want to verify that a issuer is a bank.
… Multiple third party providers can issue credentials to attest to specific issuers
… We have open source the code for this. It is based on Verifiable Credentials
… We have a conceptual document defining how multiple third parties can annotate issuers
<Shigeya Suzuki> https://
Joe Andrieu: phila mentioned that we are likely to want class 4 changes to the VCDM. I am wondering if there are any other changes that might be required by other specs
Manu Sporny: Yes, we should leave the door open for class 4 changes
<Shigeya Suzuki> Code; originator-profile/
Joe Andrieu: Are there any other specs with obvious areas we might require a change
Manu Sporny: no
Brent Zundel: I think potentially
Manu Sporny: Yes it is definitely possible, but chances are low for the other specs we have talked about today. The verifiable issuers and verifiers has a high chance of requiring changes to the data model
Brent Zundel: There are three implementations of the verifiable issuers and verifiers spec, with broad interest in this area
Manu Sporny: It would be very interesting to pull in the originators work
Brent Zundel: Editors?
Manu Sporny: David Chadwick will, dmitriz can you>?
Dmitri Zagidulin: I am happy to contribute, not sure I have the bandwidth to coeditor
Phil Archer: You can put down GS1 and PYZ
Phil Archer: Thanks Will Abramson
Brent Zundel: We have had interest from a possible Chinese (SM3/SM4) Data Integrity securing mechanism
Brent Zundel: They received the usual call for editors, commitments etc. Might happen in the Chinese WG sperate from VCWG
Brent Zundel: [Talks about how we can advance the charter]
Brent Zundel: Would like to see an order of action in the charter
Brent Zundel: We need some rough agreement on how to run the WG
Shigeya Suzuki: I have previously proposed multilingual text outside the VC
… We saw that the developers really don't want to use JSON-LD-style encoding inside the VC for multilingual text
… maybe have two separate VCs, each in a single language
… these could be linked and shown as equivalent
… Need to find a better way to make developers happy
… I din't have specific proposal just yet but want to look into it
… I'd like to discuss this if possible in the WG
Joe Andrieu: Support for multilingual, sure
Joe Andrieu: Are we talking about the charter or immediate adoption?
Brent Zundel: We can't adopt any of these under the current charter
Joe Andrieu: Can we extend an existing test suite rather than set up separate test suites
Manu Sporny: MOSIP, in India, has issued 100M VCs. They have an OS platform. Multiligualism is an issue, especially for render methods
… They have to render in English, Tamil and more
Manu Sporny: Hopefully i18n wil come out of the render method work
Manu Sporny: Yes, we could extend the existing test suite but we can't/shouldn't get ourslelves mixed up with protocols
… may or may not need a separate test suite
Manu Sporny: I'd also like to propose an order.
Manu Sporny: VCALM already has a lot of implementations so it's probably on the top.
… VC over wireless needs more editors and time. Important use case but we might not have the people
Manu Sporny: I wish we had more people to work on the post-quantum, so maybe that goes into the optional section
Manu Sporny: Barcodes - we're late. Let's get on with that
Manu Sporny: Verified issuers and verifiers - looks like we should work on that.
Manu Sporny: refresh - it's out there but we need more people
Brent Zundel: So we have a proposed prioritization
[recorded in the spreadsheet]
Brent Zundel: No one is saying that we should not recharter. So let's move forward with that.
Brent Zundel: We have a proposed division of work. Three are prioritized. Three if we have the capacity
Brent Zundel: So the question is: do you agree with this division. It works for me
Brent Zundel: I can see refresh as the top of the tentative list
Brent Zundel: Speak up if you;d like to propose a different order
Shigeya Suzuki: Manu mentioned MOSIP. I know they can handle multilingualism.
Manu Sporny: +1 to that
Manu Sporny: Working on render method will force us to work on multilingual. But, as shigeya says, it can't be the only way
Shigeya Suzuki: We need a way to select which language will appear - could be field by field
Brent Zundel: I'm not hearing anyone speak out against the proritization.
<Kevin Dean> https://
Render method
Phil Archer: we have 5 open PRs
PRs https://
w3c/vc-render-method#24
Dmitri Zagidulin: it's a minor typos, has approves no comments
… propose to merge that
Phil Archer: hearing no objection, do it
w3c/vc-render-method#35
Dmitri Zagidulin: unless there is an objection, I suggest to merge
[no objection]
w3c/vc-render-method#25 and w3c/vc-render-method#30
Dmitri Zagidulin: those were discussed previously
… a proposal was to introduce in the core spec itself
Brent Zundel: do you mean the core data model?
Dmitri Zagidulin: no, the render spec
… that will describe a generic render method, then we would have additional specs for specific methods
… let's look at w3c/
… the properties it introduces are general purpose (name, digest multibase, version)
… any method will need those
… So I suggest to wait on this one, as well as PR 25
Brent Zundel: to clarify: this method is introducing things for a specific render method
… what you propose is to create a separate PR introducing them on the generic render method
Dmitri Zagidulin: correct
Phil Archer: reminds me of a discussion I had a long time ago with Mark Nottingham
… about registering a link relation type; Mark pointed out that the link relation type does not give you the media type
… a given VC may have several render method
… having an specific OCA method feels wrong
Dmitri Zagidulin: my understanding of the PR is that it proposes a "super class" of OCABundle
Phil Archer: that feels right
Manu Sporny: the current way the specification is structured is: we have an extension mechanism, called render method
… we are going to define the generic mechanism, and propose a few concrete ways to use it (PDF, SVG...)
… this is an enormous amount of work
… can we at least prioritize the order in which we go into these things?
Manu Sporny: I don't want us to take 2 years to get Render Methods 1.0 published
Phil Archer: difference between linking to a render method and embedding
Joe Andrieu: we want to get one, to be able to go to CR
… knowing which one is the 1st one is important
Dmitri Zagidulin: this is a good segway to look at PR 36, which emphasized that the spec is an extension mechanism (as manu_ and JoeAndrieu said)
… I love the idea of "let's take one"; agree with JoeAndrieu that this is going to be a difficult conversation
<Dmitri Zagidulin> we've implemented the HTML template, at MIT DCC. (we started with SVG, but ran into line wrapping probems, and switched to HTML)
Dmitri Zagidulin: SVG and HTML are widely applicable, but maybe not the ones with the most implementations
Phil Archer: as GS1, we use SVG and would like SVG to be in there
… any opinion across the room?
Dmitri Zagidulin: dare we bring up the dreaded word "registry"?
… We should not prioritize now, but this discussion is related to deciding what to do with those PRs.
… Let's leave 20 and 35 open for the moment.
w3c/vc-render-method#36
Dmitri Zagidulin: I made a pass on it, please have a look and tell if you think more is needed
Phil Archer: I strikes me as straightforward. I think we should merge, and anybody with a problem can suggest further edits.
Manu Sporny: It is not only an extension mechanism.
Phil Archer: it is an extension of VCDM.
Dmitri Zagidulin: question to manu_ and the group: could specific render methods (PDF, other...) be separate specifications, just like for DI?
Manu Sporny: let's not do that, this will give us too many specs to publish
Brent Zundel: note that we have the freedom to break out a spec listed in our charter into separate documents
Joe Andrieu: +1, let's start with one spec; creating new documents creates overhead
Dmitri Zagidulin: agreed
Phil Archer: proposal "this document is an extension of VCDM, and here is how you can extend it yourself"
Dmitri Zagidulin: that seems reasonable
Joe Andrieu: this is also defining not just an extension of VCDM but an extension mechanism for render methods itself
Phil Archer: with that in mind, I have no problem with merging this
… we may want to extend it further
Dmitri Zagidulin: should I merge now, or do we have to pass the 7 days review perdio
Manu Sporny: seems editorial
Phil Archer: let's move on to the issues
w3c/vc-render-method#26
<Dmitri Zagidulin> w3c/
Dmitri Zagidulin: I don't think this is a class 4 change
… it just reuses @@
… it defines a kind of "mixin"
Manu Sporny: you might be concerned about the class-4 change, but we are allowed to do that, as this is a new spec
… and it *is* a new feature
Brent Zundel: +1 to Manu Sporny, class 4 only matters for specs we are maintaining
Phil Archer: it feels to me likely that we are heading towards a possible solution in which each VC is monolingual, pointing to equivalent VCs in other languages
Dmitri Zagidulin: that's interesting
Shigeya Suzuki: it is possible to have different VCs coexist, that differ only in language of the text
… this is what we do in Originator Profile
sounds like property names in other languages are a Render Method thing, but property values in each language would need to be different VCs?
Shigeya Suzuki: we need to look into the use-cases to determine the best solution
Phil Archer: this is a complex issue, you need to think about the field names, not just the field values
Manu Sporny: +1 to studying use-cases first
… especially use-cases that have been deployed largely
… I would push against multiple VCs differing only in languages, this would not scale up
… I would like to step back and have the discussion on what we want to prioritize
Joe Andrieu: I want to suggest a different mechanism
… the RDF claims are mostly language independant
… we could have a lookup table that would allow us to deal with locale, not just language
… it could even specify different render methods
<Shigeya Suzuki> +1 to needs to consider locale
Dmitri Zagidulin: Joe Andrieu, hold on to that thought, we are going to come back to it
… yes, we need to prioritize
… +1 also to start with use-cases, but how do we do that procedurally?
benoit: about language: my drivers license is in French, but any value is in fact an enumerate
… is there a way to have translation for each value of these enumerates somewhere?
Phil Archer: this is exactly what JoeAndrieu was proposing
benoit: then +1 :)
Manu Sporny: we need the i18n WG to discuss those topics, we are not the experts
<Shigeya Suzuki> +1 on A11y
Brent Zundel: throw a couple use-cases in the spec, that's easy
… also, we need to talk to the i18n, but also to the accessibility people
… they are expert in communicating information to many people
Phil Archer: I don't think we are ready for full horizontal review, but that does not prevent us from inviting those experts to one of our calls
Dmitri Zagidulin: very good point!
… Another point: we focus on templated render methods,
… and parameterized method, where one parameter specifies the media-type, and another specifies the templating mechanism (handlebar, etc...)
Manu Sporny: +1 to that as a basis
… I'm concerned about HTML, because of security/privacy issues
… someone could include a tracker img tag in the template, so that someone knows everytime you display your drivers license
… or some javascript code
… sandboxing might be a solution, but not sure it is an option
… PDF, SVG are other safer options
Dmitri Zagidulin: I don't think PDF is an option
… we can generate it from HTML or SVG, but can we template a binary format directly?
… also it is turing complete
Brent Zundel: could we just simply define a subset of HTML that has no img or JS?
Phil Archer: we can not prevent people from doing things.
… Possibly we can limit it.
… A sensible thing would be to just say "you should not do these things in HTML"
Manu Sporny: to Brent Zundel, if an HTML method has to be done, we should do it
… rather than let people do it who are less careful about security
<Dmitri Zagidulin> @manu - haha, very valid concern
Manu Sporny: there will be great impacts on the whole ecosystem
… ok to start by saying "do not do that"
Manu Sporny: then maybe talk to the browser people what solutions they have
<Dmitri Zagidulin> @manu - even if PDF is sandbox-able, I don't think it lends itself well to templating. -1 to starting with it
Manu Sporny: to Dmitri Zagidulin: yes PDF is turing complete but it is sandboxable. So is SVG. AFAIK, HTML is not.
Joe Andrieu: HTML has too much of an attack surface
… we can restrict the SVG render method, in particular by telling to disable JS
Phil Archer: we need to move on. Dmitri Zagidulin, any last word?
Dmitri Zagidulin: thank you everyone.
… It sounds like we should open an issue "propose method we should include".
Confidence methods
subissue: w3c/
Joe Andrieu: I think did-auth is a good candidate as a first authentication method
Manu Sporny: +1 to some variation of did-auth
… If I understand what you are saying: presentations today amount to do a signature
… you propose to add a public key that people should use when presenting
… to Denken Chen: there are other methods, e.g. challenge via email address, MFA
… biometrics base
… we want to get this first one done, but I would like to see a list of other methods that people are interested in
Joe Andrieu: +1; let's finish one and discuss the others
… I think what you described 2 types of methods
… one is embedding something in the VP establishing confidence
… another is going through another channel; I want to enable that
… what we have is not how issuer establish confidence, but hints to help the verifier establish confidence
Phil Archer: I'm wondering what the crossover is between this idea of establishing confidence in a VP, and what we discussed yesterday and briefly this morning?
… Am I wrong?
Joe Andrieu: that's brilliant. That's a good case of that attribute.
Denken Chen: we have something similar in Taiwan.
… We require 2 credentials (e.g. banking and telecom). That's one way to improve confidence.
… Not sure it is a good place to talk about that, it is verifier's logic.
Kazue: one part is confidence in the holder, the other part is confidence in the issuer.
Phil Archer: yes, but both are about what you need beyond/around the main credential to establish confidence
Joe Andrieu: do we still have the "evidence" property? it was at risk at some time...
Manu Sporny: yes, we do
Phil Archer: in our own case, I have been talking to our legal team, asking how we find out if someone is authorized to talk in the name of the organization.
… I would use the "evidence" property to point such a document. Not exactly the same thing, but related.
Will Abramson: I think it is good to separate the confidence in the presenter and the confidence in the issuer.
Manu Sporny: the confidence method can be attached to any subject. You can have 20 subjects, each with their own confidence method.
… In a parent-child relationship, you may have one confidence method about the parent, and another one about the child.
… It is not just about the presenter.
w3c/vc-confidence-method#13
Joe Andrieu: This isabout "should confidenceMethod be renamed to authentication"
… I don't think that we should
… difference between identifying vs. linking to a given account
… I suggest to close it.
w3c/vc-confidence-method#12
Denken Chen: difference between confidence that the holder is the subject, or the holder is authorized to present that VC
… e.g. parent of the subject, spouse of the subject
… other example: someone buying medicine for an elder relative
Joe Andrieu: I think this is a data modeling issue
… Assumes that the VC for a dog only has the dog as the subject.
… This is not how we usually do things. The owner of the doc would also be a subject of the VC.
… So the information required to assess this would be in the VC.
Manu Sporny: +1, the place to put that data is not in the confidence data, it is in the credentials
Joe Andrieu: people are not yet fully apprehending the multi-subject nature of VCs
w3c/vc-confidence-method#16
Denken Chen: this one is about levels of confidence
… there was a comment by TallTed that it was unclear. I agree, it is very high level.
… In the last meeting we talked about where to put that confidence level.
… We can make it clear that every issuance should have exactly one confidence level, on which confidence methods will be based.
Denken Chen: E.g. higher level if I show up IRL in front of the issuer to respond with my email address, than if I respond remotely
Manu Sporny: I think that should go into the evidence field.
… [discussion about what should go in "evidence" vs. "confidence level"]
Joe Andrieu: +1 to that framing, I think there are two different things here
… that the issuer had a certain confidence level when issuing the credential is a valuable information that we should keep; not sure the term "evidence" is appropriate
… I believe that eventually, assurance level will be defined in terms of confidence methods
Brent Zundel: note that OpenID4VP has "Hight Assurance" profile
… might be interesting to look at
https://
Denken Chen: there is little guidance in the VCDM spec about the "evidence" field
… But otherwise supportive of the suggestions made here.
Manu Sporny: +1 to look at the HIPE spec; we have met with OpenID Foundation about that and were deeply disappointed that W3C VC were excluded from it.
… They only cover mDoc and SD-JWT-VC
Brent Zundel: despite SD-JWT-VC not being a standard...
Joe Andrieu: I'm sad that none of our specs have any evidence method, this conceptual idea we are talking about.
… A method to put something in the "evidence" property.
… But I think the separation btw "evidence" and "confidence method" is: "evidence" is what the issuer has done, while "confidence method" is what the verifier might do
Phil Archer: what should we do about this issue?
Joe Andrieu: I'm not sure what we can do in terms of spec text.
… TallTed's comment shows that we need to better frame this in the text.
Horizontal review
Phil Archer: I understand we are not ready for HR, but how long before we get there?
Joe Andrieu: I would say Q1
w3c/vc-confidence-method#14
Manu Sporny: use-case is VCs for farmers, no mobile phones, just QR-Codes
… the would like to move it to a VC barcode
… the farmer's credential contains their ID and biometrics, allows them to claim some seeds
… I just wanted that in this group's radar
Joe Andrieu: yes, this is important
… it is in our scope, I don't know how long it is going to take
back to w3c/vc-confidence-method#16
Denken Chen: I am not sure what class of change this issue introduce in the core spec
… and if it has impact on the charter
Manu Sporny: this is a good question
… one way is to define it as an extension
Joe Andrieu: isn't that already an extension point?
… in this case, I don't think that it is a class-4 change
… we could put that in the Confidence Methods spec.
Brent Zundel: it is up to you guys, editors of the Confidence Methods specs, if it is in scope for you
Joe Andrieu: maybe we could get through an evidence method after we address the rest
… this should not prevent us from going to CR
w3c/vc-confidence-method#21
Denken Chen: one must be very careful whenever biometric data is presented, because verifiers may need to keep them for a while
… this issue suggest that some prompting should be implemented before presenting such VCs
Manu Sporny: +1 to that
Joe Andrieu: +1 with the nuance that it is about biometrics claims
Wrapping up
Phil Archer: this concludes this meeting
… thank you for the discussion on the rechartering
… we made good progress on the ongoing documents
… I'm keen to start the conversation with i18n and a11y
… Thanks to all for being here.