Meeting minutes
brent: Welcome everyone, this is the VCWG weekly telecon at W3C. If you're not a member of the W3C and a registered participant of the WG, please let us know.
dlongley: present+
brent: Agenda today: Brief around of updates from the task force, then a dive into the Confidence Method task force, then wrap up on maintenance on the CID spec. Any proposed changes to the agenda? Please add yourself to the queue.
brent: We handle all the queuing and note taking in IRC.
brent: Manu?
manu: Thanks, Brent. We had a quick kind of discussion in the VC barcode call yesterday. This was around adding something to bitstring status list from the VC barcode spec, it's the TerseBitstringStatusList mechanism. The group was in agreement to do this but there's no FPWD BitstringStatusList yet for 1.1. Nothing has changed there, but we should get the wheels turning on that to get it published.
manu: So we have a place for those changes to land.
brent: Excellent question. The proposed additions to BitstringStatusList -- what's the assertion that they are in within the scope of the charter? Manu: It's a security mechanism that the barcode specification uses that layers on top of the bitstring status list spec. We could continue to just
manu: The group can decide where to put it, it's up to us, we can put it where we like.
brent: Is this mature enough to exist on its own, or could it use more development?
manu: I'll defer to Wes on that question.
wes-smith: I think it's mature enough. As part of the transition, I'll review it of course, but regarding charter-scoping, it's the "add features as needed by the new docs in the charter" and it fits easily there, the BitstringStatusListEntry is too big for VC barcodes, this is a smaller approach.
publish it within VC barcodes, that's well within charter, but we could break it out and put it in BSL instead, which the group feels is a better place.
brent: That sounds good, I'm happy for us to draft some proposal language for FPWD for BSL 1.1.
<brent> thank you Phil for remembering editors
phila: Looks ok to me. Thought comes to me -- I'm looking at the authorship, given that old editors aren't active in the group, the new editors would all be from the same company, that isn't a good look, can we have some others join?
phila: Could someone please volunteer to be a co-editor?
<pdl_asu> If no one eise will and it's light I would
TallTed: I can't volunteer taking on extra work per se, but running the same tool on this that was run elsewhere? To analyze contributions?
manu: I can do a quick run on that.
brent: Regardless of contribution, having a named editor would be very valuable.
KevinDean: Yes, Kevin is volunteering.
phila: Thank you Kevin!
brent: Thank you.
manu: Thank you.
<brent> PROPOSAL: Publish Bitstring Status List v1.1 with a short name of vc-bitstring-status-list-1.1 as a FPWD
<manu> +1
<phila> +1
<brent> +1
dlongley: +1
<JoeAndrieu> +1
<hsano> +1
<JennieM> +1
<michaelshea2> +1
<pdl_asu> +1
<kezike> +1
<TallTed> +1
<wes-smith> +1
<Elaine> +1
<denkeni> +1
<hsxavier> +1
RESOLUTION: Publish Bitstring Status List v1.1 with a short name of vc-bitstring-status-list-1.1 as a FPWD
brent: Thanks folks. Is there anyone on the call who would like to re-introduce themselves or otherwise give updates?
brent: I should probably let people know that starting last week, I also chair the advisory board.
brent: I'm no longer chairing the process community group.
Task Force Updates
brent: If you are heading up a task force and have a brief update for the group, please jump on the queue.
<Zakim> manu, you wanted to provide update for Recognized Entities.
brent: This isn't a formal go-around, but if you have something you'd like us to know, we'd like to hear it.
manu: The Recognized Entities TF is making good progress, we have a set of PRs that we believe once we merge will make the spec more or less feature complete. We have also merged the initial draft of the threat model which is fairly complete, includes all the group's inputs on threats they are concerned about, rankings, DFD, categorizations.
manu: Phil Archer is reviewing, we could always use another reviewer. We have also prepared the self reviews for i18n, security, privacy, a11y, so in about two weeks if that TF gets to consensus on it, we're going to ask for horizontal review to go into CR.
manu: We expect it's going to take months for those groups to get around to it, but the hope is that puts us into very good shape for W3C TPAC and getting the Recognized Entities spec into CR during that meeting.
brent: Thank you, Manu.
brent: Not seeing anyone else on the queue.
brent: We can move on.
brent: Next up, we're going to look at confidence method. The chairs are anticipating that we will pick on a particular TF to talk about on the main call.
kezike: A quick update on VCALM. With VCALM the main things that we're doing -- we're making good progress with raising PRs. I am trying to get us down to zero issues by the end of the month. We are working on that.
kezike: We have a PR on the threat model going in next week, and work on the test suite as well. Patrick St. Louis has a new repo with a test suite PR.
Confidence Method
kezike: It's a refurbish of what we had before that was used previously with integration into VC playground but now we have a new mechanism that picks up on normative language in the spec and we can use OpenAPI to guide configuration of the test suites. Will be more to share later as it develops. Just wanted to give a quick update.
brent: Thank you.
w3c/vc-confidence-method#33
brent: Two issues to look at today. Denken and Joe feel free to jump in as much as you like.
brent: The definition of confidence method in the VCDM and in the confidence method spec aren't consistent, this issue was opened by Ivan.
brent: Let's talk about this. What should the definition be? Where are we at here.
JoeAndrieu: There are two different issues here worth kicking around. The first is, what do we do to update the VCDM to update it to be aligned with confidence method, and the second is, is the definition that the CM spec has good? Because it is different from the VCDM spec.
<brent> related VCDM issue: w3c/
JoeAndrieu: The first one is logistical, because if the group agrees on a definition we can remove CM from VCDM, or we could update and point from the CM to VCDM.
manu: +1 not having the definition in two places. I don't have a strong opinion on the definition. Probably the CM spec should define it not the VCDM spec.
manu: We can point from VCDM to the confidence method spec, for whatever language we might need there, but that's easy enough to do. That's probably an editorial change but even if not it's within the charter.
dlongley: +1 that we should move as much as possible to the CM spec and remove from the VCDM.
denkeni: I started looking into CM as a way for digital identity for human beings, so that's why we were are more serious about checking that the subject of a VC is the holder and other issues. I am also wondering when we are using VC for digital product passport, is there a need for a CM about the subjects there?
denkeni: I'm curious about the use cases there to understand how it can be used.
brent: It sounds like we have general agreement that we should remove the CM from the VCDM and put it in the new spec, leaving a pointer if we need anything from the VCDM into it.
<manu> +1 to Brent's summary of where we are at with this issue.
brent: Stating that out loud.
brent: Second issue, what should the description, definition be here? In the issue Ivan lists both of them. Ted expresses support for the VCDM definition over the CM one.
brent: That's where the conversation should be. That's try to come to consensus about that and what the CM should say about itself.
brent: Could you bring your comment in that you just made on the issue, JoeAndrieu ?
manu: I'm fine with either definition, Joe. I think the CM definition is more accurate wrt. what's going on. But I think that might be harder for first time readers to understand it at depth. I don't have a strong preference.
manu: The first one is generalized enough to be in the VCDM and then put the detail in the CM spec, that's one way to do it. But I think we need to see a PR after the discussion today because it will need fine tuning.
JoeAndrieu: I think the one in the VCDM is not the one we want to proceed with. The thing I got behind with the CM -- is that the issuer provides something for the verifier to double check.
JoeAndrieu: The mechanisms of CM let the verifier do some checks on their own using DID auth/biometric/etc. to see if it matches up with what was issued.
JoeAndrieu: I'm not opposed with coming up with a shared term that an issuer might use to describe their confidence in a claim. But we are trusting issuers to make the claim, so we take what they are saying or not. But having an issuer say that they have a 95% confidence level in something is fine -- but there's nothing for a verifier to do with that.
phila: Those two definitions are quite different from each other. It's clear that the CM TF and spec is focusing on the identity of a subject in the VC. The whole point of issuing a VC is that an issuer is already sure enough to issue it.
phila: I can see how expressing a confidence level might be useful, but it's not what CM is about.
phila: Is it ok to slightly alter the CM definition in the VCDM that allows the CM spec to be about confidence in the subject? Can the VCDM put it in the hand of the issuer?
TallTed: Theoretically, an issuer only issues a VC about a subject that they are confident is the subject. I can't imagine that an issue would last very long or be looked to by many verifiers if they weren't confident about the subject about whom they were making claims.
TallTed: I don't see that it's particularly valuable to tell the verifier how they were confident in that identification.
TallTed: Either the verifier trusts the issuer on that or the whole thing falls to pieces.
TallTed: Many of the verifiable credentials that are discussed -- to take an example -- are in the educational field, that someone has taken a course and achieved a level of proficiency and got a grade about a 3.0 (whatever that means in that institution).
TallTed: We don't particularly care how that institution that this individual, bearing this identifier, is actually the individual that took that course. That's not the thing that we're concerned with. We're concerned with the grade that they received.
TallTed: Maybe what needs to happen is that the CM spec needs a little retitling because it's not a generic, it's a specific kind.
<Zakim> brent, you wanted to talk confidence vs evidence
TallTed: That might do the job, I'm not particularly interested in blocking things, but it's not making sense how it's stacking up. We have a very generic definition in the VCDM but a very specific definition in the nominally generic CM spec. That can cause confusion for people trying to use these and we'd be better off avoiding it.
brent: It sounds like a little bit of this is confidence vs. evidence.
brent: I like Ted's suggestion that, because the CM spec, as currently being drafted is one specific confidence method, perhaps a more specific titling would be useful? That would clear this up for me.
brent: I like that idea.
<Zakim> manu, you wanted to note "a subject" (can be used on many objects) not "the subject" (only used on the top-level credentialSubject)
manu: Two responses. One to something Phil said, something to what Ted said.
manu: Ted's item first. The spec currently contemplates three different types of confidence method. Does the subject have a cryptographic key and can they prove that, i.e., DIDAuth. Another is: Is there a static photo I can look at as a verifier to see if the person, shipping container, whatever in front of me matches? And third, is there some kind of liveness checking mechanism that can be done in a privacy-preserving way to check that the
human/cat/dog/whatever is what's referred to in the credential.
manu: What we typically do, the pattern we follow in the group is, we will define a generalized thing, like here are the quantum resistant cryptosuites and then we'll define a bunch of specific ones. This would follow that pattern.
manu: And potentially the BSL as well.
manu: Phil you mentioned "the subject" a couple of times, I want to make sure that it's not just one subject, it's "a subject". A VC can have a human and a cat, two different subjects, for example, and you can have a different confidence method on each one.
<TallTed> +1 about multiple subjects
<Zakim> JoeAndrieu, you wanted to suggest that's assuranceLevel, not confidenceMethod
manu: The expectation is that assigning the photo for each of them, for example, could enable verifiers to get confidence about the identity of those subjects.
JoeAndrieu: First, I'm totally open for getting a better name for the document. I understand that updating the repo and short name might be complicated. That's perhaps why the name in the repo isn't just "VC Confidence". We knew we were defining things beyond just CMs.
JoeAndrieu: Bikeshedding opportunity.
JoeAndrieu: Regarding the content of what you said, Ted... I think we do care about understanding two things that the CM spec is trying to address. Assurance level -- sometimes we do care what did the issuer do to convince themselves that this person was a certain person, like we satisfied NIST level 3. That's valuable for the issuer to explicitly attest to that.
<manu> NIST IAL2 Remote Identity Proofing: https://
JoeAndrieu: For identity assurance prior to issuance.
JoeAndrieu: But the second part, a CM is really about what the verifier can do -- not what the issuer did.
JoeAndrieu: In the DIDAuth pattern, it's presumed that the issuer checked the DID to ensure the subject was in control of it -- but it's the use of the DID to prove use of its VMs at the verifier that's use of the CM.
michaelshea: More of a question than a statement -- examples all around peoples and cats, but does CM extend to a VC by an auditor regarding a meeting or whatever about a good?
denkeni: To add a little bit to Joe's comments. We face challenges too with the issuer to issue a credential unless we have a clear way to let the holder/presenter is the subject. If my brother got an education VC from MIT, but I can use his credential to claim I have credit from MIT.
denkeni: Online. It's very hard to avoid fraud. It's also interesting because when the verifier sees a VC issued by an issuer, what does the trust look like? Does the verifier need to trust every single claim in the VC or can the verifier question about every claim in the VC? This is an interesting question.
denkeni: Does the verifier trust the whole VC -- doesn't need to check any of them, trust is easier. But if that's not the case, we could add some CM to each claim to persuade the verifier the claims are trustable. If we want to pursue that then we probably need to rethink evidence and transform it into a unified structure.
<Zakim> JoeAndrieu, you wanted to say it can be about a business, products maybe
denkeni: Like every claim can come with an evidence field.
JoeAndrieu: I'm a little wary of what you just proposed, Denken. I do embrace that the issuer can put claims in that moderate the primary claims. They can put in language in their claims like that now, Joe got 95% level in this in his class, etc.
JoeAndrieu: I wanted to speak to Michael's question -- CM as envisioned is a point of extensibility and some things aren't on our queue for this cycle. Some of those could be used for a business, you might have an LEI to get confidence in a particular business's identity. You might have some board minutes for decisions, etc.
JoeAndrieu: I can see CMs about businesses and which business is acting, etc. Products you can do the same thing. You're providing a mechanism -- when someone sees one, like the latest iPhone, and you might provide evidence for how to make sure it's really the latest real iPhone.
JoeAndrieu: There are things that manufacturers do to products so that they and law enforcement can check those things. And some of those things aren't public and then fraudsters can do those things if public, so sometimes hard to put there.
<TallTed> business is listed at Companies House in Britain... or is a registered DBA in community x in USA... or has presented successful audit by Big4AcctFirm... or (so many possibilities)
JoeAndrieu: Would be great to have CM for making sure people are buying an actually valuable good, etc.
<michaelshea2> thanks Joe!
brent: Thanks, this was a great conversation. I encourage the CM TF to keep noodling on this and bring back things to the group.
Controlled Identifiers
brent: Moving over to CID now.
<brent> w3c/
brent: This specification is one which is within our remit to maintain.
brent: We're going to do some maintaining of it.
brent: If we look at -- there are two open PRs that we could look at. I think we have talked about one of them before.
brent: I'd like to look at 171 first.
w3c/cid#171
manu: Just noting that this look editorial and good and we should merge it.
JoeAndrieu: Yeah, I think it's editorial. Respec can use xref for this and it helps and makes it easier for other specs to reference this.
brent: A fantastically tiny change that could have a big impact, makes sense to merge it.
brent: Folks, jump onto that PR and give it a thumbs up if you like it. We can probably merge it after the call.
<JoeAndrieu> +1
TallTed: I did put a comment on 170 -- the issue for 171. DID abbreviates Decentralized Identifier, so CID should abbreviate Controlled Identifier not Controlled Identifier Document.
<pdl_asu> +1
<manu> The PR will need to be updated to align w/ what Ted said :)
brent: Are we matching an acronym or a short name?
<hsxavier> +1
manu: I don't know if I quite understood that question. But "CID" should expand to "Controlled Identifier" because "DID" expands to "Decentralized Identifier". We say DID document so we should say CID document and that would all align.
brent: So, we are going to adjust the PR.
JoeAndrieu: I just put the alias in the wrong term. It's an easy fix.
brent: Looking at the issues now.
w3c/cid#167
brent: This was raised by Pierre-Antoine, not a lot of conversation, let's talk about it.
<Zakim> JoeAndrieu, you wanted to say I just updated the wrong def
manu: Have to context swap a lot in my head here. When you define a datatype in a specification -- you have to define what it is and what it's used for, an you need to define the lexical space for the datatype like -- how do you express it using text. vs. what's the value space, mathematically what could this value be.
manu: Where some of those values may not always map into the lexical space, like you can't represent "Infinity" in ASCII or whatever.
manu: As a single symbol, etc.
manu: How do you take the value and map it into lexical space -- these things need to be defined. This one is about the canonical mapping is not the lexical-to-value mapping and it should go the other way.
brent: Yes, this is saying it should go the other way.
manu: One thing we can do in a PR here is just remove the canonical mapping or if it's possible to define it. Ivan suggests we just remove it. I'd like to understand why we should just remove it first, but don't care either way, just want to take more time.
brent: Requires expertise in multibase?
manu: That and RDF.
TallTed: Does anyone know if we have anywhere an actual definition of canonical mapping?
manu: Maybe in RDF concepts?
brent: The definition, I believe is linked to in the first comment.
manu: We should delete this, I think I know what would need to happen -- and when we go through the pain of writing all that text I don't think anyone would care or pay attention to it.
manu: +1 to deleting it.
brent: Excellent. Anyone willing to do this PR?
manu: Easy first issue, just deleting that text.
michaelshea: I'll take a wack at it.
brent: Ok, that is time for the meeting today. Thanks all for being here!
brent: Thanks for scribing, Dave.
dlongley: Sure!