[MINUTES] CCG Incubation and Promotion 2025-08-20

CCG Incubation and Promotion Meeting Summary - 2025/08/20

*Topics Covered:*

   1.

   *Verifiable Credential Working Group (VCWG) Updates:* The VCWG is
   currently in maintenance mode, meeting monthly to maintain existing
   specifications. Two specifications (render method and confidence method)
   were deemed ready for promotion to final community group specifications. A
   new charter is being drafted for future work, to be presented before the
   W3C TAC in November.
   2.

   *Decentralized Verifiable Issuers and Verifiers:* The primary discussion
   centered on a pull request proposing a more decentralized approach to
   verifiable issuers and verifiers, moving away from centralized trust
   registries. The current proposal uses JSON Schema to define issuer
   authorization, but several concerns were raised:
   - The proposed "issuance grant" model was considered too coarse-grained,
      not adequately addressing nuanced jurisdictional issues and differing
      levels of authority for various claims within a credential.
      - The definition of "authoritative" for a claim is context-dependent
      and varies across jurisdictions.
      - The approach might not fully address verifier business rules, which
      often involve more complex logic than simply checking an
authorization list.
   3.

   *Specification Renaming and Re-scoping:* The group discussed renaming
   the specification to better reflect its focus on a data model for
   verifiable lists, rather than protocols. A suggestion was made to
   potentially re-scope the specification to point to existing
   ecosystem-specific trust frameworks (e.g., OpenID Federation, Train)
   instead of creating a new, comprehensive model. The group also debated
   whether the focus should be on KYC (Know Your Customer) of entities and the
   need to separate this from authorization grants.

*Key Points:*

   - The group agreed to publish the render method and confidence method
   specifications as final community group specifications.
   - Significant concerns were raised regarding the decentralized
   verifiable issuers and verifiers proposal, highlighting the complexity of
   modeling jurisdictional variations and verifier-specific business rules.
   Further discussion and refinement are needed.
   - The group will consider re-scoping the specification to leverage
   existing trust frameworks instead of creating a new, all-encompassing model.
   - The group agreed to separate the concerns of organizational identity
   verification (KYC) from the authorization aspects.
   - The use of JSON Schema as a mechanism for defining issuer
   authorization is under review and further discussion is needed.
   - More refined terminology and a more nuanced data model are needed to
   effectively address the complexities of decentralized trust.

Text:
https://meet.w3c-ccg.org/archives/w3c-ccg-ccg-incubation-and-promotion-2025-08-20.md

Video:
https://meet.w3c-ccg.org/archives/w3c-ccg-ccg-incubation-and-promotion-2025-08-20.mp4
*CCG Incubation and Promotion - 2025/08/20 10:58 EDT - Transcript*
*Attendees*

Alex Higuera, Benjamin Young, Dave Longley, Dmitri Zagidulin, Hiroyuki
Sano, Joe Andrieu, John's Notetaker, Kayode Ezike, Manu Sporny, Manu
Sporny's Presentation, Parth Bhatt, Phillip Long, Ted Thibodeau Jr, Tom
Jones
*Transcript*

Manu Sporny: All right, let's go ahead and get started. I was hoping to
have Isaac on the call today so we David Chadwick has noted that he was
busy for the entire month of August, but should be able to start making the
call next week. so unfortunately I was needed to reschedule a call to try
and shift the meeting so that David could meet it but haven't done it for
the last three weeks and that was the time he was off. So now he can start
meeting making these calls again next week. noting that we do have an
agenda today. this is the incubation call. So we are covering all of the
items we're incubating right now. I'll get that list on the screen.

Manu Sporny: the items that we have said are basically ready for promotion
are these items here at the top and we continue to incubate the items down
here. and are not done with at least these three items. verifiable issuers
and verifiers is the thing that we are largely going to be discussing today
to try to move that forward. credential refresh. It would be really nice if
we could, this shouldn't be a difficult thing to get updated and done to
push over to ready for promotion, but we have put very little time into it
and so it's languishing a bit because of that. but we're doing things in
priority order and this is the current priority is to focus on the issuers
and verifiers.

Manu Sporny: So we'll start off with just some brief updates on the
verifiable credential working group and where they are and what they need
from us. the main topic of discussion today is a pull request on verifiable
issuers and verifiers. the more decentralized version of it. So everything
that we've been dealing with to date has been kind of around this concept
of centralized trust registries. And I think there's some trepidation among
some of us that we want to solve the problem in a more decentralized way so
we'll be talking about that. and then we'll also have a brief discussion on
renaming the specification at the end of the call. because if we start that
at the beginning of the call, we might spend the entire call renaming the
specification. So just starting kicking off that discussion. We're not
going to be making any decisions today.
00:05:00

Manu Sporny: are there any other updates or changes to the agenda? Is there
anything else that folks would like to discuss today? If there are no
changes or updates to the agenda, we'll use this and go forward. first
agenda item is that the verifiable credential working group has started
meeting again. that group some of us are in that group. we're in
maintenance mode right now which means that we're only meeting once a
month. we're only really meeting to maintain the current set seven whatever
specifications that we've published in the G. During this next iteration
we're discussing point releases and that sort of thing.

Manu Sporny: in maintenance mode we are not allowed to add new features
except for render method and confidence method per the specification. which
means that if we want to do any of these other items here we have to
recharter and we've noted that with the group and we are hoping to get a
proposed charter up and out there before W3C TAC which is in November in
Coobe Japan this year. for the things that are scope in the current charter
and that includes render method and confidence method. These two we could
make a decision to publish them as final community group specifications. we
in this group have already said they're ready for promotion. we're not
going to touch them until the BCWG picks them up.

Manu Sporny: so what we should probably do is publish these as final
community group specifications at this point in time. would anybody object
to doing that? All that is we basically change the header on respec it
generates a final copy. We publish it in a way that archives that final
copy forever. as long as the W3C and the Library of Congress exist. and
then we ask anyone that has any IP commitments, if they have any to do a
final, sign off on them. and then we notify the verifiable credential
working group that those items are ready for them to be picked up by them.

Manu Sporny: if we say yes today, I'll go ahead and kickstart the process.
It's a pretty easy process. it takes a day or two to do. and then we go
from there. And then we've handed those two We've promoted them and handed
them over. So, let me ask again. would anybody on the call object to us
publishing final community group specifications on these two so that the
verifiable credential working group can pick up the work and start
progressing it on the standards track?

Tom Jones: Could you post that link in the chat for me?

Manu Sporny: So, I'm hearing. Yes, absolutely. there's the link to what's
on the screen right now. Is that what you wanted to see, Tom? Okay.

Tom Jones: Yes. It's hard to find the microphone button. That's Thanks,

Manu Sporny: Okay. I'm not hearing any objections. Again, the specs aren't
done. All it means is that we're just, doing a static release of them.
that's a snapshot and then the VCWG is going to decide whether or not they
want to take on the work and they could decide to change, any parts of the
specification. It'll be under working group control at that point.

Manu Sporny: okay. I will get that process kick started today or whenever I
get some free time this week some point. Okay, that's the first item. We
will be asking that same question for some of these other documents. But
right now, until there's a clear rechartering or at least the new charter
is up there, I think we can just not do that for now. Save ourselves some
time. we can still do some iterations. that's it with the VCWG and where
they currently exist. I think the current plan is to keep in maintenance
mode until TAC explore the new charter and new work that needs to be done
around TAC and after TAC and then slowly pull in, the work that we're doing
here into that group.
00:10:00

Manu Sporny: Okay. That's it for verifying credential working group. the
next item up is sure.

Tom Jones: Sorry, could I back you up just sorry to do that. I see some
issues in the confidence one.

Manu Sporny: Yeah. there will be issues. It doesn't mean it does Yes.

Tom Jones: I mean are you publish it with issues in it? Thanks.

Manu Sporny: You can cuz it's just a community group specification and all
we're saying is the only thing we do here is we incubate it to a certain
degree. but then when it gets handed over to the working group, the working
group has to deal with the rest of the issues. There will be new issues
that are raised either by the working group or external parties. It becomes
a more formal process. So we won't close those issues. Those issues will
just be transferred over to the working group to deal with. Yep.

Manu Sporny: going back to the current agenda item. this is the discussion
around a more decentralized version of verifiable issuers and verifiers. to
kind of kickstart that discussion, I added a PR around what that might look
like. and specifically there's a section around let's see issue roles
around decentralized verifiable roles. I just made verifiable role is I
don't know how I feel about it. I don't really like it all that much, but I
wanted to try and name something here.

Manu Sporny: so the idea here is for a more decentralized list in focusing
on an issuer do I trust this issuer to issue X how do we do that in a way
where you can centralize that list you can take those things and you can
put it in a central place and people can download it from that central
place but is

Manu Sporny: there a way for us to decentralize that so that if a verifier
wants to know if you want to present something to a verifier and the
verifier says these are the authorities I trust for these types of
credentials they can communicate that to you and then you can respond back
with I've got a proof that the issuer I'm going to the credential I'm going
to you is going to be associated with an issuer that is authorized to issue
based on your root of trust. Right? So that is the decentralized version of
this. That is where the verifier doesn't have to phone home. They don't
have to go and check a centralized list. it's a bit more decentralized.

Manu Sporny: Yeah and as Dave said there are ways of making this even more
unlinkable in a kind of a zero knowledge way where you can prove that the
issuer that you're using for a particular ZKP is anyway I don't want to go
into those details now but okay so let me kind of go through the example
here but before we do that Demetri go ahead you're on you.

Dmitri Zagidulin: No. go ahead with the example. I want to go when you're
ready for questions.

Manu Sporny: All so let's just look at an example on what this might look
like. and again, modeled it as a grant. I don't really like this either.
but the idea here is that you've basically got an authority of some kind
that is going to issue a verifiable credential.

Manu Sporny: And in that verifiable credential, they're going to say, I
recognize another issuer to issue credentials of this type. And for this,
we're just using JSON schema. So basically, if they can use any arbitrary
JSON schema that they want. But if the credential matches JSON schema then
that the issuer is issuing a specific type of credential that authority
recognizes them to issue. the reason for the use of JSON schema is that
sometimes these authorities might want to be very specific about the type
of credential. Right? It's like I don't trust you to issue just any kind of
bachelor's degree.
00:15:00

Manu Sporny: you are only accredited to issue these types of bachelor's
degrees or you were only accredited to issue these types of bachelor's
degrees between these dates, right? You lost your accreditation for a
while, you got it back, a bit later or you've gone out of business and so I
only recognize you for, this many years. and so JSON schema is used to kind
of get at the richness of what some of those, tests might be. clearly can't
get every use case there, but got to start somewhere and so this might be a
good place to start. the other design decision here was that we could get
very complex with the data model and we' do that. we're trying to start
with something a little simpler that covers a series of them.

Manu Sporny: There are performance concerns around this you didn't say what
type are the context in there or not. but this approach we think works for
just kind of any kind of JSON based structure. So even if you're not using
verifiable credential or JSON LD or something like that you can still match
on JSON schema. and so on and so forth. and then, we do the digest
multi-base thing to make sure that, we tied in there. So, let me stop
there. I'm sure there are questions at this point. Go ahead, Joe. You might
be muted or you are muted. I can see.

Joe Andrieu: I was just deferring to Demetri because his hand was actually
up All right.

Manu Sporny: I'm sorry. Sure. Go ahead, Dmitri.

Dmitri Zagidulin: Thanks, I appreciate it. Okay, one thing that immediately
springs to mind that we've got is that role might be combining too many
things because we've got two crucial things going on here. We've got is
this a known entity and then what is the entity allowed to do, right? and
one is valuable without the other. for example, this is a known entity in
that this is a KYC organization. Do we know whether it's authorized to
issue or verify? No, we don't yet. But for the user interacting with this
thing, at least that's an important piece of information. At least we know
who we're dealing with, if not what they're allowed to do.

Dmitri Zagidulin: Similarly in some sort of exotic anonymous use case we
know that this entity is allowed to issue or allowed to verify but we don't
know who it is. So I think those are two crucial dimensions that we should
model. so I think role is too coarse grained and com combines those two.
whereas I think we should look at it as is this a known entity and…

Joe Andrieu: I'm still concerned that we aren't yet aligned with the
conformant language in the VC spec about validating claims based on…

Dmitri Zagidulin: then what is it authorized to

Manu Sporny: Great input. go ahead Joe and then I'll try and respond to you
Dmitri.

Joe Andrieu: which issuers are considered definitive for claims. this seems
to suggest that if some authority grants someone else a schema then they
are definitive for everything in that schema. but there's a lot of stuff on
my driver's license for which the DMV should not be considered definitive.
And there are things on my driver's license that they should be. So, I
think there's still some more nuance to tease out.

Manu Sporny: Yeah, plus I think that makes sense too. plus one to what both
Dimmitri and you are saying. there's a number of rough edges here. Right.
So this issuance grant not being co fine grained enough. Demetri I agree.
but I don't know what the other types are going to be. So I think maybe we
raise an issue and say We need to figure out what the types here are. it's
not, issuer and verifier and maybe role based things are just way too
coarse grain and we need to get very specific about it. plus one to that. I
don't know what to replace it with right now Demetri in the PR to make it
feel acceptable.

Manu Sporny: so looking to you to say this is an issue let's add it and
maybe we can merge or no we shouldn't merge until we add these items. Joe,
to your point, yeah, you're right. I mean, there's another ecosystem here
where, you kind of look at all of this stuff and you're like, none of this
stuff is necessary. we are the verifier. We will decide what we think, the
authority should be authoritative and we're just going to ignore this,
right?
00:20:00

Manu Sporny: I think we can get down to specific claims, but you said, when
it comes to a driver's license, and we've got an authority that is a bit
overzealous on what they believe, DMVs are authoritative for, and we've got
a disagreement kind of in society on whether or not the DMV is actually
authoritative for, that particular

Manu Sporny: thing. so, I'm trying to think of something that could be
controversial.

Manu Sporny: So birth date, the DMV is not authoritative for birth date,
right? if you ask a vital records agency, they're going to be like, the
only thing they're authoritative for is your ability to drive. That's the
only thing they're testing. Every other piece of data that they have on
that driver's license came from somewhere else. especially your birthday.
sure, please go ahead. Excellent.

Tom Jones: Can I give you a hard case?

Tom Jones: So, the question is whether the MDL is authoritative for organ
transplant donation. It turns out that, the one state may issue that and
say it's true and another state may say that's not acceptable in our state.
So I don't believe that the assertion of an authority being authoritative
is necessarily a fixed constant thing.

Manu Sporny: I think that's absolutely true and yeah that's correct. so I
think and Joe to your point what do we do about quote unquote authorities
that are overreaching with this particular thing I don't know how to
address that broad question Joe I think the authority can say whatever they
want and they can create whatever JSON schema they want but it doesn't mean
that they're actually authoritative for you

Manu Sporny: know that thing. right.

Tom Jones: in a particular jurisdiction. That's the point. Right.

Tom Jones:

Manu Sporny: At all, I mean, people think that, driver your language is
more careful, Tom. I like it better, but I think there's just general
uneasiness about these authorities and what they're going to say and what
happens when it doesn't actually align with, reality, the complexities of
jurisdictional reality. Mhm.

Tom Jones: And my driver's license may be perfectly valid in Austria today,
but not tomorrow.

Tom Jones: That's the way the world works, right?

Manu Sporny: Yep. Yeah.

Manu Sporny: So yeah, absolutely. so Joe, I mean I don't know. I mean, what
issue can we raise to recognize that or is there a technical change we can
make to address the concern that you have?

Joe Andrieu: I think the claims have a definitive URL. I mean, we can
literally have a data structure that has the expanded RDF identifier for
the property that this issuer is deemed to be definitive for.

Manu Sporny: okay. go ahead, Dave. I got a thought on that.

Dave Longley: Yeah, that's worth exploring. and that's kind of what I
thought you were getting at, Joe, but I worry that it's insufficient to
say, I would recognize you for making this claim, but can you make the
claim about anyone or anything might be further constraint that's required?
And so, I feel like there are additional challenges. Maybe that's not true.
And maybe we find that all we need to do is list all of the, URLs that
globally disambiguate whatever the claim is and that's sufficient and that
works for the model. But intuitively, it feels like people would want to
say, you can make this claim, but about things that might have these other
properties or these other claims that are true about them. And it gets more
complex.
00:25:00

Manu Sporny: All right, thanks Dave. yeah, Joe, I mean, one of the things I
struggled with in this PR was, how specific do we want to get? The reason I
thought Jason's schema would probably strike the right balance is because,
if remember JSLD, you're only supposed to use as much of it as is helpful
to you. And in this case if the schema checked the contexts and it checked
the properties then you are effectively able to encode that full URL into
the JSON schema check. So while we're not spelling out the entire URL you
can construct a JSON schema to basically do that test for you.

Manu Sporny: in a way that's pretty clear about what you mean. the only
other, thing we could do is create a new data structure that's not JSON
schema and, list the URLs out explicitly and then potentially piss off a
whole bunch of people that don't like using URLs or hate Jason Lley or
whatever, I was trying to use JSON schema as a good enough, middle ground.
I don't think the JSON LD, the semantic folks are going to complain about
it.

Manu Sporny: And it puts it into a form where, the people that really
dislike Jason LD should hopefully find it acceptable. go ahead, Joe.

Joe Andrieu: Yeah,…

Joe Andrieu: I think Dave's core point I agree with, but it's why the
structure of the implied semantics here I oppose generally I don't
understand how people think that this particular approach of deferring
authority to someone else is helping in the way that they think it we know
Tom Jones pointed out what's true in Nevada is not true in California. so
saying that this issuer is definitive for this thing no matter what
jurisdiction you're in is kind of crazy.

Joe Andrieu: So there's something that is desired here that I don't think
has anything to do with validation. And if we don't have it, and that might
be fine. Maybe that's how we get around is we do not describe this as how
we validate a verifiable credential because if we're not getting to the
actual claims, then we're not addressing the substance of what you are
validating. we might be helping with verification somehow. but I think the
schema itself doesn't tell me that the DMV shouldn't be considered
definitive for my address, Because the DMV schema is going to include the
address and people are going to say, "Wait, if I'm accepting this thing
from the DMV, then I have to accept all these PDF47 data points as
definitive." So that's it.

Dave Longley: So that's all right.

Manu Sporny: Yep. Go ahead, Dave. We got a queue.

Dave Longley: I think a couple things are going on here. I think that we
need better examples of what these credential schemas can be because I
don't think that it's maybe credential schema isn't even the right word.
this seems like it could be expressed as a partial schema on a credential
where the number of additional properties in JSON schema terminology you
can set additional properties to true and allow other things to be claimed
which creates sort of a problem on the validation side.

Dave Longley: did you mean that you can now claim whatever you want in
addition to what's in the schema, which clearly that's not what we want to
have happen. But if the credential schema, for example, listed that the
jurisdiction was had to be the constant North Carolina, for example, then
if you tried to issue something with a different value, it would not meet
the schema. But I think we're stretching the idea of this being a
credential schema a little too far. So some other kind of schema and you'd
have to be really careful with how you went about evaluating it and in
understanding the semantics of it. you might want to take this schema when
you're done check it against a credential and then convert it into some
other technology like JSON pointers and pluck out the bits from that
credential which might have had lots of other things in it.
00:30:00

Dave Longley: you could pluck out the bits that this particular authority
said was but it wouldn't match that schema unless it matched the right
state for which this authority is saying recognizes you as an issuer.
there's a bunch of details there and I worry about finding the right
abstractions and the right APIs to make it so people don't mess up the
validation bits, but I get what the tool is trying to do in that sense.

Manu Sporny: Thanks, Dave.

Kayode Ezike: So I guess as I was listening I was wondering if part of the
solution is reminding ourselves that in the real world we do expect for
there to be multiple of these lists, right? I think and so I mean couldn't
it be possible that two different lists sort of assert different types of
authorities for certain entities than others? And I think that is the way
that we reconcile these differences in jurisdiction and so forth. But maybe
I'm missing a detail that confounds what I just said.

Manu Sporny: My read is the same as yours, go ahead, Phil. You're next.

Phillip Long: Yeah, this sounds like we're talking a little bit about what
Demetri was mentioning before, which is we're talking about something, an
organization that has a certain position to be able to do something and now
we're arguing about the details of in what context those things are and
where are they applied in such and that's where I think we're getting we
just need a vocabulary that is much more nuanced than we're able to use
here so far.

Manu Sporny: Plus one to all of that. And I don't think so going back to,
Joe's, concern in what is what is this entity actually authoritative for? I
don't think we're trying to do that with this particular VC or this
credential, right?

Manu Sporny: as Dave mentioned I think we're trying to do it in a coar
grained way but as Ted is saying in the chat channel these largely are
verifier business rules and as Tom said we cannot cover every single case w
with this thing right I mean I mean we could attempt to and we'll be here
for two and a half three years trying to figure out the language to express
this stuff but I think this is more coarse grain it's more like there are
22,000 emergency management agencies in the United States and there are
only four kind of national bodies that acknowledge those 22,000 entities.

Manu Sporny: Is there a way for us to basically say the four, bodies, these
author quote unquote authorities, have basically acknowledged that this
county in the middle of Montana is allowed to issue a first responder
badge, Because they're a known first responder agency. I think at a high
level, that's all we're trying to get to. can they issue a badge with what
are they authoritative on that is complex and changes from agency to agency
and I don't think we can get to that solution or rather I think if we try
and boil that ocean we'll be here for a while so think I don't yeah so I
think as Dimmitri

Manu Sporny: is asking I guess we need to decide what definitive enough is
or if we're even trying to do that maybe I thought what we were trying to
do here is just get the fact where there's an authority that says this
issuer I know of this issuer and they can issue a credential of this type
and here's a rough schema that you can use to match against it. it is still
verifier your job to figure out whether or…

Manu Sporny: not the properties are definitive for the business rules and
the use case you're trying to execute. go ahead Tom. Yes.

Tom Jones: I'm confused about who's actually issuing this.

Tom Jones: So, I mean, let's be very specific for the state of California.
Is this being issued by VA? But now the state of California is making
claims that apply only in the state of California and what the constitution
says full faith and credit. Each other state decides whether they'll accept
it. I don't think has anything to say about that.
00:35:00

Manu Sporny: Exactly right. This is an optional depends on who you ask at
AMva. yeah.

Tom Jones: I can do that. I can ask Wy Jordan.

Manu Sporny: So there are going to be jurisdictions and things that pay
attention to that list if AMA publishes it. And there going to be other
jurisdictions that pay attention to it and have their own additional things
that they layer on top of it. And then there going to be jurisdictions that
ignore it and maintain their own lists. And so I don't think what we're
trying to do here is we're trying to enable organizations to convey this
information if they want to and we're trying to get other organizations to
voluntarily pay attention to it if they want to.

Manu Sporny: But I don't think what we're saying is that this statement
made by the authority is fully definitive for all use cases across all time
and you must use this stuff, right? again,…

Manu Sporny: it's a verifiable credential. You decide whether or not you're
going to pay attention to the contents of it not and to what degree you pay
attention to the claims. right now I'd rather no because we're working
through this and I don't want that kind of it's complicated with AMBA.

Tom Jones: Should I ask Amber?

Tom Jones: You don't want feedback from the kind of organization that would
actually issue one of those things. Yeah. So,…

Manu Sporny: We're talking to first responder agencies and other folks like
that that are issuing that could issue this. We're talking to vital records
agencies.

Manu Sporny: we're getting input from those places. I think it's way more
complex to ask Amber this question at this point in time, Tom. …

Tom Jones: you're talking to the Boulder Labs for first responders.

Manu Sporny: the Bold…

Manu Sporny: who are the Boulder Labs? We're currently talking to a number
of first responder agencies under contracts with DHS, but we're getting a
bit bit off topic. I guess you can feel free to ask them, Tom, but it's
just we would like there to be something a little more fully formed here
before we ask for, opinions. This is the first PR that we've raised here,
right? go ahead, Dave.

Tom Jones: It's run by Nest.

Dave Longley: Yeah, I was just going to put a finer point on the fact that
these are just more VCs and a verifier always takes a look at the issuer
field or states which issuers they're willing to accept something from and
this is just an extension of that. you would look at if you were willing to
accept what this did web authority.ample example had to say in all these
claims about other issuers then you've decided that's some trust anchor
that you're okay with and you can decide whether or not to accept these
other issuance grants or whatever we end up naming them. so I don't think
that's anything new in how any of this operates and nothing says you have
to accept that. that's an external decision that you make in your ecosystem
according to whatever business rules you have.

Manu Sporny: All I guess where are we with this kind of discussion? So,
Joe, let's go back to you. You had a concern. I don't know if the current
discussion has given you clarity on kind of…

Joe Andrieu: I think the languaging changes that might help me most is just
to align more with …

Manu Sporny: what we can do here or what we need to focus on.

Joe Andrieu: how accrediting bodies describe what is happening here. I
think that this is what I was trying to get to with the use cases that
people want this for a reason. I think there are good reasons. I'm trying
to understand what exactly they need so we can deconstruct the technology.
And I think what people are looking for is to have some other authority
give them an indicator that another issuer should be trusted for some
reason. And so that could be, the state health department saying these
entities are authorized to issue EMT credentials.

Joe Andrieu: And we want to be able to accept those EMT credentials knowing
that the state has blessed them. and I think that ends up not being about
validating the claims. It's something else about understanding who the
state as an authority has blessed or authorized to act on their behalf in
this small way. so I'm not sure what the text is, but that's been the shift
in my conversation here. menu. I think it's raised an issue.
00:40:00

Manu Sporny: I'm looking for is that a raise an issue and discuss in the
issue thing, Joe, or is that a update the PR with specific language or…

Joe Andrieu: So, let me get over there and…

Manu Sporny: Okay.

Joe Andrieu: do that.

Manu Sporny: And then Dimmitri going back to kind of the issue you raised
is that an issue thing or is that a concrete change to the PR thing.

Dmitri Zagidulin: Yeah, good question. not yet. Just wanted to start the
conversation with all of you about thinking in terms of entities and
recognitions. Okay.

Manu Sporny: Got it. But let's see. If we could raise two issues, I could.

Manu Sporny: So, Dimmitri, would you mind raising an issue? it can be
vague, but I just want an issue marker that I can kind of put into the R,
both your and Joe's, so that we can start tracking it,…

Dmitri Zagidulin: Okay.

Manu Sporny: and keep that concern in the spec. okay.

Dmitri Zagidulin: Can just quick logistic will issues get moved when this
gets passed over to the WG.

Manu Sporny: Appreciate that. So, the go ahead. Yes. Yeah. Yep. Yeah.

Dmitri Zagidulin: Okay, cool.

Manu Sporny: we transfer the entire repo. that's what we do. So, Joe's
raising an issue, Demetri is raising an issue. I will integrate those
issues into this PR. and I'm not going to merge this yet. I think we need
to get Isaac and David Chadwick's feedback on it. and once we get that, we
can kind of go forward.

Manu Sporny: And then Tom, once I think we settle on this is what we're
thinking, I think at that point, let's go and ask for opinion. just
because,…

Tom Jones: Sure, that's fine.

Manu Sporny: showing somebody something halfbaked is probably, could send
them down the wrong path.

Tom Jones: Somewhat responding to Joe, it isn't just governments. So, we
have Canara issues certificates saying somebody is allowed to issue a
certificate saying that you're a NIST 863-4 compliant. So there's also
Canara as one besides ANVA.

Manu Sporny: Plus one to that. and it can even go all the way down to, your
local government, has decided that other, organizations in the local
community can issue, credentials.

Manu Sporny: So it doesn't have to be this national thing. It can also be
very localized or…

Tom Jones: In my state,…

Manu Sporny: at least Mhm.

Tom Jones: it happens to be the county and not the state that issues these

Manu Sporny: Yep. All right. I think that We'll come back to it after the
adjustments have been made. let's see it's 11:45. let's the other thing I
want folks to think about is that Dimmitri was thinking about your comments
on the open ID federation stuff and then also thinking about this train
stuff. and these are examples of other ecosystems that they have their own
trust frameworks their own trust formats that kind of stuff.

Manu Sporny: I'm wondering if we should reposition the specification to
just point to those documents that already exist that already have formats
instead of trying to move into the core data model here. So the suggestion
and definitely don't want to debate it today but maybe when Isaac and David
get back is there a way for us to put together a verifiable credential that
can then just defer to the appropriate ecosystem if you want to do a Etsy
train trust list thing using their XML format then we can generate a
verifiable credential that points to that XML file that tells you it's a
train thing and then we don't have to
00:45:00

Manu Sporny: do this complex mapping operation between the XML and the JSON
stuff and the verifiable credential stuff we just point to we can say look
there's a trust list thingy that you can go and read there the idea that
would be kind of like how we're using JSON schema down here but instead of
credential schema we'd say there's a train trust list over there's an open
ID federation thingy over there and we defer entirely to that ecosystem on…

Dmitri Zagidulin: Seems like a good idea worth talking

Manu Sporny: how you interpret that document. So, I'll go ahead and raise
an issue and we can kind of discuss that during the next call. Okay.

Manu Sporny: the other thing I think David Chadwick raised an issue to
change the document title. now that it's clear that the document only
specifies a data model for verifiable lists and doesn't contain any
protocol elements, then it is preferable to change the title of the
document to one that's more accurate. I suggest data model for verifiable
lists of verifiable credential entities. I had suggested verifiable roles
which again I don't really like all that much but I think this is the
section of the call where we can bike shed a bit brainstorm a bit about
what are we actually trying to do with this specification.

Manu Sporny: so does anyone so we currently have verifiable issuers and
verifiers but it might be better generalized as these are entities I know
and these are the things they're allowed to do. specifically for issuers
these are the issuers I know and these are the credentials they're allowed
to issue. for verifiers, these are the verifiers I know and these are the
credentials they're authorized to request. and then to Demitri's kind of
use cases, I don't know this entity, in I don't Dmitri, you had two other
ones that didn't I think neatly fit into issuer verifier maybe.

Joe Andrieu: Excellent.

Dmitri Zagidulin: So I mean yeah I really like the known entities
terminology …

Manu Sporny: Gotcha.

Dmitri Zagidulin: because then we can talk about they're recognized to
issue verify I don't know search index store whatever

Manu Sporny: So, no known entities of some kind. go ahead, Dave.

Dave Longley: this might not be the right spec for it. and maybe this is
different future work. But another thing to consider is flipping the script
on this so it isn't some authority saying these other things have sub
authority based on my own authority instead of driving it all from an
authority perspective. these could be statements made. I would trust other
parties to make these claims and that might help create more decentralized
trust frameworks and networks and allow us to explore things in a different
way. So it isn't that approach.

Manu Sporny: Great. Ted

Dave Longley: I don't know

Dave Longley: if this is the right spec for that, but we might want to
consider using that sort of language and see if we can model what we're
already doing in that way because it might allow for greater innovation and
greater decentralization.

Ted Thibodeau Jr: Yeah, I just threw into the chat,…

Ted Thibodeau Jr: allowed to issue is the wrong framing. I will accept VCs
of these types from this issuer and I will these claims made by this
issuer. the issuer can say anything they want still. there's no allowance
or not.

Ted Thibodeau Jr: Issuers can say anything they want about anything and the
impact that has is dependent on my business rules which say that Joe's
driver license is not acceptable to me because it was issued by Fred's wash
and glow. but if it is issued by the state of Massachusetts then I'll
accept it and…

Ted Thibodeau Jr: the state all the statements therein I will trust. except
for hair color because that's constantly mutable. And we know that Joe
likes to have purple hair sometimes. this is the sort of thing. It's very
tenuous, but that's the way the system is built. That's it.
00:50:00

Manu Sporny: Mhm. Yep.

Manu Sporny: Good thoughts. Dmitri

Dmitri Zagidulin: Building on that, I wonder if it makes sense for us to
split the concerns out into two different lists. One is just KYC entities
and the other one is wrestling with the questions of grants, recognitions,
relevance for issuing and things like that because those two things are
definitely separate, right? there's a number of trusted authorities that
can KYC organizations and then a different set decide on and like Ted
mentioned it's such fine grained business logic that matters. So yeah, I'm
proposing we split the known and what they're authorized to do into two
different lists.

Manu Sporny: Good input, Dmitri Joe.

Joe Andrieu: Yeah as I mentioned in chat I think the allowed language is
part of…

Joe Andrieu: what I think we need to shift. the interesting I agreed almost
entirely with what Ted said with one nuance which is these lists are not
what the individual verifiers using for their own internal validation rules
which is what I think you described.

Joe Andrieu: This is this pattern where we want to defer to someone else so
they can help us because we don't know all the medical trainers who are
qualified in the state but the state knows all the medical trainers who are
qualified in the state to train in different areas. So there is something
about hey I want this reference from external parties that will help me
sort of make this decision. that said I think just KYC is a dangerous path.
Demetri because in general you actually need very specific things for
different aspects of KYC. So I'm just KYC then hey someone who's a
financial institution has access to the OFAC list has checked me on the
OFAC list and someone else might check me against the ITAR list and someone
else might check me against a different list. So that's all.

Manu Sporny: Thanks Dmitri, you're up.

Dmitri Zagidulin: So I want to expand on why I was proposing that just
organizational identity verification might be useful by itself. and that is
as a transitional phase as a stepping stone towards the kind of ecosystem
we want. For example, in education, right? let's just take university
diplomas. there's a list of universities and then there's v various
accredited bodies.

Dmitri Zagidulin: by just focusing on organizational identity verification
we can reuse the existing infrastructure of registars looking at the lists
of which bodies are accredited their paper lists or whatever's in their
software until those accreditation bodies get their act together and start
issuing these VCs. so my point is we can start issuing identity
verification much earlier and much easier and that'll add enough value
until the accreditationalists get their act together.

Manu Sporny: Plus one for kind of separating the concerns that you
mentioned Dimmitri when you said the KYC or identity verification I was the
first thing that popped into my head was like isn' that just a regular VC
like is isn't that just what you can currently issue with the VC meaning
that felt like a very good constrained focused data modeling problem that
just had to do with the identity of an organization, the name of the
organization, maybe their URL, number that you can reach them at or
something like that. and so I don't know.

Manu Sporny: I mean, I'm, plus one for, people doing that work and that's
good and nice and everything, but I'm wondering if that feels like to a
certain degree outside of and maybe it isn't. but it felt kind of like
outside of the verifiable issuers, verifiers, thing that we're talking
about. plus one for splitting that out. I didn't think that that what the
spec was trying to do. But totally understand that that is definitely what
train and some of that stuff's trying to do, I mean, there's a very big
kind of section that's about accreditation and all that kind of stuff.
yeah, plus one for separating it.
00:55:00

Manu Sporny: I think at least the core thing again just kind of with my
corporate hat on one of the things we're looking for here is just if
somebody wants to externalize some part of that the trust metric I am
deferring to the state to tell me who the medical practitioners are in my
state it's not a part of my business specialty I just give me something
that says that the state has said that, one of these issuers for medical
practitioner certificates are valid. and so going back to the I think known
entities maybe Demetri is more about the KYC thing.

Manu Sporny: I'm wondering what this other thing is where you're like,
there's some authority out there and they have said that they would using
Ted's language trust, someone that comes in with this credential. again to
agree with what Ted and Dave are saying. maybe we can frame this in a more
decentralized way. I agree with Joe that the languaging around authority
and allowed is probably too strong. as long as we're able to kind of
address these use cases for there's a state agency and they've said that
these other issuers within the state are, good for them. and therefore they
should be good for you if you don't want to, specialize in vetting these
organizations.

Manu Sporny: I still don't think we quite have a name though. which is
fine. We can keep exploring Go ahead, Dmitri.

Dmitri Zagidulin: I agree with everything you said. I want to address maybe
this is a separate concern of just organizational identity one I don't
think as a sort of VC ecosystem have settled on what an organizational
identity VC looks if we have a couple of good candidates then we should
reuse that notation in the identity portion of these verified assure lists
and if not then we have a chance to provide some guidance as to what fields
should be in there. let me give you an example. so the open ID federation
what are they called?

Dmitri Zagidulin: not the trust mark but The entity statement has some
really simplistic fields like entity location like that sort of thing. In
the educational use case we immediately ran into entity name by itself is
not enough. You need to also put in a legal name which is often separate
from the entity name. So it's like Harvard University is the entity name
and then the legal name is the August trusted association of Harvard
registars or something ridiculous like that. so my point is that kind of
stuff is going to be needed for these registries. so we either should look
around and select the existing identity verification VC schemas and reuse
them here or provide guidance for creating such things.

Manu Sporny: Yeah, plus one to that. okay, we're out of time for today, but
these are all great conversations. We will continue them next time. We'll
come back around to the pull request, take another kind of deeper look at
it. We'll talk about, deferring authority to these other trustless
mechanisms. and we'll try to figure out, what the core of this spec is
actually trying to do. food for thought. I'm wondering if we can just say,
what, schema.org or organization that is the base that you use. You can add
your own things to it if you want but it had that distinction Demetri
between name and legal name and other things like that. So we might want to
start there and if that solves the problem 90% of the problem I think we've
made good progress without having to create potentially yet another spec.
okay that's it for today.

Manu Sporny: Thank you everyone for the fantastic discussion. I really
appreciate it. we will meet again next week to continue the discussion.
Thanks all. Take care. Bye.
Meeting ended after 01:00:12 👋

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