[MINUTES] CCG Incubation and Promotion 2025-09-17

CCG Incubation and Promotion Meeting Summary - 2025-09-17

*Topics Covered:*

   1.

   *W3C Verifiable Credential Working Group Standardization Poll:* A poll
   to gather community input on prioritization for the VCWG is closing Friday.
   Results will guide VCWG priorities.
   2.

   *Verifiable Credential Refresh Specification Update:* The specification
   was updated to align with the latest VCOM spec. Key changes include
   simplifying manual and automated refresh mechanisms using VCOM interactions
   and removing redundant features. A refresh credential example will be added
   to improve DID authentication. The updated spec will be reviewed for
   promotion to the VCWG.
   3.

   *Verifiable Issuers and Verifiers Specification:* Discussion was
   hampered by the absence of key attendees (Isaac, David, Dmitri). However,
   three core use cases were identified:
   - A trusted directory of vetted entities (Dmitri's use case).
      - Support for the EU trust service provider model (Isaac and David's
      use case).
      - A fully decentralized solution with no central list, relying on
      verifiable presentations and root-of-trust credentials.
   4.

   *Data Aggregation and Credential Usage:* The potential for data
   aggregation to inform credential improvement was raised but deemed a
   separate, potentially high-risk work item due to privacy concerns. The
   group agreed this topic requires careful consideration to avoid unintended
   consequences. The dangers of enabling data mining and the need for
   privacy-preserving solutions were emphasized, illustrated by an example of
   airline data being sold to government agencies.

*Key Points:*

   - The absence of key attendees significantly limited progress on the
   Verifiable Issuers and Verifiers specification.
   - The Verifiable Credential Refresh specification is nearing completion
   and will be reviewed for promotion.
   - Three core use cases were identified for the Verifiable Issuers and
   Verifiers specification, requiring further discussion and development of
   minimum viable examples.
   - Data aggregation for credential usage improvement was identified as a
   high-risk but potentially valuable area requiring a separate work item
   focused on privacy-preserving methodologies.
   - The meeting highlighted the importance of prioritizing privacy and
   avoiding data mining practices.

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

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

Benjamin Young, Dave Longley, Denken Chen, Dmitri Zagidulin, Hiroyuki Sano,
John's Notetaker, Kayode Ezike, Manu Sporny, Phillip Long, Ted Thibodeau Jr
*Transcript*

Manu Sporny: All right. Hey everyone, let's go ahead and get started. David
Chadwick sent his regrets for today, which is unfortunate because we really
do need to talk about the core, use cases and objections that he has, to
the current direction. it would also be good if we had Dimmitri here
because Dimmitri also has some ideas about what he would like us to focus
on, with the verifiable issuers verifiers specification. So, it sounds like
we're probably not going to have two of the core people that we need here
to move the discussion forward today.

Manu Sporny: so in the meantime we can give everyone kind of an update on
the polls. there is other work that was done on the credential refresh
specification so we can review some of those changes. and then we might
need to end early because we don't have Isaac David nor Dimmitri So, that's
our agenda for today. Are there any updates or changes to the agenda?
Anything else we want to discuss? All right. let's go ahead and jump in.
just a reminder that there is a poll for the W3C verifiable credential
working group standardization.

Manu Sporny: so the items that we're incubating and promoting in this group
are going to go over to the VCWG. and we're trying to get as much input
from the community as we can for what we should be focusing on over the
next couple of jeez what is going on here? not that. Yeah, there we go.
Sorry, I'm trying to get the link here and share it in the channel. so the
incubation and prioritization work, polls out there. We are going to close
the poll this Friday. so if you or someone has not responded to the poll
yet, please do let them know. we would really like as much feedback as
possible here.

Manu Sporny: I did send private requests out to everyone that I could think
of in the CCG and the verifiable credential working group as well as other
standards bodies in the retail sector, the vital records sector to provide
input if they haven't already. okay, so I think that is it for any
questions or comments on the poll? We basically closing it as of the close
of business Friday and then we will report out the results to everyone and
that will set the priorities for the verifiable credential working group.
Okay.
00:05:00

Manu Sporny: up on the agenda is a quick update on verifiable credential
refresh. so this is one of the items that we're incubating. It's this one
down here. We really haven't put too much effort into it. it needed to be
updated to match kind of the latest in the VCOM spec and other things like
that. I was able to do some work on it this past weekend. it still needs
another pass, but it's in much better shape now. I would suggest it's
probably a review or two from other people away from being able to say
we're ready to promote it.

Manu Sporny: so I'm just going to go through kind of some of the updates on
the call today and then see if we have any concerns, feedback, anything of
that nature. okay. before I do this, can someone ping Dimmitri and see if
he can be on the call today because hopefully he can make it. thank you
Dave. so we'll go through this and if Dimmitri is not here, we'll just need
to end the call early. verifiable credential refresh. this is what you do
if your credential expires. there are two main ways that we had ways to
engage on a refresh that we had discussed previously. One of them is to do
a manual refresh.

Manu Sporny: So basically you get a credential and that credential in it
says here's the refresh service and when you go to the refresh service they
require you as a human being to engage in some way filling out some
information some form logging in doing authentication something like that
that would then result in a new verifiable credential being issued to you.
So that one is a human in the loop use case and then we also have an
automated use case where you have a refresh service and the refresh service
says here's a place you can refresh but it's an automated mechanism so your
digital wallet can take care of the refresh behind the scenes without
having to bug you.

Manu Sporny: So let's say your credential for whatever reason expires every
6 months or every year your digital wallet could in the background go and
fetch a new credential without having to bother you if there is an
automated refresh way of doing that. For example, one way is through the
COM mechanism the issuer would ask you to DID authentication first for the
credential you currently provide the current credential that's expiring
over BC API.

Manu Sporny: And then if you do both of those things, there might be a
business rule where the issuer goes, okay, here's a new version of that
credential. and that could all happen behind the scenes without you having
to engage unless you configure your software to not do that. so those are
the two main use cases, manual automated refresh. and we hadn't updated the
specification in a long time. we have some new features in the BCOM
specification which allows us to do a refresh pretty easily. The data model
is pretty straightforward. you use the refresh service in the verifiable
cred 20 data model. the object has a type. Right now we've just verifiable
credential interaction service.

Manu Sporny: So this is an interaction that you can do to refresh the
service endpoints provided. so this kind of follow the did service
endpoints approach and their validity dates when is the refresh service
valid from invalid So you can basically say for example for a credential
that lasts a year maybe the refresh service is only active in the last 3
months of that year. you really don't want people like hitting and trying
to refresh the credential until you're 3 months away from expiration. so
that's what valid from invalid until are for. the way it would be expressed
is just like so this is an example of a bachelor's degree which for
whatever reason expires every 10 years or so. They want you to come back
and just refresh a new one.
00:10:00

Manu Sporny: Maybe they change the look and feel of it. Maybe they, do do
something or another on it, but you can have your wallet just automatically
refresh it. Or maybe manually, they want to hit you up for a donation to
the university or something before you refresh your credential. Those are
all examples of reasons they might make it manual instead of the automatic
refresh is kind of the same thing. in fact it's so similar that we might
just get rid of we might just boil this down to one example. because we now
have interactions in the VCOM spec it allows the issuer to dynamically
decide whether to do manual or automatic. They can start off with manual
change to automatic if something changes with that particular individual or
the particular type of credential.

Manu Sporny: so this has given us a lot of flexibility that we didn't have
before which is really nice. made the whole thing much simpler. The refresh
protocol is a pretty tip normal meaning most refresh procedures are pretty
straightforward. It's either the wallet it reaches out once it needs to
refresh it's told whether or not where it needs to go.

Manu Sporny: the wallet goes there retrieves some information and at that
point the wallet then has to either do the refresh automatically or the
wallet's told nope sorry you've got to involve the person in the refresh
there's some manual process that they've got to do here so that's
effectively the back and forth we do need to update the diagram I probably
need to upgrade it to use respect mermaid so that's one of the updates that
needs to be done there and then

Manu Sporny: for a manual this is wrong right now, so I'm going to skip it.
the initial post is incorrect, so I need to go and rework that. But
basically, the wallet reaches out to The issuer provides the VPR. This
one's an automatic refresh. It asks for did authentication. s the example
It understands the ECDSA crypto suite. And so the response will have DID
authentication assertion and then the query by example is we need your
university degree credential as well. So please provide that provides a
challenge provides a domain and provides an interact response. But I think
Dave Longley we're getting rid of this. Is that right?

Dave Longley: If there's not a good use case for it, I think it has been
replaced entirely by the redirect possibility that you can send at the end
of an exchange. So by sending an interact object sort of in the middle of
an exchange, it's unclear, whether or not you would go take it and use it
somewhere or what you would, when you would use this. the exchange protocol
has changed over time since the interact object was created where you can
transmit multiple messages back and forth until the exchange ends. And if
you need to go somewhere else at the end of the exchange either party can
send a redirect URL and the redirect URL could be to anywhere and it can
also be an interaction again taking you to yet another interaction.

Dave Longley: So, I don't think we need that property anymore.

Manu Sporny: Okay. …

Manu Sporny: So, I can remove that and then of course this gets changed
back to BC API based on the call we had yesterday. so VPR is sent and then
a verifiable presentation is responded with. one I forget for did off if
This one doesn't have a D off in it. There need to be two credentials here.
One of them is the actual bachelor's degree and the other one's a did off.
we do have some weirdness here where this is effectively that's happening
here. I don't know if we need to figure out if for the authentication
protocol this is in the VCOM specification if this is acceptable as a did
off or you need to be more explicit.
00:15:00

Manu Sporny: and then once they do the did off and the presentation a
verifiable presentation is sent back to the holder with the new university
degree credential. So that thing's been refreshed at this point. and then
the validity period has been updated to extend another 10 years. and that's
it. pretty straightforward specification. Let me see if there are any
questions Any questions, concerns? Go ahead, Dave.

Dave Longley: The one thing I'll bring up is that there had been discussion
around an alternative approach where either could be used by an issuer
where a refresh credential could be created so that it could be used for
any number of different credentials that might not include refresh services
themselves.

Dave Longley: And we could do that in the working group or we could have an
example of that in this spec for something to work on when it hits the
working group.

Manu Sporny: We should probably put it in before it goes into the working
group.

Manu Sporny: Let me add an issue actually.

Dave Longley: And that is another place where the a can be put to help did
off problem you were mentioning.

Dave Longley: As long as you always have that refresh credential, you could
did off, put a D in that refresh credential and then perform D O using it
and…

Dave Longley: any other credential that the issue would be willing to
refresh for you.

Manu Sporny: So add refresh credential example to data model.

Manu Sporny: Discussed the possibility of a re f that lists one or more
credentials that could be refreshed provided the service. that would not go
into the fresh service end point.

Manu Sporny: go ahead and create that. we don't have any of the effort
stuff on this repo. So, I'll try to process that and get that into the
spec. Any other questions, comments on the spec. All right. So, we will I
also forgot I added the conformance glasses, too. So, please do take a look
at the spec.

Manu Sporny: we will probably ask next week after this other stuff's in
there whether or not we're ready to promote this to the VCWG. so if you
have any comments or concerns or issues, please raise them before next
week. okay, that's it for the verifiable credential refresh spec. the next
item up is the verifiable issuers and verifiers list or specification. we
really do need Isaac and David or Dimmitri here for this conversation
because Dimmitri's got a set of use cases that we need to discuss.
00:20:00

Manu Sporny: David's got a set of objections that we need to discuss and we
need Isaac's input as well since he's provided input on this. okay. and
we're not going to have that discussion today because they're not here. but
to point out kind of the issues we're having now. I think the core of the
issue right now is that we were unable to merge this David's insisting that
we use the current data model. I think the concern is that the current data
model does not fit the fully decentralized use case very well. it sounds
like we have three different core use cases at this point. I didn't during
the last call hear any objections that those are all three valid use cases.

Manu Sporny: As I understand it one Dmitri has a use case where he wants to
just list known entities in the coem. so basically entities that have been
identity proofed to some degree. So for example, a list of all the
universities in the United States including their URLs their ds a variety
of things like that. So it's just kind of a kybad list of entities.

Manu Sporny: Go ahead Dave.

Dave Longley: I want to say it's not necessarily even KYC,…

Dave Longley: but How you get into the trusted directory might be an open
thing for different ecosystems, but it's a mapping of identifier like it
did to information about that entity.

Dave Longley: And that's especially useful for displaying information about
entities in digital wallets and so on. So, I think he's looking for a
trusted directory.

Manu Sporny: Plus one.

Manu Sporny: So, let's say that's the trusted directory use case. the
second one is the one that Isaac and David seem to be most interested in
which is to effectively support the trust service provider model in the
European Union. so there is this standard out there Isaac has done some
work on it as well with David.

Manu Sporny: it's based on train which basically says here are the trust
service providers in the EU this is what they're trusted to provide these
are legal agreements associated with how they operate these are the things
that they can issue these are things that they're certified to issue all
that kind of stuff so it's kind of a very detailed directory or not it's a
very detailed list of which entities are trusted to authorize rise other
entities to issue credentials. go ahead Dave.

Dave Longley: And I want to say there might be some synergy between those
two use cases where you could have an entry in your trusted directory that
says that this particular entity is a trust service provider and then use
the data model that Dave is talking about to describe that portion of that
entity.

Dave Longley: So there's good ways to put those things together where you
can have the trusted directory independently of that. But if you wanted to
augment information about any given entity, you could use the trust service
provider data model if it was applicable for that entity.

Manu Sporny: Yep. Bless one to that.

Manu Sporny: So there is some overlap there.

Manu Sporny: Certainly. Go ahead, Ted.

Ted Thibodeau Jr: Yeah, I think terminology should be avoided about
authorizing entities to issue credentials.

Ted Thibodeau Jr: Rather, it's an ement of not even validity, the
endorsement that this issuer of credentials is authoritative just isn't the
right word.

Manu Sporny: Yeah.

Dave Longley: I think it's one party is saying that they would be willing
to accept credentials for credentials and…

Dave Longley: and specifically these claims made by these parties. So I
think you're just making that assertion. You're saying if you saw these
claims made by these parties, I'd be willing to accept those.

Ted Thibodeau Jr: Yeah. Wait, wait.

Dave Longley: And that is what is on offer. It's not saying these are the
parties that are authoritative to say these things in the world. That's
what we don't want.

Manu Sporny: Yeah, plus one.

Manu Sporny: I think that sensitivity is definitely strong among a subset
of us. I do think that there's a cultural misalignment here, meaning that
it really is authoritative to issue in the EU. it is very heavy-handed,
right? is and I think that's making some of us a little nervous because I
don't think we're wanting that level of authoritiveness to necessarily
follow with the third use case which we haven't talked about just yet.
remember that it's also verifiers.
00:25:00

Manu Sporny: So in the EU' basically there are authorized verifiers for
national IDs and if you are not on that list you are not supposed to hand
over the document to that entity and it legal consequences if you as a
digital wallet hand over a credential to someone that is not an authorized
verifier of a national ID document for example. so we are going to have to
tease this apart, right? …

Manu Sporny: but go ahead, Dave.

Dave Longley: Yeah, I think with the model and…

Dave Longley: design that we're suggesting that Ted and I have both I think
we're in agreement here allows for that to happen but also allows the other
use cases. And if you design it such that what you're describing is I would
accept these then a business or…

Dave Longley: some group in some ecosystem could all agree to say we're
only going to accept whatever this other party says they would accept. And
that accomplishes the same thing without putting it into the data model and
the design that everything has to take that authoritative approach. But you
can do that within the same design. So I think this more decentralized
approach covers both cases.

Manu Sporny: Mhm.

Dave Longley: and we can talk about how to do that in the spec to smooth
over any rough edges that people…

Dave Longley: who want to say we need to say this is authoritative in our
ecosystem you can do that and here's

Manu Sporny: Mhm. Yep.

Manu Sporny: Plus one of that. T

Ted Thibodeau Jr: Yeah, that's exactly the direction that I think we should
be going in is enforcing the idea of business logic to accomplish that goal
of authoritative issuers…

Ted Thibodeau Jr: which is different than and trust is the wrong word
again. but I guess that sort of is the right word.

Ted Thibodeau Jr: I'm saying I would trust a certificate issued by this
entity with these claims in it and…

Manu Sporny: Mhm.

Ted Thibodeau Jr: then you base your decisions on what I say. That's fine.
But it's not that I am making them the authoritative issuer for everybody
else in the world.

Manu Sporny: Mhm.

Ted Thibodeau Jr: It's just I'm saying about what I would do and this is EU
entity that is endorsing these issuers is doing All right.

Manu Sporny: Yep. Yeah. And so maybe endorsement is a better thing than
authority. and then trust is always that slippery slope than that. Everyone
has a different definition of trust. Sure. okay. okay.

Manu Sporny: so the second use case I think it is coming from something
that's making a much stronger statement the EU trust service provider thing
and then the third thing is the fully decentralized solution meaning what
do we need to do a kind of a fully decentralized solution where there
really doesn't need to be a list anywhere but you need to show up with a
couple of things.

Manu Sporny: Meaning when you go to a verifier the verifier can say it's a
bad word but these are my roots of trust give me a credential from one of
these roots of trust for any credential that you give me it's got to be
rooted back to that root of trust and then I want a university degree yeah
so yeah acceptable endorsers or something like that so

Manu Sporny: So what actually ends up happening is behind the scenes the
wallet can go out and get one of those credentials or look it up or that's
out of scope but what the holder hands over or the university degree itself
and then something that links the issuer of that university degree to the
the acceptable endorser root of trust that the verifier has asked for. And
it might go through two hops, whatever. X5 or 9erts do this through
certificate chaining. we're trying not to be that hierarchical about this.
and so that's the third use case is how fully decentralized. There is no
list out there anywhere, but the individual shows up with the things that
they need.
00:30:00

Manu Sporny: and this is analogous to the way bitstring status list works
in theory and in reality potentially the entity the digital wallet
presenting is capable of giving the credential and bitstring status list at
the same time So the verifier doesn't need to go out anywhere to get that
information. go ahead, Dave.

Dave Longley: Yeah, I was going to draw the same analogy and I think that
the specification should be clear that the design is such that whoever is
going to be presenting these credentials can go out and gather what they
need to. They can gather it on a schedule that's appropriate for them and
they can do it without leaking who they're going to be sharing that
information with. that is a much more privacy preserving way of doing it
than some of the alternatives that might be in the ecosystem today that
rely on federations where verifiers will hop all around going to different
federations asking about someone. And so we want to sort of avoid those
little phone homes. and I think this design can do that.

Manu Sporny: Yeah, plus one. on that note, it may be that, I want to be
careful about how to say this. It may be that federation is the anti-attern
we're trying to avoid. because federation by and large is a phone home
system. It's, two-party. I know that there's some people that argue that it
is possible to configure Open ID Connect so that it doesn't phone home. as
evidenced by OID4VP and OID for VCI. but I think largely federation with
its constant ping backs to the system of record is fundamentally a phone
home system that we're trying to avoid. but I don't know if that's the
right way to talk about it without infuriating a bunch of people. go ahead
Dave.

Dave Longley: Yeah, I don't think there's anything wrong with a federation
of acceptable endorsers. it becomes problematic in the way in which it is
implemented and how you go about collecting information. So I think it's
important that the protocol that's used between amongst a federation for
trying to verify VCs when someone's presenting that's where things can get
messy and it's important that the presentation protocol can be privacy
preserving so people can bring with them and always do bring with them. No
one goes and does phone homes. they bring with them what they need to be
accepted and they're able to find out what they need to bring to the table
to be accepted and all of that can be based on top of the concept of a
federation.

Dave Longley: we need to be careful though that there we don't build into a
protocol that does these phone homes.

Manu Sporny: Plus one to that fill.

Phillip Long: Yeah, and I've been struggling with this from the higher ed
perspective at least because it's very clear that many institutions express
the desire to have information about how their credentials are being used
or if they're being used and ways in which that information can inform the
better construction of that credential or improve the contents or whatever.
ever it is. And so that's an aspect of the phone home which is valuable to
The question, but obviously it violates the idea that we share that this
should not be something that's is done without the permission of the
individual.

Phillip Long: So the question I guess I have is there a way to present this
in a fashion to the individual when verification is sought that does in
fact seek permission or at least if not seek permission is there a way of
including data in the credential that says for these circumstances I'm okay
with the institution seeing the verification that is the issuer seeing the
verification Yeah.
00:35:00

Manu Sporny: Yeah, it's excellent question.

Dave Longley: Yeah, and that sounds like a useful fourth use case. We were
listing use cases. Maybe there's some kind of aggregate credential usage
use case that could be explored for how that could be accomplished to meet
those goals without harming people's privacy. The end soing.

Phillip Long: the extent to which we can do that with giving a default
option that can be in there so it can be done quickly without necessarily a
decision every time it's verified. Going back to the individual and waiting
for them to respond would be helpful.

Manu Sporny: Yeah, I'm very concerned that we're wandering right into data
mining territory and it is really difficult to design a system that does
not fall over, I'm wondering if this is the spec to have that discussion
in. Right. I think it feels like a different thing. I mean plus one like
Phil I completely get the value and it's coming from a good place where the
education institutions want to make sure that they are providing education
that is aligned with the needs of the individual. so that statement stands
on its own.

Manu Sporny: My concern here is that it becomes very easy to accidentally
enable massive data collection and data mining even if it's a voluntary
thing. People will click through things to get to other things and
typically what the entire web has been optimized onto making sure that
people click past the things that give away their data. And so e I'm very
concerned about even approaching that problem. I think it might be okay for
us to tell the education institutions that you should do your discovery in
the same way you've been doing it.

Manu Sporny: and maybe we have a different work item to figure out how to
do good statistical aggregation of data to provide people information.

Manu Sporny: It just feels like an immediate lightning rod for ACLU and
data mining and whatnot like opening that door while we're just trying to
work on the base kind of use cases. Go ahead, Phil.

Phillip Long: I completely understand that and… that's why I hesitated to
say it. But I also know we just had from the CCG meeting earlier this week,
yesterday I guess it was the presentation from the folks from the center
for digital public infrastructure and one of the questions they pointed out
in their implementation of VCs was that the issuers wanted to know how
their VCs were being used the same problem that you're describing which
essentially is an endound this decentralization in order to get the kind of
data flows they've always had coming to them.

Phillip Long:

Phillip Long: So I appreciate this and maybe we just need to flag this as
an issue even even if we agree that it should not be something that this
particular implementation of a verifier issue or process supports and…

Phillip Long: and highlights it as a topic that needs its own discussion as
you'd mentioned. I do think it's a use case as Dave had said earlier that's
important. It may not be the use case for this solution. Thanks.

Manu Sporny: Plus one that.

Manu Sporny: Go ahead, Dave.

Dave Longley: Yeah, I share all those concerns. Having it be a different
work item of sorts is a good idea. I want to point out that from the
standards group from this ecosystem, if we don't have good people who
really care about privacy preserving ways of accomplishing certain goals,
then those people will go outside and find other ways to do it. And now
some of those goals we might say they shouldn't be accomplished, but I'm
sure within all of the goals that people might want to do with data
collection, some of those goals are okay and can be done in privacy
preserving ways. Other ones are not and not we just shouldn't support that
and we don't have to be part of it.

Dave Longley: But collecting some of the information in aggregate to better
understand how things can be used and so on provided that that can be done
in a privacy preserving way seems to be a legitimate goal and if this group
maybe it's not in this iteration but I don't know when it is it doesn't say
how you can do that probably groups and companies and ecosystems will
probably do it in less than optimal ways. because there are other benefits
that they can get in places that, it's not helpful in. And so I want to
make sure that we don't say we're going to completely walk away from
solving any of the legitimate goals providing any guidance to do this in a
legitimate privacy preserving way because all that does is put all the
incentives on doing it in some other way that violates people's privacy.
00:40:00

Manu Sporny: Yeah, plus one to that. if we don't actively work on a
solution, a worse solution will be u put in place. I do want to double down
though. I do not think that the verifiable issuers verifiers thing is the
place to solve this problem. so I appreciate Phil that you were hesitant to
bring it up at all. I think it's a good point, but I do not think we should
put it in this spec. I think we should have a separate work item and treat
it as the

Manu Sporny: potentially radioactive dangerous thing that it is if done
incorrectly. I wanted to point out, a recent story that I saw. so I didn't
know this, but the airlines operate a data broker and it's jointly owned by
the American Airlines, United Delta. and they just got caught selling to
the US government, Secret Service, ICE. and they also were specifically
caught saying that they did not want to be named as selling this
information, to governments. So, this is an example of, this is I think
they're a nonprofit.

Manu Sporny: They're jointly owned by the airlines and they are selling US
citizen data to the government where traditionally governments are not
allowed to collect that information on their citizens right so this is the
endound that is happening in the US this is 12,800 travel agencies it's 270
carriers if you have flown in the last 5 years your data has been sold
multiple times over by this organization and it is not anonymized. It is
your full flight details. Right? so this is the kind of thing that can
happen when privacy preserving solutions aren't taken and this is
specifically in an attempt to avoid any kind of privacy preserving solution.

Manu Sporny: So, this kind of bad behavior is going to continue to happen
until there's rules and laws and regulations against it. and this is the
type of thing that I think is really dangerous for us to enable. I think
some of these organizations asking for this data are not trained when it
comes to, privacy. and they just have a data problem and they're just
trying to solve it. but they don't quite understand the danger to civil
liberties that they are creating.

Manu Sporny: Okay so enough on that but hopefully that I think what the
takeaway here is maybe this is a different work item and if we don't
provide a solution we're going to continue to see this type of data broker
stuff happening. go ahead, Phil.

Phillip Long: And I thought,…

Phillip Long: yeah, just to close it out, I agree with this isn't the place
to do it. I also think that we at least should say something about it to
say that this is a really important slippery slope. It needs its own work
item and such. We just need to mention it here so people don't think we
just blindly left it off.

Manu Sporny: Yeah, agreed. And it might be the best place to put that is
the core VC data model spec, right? And privacy security considerations
there.

Phillip Long: People are going to look for it in here if it's a feature
that they can use. So, I don't think it's inappropriate to make at least a
reference in here, maybe point back to the VCDM for a deeper explanation of
it, but I think they'll look for it here.

Manu Sporny: Yep. Okay.

Phillip Long: And by this airline thing, ironically, the one place that
data hasn't been collected from is third-party booking sites. for whatever
reason, the hoppers and things like that did not get involved in selling
your data and…

Phillip Long: the associated credit card information with it and it's a
mystery to me why that was overlooked, but it was. Anyway, thanks

Manu Sporny: Yeah. Yeah.

Manu Sporny: All right. Good. So, we've basically identified the use cases.
Demetri, I see you joined. we just spent the call because we didn't have
David nor Isaac nor you. We spent the call just kind of focused on the core
use cases. to summarize, your use case is effectively being able to publish
a directory of known entities like universities, the identifiers they're
associated with, and some information images, names that have been vetted
for the purposes of, helping wallets, display them things of that nature.
00:45:00

Manu Sporny: that was Use case two was David and Isaac's use case which
kind of builds on top of your use case which is here the known institutions
and these are the things that they're allowed to issue known to issue. we
tried to figure out some better language other than authorized to issue and
whatnot there. And then the third use case is a fully decentralized use
case where there is no list published online but a verifier can a say that
these are my roots of trust. and then the holder can present a set of
credentials that are bound all the way back to the root of trust.

Manu Sporny: going from the accrediting or endorsing institution or person
down to an endorsement of a particular issuer to the credential itself
being kind of presented in a decentralized way. And then finally we talked
about a use case about aggregation of data and understanding how
credentials are being used.

Manu Sporny: but I think decided that that is a separate work item. We'll
want to mention it in this specification but doing good differential
privacy on who's using what credential where is a useful thing but a highly
dangerous and we need to spend a lot of time trying to figure out the best
way to do privacy preserving data aggregation of that nature.

Manu Sporny: okay those I think are the high level use cases. we can do a
PR to add those use cases to the spec. We do have use cases here but
they're very old and I don't know if I think what I might do is just add
some use cases and then we can decide if we want to keep these use cases or
not. so that seems like the use case here. any other comments, concerns?
We've got a concrete next step and then we'll meet again next week and try
to go through the use cases.

Manu Sporny: And once we have the core use cases though I think the next
step after that to make sure that we keep making concrete progress is to
provide minimum viable examples of each use case. what's the minimum thing
that we need to achieve each use case we work on that and then that will
inform the data model. rather going top down from train to what we have. I
think we're going to try to go bottom up from use cases to data model. I
think that is it for the call this week. thank you everyone very much for
the discussion today. we will meet again next week to continue this
verifiable issuers verifiers thanks Have a wonderful rest of your week and
we will chat again next week. Bye.

Dmitri Zagidulin: Thanks all. Bye.
Meeting ended after 00:49:11 👋

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