[MINUTES] CCG Incubation 2026-01-15

CCG Incubation Meeting Summary - 2026/01/15

*Attendees:* Benjamin Young, Dave Longley, David C, Kayode Ezike, maggie
chadwick, Manu Sporny, Parth Bhatt, Phillip Long, Ted Thibodeau Jr
------------------------------
Topics Covered:

   - *Meeting Logistics & Purpose:* Clarification of call topic,
   introduction of transcription, and general meeting flow.
   - *Data Model Structure & Terminology:* Discussion on refining the data
   model for verifiable issuers and verifiers, focusing on clarity,
   conciseness, and alignment with use cases.
   - *"Recognized Entity" & Actions:* Debating the naming and structure for
   entities that are recognized and the actions they are recognized to
   perform, specifically regarding issuers and verifiers.
   - *Trusted Verifier Lists & Regulation:* A significant discussion on the
   implications and desirability of mandatory trusted verifier lists, the role
   of regulation, and the balance between user choice and enforced security.
   - *Credential Schema & Action Specificity:* Examining how credential
   schema should be integrated with recognized actions, and the implications
   for model extensibility and specificity.

Key Points:

   - The meeting will focus on the "Verifiable Issuer and Verifier" aspect
   of the CCG Incubation work.
   - A notification will be sent out earlier for future meetings to clarify
   the topic.
   - All discussions are being transcribed and are part of the public
   record.
   - The group aims to create a unified data model that addresses all use
   cases and is working through "corner parts" and edge cases.
   - A PR will be raised to memorialize the agreed-upon data model.
   - There is a desire for illustrative use cases to demonstrate how the
   data model translates into practical solutions.
   - Dave Longley expressed initial confusion about the directional mapping
   of the data structure and how it relates to use cases.
   - Manu Sporny highlighted the challenge around the "trust service
   provider" and "trust service provider list" and whether these are
   universally applicable to all use cases.
   - David C suggested starting the data modeling from the smallest atomic
   unit (a single trusted service) and building upwards.
   - Dave Longley emphasized the need to consider which parts of a
   credential can be externalized for privacy and how the credential will be
   used in presentations or requests.
   - David C argued against the scalability of very granular use cases and
   advocated for a more generalized approach, using UK JISC as an example.
   - The discussion on "recognition criteria" shifted to "recognized to"
   and the actions associated with it (e.g., "issue," "verify").
   - There was debate on whether "recognizer" should be a generic
   "recognized entity" or more specific types like "recognized issuer" or
   "recognized verifier."
   - Manu Sporny voiced strong concerns about mandatory trusted verifier
   lists, viewing them as a detriment to competition and user choice, and
   expressed hope that regulations would not enforce them.
   - David C countered that trusted verifier lists are analogous to TLS
   certificates, providing a necessary layer of trust and security, and that
   regulations are a natural evolution of this.
   - Manu Sporny clarified that his concern is with regulations that
   *mandate* interaction or *punish* software vendors for allowing
   non-compliant interactions, rather than optional trust signals.
   - The group agreed that a single entity can be both an issuer and a
   verifier, and the data model should accommodate this without forcing
   separate lists.
   - The distinction between issuer and verifier actions was seen as
   potentially residing in the "action" property rather than a top-level type.
   - The group agreed to use "recognized entity" as a temporary type for
   line 14 and to consider "recognized by" for line 15 for clarity.
   - The conversation ended with a discussion on how to handle credential
   schema specificity under different actions (issue, verify).

Text: https://meet.w3c-ccg.org/archives/w3c-ccg-ccg-incubation-2026-01-15.md

Video:
https://meet.w3c-ccg.org/archives/w3c-ccg-ccg-incubation-2026-01-15.mp4
*CCG Incubation - 2026/01/15 09:58 EST - Transcript* *Attendees*

Benjamin Young, Dave Longley, David C, Kayode Ezike, maggie chadwick, Manu
Sporny, Parth Bhatt, Phillip Long, Ted Thibodeau Jr
*Transcript*

Phillip Long: Good morning,…

Phillip Long: I sent you a brief note.

Benjamin Young: Good morning,…

Benjamin Young: Phillip. …

Phillip Long: Perhaps I haven't actually seen your reply.

Benjamin Young: A reply to my reply.

Phillip Long: Maybe that's my mistake.

Benjamin Young:

Benjamin Young: Yeah.

Phillip Long: When did you send your replay?

Benjamin Young: Yesterday I'll be jealous…

Phillip Long: I was out doing a long walk yesterday afternoon.

Benjamin Young: then That's awesome.

Phillip Long: Yeah. I'm in New York City visiting a friend and the
afternoon was surprisingly clear. So we're staying in Brooklyn at Prospect
Heights.

Phillip Long: I took the train over to 48th Street and then walked all the
way down through Manhattan down to the Brooklyn Bridge and across and back
up through Brooklyn Heights rather the Heights then Cobble Hill and then
Bora and all that used to live in Cobble Hill.

Benjamin Young: Very cool. So, memory lane, I guess.

Phillip Long: It's not almost unrecognizable from when I was there.

Benjamin Young:

Benjamin Young: No doubt. Very cool.

Phillip Long: So, kind of both in interesting and shocking at the same time.

Benjamin Young: As life tends to be. we'll obviously give it some more time
while folks wander in.

Benjamin Young: Manu is planning on being here.

Phillip Long: I hope so.

Benjamin Young: I don't know.

Phillip Long: He's presenting,…

Phillip Long: isn't he?

Benjamin Young: Yes,…

Benjamin Young: generally speaking, he's passed the reigns of MCing this
call to me just this morning. So I've been doing it while he was away, but
I'll be continuing that. and…

Benjamin Young: we'll consequently try and get a notification out much
sooner about what we're doing and on what topic, etc. I don't …

Phillip Long: This one we'll talk about did so I think is that right?

Benjamin Young: I don't know if that's this one or not. We'll find out.

Phillip Long: Okay, we will this afternoon.

Benjamin Young: I think this is the verifiable issuer and verifier call. I
think the did sell call was going to happen later, but I have no idea.

Phillip Long: Okay.

Benjamin Young: No idea. let's see what happens. yeah, also and I'll do
this again once Manu's here. so we probably can kick it off, but I was just
going to note that we are being transcribed. So Manu, there was some
question that whether this was going to be did sell discussion or…

Manu Sporny: No, Did WebVH group that is later today at noon Eastern.

Benjamin Young: the No. When is that one? Yeah, I don't think I have that
one on my calendar.

Phillip Long: just have got it.

Manu Sporny: Yeah, maybe I'll let me go ahead and forward this. edit event
at guest credentials and…

Manu Sporny: invite all guests. There we go. Send it out to CCG. So yeah,
that's

Benjamin Young: Yeah, very good.

Benjamin Young: With that, this call will be the verifiable issuer and
verifiers. all going forward. I think we're gonna rename the calendar event
accordingly so that it's clear what it's about. and should make things more
manageable that way. I do apologize for the late agenda edition. it's same
thing we've been doing. I will drop the spreadsheet link in here.

Benjamin Young: But before we kick it off much more before we get into it I
guess we are being transcribed and there's a W33C process point that is to
state that we are being transcribed by robots.

Benjamin Young: So there's no off the record anything we talk about is
going to be in public record and there's no way to pause the transcription.
So, keep that in mind as you share or manage your mute button or whatever
you're going to do. yeah. So, just something to keep in mind.
00:05:00

maggie chadwick: Can I just think of a minute,…

maggie chadwick: Ben? I'm just going to log out and…

Benjamin Young: Okay.

maggie chadwick: log back in because I realize I'm in my wife's account at
the moment. So, I need to log into Google as myself and then come back in.
Okay.

Benjamin Young: Yeah.

Benjamin Young: We'll give you So,…

Phillip Long: No, that's it.

Benjamin Young: while we're waiting on David, does anybody have questions
or announcements or I don't think this group needs introductions. the bulk
of this is going to be exactly what we've been doing, going through the
spreadsheet, which I will screen share, and continuing to work on
terminology decision making. And is that semiensible size for most of you
or is that better?

Manu Sporny: That's still a little small, but good.

Benjamin Young: Okay, I keep going in.

Manu Sporny: Yeah, that's good.

Phillip Long: Yep.

Benjamin Young: Go a little wider feedback. Is that okay? Yeah. All righty.
we're not going to wait on David. he'll be back when he's back. cool. So,
we had made it through much of this initial part and started working our
way into these prefixed terms and trying to work them towards we'll say
more contextual naming where we don't have as verbose

Benjamin Young: acronymmed term names and also trying to case things in a
way that matches the patterns we use so it's clear these are field names
and not classes. we had also bumped into here we go. a bit of a nesting
problem that we never quite solved I don't think where we had this
recognizer object which was a list which was a list of items which were
service types and bumped into questions of services and service expert
expiration right at the end of our previous call.

Benjamin Young: so does anyone have thoughts on where they'd like to pick
back up or ruminations they might have had over the holidays? Go ahead.

Manu Sporny: Yeah, just I guess a highlight where I hope we're going. at a
high level, I think we're just trying to get to this is really a question
of the group. We're just trying to get to a unified data model that
addresses all of the use cases. And what we're working through right now is
just some kind of corner parts of that data model. and once we figure that
out, then the expectation is that there will be a PR that's raised that
opens a PR for this, one or more PRs to u memorialize where we got to in
the spreadsheet. Is that what everyone else thinks we're doing?

David C: Yep.

Manu Sporny: Okay, great.

Manu Sporny: So I mean I think then we just need to work through the corner
cases. Hopefully we can get through all of them today, but if not and then
raise a PR in parallel if we get through most of it today to just kind of
get the basis of the data model in there and then once that's in there we
can do stuff. We may also want to play around with this is what each use
case would look I don't know if we need to do that before we do the PR or
not. So those are kind I think we're all aligned on what we're doing. I
heard And so I'm mostly wondering whether when I should raise a PR or…

Manu Sporny: when I should start raising PR. So, I'm guessing it's after we
get through, this stuff as much as we can.

Benjamin Young: Yeah. …

Benjamin Young: maybe we look through what the spreadsheet looks like now
and see if there are any things in the way of you doing a PR to continue
the discussion. That sounds okay. this go ahead, Phil. Cool.
00:10:00

Phillip Long: I was just saying that one or two illustrative use cases as
to how this sort of translates into a particular solution would be helpful.

Manu Sporny: Yeah, plus one at that.

Benjamin Young: Yeah,…

Manu Sporny: I think we have issues that call explicitly for and we have at
least three use cases where the data model has to work for all three use
cases.

Phillip Long: Yeah, that would be helpful.

Benjamin Young: especially to cross-section so why don't we look at what
we've got now? And those of you who maybe already have those use cases in
your gates can speak for whichever use case you want to represent and let's
see where things fall off the wagon. the top stuff has not really been
debated recently anyway. we had gotten down to this is in red.

Benjamin Young: I don't remember if it was debated or just an important
part of the model that people had to comprehend. I think it was the latter.
Go ahead. M So it may still continue to exist on line 17.

Manu Sporny: Yeah, I think we had decided the issuer is the list operator.
that's the presumption there. and because of that, we didn't have to have
this separate list operator thing at the top level, but we might want it
lower down. for example. Yes, I think it's an open question, but I think
we're going to try it, on line 17 and see if that works out. and if it
doesn't, we'll have to think about it

Benjamin Young: So we'll leave that as is.

Benjamin Young: as Parthnets I think we had gotten essentially all the way
down this tree to services and how we were going to express services and
then the get service expression stuff came up and I think that's then where
the call stopped. and this is the sort of overall nesting structure of
objects. that's the same on the left side as well just with less ephemera.
and then there were word smithing things about what the type of the list
was. and then of course service type which relates to extracting things
from bid or not.

Benjamin Young: does anyone have thoughts on the overall restructure that
we have so far? Go ahead, Dave.

Dave Longley: Just I have a high level thought that when I read this
structure I feel like I get turned around and that I'm mostly going to be
listening for a little bit to see see if that directional confusion sort of
goes away. I see that we have recognized issuer and verifier at the top
level of a verifiable c that credent about that issuer or verifier and then
we sort of go into who recognizes it and then we go into some list and then
we're back into trust service provider and I start to wonder what the trust
pro is for I start to wonder if we're getting into a cycle

Dave Longley: And I'm just interested to see sort of where it goes and if I
can get myself on turned around or…

Benjamin Young: on it.

Dave Longley: how this clearly maps to particular use cases. So all of that
will help.

Manu Sporny: Yeah, I mean I've had the same challenge for a while. I think
it really gets highlighted around row 28 the services let's see we have an
issuer which is the list operator and then we recognize an entity that is
also a list operator right and then why are the services

Manu Sporny: not attached to that list operator directly because those
services are things that list operator provides directly. And so the only
reason I can think of is that those services are really services that are
associated with the particular trust list. But then I'm kind of like but
the list only has version identifier and sequence number in there. I think
this is a list of services and if it's a list of services why don't we take
services and bring it up to list operator and then there's an open question
of why does the list have a version identifier and a sequence number I mean
I can understand it's because you want to know you have the latest one but
if there's no standard way of doing
00:15:00

Manu Sporny: that then it becomes really difficult to do an standardsbased
implementation of it. so I'm wondering if this is really about the list is
the verifiable credential It lists recognized issuers and verifiers. yeah I
guess it's not the recognized entity right the list operator is separate so
the credential subject it may be that the list operator is a totally
different credential subject and it may be that information does go in the
issuer

Manu Sporny: Right. The issuer is a list operator and the issuer has a set
of services that they provide. and that no,…

Manu Sporny: never mind. That's the recognizer. I'm getting confused as So,
it's fine where I think it's fine where it is cuz there's a recognizer and
that's the list operator and we give information about that list operator
and we show the services that they provide. That feels clean to me like
what's on the screen right now feels clean cleaner to me.

Benjamin Young: Yeah. So to show…

Manu Sporny: Interested to hear others thoughts.

Benjamin Young: what we cut out was essentially the nesting that says
what's that it's a list and…

Benjamin Young: that it has a version and a sequence somewhere.

Manu Sporny: And if we wanted to keep version and…

Manu Sporny: sequence number, we can potentially move it down into the
service because the list is a service I think and that service can have a
version ID sequence number we move list into the service.

Manu Sporny: So the topmost thing is the service and then the service
you've got an array of services and each service could define a list with a
version identifier and sequence number. Yeah, that's right.

Benjamin Young: specific to that service.

David C: It might help…

Benjamin Young: All right.

David C: rather than starting at the macro level, you start at the micro
level and say what is the smallest atomic thing that's been trusted and so
it is a particular service from particular entity that's trusted by some
higher entity. to start at the bottom and…

Manu Sporny: Mhm.

Benjamin Young: Yeah. Dave

David C: then grow it up bigger and then you'll see how many layers you
need to encapsulate on top of it. Yeah.

Dave Longley: So, two thoughts I have that might be helpful is thinking
about when we're using whatever credential we're modeling or…

Dave Longley: credentials we end up modeling,…

Phillip Long: Thank you.

Dave Longley: what parts of it could be sensibly externalized so that they
could be fetched only if necessary or if you're trying to discover more
information in privacy preserving way.

Phillip Long: But not like this for

Dave Longley: Phil, you might not be muted. and then understanding when
this credential is going to be in use or presented or requested would help
understand what's driving the use case. So I can imagine wanting to know if
a issuer verifier is recognized and asking for a credential or having that
be presented during the presentation of some other credential.

Dave Longley: So as a end user I'm presenting some credential and as an end
user I'm using some service that service has asked for a particular
credential and they have told me which issuers of that credential they
trust and so I would present my credential and a recognized issuer who
might also have to then be recognized up the chain by someone else in order
to meet the requirements like that is a use case that is readily available
in my brain for understanding how to use this credential. but that does not
what we currently have on the screen doesn't quite match to that use case.
I don't know or care about cross service providers in that situation. I
just care about a chain of trusted issuers. So getting a good idea of for
this thing that we're modeling on the screen, what is the goal?
00:20:00

Dave Longley: what can or might be externalized because it's not needed for
this use case or that use case…

Benjamin Young: Okay, David.

Dave Longley: but could be fetched in a privacy preserving way. Those sorts
of things might be helpful to me to understand the modeling.

David C: I think Dave's use case is working at a very small level and
doesn't really scale up very well. If you think of the number of
universities there are in America and indeed globally then someone who's
trying to recruit they're not going to list all the universities in the
world that they accept qualifications from. so that particular use case
they've suggested doesn't really scale it.

David C: It's going to be, I trust anybody that in the UK, JC or whoever
Jisk says are universities. So if this qualification came from a JISK
trusted university and that's much more scalable. Yeah. …

Dave Longley: Yeah, I wouldn't be responsive to that because I might not
have described the use case very well. So, the request is I want a diploma
from an issuer that's recognized by a large recognizer is the use case. And
I'm going to be Yeah,…

David C: So, I agree with that. Yeah. Yeah.

Dave Longley: I'm going to be holding a diploma from a small university
that has potentially either a direct linkage to that large I'm going to be
holding a diploma from a small university from a small issuer. That small
issuer either themselves is a recognized issuer that there's a credential
for from that large recognizer or there's some chain to get to it one way
or another.

Dave Longley: And so that's the use case that I'm trying to think about
here in that use case everything is a recognized issuer up that chain. I
don't think about any services that these things have. I don't think about
them as trust service providers. it's just my issuer is a recognized issuer
and…

Benjamin Young: Hey,

David C: Yeah.

Dave Longley: there's some other recognized issuer just some root issuer at
the end of all

Phillip Long: So in the US then the accreditation bodies that divide up the
country effectively aggregate subsets of institutions in their catchment
area so to speak and so we have at least potentially two levels of that
because the accrediting bodies themselves may have something above them.

Phillip Long: But that will cascading level of two to three be a problem in
this model?

Dave Longley: If the question is for me,…

Benjamin Young: Yeah.

Dave Longley: the answer for me is it should not be.

Benjamin Young: Go. Yeah,…

Dave Longley: We need to design something where that will work just fine.

Benjamin Young: Go ahead.

David C: Yeah, I agree with that.

David C: No, what I wanted to say to Dave is that he's thinking from the
viewpoint of a specific trust service provider which is an issue, but if we
make it generic, okay, you've got different types of trust services. So
that's why the generic term trust service is there because an issuer and a
verifier are both subtypes of the generic. So when we do the data model we
don't want at some point we may want to have the generic term and then the
specific instance of it the subtype of it. Right?

David C: So you're a trust service provider and the service you provide is
issuing verifiable credentials or you're a trust service provider and the
service you provide is receiving credit cards or whatever. Yeah. and then
at a higher level there might be you're a trust service provider and what
you are is an amalgamator of all the different universities authorities
from Ben's model right where at a particular region you've got you're
issuing something for all the issuers in all the credential issues in your
region and…
00:25:00

Benjamin Young: Damn it.

David C: then you are a trust service provider of the list that
amalgamating type. so that's why we need the generic type.

Manu Sporny: Yeah, I don't know if we should dwell on this too long because
I think technically we support, s of lists and chaining. I do want to say
that the whole chain thing to me feels it's a lot of technical complexity
for something that you could just point to all the different lists, I get
the whole it would be nice to have this, aggregating, thing. And so you
have one list that says who all the aggregators are and then you go to each
aggregator and then you get the breakdown of the sublist.

Manu Sporny: So for example using the US education vertical you have
regional accredititors and then each regional accredititor accredits their
colleges universities and then you may have the college and university then
also accredit departments whatever w within them. and so you have this
three hierarchy of three thing and it's complex to write software to do
that kind of reasoning it's not impossible but frankly you could just list
all the URLs like that that's what we do for X5 and9 certificates have this
hierarchical mechanism and it supports it

Manu Sporny: But yeah, I know that's the way the world works right now and
today, but the way these lists are done, writing software to go and just
fetch all 15,000 or 30,000 issuing institutions and put them into a single
unified list is not a difficult piece of software to write. In fact, it's
easier to write that piece of software and get it right than it is to do
the whole hierarchical, …

Benjamin Young: Damn it, guys.

Manu Sporny: thing. that said, I'm not going to argue against the whole
hierarchal thing. I'm just very skeptical that that is the way that we
actually want to tell people to do things. that's it.

David C: Yeah, on the X509 from it's much simpler because there's only one
type which is the CA and everything in the hierarchy is a CA and then right
at the bottom you've got the actual service providers who provide web
services that the CAS have issued certificates for. So it's a much simpler
model…

David C: because if you like one-dimensional whereas when we get into
verifiable credentials you've then got much more dimensions much more
complexity

Benjamin Young: So I wonder…

Benjamin Young: if it makes sense to sort of shake up our approach from
this because I think what I've had highlighted here is the thing generally
in debate. but to switch from, trying to hold these different approaches in
our heads and the different use cases in our heads and look at the whole
thing this way that we instead take one or either of these approaches as in
the blue square being there or not there and type it out with values in
another copy of this and

David C: This is…

Benjamin Young: See where we end up.

David C: why I suggesting starting at the bottom, the smallest granularity
and then building it upwards. So if we think of just take one single thing,
verifier, one issuer, one whatever. And saying and we've got most of the
properties because they're in the top they're all classes can have them.
and then what additionally do you need for this particular class of thing
which is a specific instance right of the most generic class…

Benjamin Young: Right. Yep.

David C:

David C: which we got at the build that up and then wrap and then say,
"Okay, what layers on top of that?" Okay.
00:30:00

Benjamin Young: Yep. Yeah,…

David C: And I think that might be an easier way to handle it.

Benjamin Young: that's kind of my thought. Monica, go ahead.

Manu Sporny: Yeah, I want us to get down to the core thing that applies to
all the use cases. So I agree sure we can do that. I think we're going to
burn up the rest of this call in two more calls potentially doing that.
whereas we have this recognition criteria thing that I'd really like to get
settled on because that's the thing that's blocking me from writing R, this
other stuff I think is I think the general structure is fine, It's just we
kind of go sideways when we get to the trust service provider and trust
service provider list and things like that, but that only applies to one of
the use cases that we're trying to solve for.

Manu Sporny: Whereas this recognition criteria thing if you scroll down
applies to all of them and it says that the group is confused by the use
case and that's the core of what we're trying to do here with these lists.

Manu Sporny: I'm wondering if we could do the recognition criteria thing
real quick. Hopefully knock that out this call and then spend the rest of
the call on that blue square and whatnot.

Benjamin Young: Yeah. …

Benjamin Young: come back to this stuff on the future call.

Manu Sporny: Yeah. And ideally somebody could do that as homework, right?
And come back with a proposal,…

Benjamin Young: Yeah. Yep.

Manu Sporny: Rather than us all sit here watching things get typed out.

Benjamin Young: And you should be able to write to this. I think everyone
has access to it. So if anyone wants to take on tackling that use case,
David, maybe you can present somebody's doing it. if you can present what
you want in that use case tab, then maybe we return to that on the next
call.

Benjamin Young: so there we go. yeah, because I agree we have a core
feature here that's not really been touched on.

David C: Yeah. The recognization criteria these are really the policies of
the list operator, aren't they? these are the policing procedures that I
use in my creation of this list and by these you will know me.

Benjamin Young: Yeah.

David C: Whether I'm good or not because of the policies that I have
adopted. Do you agree with that manu? No.

Manu Sporny: No, I think it's a very different I do agree that what you
just highlighted is something that in the The recognition criteria is more
mechanical than that, right? So recognition criteria is basically like what
does the recognizer recognize you to do? Do they recognize you to issue a
certain type of university degree credential? That's what recognition
criteria is supposed to answer. So the recognition criteria is I recognize
this entity to issue this specific type of credential or to request this
specific type of this class of credentials or that sort of thing.

Manu Sporny: That's what it's meant for and it's a property that hangs off
of recognized issuer recognized verifier and we had initially thought of it
as an action I recognize this entity to perform this action so…

Manu Sporny: which is very different from policy it's a result of policy
you execute all the policies and then at the end of the day you recognize
this entity to issue a university degree Yeah,…

David C: I think the term's wrong.

David C: Gnic criteria.

Manu Sporny: possibly. So, we can bike shed it. But I was Yeah,…

David C: Yeah. Re recognize to is…

Manu Sporny: but I think we need something like this so that we can
automate the processing of these PCs.

David C: what you're saying. Not recogn Yeah.

Manu Sporny: Yeah. Yep.

David C: recognize and then it's issue credentials that conform to this
schema or…

David C: accept credit cards for money I don't know up to 100 pound
whatever but you recognize to do something as you say action that's what
you said initially you thought of it as an action yeah so not criteria…

Manu Sporny: Yep.

Manu Sporny: D Recognized. Some Yeah. Agreed.

David C: because to me that's sounding like the criteria I've used in my
recognition which was policies.

Benjamin Young: Any objections to kind of switching lanes on this field to
run down the recognize two approach and see where we end up? It does feel
clearer and what to expect inside of it. Thanks for words smithing you. I
don't know if what y'all are writing all are alternatives or…
00:35:00

Manu Sporny: alternatives again.

Benjamin Young: just more. Okay. Is it? Yeah.

Dave Longley: there are alternatives then I think they might slightly
change how that gets modeled.

Dave Longley: Are you recognized as a particular role for what and maybe
this property is trying to do two things at once. maybe that's good or bad.
recognize two …

David C: generally bad.

David C: I would say Dave, I would say generally bad.

Dave Longley: what I mean is you're pointing to an object that will
describe both an action that can be taken and what you could do
specifically both a role that is kind of modeled here as an action and then
the parameters of that action and what you can do with that action. So,
it's kind of two things are happening there. and maybe because those things
are broken out in the sub nested object,…

Dave Longley: it's not a problem to do that. hands are going

Benjamin Young: Yeah, I'm on it.

Manu Sporny: I think the role is captured in the type on row 14. So you're
either a recognized issuer, recognized verifier or recognized something
else.

Benjamin Young: Yeah. Yeah,…

Manu Sporny: So I think that's where the role is expressed and then
something some entity recognizes you and then you are recognized to do
Something.

Dave Longley: Yeah, I'm not yet convinced whether that jumping around is
good or bad. …

Benjamin Young: I think recognized as I put in column does feel redundant
with being an issuer unless you're recognized as some other thing, right?

Dave Longley: my concern would be you have an object that says what your
role is and then later I mean it really depends on how we go about changing
what's nested under recognition criteria because right now also if you
could put the type down there for issuance the action down there then you
could easily mismodel you're a recognized verifier but you put your actions
down there and the action is issuance. So you shouldn't even be able to do
that with the model is I guess what I'm getting

Phillip Long: So if we're going to focus on recognize too and the actions
associated with it, those actions are a requesting institutions that issue
that type of credential. What's the breadth of the action types?

Manu Sporny: right now.

Manu Sporny: I should show some verification I think.

Dave Longley: Yeah. At and…

Dave Longley: that's a good question. what if I also wanted to model what
if I recognize some entity for both requesting and issuance at the same
time? Should I be able to do that? Would that be done by listing two
different types and…

Dave Longley: then I would have multiple types of actions does the type for
this just become a recognized entity and then the actions that are it it's
recognized to do is all down at the bottom.

David C: I think Dave in that particular case they'd probably have two
different service endpoints.

David C: So they' be recognized as two different services. There's an
issuing service with an issue endpoint and there's a verification service
the verification endpoint.

David C: So I would put them as totally separate.

Dave Longley: that still scratches at my itch around services not quite
making sense to me.

David C: The fact Yeah.

Dave Longley: I don't really care what the services are in these systems. I
don't care how you got a credential if it was issued. I don't care what
service is the one that is requesting a credential. I only care what the
identity is behind that service.

Dave Longley: And so

David C: No, no,…

David C: no. But if I want to get a particular credential, I might very
well be interested. this trust operator or list operator that I trust, he
says that for me to get I don't know some sort of card,…

David C: plastic card in today's world as an electronic one of this
particular type, then that's the service point I would go to get it,…

Dave Longley: Yeah, I yeah,…

David C: right? Yeah.

Dave Longley: I think that's a discovery concern it may not be of use to
include that in this sort of area, but I think it's a sort of an auxiliary
or separate concern and I'd be worried if we conflate those things and
don't do at least one thing that might not be quite the right way to do
that. I feel like there's two different concerns going on there. And I
think if we're going to talk about services in that way, then we shouldn't
bind it to I trust you for this service. That's not what it is. I trust you
for this action. What service it is irrelevant. But being able to get to
discover where those services are if I want to go get a credential or
present one, that's an important use case.
00:40:00

Dave Longley: but I think we need to separate those concerns.

David C: Yeah, I can see that.

David C: I can see that you've moved up a level. You say I don't care how
you got it. Yeah. But I can actually buy into that it's the end result of
it is this particular concrete thing which is this verifiable credential
right so yeah I can understand that yeah exactly exactly yeah exactly Yeah.

Benjamin Young: which is where credential schema is going to take us for
sure. Yeah. Come on.

Manu Sporny: All So, what I'm hearing is that our hype on row 14 is
probably not good, incorrect. It's recognized entity, and that's generic,
and I don't really like it, but it's definitely not recognized issuer or
verifier right now because you can have a single entity be both an issue
and a verifier. And we want to be able to express that in the same list.

David C: I mean the interesting thing there though ma manu is when you've
got this list which is a mixed list do you actually model it as two
separate list so here's the list of issues I trust and here's the list of
verifiers and you have two separate lists

Manu Sporny: I think you can do it that way, but you can also but we
shouldn't prevent them from being combined, right? Because if there is a
market entity that does both it qualifies both the issuers and the
verifiers. why force them to break it into two separate lists when the data
model can just have one list and…

Manu Sporny: everyone just gets the one list and I think computers are so
fast these days that it happens in milliseconds.

David C: …

David C: because it's more inefficient, isn't it? if you've got a whole
long list of mixed apples and oranges, and you're looking for specific
orange, it's much better to go to the barrel of oranges rather than go to a
fruit salad.

Manu Sporny: Any variation of those with hundreds of thousands of entries,
right?

Phillip Long: Yeah. …

Manu Sporny: I mean,…

Benjamin Young: So for you man that distinction would come within the list.

Manu Sporny: but I didn't understand the question,…

Phillip Long: isn't Sorry. Go ahead.

Manu Sporny: I'm saying the distinction between the apples and…

Benjamin Young: So right now we're grouping recognized issuers and
recognized verifiers. And if they were all just the recognized things, is
there a need for a distinction between the apples and oranges in the list?

Manu Sporny: oranges probably goes into the action like line 38, row 38
where we say issuance and verification and the distinction doesn't happen
on row 14,…

Benjamin Young: I see. Yeah, it does.

Manu Sporny: right? It's

Benjamin Young: It does feel like we're expressing it twice as we go.

Phillip Long: So in reality it seems like the majority of folks are going
to be both. I mean isuaries and verifiers. certainly businesses are likely
to be both because if they're verifying they're often verifying for things
that are relevant to them and so they would want to make sure that that
they're getting is not just a credential structured properly but also has
additional things that they care about. so the number of verifiers seems to
be to me the smaller list and I don't think it's needed necessary I guess
from the parsimony perspective to separate it out because the process of
requesting it is computationally simple either Okay.

Benjamin Young: money.

Manu Sporny: Yeah, plus one of that. I'll also kind of use this as an
opportunity to highlight that I think the verifier lists are just a really
bad idea in the general case. don't Don't prevent people from sharing data
that they have control over. I understand the desire, with some governments
to, make it so software can't present an identification card a vile record
or a healthcare record or something like that. But it's such a bad idea.
don't stop people from being able to share, their data. There are other
things that we can layer on top other than, this mechanism.

Manu Sporny: So my hope is that we don't end up with trusted verifier lists
in here. If we do, we're looking at a closed loop ecosystem with incredibly
difficult, high barriers to entry, which means low competition, which means
high prices, all that kind of stuff. so my hope is, we don't prevent this
from happening,…
00:45:00

Manu Sporny: but I hope that we write something in the specification where
we're what, in general, trusted verifier lists are just a bad idea. Don't
do it. I know that can be a controversial statement, especially in the EU.
That's it.

David C: No, no.

David C: I would say it's in the world. I mean, basically what you're
saying is we don't need TLS certificates because people don't need to know
that the website is trustworthy. they should just be allowed to send all
their personal information to anyone.

Manu Sporny: Nope. That is definitely not what I'm saying. That is not…

David C: It is.

Manu Sporny: what I'm saying at

David C: It is because you're saying we don't want trusted verifiers.

Dave Longley: I want to talk about the ultimate goal of that and…

David C: But that's exactly what TLS does.

Dave Longley: I typed it in the chat as well.

David C: Yeah. Right.

Dave Longley: I think the ultimate goal in the verification piece is to
help people decide if it is safe to share credentials with some party. I
don't think anyone disagrees with that goal. what we don't want is for that
to become an allow list that obscures everything and blocks what people act
actually want to do. So on the web with TLS certificates I don't get the
impression that humans can't go to whatever website they want to and then
start typing into a form. it doesn't even cover that you can go to whatever
website you want to and what you want to know is that you're on the site
that you think you're on. That's all that TLS is providing for you.

Dave Longley: Whether or not you decide to start typing in your, personal
social security number or whatever other government numbers, if you have a
government that did something bad with ID numbers, into that site or
whatever else, any of your PII into that site today, that's just a choice
anybody can make. we don't have any protections on that and we don't have
help any standardized signals that help people make those choices. so it's
good to have those kinds of standardized signals to help people do it,…

Dave Longley: but we don't want to control people on what they do. We just
want to help them make safe choices.

David C: Yeah. …

David C: what you're saying, we need to build on what we've got at the
moment. So, on the web, anybody can put a website up. You don't know
whether it's the real name or not. If you want to know that, they get a TLS
certificate and then you can verify you're really connecting to the right
entity. But if you want to connect to an entity, you don't know who he is,
then you're still not the browser. You can get around the browser and still
do it. Now you layer on top of that. you're at the website that really is
who he says Am I really good to give him my social security number and my
passport and things like that or not? here's the markers that allow you to
do that. if this guy doesn't have the markers, you're still allowed to do
it. You can still send all your but it's on your own head.

David C: So all you're doing is we're just layering up on exactly the same
models below with an extra layer of security and trust for the user only
when now it's on the entry of the PII to the website.

Benjamin Young: Yeah, go ahead.

David C: Do you not see it's exactly recursively the same as what's there
today…

David C: but just adding another layer on top.

Dave Longley: Just real quick,…

Dave Longley: it could come that way. there are other ways it can go ahead.

Manu Sporny: Yeah, that is definitely not the way some of the regulations
are being written right now, David. I totally agree with you. If it stays
optional and it's a warning to the individual, that's fine. But that is not
how some of the governments are thinking about it and that is not how the
regulations are being written. it's been turned into a mandatory you will
not interact with this website which is effectively like me going to a
website that has a TLS certificate and then I go and try to type some of my
information into the website and the browser comes back and says no you're
not allowed to interact with this website you can't type that's the concern
that I have and…

David C: Yeah. No,…

Manu Sporny: it's not an unfounded concern we

Manu Sporny: work with, …

David C: no, but what you're saying is no different to the browser won't
let you go to the website that doesn't have a TLS certificate.

Manu Sporny: the browser does let me go to the website today,…

David C: Yeah. Exactly.

Manu Sporny: even if it's the LS…

David C: So why wouldn't the layer on top okay let you go to this pls
website and…

Benjamin Young: Yeah.

David C: enter information that hasn't been approved by anybody and…

Manu Sporny: because the regulations are being written to punish software
vendors that allow that to happen. Yep, that's right.

David C: and that has to be wallet software doesn't it because your
credential in your wallet yeah exactly so exactly…

Manu Sporny: You're not allowed to do that as a software vendor.

David C:

David C: which it's like saying, "We've got a web browser that absolutely
forbids you from going to any website that hasn't got a TLS certificate."
Okay. if users choose to implement or…

Benjamin Young: Yeah, there's
00:50:00

David C: to put on their that sort of web browser and they can. If not,
they'll put another one on.

Manu Sporny: No, it is illegal.

David C: And the same with wallets.

Manu Sporny: the people that build that software will go to jail. that's my
point. that is what the regulation's setting up is as a software vendor, if
you provide that kind of software, one, you will be totally banned from
selling your software in that regulatory environment and if somehow someone
runs your software in that regulated environment and you bypass those
rules, you are liable, dragged off to jail. That's the issue, right? Yeah,
exactly.

David C: I don't see that happening. That's really big, brother. That's
really 1984.

Benjamin Young: Yeah, I think there's text already that plays 1984 out,
David. at the very least, it hands over all kinds of keys and weapons and
beat sticks and the likening the wallet space to the browser space …

Phillip Long: Come here.

Benjamin Young: and ignoring regulations. misses the fact that browsers are
mostly unregulated. Nobody forced browser vendors to implement TLS and the
market has mostly driven that desire and that and nobody's saying, you must
stop allowing people to go to old websites that have never added TLS, which
is still totally viable, let alone self-signed certificates and things that
browsers let you continue past and as they should. but…

Benjamin Young: if you couple regulation to that, which thank God hasn't
happened yet, then we would all be s*** out of luck.

David C: Great.

Benjamin Young: and please transcribe that robot. because that would
prevent us from free action as individuals and…

Benjamin Young: free action does come with risk.

Benjamin Young: But ideally and…

David C: Correct.

David C: And that's the model I'm arguing for where there's a protection
regime that you can choose to use or not use. I don't believe the users are
going to buy into that model that Manu's Mano suggesting.

Benjamin Young: I don't Yeah, but I think you're speaking of governments as
if they're just offering a buffet of choices to the people in their
countries and…

David C: Thank you.

Benjamin Young: and expect the humans to sort it out. And that's not how
regulations when they exist are generally written. And they do come with
consequences that amount to weapons in a room. Whether that's a courtroom
or a prison, it doesn't matter. There's still a weapon that enforces the
law.

Benjamin Young: So what we don't want to do is this space Karine away from
a human-driven interaction space that allows for evolution and have it end
up in a highly constrained, highly regulated lock down before it ever gets
to evolve space, which is the tension I think that that's coming up in

Benjamin Young: in this thing to design a technology the hope is that you
don't design it for trusted players. You design it because you don't trust
any of the players. And if it's truly secure software, then it has to lean
on that. So even if you look at the people writing regulations now and they
have the best intentions at heart, that's great, lucky us. but don't expect
that to last. and build in all kinds of mitigation. that's it. Go ahead.

Manu Sporny: So, let me trying to summarize. I think we're all on the same
page. so, apologies for bringing this up originally in taking us off
course. I think we're all saying the same thing. this information should be
used to help individuals understand whether that individuals or
organizations understand the trustworthiness of the issuer or the verifier
and my hope is that we can also say regulators should not in write
legislation that enforces

Manu Sporny: Because the choice should always be left up to the individual
with that is in control of the software, the end user, the organization
consuming a credential, the person going to a website to share their
credential. these are trust signals. There are not absolute requirements
that you are on or off this list. but again I mean that's sorry let's get
back to I think the core of it which is what are we naming this property?
that's
00:55:00

Benjamin Young: David, go ahead.

David C: Yeah. Yeah.

David C: It's just to say that given Mano's I think his original assertion
was we don't want anything to do with verifiers in this but I think he's
rolled back off that now. so I'm happy that he has rolled it back because
if we built something that was issuers only, then the scenario that manu
was saying is going to come into effect in the world, it means this won't
be used at all because it's no good because it doesn't fit into the
scenario where verifiers are mandatory. So, we only make this software
relevant if it actually does support verifiers as well as issuers.

Benjamin Young: Go ahead, man.

Manu Sporny: Yeah, I never said we shouldn't support verifiers. I said we
should support both issuers and verifiers and those actions, but I really
hope that the The mandatory thing goes away. Anyway, let's get back to the
So,…

Manu Sporny: I think that whole thread maybe was a miscommunication. what
do we want to name this property?

David C: Yeah,

Manu Sporny: Because I need that to raise the PR.

Benjamin Young: and by property you mean the type of the line 14,…

Benjamin Young: And also line 37.

Manu Sporny: Line 14 and then 37 and 38, right?

Benjamin Young: So this is not a suggestion for the type, but we're looking
for something that is generic. And then we're also looking for how these
read together. Yeah.

David C: I mean what we're addressing is this is a real fundamental issue,
isn't it? it is the list fruit salad or is it separate apples, oranges,
bananas or whatever. And the way the top at line 14 is you've got your
bananas and your apples and the oranges. if we actually say it's fruit
salad, then we don't need the specific type at line 14, do we? Because it's
fruit salad and there can be anything in it. And if a new fruit comes up
like dragon fruit, we stick dragon fruit in as well. …

Dave Longley: So you still need a type…

David C:

Dave Longley: because you're still saying that it's a typed object that is
about recognition. But it doesn't have to be more specific than that.
Otherwise, I Recognized entity

Benjamin Young: Yeah. I mean recognized thing as clumsy as it is gets to
the point.

Benjamin Young: Yeah. Entity could be because I think what I have
highlighted here is what we're trying to shape, What is recognized by whom
to do what is

Manu Sporny: Yeah, let's recognize entity for now and then see how the rest
of the properties shake out and we can come back to it. in recognize two
should we have a property like action issue verify Hi ants.

David C: Could we actually change line 15 to be recognized by and…

Dave Longley: Yes. Yeah,…

Benjamin Young: That probably be clear.

Benjamin Young: Yeah. Yeah,…

Manu Sporny: Yep.

Dave Longley: seems fine.

Benjamin Young: I think so.

David C: then recogn recognized to that's fine. Yeah. Okay, that makes
sense and it's a bit clearer.

Benjamin Young: Say that again.

Dave Longley: We might end up putting recognize inside of recognized too,
but you'd get a lot of repetition. But there would be some value in doing
that. We don't have to do that right now. Just something to consider.

Benjamin Young: Put two inside of by.

Benjamin Young: Recognized by it. Right.

Dave Longley: Yeah. You're recognized to do this by this party.

Benjamin Young: Because then you could have several recognized by Sounds
right.

Dave Longley: That's right.

Manu Sporny: Maybe the type needs to be issue and verify. Yeah.

Dave Longley: I think we can do that. but it does lock us into this data
model. So it's cleaner…

Manu Sporny: Yep. What's the type on this thing? Action.

Dave Longley: if you move it into The recognition action or…

Dave Longley: recognized action

David C: Okay. Yeah,…

David C: but you're going to have to say because credential schema is
specific to a particular action.

Manu Sporny: Yeah, it's optional for everything but issue and verify, right?

Dave Longley: Yeah, this could also be a recognized role and…

Benjamin Young: ground. We go

Dave Longley: a specific role. And now we're just defining an access
control list of some of a specific kind without calling it access…
01:00:00

Dave Longley: since it's only about recognition.

David C: I don't like having credential schema under recognized action.

David C: I mean to me it doesn't make sense as it is exactly.

Dave Longley: Yeah, it's too specific to the action and that

David C: So you're recognized to do an action but you don't know what
action it is at the moment. So we've already got the action So take line 39
certainly wants to be removed from there and then under the action field
there'll then be action specific properties. Right? because now you've got
down to the finest granularity. they're going to have to be different
properties. Otherwise, if they're the same properties, everything performs
the same action, which is not.

Benjamin Young: Yeah, that what I put on 41 is probably a stupid name, and
that color is going to be hard to read.

Dave Longley: And maybe it's not credential schema. Maybe it's just
validation schema. Maybe you can check any action.

David C: No, we already have credential schema Dave, it's already a
well-known term.

Dave Longley: I know.

David C: That's so…

Dave Longley: I know.

Benjamin Young: Yeah. …

David C: if that goes below the action of issue.

Dave Longley: I know.

David C: So if line 39 is set to issue, then credential schema is a
perfectly sensible property to have underneath that. So I think you need to
separate it out here Benjamin into if the action is issue then are the
properties. If the action is verify, these are the properties.

Benjamin Young: I think if we're going to do that, we're going to end up
with that showing back up in the title.

Dave Longley: So either we're having the fact that credential schema
happens to already exist drive this model.

Dave Longley: In which case I would if we're going to do that I would not
have recognized action. that would become a base class and there would be
specific classes for issue and verify but that has the downside of making
this a less extensible model for people who want to come in later and add
other actions. if we find a different way to either reuse credential schema
or…

Dave Longley: use a more generic field even though I know credential schema
already exists we could use a different field that's like validation schema
that would work across all actions then we get a more extensible

Benjamin Young: And 11 o'clock came and…

Manu Sporny: Yeah,

Benjamin Young: land We got into the thick of it. All come back in a week
for the thrilling nonconclusion. Thanks everybody.

David C: Okay, thank you.

David C: Thank you.

Phillip Long: Cheers.
Meeting ended after 01:03:10 👋

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