[MINUTES] CCG Incubation 2026-03-10

This meeting focused on reviewing and refining several pull requests and
issues related to verifiable recognition credentials. The attendees
discussed the need for clearer language, better examples, and potential
overlaps with existing standards. A significant portion of the discussion
revolved around how holders can present credentials and the implications
for privacy and decentralization, particularly in the context of validation
before sharing and the "who is" service. The group also touched upon naming
conventions for the specification and the interaction with other standards
like the UN trade protocol.

*Topics Covered:*

   - *PR 39 Closure:* The pull request was closed as it was outdated and
   its content had been superseded by newer revisions.
   - *PR 53 & 54 (Abstract & Introduction Updates):* These pull requests
   update the abstract and introduction of the specification to better align
   with the current focus on decentralization. They are intended to be merged
   after a period for feedback.
   - *PR 55 (Validation Before Sharing):* This pull request introduces a
   section on validating credentials before trusting or using them,
   highlighting the need for verifiers to vet issuers independently. The
   discussion focused on refining the title and clarifying the language around
   "validate" vs. "vet."
   - *Issue Naming Convention:* The group discussed options for naming the
   specification, with "Verifiable Recognition Credentials" being a preferred
   choice, and decided to poll the mailing list for further input.
   - *Issue 46 (Output Validation):* The discussion clarified that the
   output validation property represents an unordered set of data schemas and
   decided to include an example with multiple schemas in the pull request.
   - *Issue 49 (WHOIS Service Publication):* This issue addresses how
   holders can publish verifiable recognition credentials via DID document
   WHOIS services, and it was decided to add a section to the spec with
   examples of this process.
   - *Issue 48 (Digital Identity Anchor Interaction):* The group explored
   the overlap between verifiable recognition credentials and the UN trade
   protocol's digital identity anchors, with the preference being for the VRC
   to potentially replace the DIA, pending discussion with Steve Capel.
   - *Issue 50 (Private Delivery of VRC):* This issue discusses the holder
   delivering a verifiable recognition credential privately to a verifier,
   particularly in offline scenarios or when centralized lists are not
   feasible. It was decided to include an example in the spec, potentially
   focusing on business registries or offline use cases. The discussion also
   covered the privacy implications of different delivery mechanisms.

*Action Items:*

   - Manu Sporny to update the PR targeting for PR 53 to ensure it's
   stacked correctly on PR 54.
   - Manu Sporny to monitor PR 53 and PR 54 for feedback over the next 7
   days and potentially merge them on the next call.
   - The mailing list to be pinged with the current naming options for the
   specification to solicit further feedback.
   - Manu Sporny to raise a pull request for Issue 46 specifying the value
   of output validation as an unordered set and including an example with
   multiple data schemas.
   - Manu Sporny to add a section to the spec with examples for Issue 49
   regarding publication via WHOIS services, including examples of how to
   document RCs and use the WHOIS protocol.
   - Manu Sporny to engage Steve Capel via the mailing list or other
   appropriate channels to discuss the options for Issue 48 (Digital Identity
   Anchor interaction) and gather his preference.
   - Manu Sporny to update Issue 50 to add the example discussed for
   private delivery of VRCs, including the offline and business registry use
   cases, and will require assistance with VPR extensions in VCOM.
   - The group will investigate and potentially update the VCOM request
   spec to better model trusted issuers and accepted issuer properties,
   including the concept of "proof of inclusion in a trusted registry."

Text: https://meet.w3c-ccg.org/archives/w3c-ccg-ccg-incubation-2026-03-10.md

Video:
https://meet.w3c-ccg.org/archives/w3c-ccg-ccg-incubation-2026-03-10.mp4
*osb-nmyo-muh (2026-03-10 11:03 GMT-4) - Transcript* *Attendees*

Benjamin Young, Dave Longley, Dmitri Zagidulin, Elaine Wooton, Manu Sporny,
Parth Bhatt, Ted Thibodeau Jr
*Transcript*

Benjamin Young: another call. let's plan to start in maybe two or three
minutes for folks to get here. AFK for those two minutes.

Benjamin Young: Okay, sorry for the wait. I think today we've got a couple
of poll requests from Monu that we'll look at. There's the lift. I will
screen share here in a second maybe.
00:05:00

Benjamin Young: to work. There we Can everybody see that? I can zoom in if
needed. Mano, is there any order you want to take these in?

Manu Sporny: They're pretty easy high level.

Manu Sporny: Maybe we want to address 39. I think we could potentially
close that…

Benjamin Young: I was going to ask.

Benjamin Young: It's been idling.

Manu Sporny: because I forget what this was about. yeah that we moved this
content.

Benjamin Young: I can give it.

Manu Sporny: The introduction section's been rewritten. it kind of comes
from a previous AON. I think we should close this. Yeah.

Benjamin Young: Yeah. Yeah.

Benjamin Young: There's not a whole lot here. So, any objections from
anyone? Sadly, we lost it, but Yeah, I don't see a reason to leave it open.

Manu Sporny: Yeah, we can just say it's been overtaken by events. We've got
lots of PRs that have modified various parts of…

Benjamin Young: Yeah. Yeah,…

Manu Sporny: what has been written.

Benjamin Young: that's fine. And David's obviously tapped out, so

Benjamin Young: He won't be back to say otherwise. Okay, I'm going to go
from oldest to newest then if that works.

Manu Sporny: And just real quick on this. So each one of these, started off
as kind of like an AI generated summary. we needed a new abstract. We need
a new introduction. and then I'm trying to start tackling the security
considerations. I did also go through Benjamin all the issues and…

Benjamin Young: Okay. Yeah. Yeah.

Manu Sporny: mark them as ready for needs further discussion just to try to
get a quick glance on what I need to do kind of editorially. so it's broken
out. So PR53 is just the redoing the abstract. and we can review async the
introduction is just updating the introduction again trying to better align
it with kind of what the spec is about now focusing on the decentralization
aspect of it and…

Manu Sporny: and that sort of thing. they are stacked to stack them.

Benjamin Young: Looks like your PR is maybe stacked.

Benjamin Young: Okay. No,…

Manu Sporny: I might not have done that because I was in a rush. Let me
Yeah,…

Benjamin Young: I think that it's just not This needs to point to the other
branch.

Manu Sporny: why can you not edit? Can you not my Yeah,…

Benjamin Young: I can't do it for you, but it's usually just in the edit at
the top, I think.

Manu Sporny: there's a new UI. They updated it.

Benjamin Young: Goody.

Manu Sporny: How do I pick a different target? I want to pick a different
target branch and I cannot do that. I can edit the title.

Benjamin Young: Is it because ready to merge is one?

Manu Sporny: No. What does that mean?

Benjamin Young: I don't know.

Manu Sporny: If I click it, does it automerge it? I haven't seen that
button before.

Benjamin Young: Should I click it?
00:10:00

Manu Sporny: No. I don't want it to get merged, So let's say it's supposed
to go in order. The abstract's supposed to go first and then the
introduction on top of the abstract. and…

Benjamin Young: Right. Okay.

Manu Sporny: and yeah, we can just I guess leave it out there for people to
provide opinions and input on. Although it's going to be confusing to Ted…

Manu Sporny: because he's going to go and modify the abstract and…

Benjamin Young: Right. Right.

Manu Sporny: I'll try to figure out how to get the target branch fixed.

Benjamin Young: Used to be easy.

Manu Sporny: That's frustrating.

Benjamin Young: It probably is hiding under that button,…

Manu Sporny: I see the exact same thing that you see on your screen.

Benjamin Young: but I can't see what you can see in terms of editing and
things. You don't have if there's an edit idle.

Manu Sporny: Yep. …

Benjamin Young: Yeah, that's where they moved It's there.

Manu Sporny: Thank I was presuming that edit title only allowed you to edit
the title.

Benjamin Young: Yeah. Crazy. Why would you think that? All right.

Manu Sporny: Yeah. …

Benjamin Young: Update abstract. Is that all right?

Manu Sporny:

Manu Sporny: I just did it. all right.

Benjamin Young: Great.

Manu Sporny: We should be good now.

Benjamin Young: Go team.

Manu Sporny: Okay. …

Benjamin Young: And then presumably this one is the Needs changing to point
to.

Manu Sporny: no,…

Benjamin Young: No. Okay.

Manu Sporny: that one I did on purpose. yep.

Benjamin Young: Great. okay.

Manu Sporny: So, we're good there.

Benjamin Young: Did you want to Sorry, we don't need to accelerate past the
intro. Was there more to say for that one?

Manu Sporny: No, I think that's it for this. I would like to take a look at
PR55. So 53 and 54 are self-explanator new introduction. Please weigh in.
We'll give it, 7 days for people to weigh in and then merge maybe on the
next call. PR55 add section on validation before sharing. Again, this was a
bit rushed, so I think it's a little off. as a heads up, I just committed
to added a privacy consideration section, a boilerplate that basically is
like, hey, you should go read the VC data model privacy section before you
read this Same treatment for the security considerations. So, see that
those two sentences.

Manu Sporny: This was just pasted from bitstring status list…

Benjamin Young: Yeah.

Manu Sporny: where we're just kind of like hey go read the privacy sections
and security consideration section in the VC data model before you read
this. and then the validate before sharing section 4.1 is the new thing.
And we had an issue raised that was basically saying hey, you shouldn't
just trust a verifiable recognition credential if a holder delivers it to
you. you should have your own vetting process for these things.

Manu Sporny: and the vetting process might be I just trust the issuer to
anything about verifiable recognition credentials. so that's what the
security section 41 valid Validate before sharing is probably the wrong
title cuz because it's really validate before trusting or validate before
using to trust other credentials or something like that. So this needs a
little more refinement. and then at the very end looks like there's a
syntax error but instead a verifier needs to vet the issuer of the
recognition credential as well as the recognized action independently of
receiving the VRC and can only depend on that's a bit sloppy. I want to
clean that up. But in general this is basically saying hey just because you
got a verifiable recognition credential doesn't mean that it speaks the
truth.

Manu Sporny: you need to trust the issuer of that redential. and if you
don't know who the issuer of the credential is, you need some kind of
adding validation process. we also didn't know if we should use validate
instead of vet or vice versa.

Manu Sporny: So some scrutiny on this one on language that we use would be
helpful I

Benjamin Young: Yeah, I'm sure Ted will be happy to when he's back.

Benjamin Young: Others are obviously welcome to. These are very fresh,
right? They're in the last two hours.

Benjamin Young: So, yeah,…

Manu Sporny: Yeah. Yep.

Manu Sporny: As of this morning,

Benjamin Young: we'll come back to this These three probably next week, I
would assume.

Benjamin Young: Unless we merge him in the meantime with support. Any Yeah.

Manu Sporny: I think let him hang out there for a

Benjamin Young: Any questions from anyone about these changes? And I think
we'll take a look at the issues. And Mono, you mentioned you curated these.
Thank you. Great.
00:15:00

Manu Sporny: Yeah, just quick largely because I was looking for editorial
things to do and I couldn't tell. So, I read through all of them and then
if I were like, yeah, I can think of the type of text that needs to be
written for the PR, I just marked it as ready for PR. And if I was like, I
don't know what to write, I marked it as discuss. so we might want to spend
a little bit of time today kind of going through the discuss items.

Manu Sporny: I know they've been discussed previously, but even based on
the previous discussion, I couldn't tell what to write. so I'd like to at
least in these issues,…

Benjamin Young: Okay. Yeah,…

Manu Sporny: type out like exactly what the PR should be once we have the
discussion.

Benjamin Young: I agreed. great. Let's take those one at a time. let's not
do this one because that's all we'll do. go ahead.

Manu Sporny: Just a real quick update on that. I agree. Let's not…

Benjamin Young: Okay. thanks.

Manu Sporny: if I shed that. I did send an email to the mailing list and
people had a good long discussion about everything but the title of the
document. I don't know if we want to. I can ping it again to see if people
have opinions, but I was wondering if we wanted to. One other option I
mentioned thought of as name the spec verifiable recognition credentials as
a play on Dave Longley's verifiable recognition.

Manu Sporny: Yep.

Benjamin Young: Yeah, because it is a or…

Benjamin Young: it looks like it's trending towards being a discrete V
type. So that would make sense,…

Manu Sporny: But I was wondering if we should write down in the issue the
current set of options.

Benjamin Young: Yeah, you had asked for a rank that you were going to run a
rank choice after people provided ideas. I don't guess you even got that
many.

Manu Sporny: I got zero from the mailing list, right, by asking them.

Benjamin Young: Yeah, it's not many.

Manu Sporny: So I was wondering if we could kick it off and…

Benjamin Young: Yeah. Right.

Manu Sporny: I could use that as a hey, here's what we have right now. Does
anybody have any new ones? last call.

Benjamin Young: Yeah, I think that makes sense.

Benjamin Young: do you want me to listen?

Manu Sporny: So I think the ones we have now please if you don't mind. so
we have recognized actions, verifiable recognition, and then verifiable
recognition credentials. Does anyone have any other suggestions?

Benjamin Young: Be nice if you could do polls in here. New slash there.
wish anybody all the above. I would lean on the last one personally. Yeah.

Manu Sporny: All I mean, that's good. We've got four choices. We can send
it out and whoever cares can, rank choice and then we'll get something and…

Manu Sporny: we can discuss it once we get something. Okay, that's it. I
don't think we need to spend any more time. Thanks.

Benjamin Young: Yeah. No,…

Benjamin Young: I think that's So, a couple of these have activity since
whenever I was in here live. do you want to keep going up from the bottom?

Manu Sporny: Dealer's choice. Whatever whichever ones you want to do.

Benjamin Young: All right, let's just do that. Let's go from the bottom.
Some of these have aged a little bit at three weeks. this one we did
discuss last week and Dave, do you remember where we left things? I think
it was kind of confused.

Benjamin Young: And Ted's not here to represent his confusion.

Dave Longley: Yeah, I think we were struggling…

Dave Longley: because the spec describes things from a Jason perspective
and Ted wanted to know how that translated to triples. but in my opinion, I
don't think it's the spec's job to say that, but it is the spec's job to be
more clear about what you actually do with this property. And it would also
benefit from some examples. so we just in some way need to better clarify
exactly how to express output validation information so that you don't get
confused and think that it's something that it's not. Ted's examples were
about are you saying that the value is like I don't remember the
terminology we're using.
00:20:00

Dave Longley: he was using does this output one triple or many triples? the
answer was many triples. so we just,…

Benjamin Young: Right. I see.

Dave Longley: yeah, so we need to be more clear in the description of what
you put in the property and having examples helps.

Benjamin Young: So, this one is in theory ready for PR. Go ahead and run.

Manu Sporny: Yeah, I just not quite clear what to write yet. So I agree
with what Dave said. I don't think we need to talk about RDF principles in
a spec that's at this level of the stack.

Benjamin Young: Yeah, great.

Manu Sporny: Plus one to adding an example on using multiple schemas that
might match.

Manu Sporny: Yeah.

Dave Longley: I think the problem here is we normally use the infra spec to
say this is a set or…

Dave Longley: an ordered map or where the order doesn't matter and we
didn't do that here. We just said must be one or more data schemas and that
confused people.

Manu Sporny: All but would just that address Ted's concern?

Dave Longley:

Dave Longley: I hope so. if the language becomes more like what the other
VC specs use I would hope that that would be sufficient.

Manu Sporny: So then this is an unordered set of data schemas.

Manu Sporny: And then we can provide an example with something that has two
schemas.

Dave Longley: Yeah, I think that sounds All right.

Manu Sporny: Is that All right. so that's what the PR is going to do. So,
let's make sure to take a note of that just I can write that.

Benjamin Young: Sounds right.

Benjamin Young: Are you writing that or should I?

Manu Sporny: One second. I got to get to the 46. all right.

Benjamin Young: Are they already there?

Manu Sporny: All right. So, PR should be raised for this issue that
specifies that the value of output or what is this thing? output validation
is a set of one or more an example that contains more than one data schema
needs to be included in the PR.

Manu Sporny: Okay, so just those two things would address it hopefully and…

Dave Longley: Hopefully. We'll have to check in with Ted.

Manu Sporny: then Okay, I'll mark this ready for PR.

Benjamin Young: Yeah, it sounds right.

Manu Sporny: Okay. Yeah.

Benjamin Young: Okay, thank you both. Next up, who is one. It came up on
the mailing list. We did talk about this one a little. Go ahead. Okay.

Manu Sporny:

Manu Sporny: So, let's see. who is one pops up in two other issues of but I
think we don't have duplication yet. this issue 49 is about making sure
that a verifiable recognition credential can be published via did documents
who is service that's a part of it. So the…

Benjamin Young: Yeah.

Manu Sporny: who is service is what you use to figure out this thing is
it's hearkens back to the 19 what7s 80s who is service. the expectation is
when you hit that service you will get back a bunch of verifiable
credentials where one of them could be a verifiable recognition credential
about you that some known authority so universities who is service would
potentially have all the accrediting bodies that have accredited that
university.
00:25:00

Manu Sporny: and so the university can self-publish I'm a legitimate
university says, the International Association of University, commissioners
or whatever. so that's what this use case is about. It's about, the holder
of a verifiable recognition credential that is likely about them. how do
they publish through the did documents who is service so I think we just
need to have a section that speaks to that and how it is done I don't know
if the best place to put that is in the use cases document or in the actual
spec it feels I don't know it's hard it could be useful in both

Manu Sporny: places and the use cases usually don't show you how you solve
the problem, They just talk about hey, these are the problems and these are
the requirements of the solution. And then the spec itself is the thing
that says this is exactly how you solve the problem. so we could put this
in the spec.

Benjamin Young: Yeah.

Manu Sporny: It feels like we're going to collect a bunch of kind of
superfluous appendices in the spec that are here's how you solve this use
case and here's how you solve that use case. And sometimes people with
those in implementation guides which as we all know just die a slow death
right we put it together as a working group and then nobody works on it for
years afterwards. So putting it in the spec might be a good thing as an
appendix. What do people think about that?

Benjamin Young: works for me.

Dave Longley: I think that's a fine start. We might decide they go
somewhere else, but I think it makes more sense there than in the use case
document.

Manu Sporny: With examples of how to be so good document as well as RC by
Wiz call protocol to get the document. All right. So, I can do that. Ready?
So,…

Manu Sporny: this one's ready for PR.

Benjamin Young: Thank you.

Benjamin Young: Right. 50. Wait. No. Yeah. Label's changed. 48. Go ahead.

Manu Sporny: This one is a little more difficult. So this one is something
that Steve Capel who is the chair of the United Nations trade protocol
which is using W3CVC's they are basically creating a big vocabulary at the
United Nations around trade and they're doing a really good job at it. they
had this concept of a digital identity anchor created it before we created
this verifiable recognition credential spec and they were like hey how do
we fit in here because looks like we're duplicating work how does it
interact and so this is just raising the fact that we should try and figure
out

Manu Sporny: how they fit together. if we go down …

Benjamin Young: this thing here. Yeah.

Manu Sporny: where that digital identity anchor there at the top, that is a
kind of a VRC. Their scope is kind of like The trust registar ID is kind of
like the issuer of the verifiable recognition The member ID is the
credential subject for one of the recognized entities. Name we support
verify dids is kind of an overlap between member ID, right? that we don't
quite do or we could do that could be same something like that. and then
the scope is the action.
00:30:00

Manu Sporny: So I think the verifiable recognition credential thing could
entirely replace that we could point to their credential. So I think this
one we should ask Steve hey what would you prefer? We think the VRC could
entirely replace a digital identity anchor. do you want that to happen or
do you want us to figure out a way to point to a digital identity anchor
because we do want to collaborate with them on this? when I don't think we
have a strong opinion either way. It's just kind of like, whatever works
for you guys. we want to support what you're doing. If you can reuse the
credential, that would be great.

Manu Sporny: if you don't want to or if there are things in here that you
need in the VRC that aren't yet, we're happy to add them to the VRC. And so
you could kind of point to that instead,…

Manu Sporny: that instead.

Benjamin Young: Yeah, there's definitely overlap.

Manu Sporny: Mhm. Yeah,…

Benjamin Young: Do you know what we already did?

Manu Sporny: he's on the CCG. he's pretty active there.

Benjamin Young: Yeah.

Manu Sporny: And he's super friendly, so he's in Australia,…

Benjamin Young: Just wondering how to loop him into this. should we try and
arrange a call to do a comparison with him live?

Manu Sporny: so we'd have to be kind to his time zone.

Benjamin Young: Yeah. Yeah.

Manu Sporny: Yeah.

Benjamin Young: Right. Some late afternoon for us, early morning for him.
Yeah.

Benjamin Young: I mean, we can ping him again here, I guess.

Manu Sporny: Yeah, maybe we ping them on the mailing list to say, Hey, how
here are the options, we could either add properties to the VRC that you
need in the digital identity anchor work and you could reuse the VRC and
replace digital identity anchor with that or we could figure out a way to
point to a UNP digital identity anchor or make it compatible. Which one
would you prefer?

Benjamin Young: And in that case, what would we be pointing from? Just, I
forget all the new words we're Trying to get that spec.

Benjamin Young: Would it be a just totally shell out recognized entity and…

Manu Sporny: Yeah. I mean,…

Benjamin Young: that would point Yeah.

Manu Sporny: I think that's what I forget what they're calling it in their
digital identity anchor is a recognized entity. It's the same thing, right?
Yeah.

Benjamin Young: So this does feel very similar to Yeah. Yeah.

Manu Sporny: They do a little bit of a weirdness with the ID scheme things.
A little weird. Register type is like that that's weird modeling, right?
Because it's like you're talking about an entity and you're saying the
register type is business and it's like, wait a second. that's weird
modeling. And then the registration scope list. I don't know what that
thing is. So, we'd have to talk with them about it.

Manu Sporny:

Benjamin Young: Yeah. Yeah,…

Benjamin Young: it would be good to have somebody familiar with it.

Manu Sporny:

Manu Sporny: And Steve's that person. So, we'll just need to chat with them
about

Benjamin Young: Scope of member registration. yeah.

Benjamin Young: There's existing type lists somewhere. Okay, sounds
workable. I'm guessing you'll follow up on this thread and…

Benjamin Young: just see if we can engage there or start a new one.

Manu Sporny: Yeah, I'm very very short on time.

Manu Sporny: I will try put it on the to-do list,…

Benjamin Young: Yeah. …

Manu Sporny: but I don't think it's going to move forward unless somebody
else does

Benjamin Young: right. Anyone else want to take the action to I think we
could just continue this thread. Yeah. this is far less effective but
00:35:00

Benjamin Young: I'll come back and finish that. and maybe turn it into an
email, too. Okay,…

Manu Sporny: I'm updating at least the options in that issue.

Benjamin Young: I'll let you just do that then and then I can send that an
email if you want. I'll let you finish typing before we start.

Benjamin Young: So, the one I've got up here seems very related to 49.
maybe more than the other one that's floating up there. another Stephen has
offered to come back more onto a call to talk about this more in depth.

Benjamin Young: Given Man, that you had a pending PR on 49, do you want to
kind of get 49 farther along and then us engage Stephen Curran after that?

Manu Sporny: Sorry, I was typing that other thing up.

Benjamin Young: Yeah, I know. Sorry. Yeah,…

Manu Sporny: That's fine. Let's take a What are we on? 50. Yeah,…

Benjamin Young: we're on 50. So Stephen's offering to, let me know when and
where. Come and join in the conversation.

Manu Sporny:

Manu Sporny: it's this one. Stephen should have probably commented on the
other one and not this one, right? Because this is kind of like the…

Benjamin Young: Yeah. right.

Manu Sporny: who is use case. there are two ways for the holder to deliver
of a verifiable recognition credential. one way is to publish it via who is
so that's kind of like a public publishing of the information by the
holder. The other one is to privately present it in a peer exchange. this
issue 50 is about private delivery of the verifiable recognition credential
to the verifier.

Manu Sporny: so we should create another kind of appendix example maybe we
have an appendex called use case examples and we show an example of here's
a VRC that the holder holds. the verifier requests a particular credential
and says which entities they trust to deliver the credential. This is a bit
of a handwave that I'll come back to. And then the holder delivers that
verifiable recognition credential along with the credential that was issued.

Manu Sporny: the bit in the middle I am unsure about when a verifier says I
will accept a credential issued by this entity of this type why would the
holder need to provide a C? unless that VRC is issued it's a second level
VRC. so it's like the verifier let's take a use case. So you've got a
verifier that is trying to hire for a particular job right?
00:40:00

Manu Sporny: So, they're a HR agency or whatever and they're like, I need
to just see an associates degree, right?" And they're tens of thousands of
community colleges across the United States that could provide that
particular associates degree. and the verifier is I trust the National
Registry of Community Colleges. So, as long as this community college, is
associated is on some kind of list that, is published by the National
Association of whatever, I'm cool with accepting it. that I think is a use
case where it's kind of you don't know about my tiny little community
college.

Manu Sporny: but you do know about the registration at the national
commission or whatever. And so I'm going to give you the verifiable
recognition credential that links the national association with the
community college and then I'm going to give you an associates degree
credential issued by the community college.

Manu Sporny: I think that's the only use case that I think makes sense and
I don't think we really talk about what that process looks like or should
be in the spec. So the first question is do folks agree with that as that
being an example that we should show how it's done in the spec. So thumbs
up from Dave Longley. Dmitri, I don't know if you have any strong opinions
about this from the education sector. I think that's one of the education
sector use cases like the education sector use

Dmitri Zagidulin: it. so it is, but I missed what you said about it.

Manu Sporny: It's so the idea here is that you've got thousands and
thousands of community colleges and there's someone that's hiring for a job
and they want you to have an associates degree in accounting. but they
don't know of every single community college, out there. and really they're
like, I trust any community college that has been vetted by the National
Registry of Community Colleges.

Manu Sporny: And in their verifiable presentation request, they just
include National Registry of Community College. I don't know how they asked
for that one. So Dave, you might have an idea about that, but I don't know
how they're like I trust anyone on this registry. but when they do that,…

Dmitri Zagidulin: Currently, for…

Manu Sporny: go ahead.

Dmitri Zagidulin: what it's worth, currently the way that's handled slash
implemented is the sort of the applicant hands over a diploma signed by one
of the colleges and the receiver asks any number of registry lists that
they trust, hey, is this did in them? So that's the general idea that they
don't ask the holder. it's an of-band check.

Dave Longley: Yeah, that's the phone home we want to avoid with the new
decentralized version.

Dmitri Zagidulin: Yes and Yes and no. Right.

Dmitri Zagidulin: So it's the whole phone home mitigated by cashing.

Dave Longley: Yeah, we can avoid the phone home entirely.

Dmitri Zagidulin: Yeah. Right.

Dave Longley: I think if we take the other approach and we should document
the other approach, the holder can fetch that information and then present
it directly to the verifier without the need for the verifier to get then
Look it up. And it also makes it a little more clear that the holder could
confirm, that this stuff works before they hand it over.
00:45:00

Manu Sporny: Yeah, I think and we might be looking for a different use case
other than the education one because I agree with Demetri like that that is
how it works today. That is probably…

Dmitri Zagidulin: I need that.

Manu Sporny: what they're going to default into no matter what we say. I'm
wondering…

Manu Sporny: if what's the use case? I think there's a desire to push for
just totally decentralized delivery of this information which is fine and
can be done.

Dmitri Zagidulin: I'm curious I'm curious…

Dmitri Zagidulin: what your thoughts are on who is mechanism because that
is potentially a solution to it, Meaning it's not the holder that holds on
to the credential, it's the did itself.

Manu Sporny: Yeah. I mean a different type of phone home, now the issuer is
being contacted whenever any one of their diplomas is being used
potentially, right? it could be that is a worse privacy outcome than just
having a big gigantic list that everybody downloads,…

Dmitri Zagidulin: It's not

Manu Sporny: Because at least when somebody downloads the big gigantic
list, it operates kind of bitstring status list where you don't really know
which issuer they care about. But if s who is hosted thing it's like that
one of my credentials is being used that's why you're and you get hit by
the verifier that's using it right and unless the verifier is caching that
stuff very aggressively which they might not be especially when the bigger
the population like community colleges versus u universities the bigger the
population the less likely there is to kind of be caching and… the more
kind of information leakage there is right. So,

Manu Sporny:

Dmitri Zagidulin: Got it.

Dmitri Zagidulin: So we have these three fundamental mechanisms. phone home
to the did server or ask the presenter to present. I get I think you're
making a very strong and valid argument that it's that third mechanism the
presenter to present the evidence of belonging is the preferred one and
honestly if we're to follow that train of thought we'll need to create a
mechanism in the vcom request spec to say just like we have accepted
issuers we need to say, " and also the issuer has to be from this accepted
list," which I guess is accepted issuers. So, we just need to modify that.

Dave Longley: Yeah, the VP request back a long time ago said it offered a
way to express more details in the trusted issuers field. I need a trusted
issuer. I'm not going to say specifically which issuer it is, but it needs
to have from this other list or a credential of this type from this other
issuer. So we do need to model that better and come up with better examples
in the VCOM spec for how to do that with the accepted issuer field. But the
point of that field is not necessarily to directly identify the issuer
you're willing to accept something from, but to talk about an issue. these
are the properties of an issuer that I would be willing to accept. And that
can include they're on this list or…

Dave Longley: they have a credential from another issuer on this list and
so on.

Dmitri Zagidulin: So just for…

Dmitri Zagidulin: what it's worth as a data point if we added that
capability to the VCOM request spec if we named it something in the trusted
issures list provide proof of inclusion in this trusted registry I'd be
willing to campaign for that method over the other

Dave Longley: Yeah that's great. The other thing that is related to this
issue around a holder delivering a verifiable recognition credential is the
use case where a holder begins an exchange and they send a verifiable
recognition credential to the verifier that the verifier must comply with.
So the holder can say I send a VPR that says I need you to send me a
credential of some type and where your issuer is on my verifiable
recognition credential list before I'm willing to respond to any request
you might have.

Benjamin Young: kind to meet you.

Dmitri Zagidulin: You're right. That's also super important. It seems like
we should also carve out a place for in the VP request back to save a round.
00:50:00

Dave Longley: I think it's the same place. you just flip it around.

Dmitri Zagidulin: Wait. Just say save a round trip though. and…

Dmitri Zagidulin: are you sure you would want to put it in the same place
rather than have a separate property for it?

Dave Longley: Yeah, I think it's just the holder is making a VPR request to
the verifier and…

Dave Longley: they're going to say, I want this credential from you and I
will accept an issuer that is on this vecogn cred that is in this
verifiable recognition credential or has one of this list,…

Dave Longley: etc. So it's the same question just being asked by the
holder. And so the holder will make that question and then the verifier
responds with their VPR and their credential.

Dmitri Zagidulin: I see…

Dmitri Zagidulin: what you're saying. Yeah, agreed.

Manu Sporny: Okay, I'm updating it to add this example, but I will need
help on the VPR extensions in VCOM. And I don't know and it's great
Dimmitri to hear that you'll rally for the education sector to do this. I
am wondering if there is an easier use case an easier to what's the word
there is I'm trying to think of journalists that are under duress and it's
kind of like please don't use this technology if you're in that situation,…

Manu Sporny:

Dmitri Zagidulin: We could draw the same analogy with employers,…

Manu Sporny: right? I Yeah,…

Dmitri Zagidulin: we can say when applying for a job ask in both sides in
both directions. The applicant asks the requester, hey, are you on some
sort of mildly approved list, even if it's the list of LinkedIn took a look
at it or some job search engine registered you, right? So that's on the one
end and then on the other end is with people it's harder. So I guess we can
start with is this not a fake job offer? We can stress I don't know if
that's easier for people to gro than education.

Manu Sporny: it's a good point. I guess we do need to create an example.
And I think what is the most believable use case for why somebody would
want to deliver this peer? because the knee-jerk reaction for most people
is we have centralized lists for this. Why are you doing this weird
roundabout thing? Right? so if we can basically say there is no centralized
list for this thing. but we're showing you how it can work anyway in a
decentralized way. I do like the business registry thing.

Manu Sporny: There so many of them out there, way more. Yeah, that is an
excellent point.

Dmitri Zagidulin: And we can I don't know…

Dmitri Zagidulin: if it's worth stressing the offline capability of it for
first responder type of things. I don't know. Right.

Manu Sporny: Maybe that is the it's an offline use case and you don't have
network connectivity. You can't go out and get that list, but you do know
who the National Registry of EMTs is, and I can prove to you that my
credential is linked back to that. And I can do that in an offline
situation. Perfect. Yeah, I think that's it, Dimmitri. Let me add that

Dmitri Zagidulin: So just out of curiosity, would this group how strong of
a recommendation among the three methods is would you all be against ever
using the download a big list from a trusted registry or so hard no or only
a sometimes food?

Manu Sporny: I don't think any one of them's so hard to know, they're
legitimate uses for all of them. I think we could talk in the privacy
section about what's the safest from a privacy preserving standpoint and
that is Direct delivery by the holder. and then maybe surprisingly for the
next best thing is the giant centralized list because you can't pinpoint
the issuer and then the least privacy preserving might be checking who is
directly.
00:55:00

Manu Sporny: So maybe we need to have something in the privacy
consideration section that just makes it clear.

Dmitri Zagidulin: Agreed. Count it.

Manu Sporny: You're like, hey, this is not necessarily intuitive. you would
think, having this more decentralized and at the issuer would be the best
thing to do. But if the verifier is going to hit the issuer, then all of a
sudden the issuer gets a lot more information than…

Manu Sporny: if they were just on some giant centralized list somewhere
else. I'm going to mark this ready for PR.

Benjamin Young: Yeah, sounds good.

Benjamin Young: And I think with that we are very much at time. thank you
everybody. We'll be back next week. Not for the thrilling conclusion sadly,
but more progress. does anybody happen to know if the CCG call that's
usually is The title says upcoming meeting.

Manu Sporny: It is I just forgot to change the title of the meeting.

Benjamin Young: Okay.

Manu Sporny: I think it's a report out I think on status

Benjamin Young: All I guess I'll be excited to see what actually happens.
yeah. Okay. Sounds good.

Benjamin Young: All right. Thanks everybody.
Meeting ended after 00:57:09 👋

*This editable transcript was computer generated and might contain errors.
People can also change the text after it was created.*