[MINUTES] CCG Incubation 2025-12-11

Meeting Summary: CCG Incubation - 2025/12/11 Attendees

   - Benjamin Young
   - Manu Sporny
   - Parth Bhatt
   - Phillip Long
   - Ted Thibodeau Jr

Topics Covered and Key Points 1. New Data Paradigm Initiative

   - *Overview:* Phillip Long provided an overview of the "New Data
   Paradigm" initiative, a collaboration by the US Chamber of Commerce
   Foundation focused on Learning and Employment Records (LERs), also known as
   VCs. The goal is to streamline data reporting for employers to states,
   which is currently done in varied, often manual formats across different
   states.
   - *Proposed Solution:* The initiative proposes a single API capable of
   consuming data in various formats, wrapped in a VC-based structure. This
   data would be ingested into a data lake managed by a public-private
   partnership.
   - *Benefits:* Aggregated data in the data lake could be used to generate
   verifiable credentials (e.g., salary history, position history) directly
   for employees. This could also enable more timely data analysis on job
   distribution and skills demand within a state.
   - *Challenges:* Significant concerns exist regarding the privacy and
   security of data in the data lake, as well as during aggregated analysis.
   Employers may be hesitant to share sensitive compensation data.
   - *W3C Privacy Concerns:* Manu Sporny highlighted that a centralized
   data lake model would likely be a "complete non-starter" for privacy
   advocates at W3C, who emphasize decentralization.
   - *Potential Solutions:* Exploring sector-specific data lakes or other
   decentralized approaches to address privacy concerns is crucial. The
   initiative acknowledges the need for a separate workstream dedicated to
   security and privacy.

2. Terminology Refactoring and Data Model Structure

   - *Goal:* The discussion shifted to refactoring terminology and
   structuring a unified data model, with the assumption that agreement to
   restructure and unify had been reached.
   - *Deep Nesting Debate:* Manu Sporny expressed concern about deeply
   nested data structures, citing the EU model as an example. He argued that
   much of the information in such structures is optional, not
   machine-readable, and therefore unlikely to drive dynamic processing. He
   advocated for a flatter structure, focusing on machine-processable
   information.
   - *Value of Nested Data:* Phillip Long argued that even
   non-machine-readable information (e.g., links to web pages, documents) can
   enhance trust in an issuer and be valuable for human debugging and
   verification of issuer quality.
   - *"Musts" vs. "Shoulds" and "May"*: A significant portion of the
   discussion focused on defining "must" statements (mandatory for software
   processing) versus "should" and "may" statements (optional).
      - Manu Sporny emphasized minimizing "must" statements to reduce the
      burden on test suite development and increase the likelihood of adoption.
      He identified issuer type, recognizer, recognizer ID, and potentially
      recognition criteria (credential schema) as core "musts" driven
by software
      algorithms.
      - Benjamin Young suggested labeling terms based on their source of
      requirement (regulatory vs. processing) and exploring ways to
refactor the
      data model to reduce complexity, potentially using profiles to handle
      regulatory differences.
   - *Profiles for Regulatory Differences:* Manu Sporny proposed using
   profiles to accommodate regulatory requirements (e.g., from the EU) without
   complicating the core specification. This allows for strengthening
   requirements within specific contexts.
   - *Core "Musts" Identified:*
      - Credential Subject Type (from VCs)
      - Recognizer
      - Recognizer ID (DID or HTTPS URL)
      - Recognition Criteria (potentially defined by Credential Schema)
   - *Recognition Criteria and Schema:* The use of "Credential Schema" as
   the means to define recognition criteria was debated. While it works for
   standard VCs, its applicability to more diverse use cases (like recognizing
   pottery) was questioned, though an AI as a recognizer for pottery was
   humorously suggested.
   - *Individuals as Recognizers:* It was clarified that individuals can be
   listed as recognizers, accommodating use cases like endorsements for
   self-issued credentials and loyalty programs.

3. Meeting Schedule and Future Plans

   - The meeting concluded with a decision to cancel the next few weekly
   meetings due to the holiday season and low attendance. The group plans to
   reconvene in 2026.

Text: https://meet.w3c-ccg.org/archives/w3c-ccg-ccg-incubation-2025-12-11.md

Video:
https://meet.w3c-ccg.org/archives/w3c-ccg-ccg-incubation-2025-12-11.mp4
*CCG Incubation - 2025/12/11 09:59 EST - Transcript* *Attendees*

Benjamin Young, Manu Sporny, Parth Bhatt, Phillip Long, Ted Thibodeau Jr
*Transcript*

Phillip Long: And then there were three.

Manu Sporny: Hey, Benjamin said he's going to be a little late today and
for me to run the meeting until he gets here. but I will note that there
are only three of us on the call today and so we can't have a meeting
unless we have more people. so I'm going to hold until Benjamin shows up
and…

Phillip Long:

Phillip Long: Hold tight. Yeah. No worries.

Manu Sporny: then let him make the

Phillip Long: I was a little bit late getting downstairs to the office
here. So, FYI, we have another I think it's the 17th next week. what is it
called? the new data paradigm webinar. to talk more about the actual
project itself as opposed to background to it.

Manu Sporny: That's good to know. do you want to reminder everything we
talk about is just ends up in the minutes automatically. but do you want to
maybe provide some background on that if you want the rest of the community
to kind of see it?

Phillip Long: Yeah. Yeah. Happy to do that. there's a lot of pieces that
need to be addressed there that are interesting and some differences of
opinion about how to approach it. So more people involved that has an
opinion that's helpful. That's great.
00:05:00

Manu Sporny: Maybe some background on what new data paradigm is about and
what you're trying to accomplish there might be good.

Phillip Long:

Phillip Long: Yeah. Yep. you want me to do that here or at the CCG or…

Manu Sporny: Yeah. Yeah. Yeah. Yeah.

Phillip Long: Okay.

Manu Sporny: Yeah. No. No. yeah. do it here because whatever you say is
going to end up in the minutes and then the minutes get auto shipped out to
the CCG so they'll see

Phillip Long: Got it. Okay, And it's a good thing to do waiting for
Benjamin. so the new data paradigm is an effort by the US Chamber of
Commerce Foundation in collaboration with a number of other parties in
including some u political entities shall we say and the chair of the House
Subcommittee on Workforce and Education just held hearings about the topic
of what they refer to as learning and employment records.

Phillip Long: aka VCs that can contain data that is both about education
and training as well as workrelated information. Think when you hear that
data that might be in an HR system describing employees and their jobs and
the positions they have and their skills. and the intention is to try to
make it to streamline and make it simpler for employers to do the data
reporting that they currently have by obligation to the states in which
their businesses operate about the efforts and business activity that
they're engaged in there which include reports about employees and salaries
and

Phillip Long: and position histories and related topics. Right now every
state does it in a unique way for that state. So any business that operates
in multiple states has to do it differently for each one. There is also
almost no and I don't think there is a single state that has a single API
that people can rip send data to. It's almost all done by virtue of either
uploading to a website or file transfers u including as text files, CSV
files, XML, you name it to file format. the states get all kinds and
there's no restriction on what kinds. So they have to deal with whatever
comes in in order to get the reporting done that they need to make for
their other agencies in their state and also the reporting they have to do
to the federal government.

Phillip Long: So the context is how do we put it together something that is
more efficient than that and can we do it in a way that leverages the data
that might be naturally occurring were adoption of the LVC data model more
widespread and ubiquitous. So that's the generic framework for it. the
current thinking which is in need of input and guidance from as many good
people in the community as we can get that from is to design a single API
that can be used and that is capable of consuming or at least carrying data
in a variety of formats.

Phillip Long: We're not for forcing a particular data structure at this
point. but it will natively be able to contain essentially as a wrapper
that is a VCbased wrapper around whatever the data structures are that
they're currently using and then encourage people to start moving to more
structured data in the process. But to send that to an endpoint that is
managed not just by the state but by a public private partnership between
state and the major industry partners in the state that is major employers
in the state and the endpoint likely being some form of data lake and the
state would draw the data from that data lake to do their reporting.

Phillip Long: And the aggregation of that data in the data lake opens up an
opportunity for data that's been sent by the employers to be turned into
verifiable credentials for particular reporting types like salary history,
position history etc. that could be set offered at least directly to the
employees from the data lake itself. with the intention of jumpstarting the
distribution and use of those things by individuals as well as offering the
opportunity for the individual to see exactly what this employer is
reporting about their positions, their history, their salary, etc. there
are lots of things that kind of build on top of that general framework.
00:10:00

Phillip Long: such as the possibility that employers might endorse a data
utility issued credential which obviously has their data originally in it.
But to endorse the credential that is sent by that utility and signed by
that utility for those that want the extra conf confirmation that
individual's records is representative of what they did at that business.
so that's the general framing. There is an interest on top of that to build
an analytics framework for doing more timely data analysis on the
distribution of jobs across a state or the skills that are being u that are
in demand at different parts within the state, different locations within
the state and things like that.

Phillip Long: But that's down the road a bit and we understand that there's
a great deal of concern about privacy and security both for where in that
data lake but also doing aggregated analysis across the input of all the
employers in the state.

Phillip Long: So that's a reasonable summary. Do you think Manu Right. Yeah.

Manu Sporny: Yeah, that's great.

Manu Sporny: Thank you, Yeah, that's super helpful. and yeah, I guess the
thing that was rattling around in my head as you were, going through kind
of the goals of the program was the security and privacy implications, I
mean, so the first kind of privacy implication is for the employer itself
who might be sending stuff up to the data lake. they don't necessarily
always want to share how much they're paying individuals, That can be a
competitive advantage for them to kind of understand that their competitors
kind of would benefit from.

Manu Sporny: so there would need to be some form of pseudotmization of the
data to potentially make it and they might just want to provide ranges. but
even then I've know some employers don't even want to report out on that
kind of stuff. So I think data model gohead. Yeah.

Phillip Long: It's challenging because the state needs to have that data
for their taxer purposes and things of that sort, right? So there they're
by definition in the based reporting level of things.

Manu Sporny: Yeah. Yeah.

Phillip Long: There's no question about that.

Manu Sporny: Yeah. Yep.

Phillip Long: And so your point about the security of that and…

Manu Sporny: Yep.

Phillip Long: the willingness to trust whatever the methods are that are
implemented in that aggregation of data are critical and…

Manu Sporny: Mhm. Yep.

Phillip Long: we recognize that a separate work stream just on that topic
is probably necessary. we've talked to a number of folks both in the data
side of IRS,…

Manu Sporny: Yep. Mhm.

Phillip Long: the data analytics reporting side of IRS and in the education
side, for example, with the so-called safe insights project, which is a
8090 million grant from NSF to a collection of institutions led by Rice
University and…

Manu Sporny: Mhm.

Phillip Long: and Rich Baronuk is the PII on that where individual campuses
This is higher ed campuses are making available their student information
data for researchers to do analytics and…

Phillip Long: research on in terms of things like if factors influencing
the pathway on a degree and in terms of degree completion and…

Manu Sporny: Mhm.

Phillip Long: such. But they're only agreed to do it such that every single
campus has its own data enclave that they put that data into that that runs
there and…

Manu Sporny: Mhm. Yep.

Phillip Long: the safe insights folks are the administrators of it and…

Phillip Long: researchers submit code that they want to run against that
data which then gets vetted and…

Manu Sporny: Mhm. Yeah.

Phillip Long: things before it can get scheduled to go in and the analysis
run. So, it's a baby step in the direction,…

Manu Sporny: Yeah. Yeah.

Phillip Long: but not what we're trying to do in this case.

Manu Sporny: Yeah. Yeah. Yeah. Totally understand.

Manu Sporny: But yeah, I mean it does seem like the kind of the privacy
implications of it that seems to be the thing that would potentially be the
hardest thing to just figure out…

Phillip Long: a sound,…

Manu Sporny: how to do it in a way that is going to work for everyone,…
00:15:00

Phillip Long: right? Right.

Manu Sporny: right? because I don't think people themselves I think that
the mere kind of discussion of a data lake and…

Manu Sporny: uploading everything to the data lake is the thing that to me
would strike the privacy folks at W3C as a complete non-starter right I
mean they would just basically be like no absolutely not that's complete
anti-attern when it comes to VCs we've talked about that before…

Phillip Long: Fear in the hearts,…

Phillip Long: right? Yep.

Manu Sporny: but de decentralizing the system so that you can still do that

Manu Sporny: type of analytics as long as you have agreement from the
individual that's okay enough safeguards around it where it doesn't end up
in a data lake…

Manu Sporny: but for example IRS is still able to get what they need out of
it and the employer still need able to get what they need out of it and the
employees similarly yeah it's a hard problem …

Phillip Long: It is and…

Phillip Long: there's nothing that suggests I mean there's no statement
that there's a data lake per state. There could be one per sector.

Manu Sporny: yeah. Yeah.

Phillip Long: And there might be greater opportunities to achieve agreement
because of the value of the predictions that are potentially useful to the
various sectors in a particular state from the aggregation of data.

Manu Sporny: Yeah. Yeah.

Phillip Long: So there's different ways to kind of address that, but you're
absolutely right and as I said, some conversations with the folks that do
data analytics at IRS. and…

Phillip Long: yeah, I mean, they've winnowed down the number of things that
they make available in their data sets for the public to see as a
consequence of concerns about inferential identity based on a particular
parameter like salary level.

Manu Sporny: Yeah. Mhm.

Manu Sporny: Yep. Yep. Yeah. right. Yeah. Exactly. okay.

Phillip Long: …

Manu Sporny: Really interesting work.

Phillip Long: Ben's here. Mhm.

Manu Sporny: Yep. Thank you, Phil, for giving us a background on that T3
Jedex stuff. Benjamin, we've just been kind of talking about a separate
project that Phil's involved in that he kind of provided an open invitation
to folks to participate in. We haven't jumped into the terminology
refactoring stuff.

Manu Sporny: So, I'm going to hand hand it over to you at this point and…

Benjamin Young: That's fine.

Manu Sporny: feel free to take us wherever you want to take us.

Benjamin Young: I appreciate y'all Sorry to be Had a end of year school
scheduling snafu thing happen. So yeah, how much of this do you feel we can
cover without Dave here,…

Benjamin Young: David C? Okay.

Manu Sporny: I mean,…

Manu Sporny: we can I think keep going through it and then, David can come
back in and tell us if we went totally, yeah, exactly. It feels like
there's a decent chunk of things in here that we can make a best guess at
and then get David's input. I think David said that one of the most
important things during the last meeting which was he believed we had
agreement to restructure everything and unify everything and…

Manu Sporny: if that's the case then it makes it much easier like we are
truly working towards a unified data model and because of that it should in
theory be fairly straightforward.

Benjamin Young: Right. Right.

Benjamin Young: Because then it can be whatever it needs to be as long as
it can map.

Manu Sporny: Yeah, exactly.

Benjamin Young: That sounds fun. And I will share from a much smaller
screen this time. So hopefully it'll be more sensibly sized. yeah, can
everybody see that?

Manu Sporny: Yep.

Benjamin Young: So this is the sort of JSON reshaped thing that we were
working on last time trying to express the tree structure of it. we can
continue on this side. this is all the stuff towards the bottom of that
sheet that hasn't been addressed yet that we can move up. if this
restructuring is helpful, I can bring up a hack or something if we want to
work directly on some JSON or we can go back to just looking at term names.

Phillip Long: Not particularly.

Benjamin Young: I don't care. Does anybody have preferences around any of
that? All right. I rather like how this was working out. and I brought back
the type word right at the end of the call last time. So, hopefully it's
looking even more like it's going to look but less like a classes and
properties maybe.
00:20:00

Benjamin Young: But consequently we had gotten to this sort of moment where
we have list operators that have lists that have items and I think we had
settled that these were indeed the version identifier and sequence number
of the list or collection or whatever that's going to be called and then we
were trying to decide or just beginning to discuss what these items were
going to be. and it was trending towards having the items be a list of
service providers. and then each service provider was going to have
services underneath it. So we're getting pretty heavily nested, but maybe
that's okay. does that sound Go ahead, Manu.

Manu Sporny: Yeah. Is I don't know if it's I would rather that the EU model
doesn't heavily influence this deeply nesting thing. my suggestion is we
don't need the deeply nesting thing. The vast majority of the information
in the EU model is it feels like it's optional,…

Benjamin Young: Thank you.

Manu Sporny: so where I'm coming from is that what is going to drive the
code that's executing and a lot of the stuff in the EU feels like it's like
the documentation of government governance decisions that don't actually
change the way something is processed.

Manu Sporny: meaning let me try and find a couple of examples of this. the
definition of the trust provider service like the service name and the
current status of the service and when the service started and the service
definition URIs and the supply points and all that kind of stuff. I don't
think systems are going to read that dynamically and make processing
decisions based off of it, I guess the additional service information is a
good example of this. The service business rules URI is not machine
readable. The CIS service governance URI is not machine readable.

Manu Sporny: contract types all of that stuff is not machine readable. It's
just kind of like if you're interested go and read this web page at which
point it's kind of like none of that information can be used to run
processing over the other stuff like information about the trust service
provider again is not real time processing I like it it could in theory in
the future be just like what was it web services infrastructure WSI was
supposed to be runtime execut

Manu Sporny: able but in the grand we know what happened there it was just
so much dynamism that you couldn't depend on it and so the entire framework
was rejected and that's why we ended up with restful APIs right the WS
stuff was just so this reminds me a lot about the WS kind of stuff you've
got a whole bunch of information that is not useful and it's fine for that
information to be deeply nested

Manu Sporny: But frankly at the end of the day, I think software is just
going to be configured to have a bunch of URLs with identifiers that
identify the issuer and then something that's machine processable that says
very strictly what they're allowed to issue in the form of that and then
that's it. Everything else is superolous information that you don't need
for processing. but might be helpful to somebody that's trying to figure out

Manu Sporny: how to track down one of these service providers. That's it.

Benjamin Young: Yeah. …

Benjamin Young: I wonder especially on that last point how much of that I
take the point that a whole lot of these terms don't need to show up in a
credential because they're not going to get used by the software that's
going to make a determination about what to do with this JSON document. is
there a chance that that data still needs to be there for some human being
debugging or trying to figure out what's going on? that wasn't actually I
was going to ask, but it's kind of related. Go ahead, mother.
00:25:00

Manu Sporny: I believe that's probably what the data is going to be used
for. This is where I even need David because David probably has a different
opinion on that. He might see this as absolutely required for processing.
I'll note that I think every use case that we have can be addressed with
the recognizer and recognition criteria entry. Everything else is optional
information that may help in debugging, but it's kind of like I don't …

Manu Sporny: it may help in debugging. I think that's the usage of all the
other information. I would expect David has a very different opinion on that

Benjamin Young: …

Phillip Long: …

Benjamin Young: in go ahead, Phil.

Phillip Long: I've just the record that is in the repository that describes
the issuer should be able to point to things that are not necessarily
directly machine readable like web pages other documents and such. In the
same way that a credential has evidence in it which reflects the evidence
that the assertion of the credential is making but may not necessarily be
directly machine readable. a video for example of something.

Phillip Long: so I'm curious about the dismissal of those kinds of pieces
of evidence that would enhance trust in the issuer, which isn't directly
machine processable, which when someone is viewing the record from the
perspective of making a query about a particular credential issuer that
they've received a credential from and trying to understand should they
trust this particular issuer? what's the quality behind the processes by
which the credential is issued etc. That information would seem to be
necessary in the registry.

Benjamin Young: Yeah, go ahead. on it.

Manu Sporny: I think if we want that just provide a single field that says
website, recognition criteria. I guess what I'm trying to say is all of
this information seems optional.

Manu Sporny: And if it's optional, it means that some people are going to
put it in there, other people are not, which means that any kind of
deterministic process cannot depend on the data being there. which means
that…

Phillip Long: There is you have right…

Manu Sporny: then it's kind of like you're better off telling people to go
read a web page about the issuer on the issuers's website and we already
have that property, right? yeah,…

Phillip Long:

Phillip Long: but the governance model in terms of accepting a registration
into the registry could in fact include some degree of checking of that
sort of stuff.

Manu Sporny: but that's part of the registration process, right?

Manu Sporny: I mean it's a part of …

Phillip Long: Right. Right.

Manu Sporny: who created this list and what were their policies for
creating the list. That is where you would expect it to be highlighted. You
wouldn't expect, and maybe as a part of the submission. they collect that
information. again, I'm not saying we don't put that information in there.
I'm saying I was kind of reacting to Benjamin's like this is a deeply
nested data structure and…

Manu Sporny: what do we feel about that? I'm pretty sure the deeply nested
data structure is kind of superfluous to what we actually need out of the
trust list, right?

Phillip Long: Keep it flat as possible.

Phillip Long: Yeah. …

Manu Sporny: I think the core thing we need out of the trust list is who's
doing the recognition and…

Phillip Long: yep. Yeah.

Manu Sporny: what are the criteria so that somebody doing a verification
can run an algorithm that says yep this is good or…

Manu Sporny: this is not good and then everything else is kind of
superolous data might be helpful in evidence ways that you mentioned Phil
but is not used by software to make the decision on whether or not to
accept the credential or not.

Phillip Long: Okay. Think about that. Thanks,

Benjamin Young: So related to all this the thing I keep wondering
especially in terms of bridge building between the EU work and…

Benjamin Young: this is so much of these terms and even if the nested
structure ends up still being a thing. may have use cases and value outside
of the actual credential. And that there's maybe a play here where we still
define the terms and we still define the mapping and say you could if you
wanted to had a reason to fully express everything that you got from some
other format and there's terms for all that stuff.
00:30:00

Benjamin Young: But then in practical fact, you're probably going to do
this much smaller thing because you're going to lean heavily on the fact
that the brokering and the horse trading happened elsewhere and you're just
getting this was agreed upon and then here's some enforcement stuff, some
digitally human free enforcement processes that can happen on this
credential. and then you'd either use one human shout out and…

Phillip Long: Thank you.

Benjamin Young: here's the web page where all this was determined publish
not at all. You would use the identifier of the credential or something to
go try and find something like that or the machines aren't expected to
carry any of that and you would debug it however you're going to debug it.
But point being, we'd have all the terminology and stuff still kept so that
if somebody wanted to do the verbose thing or felt they had a need to, it
would still be there. so that we also wouldn't get mud thrown on us of the
credential version is just this, some minimum thing that's not enough.

Benjamin Young: but we don't run the opposite problem of we boiled the
ocean and now nobody wants to use these credentials because they expect
they have to encode all this other stuff. That's the basic idea said way
too verbosely. Go ahead Mon

Manu Sporny: Yeah, I agree with that. I think the strongest argument for
having every single one of these properties in here is so that we can say,
"Hey, the European MA model maps directly into this data structure. If you
like the European model, you can use this data structure." That's the
strongest argument for keeping every single one of these fields. in
reality, what I'm saying is in reality, you're not going to use any of
those fields, unless there's some kind of European processing you want to
do on the thing which is totally fine. So I think that's the reason we're
doing this. I don't think we have confirmation on that assumption meaning
we do not have an implementer saying yes I'm from the EU and I see what
you're doing and it looks good to me and I'm going to use it.

Manu Sporny: So the other concern is that we're going to go to all this
trouble and then we're going to get to implementing it and no one's going
to implement the thing and we would have to spend a lot of time, trying to
fit this into the data model. That said, I don't think it's a ton of work
and we should continue to do it. I just want us to be very aware that we
don't have an implementer for the mapping thing. and that is concerning to
me. and hopefully David can point us at someone in the EU that's going to
actually use all of these things that we're defining.

Phillip Long: Just me.

Manu Sporny: And I don't really even know how much this thing is used in
the EU. it's the other data point. I think Isaac and David have said, " no,
it's totally used." But it's kind of like,…

Manu Sporny: okay, who's using it exactly? And who's implementing it
exactly? And we need to pull them into the working group. that's

Benjamin Young: Yeah, for sure.

Benjamin Young: As somebody who spent too much time with test suites and
W3C specs, I'm also wondering when and where does this take the shape of,
tests and how much of it would actually be tested? right now we're just
talking about vocabulary terms. which notably don't ever get tests. So at
the moment it's not a big deal but when this becomes grows a set of API or
processing instructions that do get documented and do get specified those
are the things that are going to get tests written about them and I think
that will probably be the mechanism by which we know what of these are
actually valuable in terms of practical

Benjamin Young: and one of them are just documentation handles for humans
who might find the thing later but may not be required. So if the vast
majority of these things are in the EU data model and we keep them around
in the vocabulary and then there is a processing specification of some kind
that explains to people consuming this credential. Here's what you would do
with all the expressions pragmatically, what you would what you would do
with the service list that's provided, etc. that expression of an
algorithm, whatever, and the tests written on top of it are likely the
things that, prunes the tree down to whatever it needs to actually grow.
00:35:00

Benjamin Young: and the rest of these could still exist in the vocabulary
and Jason LD would accommodate them being expressed without damage or risk
to the core plumbing, but not just saying the same thing a different way, I
think. Go ahead, L.

Manu Sporny: Yeah, a plus one to that on regard, regarding the test suite,
what are we actually going to test in the test suite? I think it's becoming
whats the Increasingly apparent that like we are this is a vocabulary like
spec, I mean that's really what we're defining here. and with some light
algorithms on top of it. the test suite that we end up writing. My hope is
that it's probably a fairly light test suite. It's like can you issue one
of these credentials and then can you use one of these credentials to
determine whether or not the credential you're verifying is valid, or not.
And so it seems like the test is what are some of the minimum viable things
you can issue? the things with must statements.

Manu Sporny: I would imagine that all this other trust service provider
list operator stuff going to should statements which traditionally we just
don't test in the test suite. or if this exists then you must do x y and z.
and then I think the burden's going to be on the people that want to use
the extra parts of the data model. so my hope here is that by adding all of
these things in, we are not massively complicating the test suite. We will
probably just not test it because they're optional things. that doesn't
drive whatever algorithm we're going to put in the specification. yeah,
that's my presumption.

Manu Sporny: And again, I think, David and Isaac are going to have to let
us know if they think differently. One other approach is that we could
break all this list operator, trust service provider stuff out into a
separate vocabulary. and then basically say, hey, that vocabulary needs to
see usage before we merge it in with the core thing. That feels like a
bridge too far. what am I trying to say? one of the downsides of putting
this in the spec we're talking about is it might make the spec look really
complicated.

Manu Sporny: And we know, from past experience, if a spec looks
complicated, people run off to IETF and then do some halfbaked way reduced
thing. And all of a sudden, we've got kind of another competitive thing in
the space that does the same thing,…

Manu Sporny: but without all the extensions that, people are not using.
that's it.

Benjamin Young: Yeah. …

Benjamin Young: yeah, 100%. the thing I'm wondering then is if we might go
through what we have here, sort of with an eye toward the must musts and,
label them in some and bold them or change their color or whatever and see
what's re rename the rest or color code the rest as these are shoulds or
even maze and shape it as best we can and then get David and Isaac on at a
later date to explain this was the approach for musts and shoulds and mays
in terms of expected use and obviously there's not an algorithm yet there's
not requirements put on anybody yet it's just a JSON object in a spreadsheet

Benjamin Young: So, as the requirements would take shape, I think it
becomes clear what people are going to care about maybe. so just at first
blush in this sort of space, a lot of these defined terms already exist in
a verifiable credential. So URL is not there. name and description are so
we already have them. but things like legal name is that a should provide a
legal name? Is that if different than name what are the musts and who's
making the musts? Is that a legislative requirement which given this is
coming from the EU my expectation is it's mostly going to be driven by
policy requirements not by software requirements. but that's still a
requirement.
00:40:00

Benjamin Young: So, calling that out. that's kind of the approach I was
thinking, but go ahead, money. It's fine,…

Manu Sporny: No, go ahead, Phil.

Phillip Long: If you're a…

Phillip Long: if I'm sorry, go ahead, I was just saying that I mean I don't
think requiring a legal name is a particularly ownorous thing to have…

Benjamin Young: Phil. Yeah.

Phillip Long: because every business and organization in the US at least
has to have something that's associated with them.

Benjamin Young: No, I'm not looking at the value or…

Phillip Long: So I Yeah,…

Benjamin Young: lack of value in ment. Just is it a requirement? Who's
making it? I think is I wasn't trying to debate the Yeah.

Phillip Long: I think for my view it's useful because if you have that and
you go to the web and use that you'll find other information about the
company and other websites because at least anything that's official is
going to take advantage of the fact that there is a name that they can
uniquely use.

Phillip Long: So to me that's a very straightforward one.

Benjamin Young: Go ahead.

Phillip Long: That's a must anyway.

Benjamin Young: And I think what I want to push for is do we think this is
a must? And if so, what's driving the mustness of it? whatever that is.

Phillip Long: Yeah. I get that.

Benjamin Young: Go ahead, Mon.

Manu Sporny: Yeah. and…

Manu Sporny: the way I like to think about the must statements is every
time we say it costs somebody $10,000 in the working group to implement the
test suite and all that kind of stuff. So, as you can imagine, I'm very
anti- lots of must statements because we typically are holding the bag when
it comes to implementing the test suite. but because of that, I don't think
there are a lot of must statements in here, I mean, the only must
statements are driven by what the algorithm needs to achieve the vast
majority of use cases, right?

Manu Sporny: And so for example the credential subject type being
recognized issuer verifier you must specify that you must specify a
recognizer but the recognizer you can specify by ID their did web or their
HTTPS URL whatever that's the minimum must everything else potentially is
useful as Phil was saying a legal name is not a huge burden to ask somebody
to do that. But does it drive the algorithm? No, it doesn't. Right? Because
the algorithm just cares about doing a JSON schema match against the
credential that you've gotten in. And the algorithm cares about the
specific issuer URL that it should be looking for. And That's all the
algorithm cares about. Everything else is superfluous because it has to do
with how the list was constructed in the first place, right?

Manu Sporny: it's the evidence that went into creating the verifiable
issuer list. So based on I don't think we have a lot of musts here. we have
a must for the credential subject type which is just from PCs. We have a
must for a recognizer and we have a must for its ID but nothing beyond
that. and then we have a potential must for recognition criteria.
specifically the credential schema that's used against the VC. Those are
the things that drive an algorithm. the list operator name doesn't,…

Phillip Long: I think we can get

Manu Sporny: the list operator address their policy legal notice doesn't.
so on so forth.

Manu Sporny: So I think we can get down to a very concentrated set of must
statements which then drives the test suite and it doesn't make the test
suite this, multi00,000 thing to implement. where we could potentially
reuse a lot of the existing infrastructure that we have and then increase
the chances of us getting this thing like pushed all the way through,…

Manu Sporny: just some thoughts on that. I'm not arguing to remove any of
these things. I'm making an argument to be as absolutely minimal as we can
with the must statements and go from there. That's a

Benjamin Young: Yeah. … definitely in favor of that. I think maybe if this
makes sense, this is kind of what I was thinking in terms of what we would
spell out. if there are musts, where do they come from? Is it regulatory?
Is it processing? Because everything you just described, Manu, is for the
software. which is great. but then the EU politician types are going to be
" when we rifle through your sock drawer and take out all your verifiable
recognition credentials, it better have this data in it or, we're just
going to lock you in prison till you can tell us what website you got this
from." that's where the regulatory style requirements might come from.

Benjamin Young:
00:45:00

Benjamin Young: But I think even in those cases if we could tell them apart
there are ways to refactor the data model to further reduce it we have name
and legal name is there even a case where those should be different should
the name always be legal name there's cases to be made that name could be
display name and you have legal name around because that's for the
regulator and the name shown is for the user digital bazaar versus dig

Benjamin Young: we don't usually show people Digital Bazaar Incorporated,
not because we're hiding anything, just because it's an extra five
characters. the point being if we were to annotate this with those kind of
sources of where that comes from and so far as we know them, then
potentially we get a clearer vision of this is what the software needs. If
you're in the EU, this is what your, dirtbound governments want you to do.
and if you're not then maybe you don't care. So I don't know. Go ahead.

Manu Sporny: Yeah. I think if we're talking about regulation, so let's
going back to kind of It creates global technical standards. regulation
does come into it every now and then, but we try to keep regulatory
differences out as much as possible because they change sometimes wildly
from ction to jurisdiction. and the way that we can do that in a nice clean
layered way is if the EU wants to strengthen the requirements around the
specification they can do that in a profile they can say what the W3C spec
says legal name is a should but no we think it's a must if you operate in
the EU and you want to use the specification that is a must requirement and
we will provide a separate test suite that tests European regulation

Manu Sporny: against this space data model thing. So I think that's the way
it's accomplished and we should probably mention that in the specification.
but that would allow us to not have a whole bunch of the EU wants this and
Australia doesn't disagreements.

Manu Sporny: So I think profiles are the answer to that and you can always
strengthen requirements in a profile.

Benjamin Young: Yeah, I like that a lot.

Benjamin Young: I can Thank you, in which case then the musts we would and
we could do this pursue first are the software ones which Mono you trotted
out a bunch real quick earlier. the issuer type and recognizer and then I
think recognition criteria and you wanted an ID on one of those.

Benjamin Young: was that recognizer or the would have an ID.

Manu Sporny: You recognize her?

Manu Sporny: Yeah. Yeah, recognize her because that's the thing that's
going to show up in the proof, I think. yeah.

Benjamin Young: So, It's going to be confusing if I make these bold at this
point. I'm going to do it So I'm just bolding what I think is required
propertywise. we don't need an ID on the credential. type I already have
elsewhere. so type of one of those recognizer. Not sure why we made that
green.

Benjamin Young: Maybe we'll make all the new bold required things green.

Benjamin Young: Feel free to interrupt or redirect as I do this.

Manu Sporny: Yeah, plus one.

Manu Sporny: I agree. there's recognition criteria at the bottom and…

Benjamin Young: Is that literally it? you got some JSON that looks like
that and you're like right, right, right.

Manu Sporny: and these ones. So I think the credential subject you've got a
recognized issuer that has recognition criteria of type and…

Benjamin Young:

Benjamin Young: And what is this a property of? Is this also the credential
subject? Yeah. So these is the Yeah.

Manu Sporny: we have not figured out is it an action or whatever. Correct.

Benjamin Young: the criteria are not properties on the recognizer, are
they? So, I'm a little confused by the difference between a recognized
issuer and…
00:50:00

Manu Sporny: Let's see the

Benjamin Young: because recognizer is what used to be recognized by, right?
It's the like Okay.

Manu Sporny: Yeah. Yeah.

Manu Sporny: So the English sentence is supposed to go something like here
is a recognized issuer, here is information about the recognized issuer,…

Benjamin Young: Yep. Let's go. Okay.

Manu Sporny: which is the recognizer relationship, and here is the
recognition criteria for that recognized issuer. meaning I recognize them
to issue credentials of I recognize them to verify credentials of this
type. That's what the English sentence is supposed to do and recognition
criteria is describes the type of credential or the action that they're
allowed to perform or recognize to perform.

Benjamin Young: And the recognizer ID would be presumably a did or…

Benjamin Young: something of an entity somewhere or…

Manu Sporny: E. Yep,…

Manu Sporny: that's right. Yeah, it's the thing that will show up in the
verification method on a proof on a credential will have that ID as, …

Benjamin Young: whatever. Okay.

Manu Sporny: the prefix of Yep. Mhm.

Benjamin Young: And then this is move that was a note from earlier that
people were confused by what this thing was.

Manu Sporny: Yeah, it's the thing that they're recognized to do. Maybe
they're recognized to ride a bicycle,…

Benjamin Young: Okay. …

Manu Sporny: right? we have collectively not figured out…

Benjamin Young: and it would be a type like an issuance and verifiation
type action. We put action in parenthetical because nobody was okay.

Manu Sporny: what that is. But yes, in general, it's like I recognize them
to do this act. I recognize my neighbor to make pottery because they're
really good at it.

Benjamin Young: And this is credential schema straight out of VC land,
right? It's just JSON schema.

Manu Sporny: Yes, I think so. Yep. Yep.

Benjamin Young: You'd write a Jason schema for your neighbor's pottery.

Manu Sporny: If it looks like this,…

Benjamin Young: I'm for that.

Manu Sporny: they have a particular style. If it looks like this,…

Benjamin Young: You call me when you're done with that.

Manu Sporny: it's quality.

Benjamin Young: Yeah, additional property equals true and you're done. go
ahead, Phil.

Phillip Long: Yeah, I'm still a little bit confused. The recognizer that
you're describing is a statement about what the issuer approved for lack of
a better word to issue a credential about. Correct. Okay.

Manu Sporny: Yes. Yeah. So if we…

Phillip Long: Is that the Right.

Manu Sporny: if we take a university example, you're recognizing maybe a
sub let's take very simple a university I recognize them to issue degrees
of this type right?

Phillip Long: But that would be who in that case is the accreditation in
organization that is given.

Manu Sporny: Yes correct.

Phillip Long: So that's All That's what I was trying to get at…

Manu Sporny: Yep. Yeah.

Phillip Long: because it wasn't clear. If you're recognizing your
neighbor's pottery, who the hell are you?

Manu Sporny: Yeah. Yeah. I mean, and we're trying to avoid the words trust
and…

Manu Sporny: allowed and accreditation because we didn't want to be Yeah.

Phillip Long: I get that.

Phillip Long: But somehow Right.

Manu Sporny: We wanted to be inclusive of other types of approach like
community based approaches for recognition.

Phillip Long: Right. Right. So does that mean so if I was a selfisssuing
issuer then I could have people recognize me.

Manu Sporny: Yep, that's right.

Phillip Long: Okay. Right.

Manu Sporny: I mean, take a local government. I mean, take something as
small as a 15 person tribe. and not that they use this technology, but
you've got 15 people. You don't need any kind of, huge infrastructure or
whatever. It's just where does your authority come it comes from everybody
else kind of recognizing you to do certain things like Yep,…

Phillip Long: If I'm using link creds and I selfisssue a credential of a
skill I have, my endorsers would be the people who would be recognizing me.

Manu Sporny: that's right.
00:55:00

Phillip Long: So individuals could be in here.

Manu Sporny: Yep. Absolutely.

Phillip Long: That was one of the distinctions I wasn't clear was being
made. So, help that's helpful.

Benjamin Young: Yeah. Yeah.

Manu Sporny: Yeah, individuals can exist in here and we don't have to
change the data model for that use case. It just slots right

Phillip Long: Right. Okay.

Benjamin Young: Yeah. The number of use cases with that view of it that
this could accommodate is pretty impressive. Loyalty programs and…

Phillip Long: Yeah. Yeah.

Benjamin Young: all kinds of other things.

Phillip Long: It could be, billions.

Benjamin Young:

Benjamin Young: Yeah, Okay. So, with those as the core thing, I'm a little
weirded out by credential schema as the means, but I also kind of get it.
but we're also down to three minutes, so I don't think we're going to solve
a whole lot. Go ahead, Mon. I mean,…

Manu Sporny: Yeah, I agreed it. Yeah, and credential schema was kind of a
first order kind of stab at trying to address the problem. If there are
better ways, we should definitely talk about them. It's the only thing that
I could think of where I'm kind of like,…

Benjamin Young: good luck with the pottery.

Manu Sporny: yeah, it's a right.

Benjamin Young: But yeah,…

Manu Sporny: Yeah, does not work on those use cases very well. but on …

Benjamin Young: Right.

Manu Sporny: bog standard VCs, hopefully you can just match by credential
schema.

Phillip Long: Uhoh.

Manu Sporny: It should work.

Benjamin Young: And if you're doing, essentially very basic schemas of
these contexts with these types and…

Benjamin Young: as long as you've got those, then I'm okay with that. Or
sure.

Manu Sporny: Yeah. and…

Manu Sporny: just it's not the only way. So you could have different
recognition criteria. So for example, for this crazy, but for the pottery
use case, I could assign an artificial intelligence to be the recognizer.
So …

Benjamin Young:

Benjamin Young: Yes, I know.

Phillip Long: Is that a schema Thanks. Yes.

Manu Sporny: take pottery,…

Manu Sporny: show it to this AI.

Manu Sporny: If the AI says Yeah, it came from this person," then there's
your recognition criteria, right? Yeah.

Benjamin Young: is actually a pot.

Benjamin Young: Of maybe certain dimensions.

Manu Sporny: Yeah. Of certain qualities,…

Benjamin Young: Right. Right.

Manu Sporny: yeah.

Benjamin Young: Right.

Manu Sporny: That's totally their art style, right? That's definitely a
Bangsky or…

Benjamin Young: Right. Yep.

Manu Sporny: Banky, right?

Benjamin Young: I don't think he's ever done pots. Maybe mostly what
elephant? Yeah. notably schema.org does not have anything about animals.
somebody was proposing we change the example on the JSONLDD homepage and
they were like you should use animals and pick a cute animal to represent
JSONLD. And I was like I'll look up schema.org animal stuff and there's
nothing.

Manu Sporny: Pray of.

Benjamin Young: Which made me happy that they hadn't boiled the entire
ocean. in fact, you can't boil the ocean with schema.org…

Phillip Long: accepting that.

Benjamin Young: because it doesn't know anything.

Phillip Long: Excepting that we're animals, too. So, I don't know.

Benjamin Young: There you go. That's why they probably didn't touch it
because that always makes,…

Phillip Long: Right. Texonomy.

Benjamin Young: smart people angry when you're humans are animals, too. And
okay, now we're into physics and metaphysics and Somebody's gonna get
cranky. So that was a fun side quest. So yeah, there's enough here
certainly from a musts put on software. so I think we'll leave this in this
state and revisit it again. I think post holidays. Sorry, we're down to the
wire on this determination. it is scheduled next week on the 18th because
we've been doing this weekly.

Benjamin Young: I will remove the other ones on the two festive days on the
horizon. are y'all interested in coming back on the 18th? Or should we? I
don't think any of this is pressing. and it seems unlikely that David and…

Manu Sporny: Yeah, I'd say let's just cancel for next week.

Benjamin Young: Isaac will show up. yeah. relatedly then I will probably
cancel from the 18th through the 8th just because I don't know how many
people are going to come back on that first full week either and…

Phillip Long: Great. Thank you.

Benjamin Young: it seems iffy that this is a small group already so we'll
take the next four weeks off and come back at it in 2026. All right, thanks
y'all. Bye.

Manu Sporny: Thanks. So all
Meeting ended after 00:59:46 👋

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