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

CCG Incubation and Promotion Meeting Summary - 2025-08-06

*Topics Covered:*

   1.

   *Specification Status Updates:* A review of the status of various
   specifications including Verifiable Credentials over Wireless, Confidence
   Methods, Quantum-safe Crypto Suites, VC API, Verifiable Presentation
   Requests, Verifiable Issuers and Verifiers, Credential Refresh, and Zcap.
   The Verifiable Credentials over Wireless spec was deemed ready for
   promotion (NFC portion), with the Bluetooth portion needing further
   implementation experience.
   2.

   *Verifiable Issuers and Verifiers List:* This was the primary discussion
   point. The group discussed a data model for expressing information about
   trusted issuers and verifiers, aiming for protocol agnosticism.
   3.

   *OpenID Federation Analysis:* Concerns were raised regarding the privacy
   implications of using OpenID Federation, particularly its chatty nature and
   potential for "phone-home" issues. The group favored a more
   privacy-preserving approach aligned with the three-party model of
   verifiable credentials.
   4.

   *Data Model Requirements:* The group agreed on the need for a data model
   focusing on core information for trust decisions (cryptographic material,
   schema matching, credential types), decoupled from distribution mechanisms
   (centralized vs. decentralized). Emphasis was placed on enabling the data
   model to function even without centralized lists.
   5.

   *Use Cases:* The importance of defining specific use cases to guide the
   development of the data model and protocol was highlighted. Three main use
   cases were identified: maximizing individual privacy, maximizing trust
   efficiency in a non-human context, and enabling holder trust in verifier
   identity. The group plans to further explore these use cases in future
   meetings.

*Key Points:*

   -

   *Privacy Concerns:* Significant attention was given to privacy issues,
   particularly regarding "phone-home" problems associated with centralized
   trust lists and the potential for correlation of seemingly non-PII data.
   The group is leaning towards a decentralized approach to mitigate these
   risks.
   -

   *Decentralization Emphasis:* The group showed a preference for
   decentralized solutions to avoid the drawbacks of centralized trust lists,
   while acknowledging that centralized approaches might be suitable for
   specific use cases. The data model should support both approaches.
   -

   *Protocol Agnosticism:* The data model should be designed to work with
   various protocols, avoiding dependence on any specific technology like
   OpenID Federation.
   -

   *Next Steps:* The group agreed to refine the data model, focusing on
   core data elements needed for trust decisions, and to develop and document
   specific use cases to guide implementation choices. Further discussion and
   PRs are expected in subsequent meetings.

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

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

Alex Higuera, Benjamin Young, Dave Longley, Denken Chen, Hiroyuki Sano,
Isaac Henderson, Joe Andrieu, John's Notetaker, Manu Sporny, Parth Bhatt,
Ted Thibodeau Jr, Venu Tech
*Transcript*

Isaac Henderson: Hello. Sure.

Manu Sporny: Hi, Isaac. We'll get started in about three minutes. We'll let
a couple more people jump on the call.

Manu Sporny: All right, let's go ahead and get started. We've got a good
group of folks here. I pinged Mitri as well, hoping he could join because I
think we scheduled this call on this date hoping that he was going to be
back. let me go ahead and share my screen. the other thing that I failed to
do is I have not sent out a new meeting invite to figure out a new time for
people that want to talk about this topic. David Chadwick said that he is
going to be unable to make the call for until the rest of August. I think
primarily because a lot of Europe is on vacation during August.

Manu Sporny: so we'll want to figure out if I'll probably have to send out
a doodle poll for that to see if there's any other time that works for
folks. our agenda though was communicated to the mailing list. this week we
are going to see if the VC wireless spec is ready for promotion and if not,
what further work we might need to do on that. and then we wanted to get to
some basic requirements for the expression of verifiable issuers and
verifiers. So we do have a data model that Isaac and David and a few others
have put together.

Manu Sporny: the next thing that we identified that needed to be done is we
need to focus on some concrete use cases that use that data model so that
we can figure out what kind of the one or two or three minimum viable
expressions of the data model might be. we had also said that we need to do
a bit more of a analysis on open ID federation. and I think Dave Longley's
been able to do a little bit of that and provide that as input to the work.
and so the majority of the call today is going to be focused on some kind
of base level requirements for how we see this verifiable issuers verifiers
list stuff working.

Manu Sporny: so that's largely the topic for discussion today. are there
any other updates or changes to the agenda? Is there anything else that
we'd like to discuss today? with that, let's do a quick review of where we
are in our incubation promotion work. recently as of last week the
verifiable credentials over wireless spec was adopted by the CCG. So let me
change this to say it's no longer needs to be adopted. there is a question
on so things that we are listing as specs ready for promotion.
00:05:00

Manu Sporny: we are, looking at the list down here and constantly,
reviewing it and then we're bumping it up to the top here when we think
things are ready. I will also note that the confidence method work is
ready. It doesn't need further work. I think we got it into a form we
wanted it in so real quick updates. The quantum saves crypto suites, we
have an implementation that dine and fork bomb have done. I think Deb Bazar
is also committed to doing an implementation of the MLDDSA 44 thing at a
minimum. We have a number of other crypto suites in there that we're going
to have to, determine if there's enough support to move forward.

Manu Sporny: they just differ in kind of the underlying cryptography that
they use. the high level stuff is largely doesn't change except for the
identifiers and of course the proof value and stuff like that. VC API has
had a lot of good work done on it over the summer. We have reduced it from
I think 43 issues down to around 17 many of which have PRs forthcoming or
they're high effort things that will require a decent bit of work but might
be work that's done in the VC working group. So this is getting very close
to being ready to say that it's ready for promotion.

Manu Sporny: verifiable presentation request. that specification I think we
came to consensus yesterday to just merge it into the VC API spec as one of
multiple query mechanisms possible. It gives the structure of changing
query languages and protocols. So it gives a lot of leeway on how you
bootstrap into the system and then switch to a different query language if
you want to do that. we're doing that because we not an explosion we're
seeing multiple different digital credential formats, multiple different
query languages, multiple different protocols out there.

Manu Sporny: And in an attempt to ensure that there's flexibility and
extensibility there, we're trying to keep pace with that verifiable issuers
and verifiers is what we're talking about today. largely verifiable
credentials over wireless has been adopted. It's mostly ready. We need to
have a quick discussion on what else do we want to do before we move it
into the BC working group. credential refresh we haven't really touched
much. I think it still needs the work work to be done on some of the
refresh protocols and the refresh data model. So that has not seen much
work or updating.

Manu Sporny: It wouldn't take a lot of work to get it done, but that hasn't
happened. Dimmitri mentioned that he's going to take over the Zcap spec and
try to incubate that and move it forward. I think he's currently talking
with the chairs in the CCG to figure out when we can kind of focus on that
a bit more. that's the high level status of the specifications. Any
questions on any of them before we focus on the BC All right, let me open
up the wireless spec. as a reminder, the verifiable credentials over
wireless spec is just a way to transmit verifiable credentials over very
short distances. so the NFC and Bluetooth primarily.

Manu Sporny: you can also do it over QR code. You could argue that optical
is part of the radio spectrum. but I think we're doing the VC barcode spec
in a separate specification. So this is purely about NFC and Bluetooth. A
lot of the NFC portions of the specification are in here we're basing it on
wireless render method. that has a very specific payload. So you can do NFC
tap for things like tickets and things of that nature public transport
tickets and things of that nature. So that part of the spec is pretty
mature in there and is being used for the NFC stuff.
00:10:00

Manu Sporny: For Bluetooth, we really haven't done a tremendous amount of
work on the Blueoth portion of the specification. It might be that we just
punt the Bluetooth stuff to a version two or version 11 one. it's not
difficult work to do effectively the Bluetooth part of the spec would
effectively run VC API over a Bluetooth connection. we just have not seen a
lot of I guess demand for this thing. a lot of people are getting stuff
done over NFC. It seems to be working well enough for them. Bluetooth's
more complicated to set up, the beacons and the phone and all that kind of
stuff.

Manu Sporny: and for that reason, VC over Bluetooth it's just, not getting
a lot of focus. However, I think we do eventually want to support it. the
question is, do we want to keep incubating it or are there people that want
to keep incubating it here? so we might make a decision to just keep it in
the spec and maybe do a first pass of I mean the Bluetooth stuff already
has an example of what would be sent over Bluetooth. We just need to have
an implementation of it to make sure it's implementable. but as you can
see, the back and forth is just standard stuff that already flows over VC
API.

Manu Sporny: So there's not much to do there other than set up the basic
Bluetooth stuff which is done through web Bluetooths largely which again is
not implemented by Apple. It's implemented by Google and has been the case
for the last decade. okay at least in the browser setting in a native app
you can do that stuff. okay that's where the spec is right now. So the
question to the group is have we incubated this enough to hand it over or
do we want to incubate the Bluetooth stuff more? Let me stop there and see
if folks have any opinions one way or the other. You're ahead, Dave.

Dave Longley: Part of my opinion on this depends on how much work the VCWG
is taking on at once. and how much any other participants are super
interested in doing the Bluetooth work because I do think more incubation
is needed in that area. But whether it happens in the CCG or VCWG is an
open question that is related to what I just said. So I don't know the
answer to that. but I will say I do think more implementation experience is
needed but it could happen in either place.

Manu Sporny: All right, Any other input on the Bluetooth section? So, how
about this? As a proposal, we'll just mark the Bluetooth section as needing
more implementation experience. and we could say that other than that, the
specifications, ready to be handed over to the BCWG with a presumption that
if more implementers for Bluetooth don't step forward, that part of the
specs just going to be dropped until a second version of the specification.
So, the specification would then really focus on the NFC portions of it.

Manu Sporny: and then either the Bluetooth portions of it get interest once
they're in the BCWG or if there isn't, they'll just be cut and dropped and
we'll largely focus on NFC for the V wireless transmission. does that seem
like a fair enough proposal? Are there anyone agree disagree? So, let's
just go with that for now and then we'll see if anyone steps forward for
the Bluetooth stuff. So, I can make that update to the specification just
mark the Bluetooth section as needing more implementation experience.

Manu Sporny: we'll move the verifiable credentials over wireless spec up to
ready for promotion just for the NFC stuff. and then move on to the other
specifications. I think that's it for that discussion. All on to our next
agenda topic which is verifiable issuers and verifiers list. during the
last discussion on the topic Dmitri presented the work that MIT and DCC has
done with Open ID Federation. we had a number of kind of concerns around
the way that specification operates kind of centralized doesn't support
DIDs that sort of thing.
00:15:00

Manu Sporny: I think both Isaac, you and David have said what we have here
it's a data model.

Isaac Henderson: Yeah. Heat.

Manu Sporny: It's protocol agnostic and so whether or not you use open ID
federation is kind of secondary thing. largely we're just focused on the
data model here and so what we're trying to focus again like what we're
trying to do here I think we got to consensus what we're trying to do here
is create a data model and you can use it over a variety of different
protocols you could use it over open ID federation you could use it over VC
API you could use it over oid4 VP we just have a data model that can be
expressed as a verifiable credential that can then be used in any of those
protocols so the focus here is to focus on the data model.

Manu Sporny: We will have to of course talk about the protocols to make
sure that you've got the data in the data model to support whatever the
protocols are doing.

Isaac Henderson: Mhm. Yeah.

Manu Sporny: U but again I think the focus here is largely on the data
model. Isaac, did you have anything else that you wanted to kind of add to
that kind of setup?

Isaac Henderson: I think you mentioned it rightly. So I think I also looked
into the digital credential work or the trust registry work which Dimitry
done actually he shared with me a couple of documents.

Isaac Henderson: I think they don't have a similar draft which we prepared
here right so I think they have a different documents which she showed me
and the GitHub links and I looked into that I think so the way they worked
is actually that it's one of the implementation for open ID for VC and the
data model which they discussed so it's not quite agnostic so they have
couple of details maybe I can share the screen shortly here moment.

Manu Sporny: Let me stop. Yeah, you should be able to share. Yes.

Isaac Henderson: Okay, Can you see my screen? Okay, perfect. so these are
the metadata which they discussed as part of this work which is a part of it

Isaac Henderson: So at the end of the day this is specific to a use case
for example university use case or education credential use case but when
we think beyond it I think some of the things which we discussed in our
data model will be really helpful for industrial ecosystems or like
federations and different others trusted services. I think and also for
example the get protocol which they used for getting the subordinated
listings from the open id federation. and so these are the wide metadatas
which they discussed and also it's specific to the use case.

Isaac Henderson: So maybe my suggestion would be bring this as one of the
implementation for this data model what we discussed and then we could
translate it so this is some of the attribute which is already discussed
here so the service provider information and this could be also in
university and then tell this is one of the impleation consideration how
you could implement in the open ID federation and that would be for example
so That's where we have here.

Isaac Henderson: So maybe we can have additional chapter where we say this
is an implementation considerations for open ID federation and then we
could tell this as an education profile for example and in future when we
are being promoted so then we could also define different profiles and data
model profiles for different use cases which can be used so that's also
part of the work which we mentioned here tell which are the

Isaac Henderson: mandatory things which are the things not required which
are the optional fields which we have a overview of the details by which we
can create multiple profiles and this can be used across different
providers actually and I also spoke to David shortly actually so maybe the
heading might be a little bit misleading we can also make it quite concrete
so data model for trusted registries or trusted issuers and verifiers or
something like that so that it more concrete so that I think we are also
flexible with that actually the group agrees on that so to make it a little
concrete so those are my commands
00:20:00

Manu Sporny: Thank you, Isaac, for that in the background and in sharing
the screen there. I do agree that probably the title of the specification
is not correct right now.

Isaac Henderson: Mhm. Yeah.

Manu Sporny: I'll also note that we've talked about the words trust and
registry and I think there are a number of minus ones to kind of using
those words for a variety of reasons we can go into but I do agree with the
base notion that we are probably going to have to retitle the spec at some
point and…

Isaac Henderson: Mhm. Yeah. Mhm.

Manu Sporny: maybe we do that after we figure out everything else that goes
in the specification. the other kind of question was kind of around so I
think we've at dig bazar have been able to look at the open ID federation
specification at least at a high level. Dave Longley, I don't know if you
want to speak to anything of the analysis that we did, before we get kind
of started on, what should the data model or what should the requirements,
go ahead Dave.

Dave Longley: Yeah, I think the way that I would frame this so I looked
over that specification with the idea of inserting this into a number of
use cases related to trusted issuers and verifiers with respect to VCs. the
thing that struck me the most is that I feel like what we're missing it's
good that we're working on a data model and talking about the various
elements we need there and working on use cases to describe why we need
those elements. on the protocol side I think it's really important that we
also come up with a set of use cases to walk through and constraints that
we have.

Dave Longley: something that's important and quite different about the V VC
ecosystem and the thirdparty model in general is that it was designed
around being more privacy preserving. And so I want us to make sure that if
we're going to say this is how you should go about expressing information
about trusted issuers and verifiers that however we express that
information we're going to adhere to those same privacy preserving
principles and perhaps more importantly when you go about fetching and
obtaining that information we similarly adhere to that.

Dave Longley: So, one of my biggest concerns in reading that other
specification is that I don't think just in their basic design requirements
and what they were going for that privacy was really high on the list or
really considered at all. There's a very short privacy consideration
section in that specification where more or less there's a few sentences
about, if you care about privacy, maybe do this or that. and I think that's
really clear in the design of that the open ID federation specification is
largely designed around a very chatty protocol where anyone can look up
information about anyone else which isn't on its base necessarily a
problem. but I would be very concerned about potential phone home issues.

Dave Longley: So you go to visit one member and if a person goes to visit
one member of a federation, that federation might then kick off a lot of
different calls as a verifier back to the place where the person is a
member of whatever their membership is with the federation and then all the
way up the trust anchor chain. And so I really think we should be careful
here because we might end up with a lot of phoning home and maybe more
phoning home than we would have in that we've tried to avoid in the
standard VC exchange ecosystem where you're not considering these
federations and trust lists. you're just worried about one phone from the
verifier to the issuer.

Dave Longley: So, in a federation scenario, if you have a very chatty
protocol, you might end up with a phone home from the verifier to the
issuer and then all the way up a chain as well. And so, I think there are
ways to avoid things like that and we should clearly define how we want
these use cases to work. we should clearly define the use cases where for
example a person is presenting a VC a person is on a website and the
website is acting as a verifier and they want to request credentials from a
user but they don't know or expect that the user will necessarily have
precisely the credential issued by the party that they trust and so the
verifier needs to in some way or another announce sort of the trust anchor
00:25:00

Dave Longley: or list of issuers that they would be able to trust. And then
the same thing needs to be reciprocal on the other end. So the holder needs
to be able to say, who are you verifier and I want here's my, trust list.
So make sure that you're on that list. But we don't want those two parties
to go look those lists up about each other because that leaks a lot of
information, becomes a phone home problem. And so we need to be really
careful in saying what our constraints are about that protocol so that we
don't leak that kind of information. And so we want that exchange between
the two parties to remain private and to adhere to all of this
architectural work we did to have this three-party model where those two
parties can talk to each other without sending a blast out and having
everybody effectively chat about the holder and what's going on.

Dave Longley: And if we don't have that clearly laid out, then it's going
to be really easy for some ecosystems to say, we'll just go with this
protocol because we don't think those privacy concerns are, matter enough.
and then there will be other areas where they do matter more, but there
won't be a technological solution and they'll potentially copy the solution
where it is a problem. So, I don't think we've done enough work defining
the constraints on what that protocol is and how we can go about making
sure that you continue to have private interactions. and I'm worried about
us selecting a protocol that was not designed with that in mind. and so
that's where I'd sort of leave the analysis that we have on that P on Open
ID Federation.

Dave Longley: I think we have more work to do to clearly say what the use
cases are and where the constraints and are and sort of red flags are that
we want to avoid and make sure that these protocols don't enable that sort
of behavior.

Manu Sporny: Plus one to that. I think in the analysis that was done for
Open ID Federation, I think the biggest concern that we saw was how chatty
the protocol is in how effectively the verifier or sorry how the trust
anchors in the ecosystem can end up seeing who's

Manu Sporny: talking to who down to a website kind of level. they get to
see as it's happening, because the protocol is so chatty and it happens,
when a verifier is verifying a credential, everyone up the trust chain gets
to effectively see who's communicating at the leaves and that's like
textbook bone home concern, right? and there's no and that is how you use
open ID federation. so I think the protocol was designed during a time
where the two-party model was just a presumption. and there was no real
concern over that sort of phone home or that type of chatty communication.

Manu Sporny: or even just side effects of calling the HTTP APIs where you
find out which domains are talking to which domains identifiers are used in
which other domains. and then you find out who your IDP is and all that
kind of stuff, again plus one to the privacy, concerns there. the other
thing that I don't know I didn't hear you say Dave and this is not about
open ID federation. It's that a lot of these systems work without
federation and without these trust lists today people keep talking about
the IKO public key directory.

Manu Sporny: IKO is the thing that tracks passport public keys, right? So
if you have a passport, the presumption is that you're on the IKO public
key directory and they manage it for all countries. the reality of it is
that not every country is on the IKOPKD and not every country wants to be
on the IKO PKD and still global travel works and people from countries that
are not on the BKOPKD seamlessly move between countries as they're flying
and in doing that sort of thing, crossing borders. So, why does that work?
H how does that work? Right?
00:30:00

Manu Sporny: If you absolutely need these federation things or these trust
lists for an ecosystem to operate, how is one of the biggest highest risk,
highest security, ecosystems able to operate without one of these things?
And I think the answer to that is you don't fundamentally need these things
for it to operate at scale. These things default to a decentralized
mechanism when the centralized mechanisms fail. And that's an example of,
what happens in passports. The readers that are at the passport, in
immigration, customs and immigration in these countries don't just read off
the IKOPKD. They are configured locally in a decentralized manner to
recognize these other passports from other places.

Manu Sporny: So, I want to suggest that, these things are not mandatory,
and I'm really concerned about us trying to suggest that they are mandatory
or to fit them into the core protocol. So, you absolutely need them in the
core protocol for it to operate. I think I'm concerned about the query for
a digital credential to say these are the trusted providers, that I have or
these are the roots that I have and making that a mandatory part of the
core protocol. I think they should remain optional things. and if you don't
answer if you don't like

Manu Sporny: high up to that route. That doesn't mean that you can't just
present the credential and have the verifier decide based on what you
handed. I'm very concerned about making it mandatory to you for you, the
holder, to prove the chain up to the trust anchor that exists because it
may be that there is no trust anchor for your credential and the verifier's
got to make a judgment call. and we should continue to support that. go
ahead, Joe.

Joe Andrieu: Yeah, thanks. I want to echo a lot of what Manu and Dave just
said about privacy plus one of the use cases. I think that's the right way
to navigate the privacy questions is which use cases do we care about and
about them what features of those use cases and solutions do we care about.
So I think that's probably the right way to get on the other side of some
of these issues. there are two big things that lead me to frankly not like
this work. I oppose it. the bigger one is I think it's a centralized
approach trying to solve decentralized problems. and I think we'd be better
off with following something like who is from the did webb work where DID
document itself, you enable a way for people who are resolving that DID
document to go and request credentials which may give the bonafidees of
that issuer.

Joe Andrieu: and in that architecture, if a verifier gets a VC and they
don't know who the issuer is, then they could look up who is and
potentially get back credentials that in fact embody whatever
certifications that issuer has that supports their authority in this
domain. And that architecture avoids the entire centrality of having a list
that someone is deferring to. and that gets past this IKO thing that Manny
just walked through we can work in that architecture without having a
centralized system. The other problem which I think is maybe more subtle
but I'm also not seeing addressed here is the definition of validation in
the VCDM specifies that what you're validating is that this issuer is
acceptable for a particular claim.

Joe Andrieu: that sensibility is not addressed in this specification. So we
haven't said, hey, for this issuer, they are definitive for your right to
drive in California. so there's a fundamental question of whether or not
you accept, for example, the Department of Motor Vehicles is definitive for
my height, for my address. There are different levels at which you might
say, I'm willing to accept the DMV's assertion about XYZ." and that is a
subjective decision that the verifier must make. So they may take the age
because that's a good signal. but really the DMV is not definitive for age.
They're definitive for the types of driving privileges you have.

Joe Andrieu: So I just want to get those two concerns in the mix. I'm not
sure how we address them, but those are my concerns with the work.

Manu Sporny: Great. Thanks, Joe.

Isaac Henderson: yeah I agree with that so I think those points are really
important…
00:35:00

Isaac Henderson: what you mentioned about the privacy but I think here when
we talk about the datas what is being stored in the trust list is belongs
to some certain entities, right? For example, these are not PII datas and
as for example, one example I would like to highlight is the universities,
which we always talk about how do we validate the credentials when this
university is not anymore present or if the university is not offering any
more the degrees for example, right?

Isaac Henderson: and the certificates where they belong for example and how
long they were existing and this is one of the use case and also for the
coming of the digital product passports coming into play and how do you
really validate the issuers behind those parts for example some can go
insolvent but still you need to find out kind of a way how long they were
valid until for example when you go to the legal whether they are eligible
to

Isaac Henderson: give the service or not so these are the details which are
mentioned in this specific list for example and also as Joe mentioned the
schema regarding what are the claims they are able to verify so each
service provider can have multiple services and some service are eligible
to only verify age and some are eligible to get more data so those things
can be entered as a part of the list as a claims at the end of the day we
are not saying this is a mandate but this is a tool helpful for verifiers
to make informed decision. So that's why I think depending on the
credential what is being used or what is being validated and based on the
use case I guess these kinds of lists are also playing a role I guess
actually because all the wallets whatever is currently implemented at least
in Europe they have these kind of list.

Isaac Henderson: I know this is the phone home problem is existing but when
we think about the use cases of education use cases or product passports
and stuff where I think these kind of list helps but I think this list
doesn't contain any personal information rather the information related to
entities are being present there so that's my argument yeah or any

Manu Sporny: Thanks. I good input. go ahead Dave.

Dave Longley: So I think having a data model to express information like
this university is accredited or we trust this entity to make assertions
about age or about this claim or that claim. All of that I think makes a
whole lot of sense. I get a little concerned if we start conflating that
and if you're going to express that information it has to be done in a list
or registry or in a centralized mechanism. I think we need to decouple that
a little bit better. and there's probably a number of ways to do that. So I
think it's vital to be able to express that information and…

Isaac Henderson: Mhm.

Dave Longley: express it in a standard way.

Dave Longley: and then we got to talk about what's the best way to go about
obtain getting that information. And there are better and worse ways to do
that with respect to both the ecosystem you're in and just by default. I
think if we make a default way that does this that would be privacy harming
in some places and not others, I think we're going to bump into some
problems. I think there are ways to do it that we can really improve the
privacy outlook and so we should be careful.

Manu Sporny: Plus one to that. going back to also what Isaac you mentioned
I think with the data model we should focus on a data model where you
express the core of the information that helps you make the decision.

Isaac Henderson: Yeah. Mhm. Yeah.

Manu Sporny: How it's distributed It's important but secondary right? So,
we just need to get the data model right so that we're expressing the
things that once they get to a verifier, however they get to a verifier,
they just need that data packet to figure out whether or not they're going
to trust these other credentials. Doesn't matter where it comes from, so I
want to make sure we focus on that because if we focus on that then it can
be published in a centralized way. it can be published in a decentralized
way and it can be done in in between. I think we should definitely focus on
that and then how do you get the information kind of a secondary discussion.

Manu Sporny: So I think the core requirements then are going to be like
what are the core fields that a verifier or a holder needs to see to be
able to make that trust decision right so I think …
00:40:00

Manu Sporny: if we could focus on that at the data model level I think
we'll end up with a solution that'll work for everyone.

Isaac Henderson: Mhm. Yeah,…

Isaac Henderson: I think that's a good point So that's what we concentrated
at this point For example, so this is one of the aspect which is present in
all of the list the public key of the certificates so in most of the list
for example in covid certificate they were just publishing the public
certificate of the issuer to validate it so there were no other attributes
or what type of credential it belongs or the schemas and stuff like that
and so here we also have the option of ds so we don't say the adas trust
list where they just have the x509 certific

Isaac Henderson: cificate in future if there are some other identifiers
beyond it for example Kerry identifiers or something like that comes in we
can also plug in here for example and here or this type of the credential
because I think that that is also really important whether this is re the
issuer or is really allowed to issue this credential or this type for
example which can be validated with the schema over here you can see here
and if they want to have high levels of assurance they can also read the

Isaac Henderson: business rules and the metadatas inside this one to find
out the leis they belong for example whether they are compliant with EOS
standard or certifications so these all are a public data so these are all
available always on the internet or belonging to the companies or in their
website so these are not anything belong is any private data I would say so
only what is belonging to the service is just the certificate and these
things are the things which we are trying to concentrate on this

Isaac Henderson: one and also the activity whether this service is active
or not how long they were active and so this is one of the implementation
which we have done as a part of regress which also tracks actually so we
had an auditability feature so that there was no records deleted you can
retract back to the versioning and to find out which list was active which
was not and that was one of the implementation approach we used so that not
any of the details are being erased or something like So the implementation
noise there are different forms or ways to implement it but these are some
of the datas which are really required to validate from the minimum level
of asurances which is used for by the public key to the higher level of
asurances with the schemas and metadatas and stuff like that. So all these
things we are bringing together and presenting as a part of this approach
actually.

Isaac Henderson: So I think these are all belonging all things are not
private datas but the public datas which are available on a website. Yeah.
Yeah.

Manu Sporny: Yeah, plus one to that meaning the specific data elements that
are needed. You need to know who for example if we're looking at verifiers
and issuers and you're trying to figure out whether or not this issuer
should have issued this understanding what their cryptographic material
identifiers is under understanding that there's a schema to match against
the credential is important and…

Isaac Henderson: Yeah. Mhm.

Manu Sporny: then understanding the types of credentials they can issue are
also important. I'll add that there's another thing that I think is
important where that entity might have very specific it might have a
cryptographic identifier like a certain did but it might also have very
specific keys that only issue certain types of documents like a driver's
license versus a vehicle registration for example.

Isaac Henderson: Mhm.

Manu Sporny: might be two totally different public keys and we're going to
have to figure out how we're going to address that. that was comment one.
So that's agreeing with everything you said Isaac about those properties
being important and we need to make sure those are in the data model. the
other thing that I've heard you say a couple of times now is that there's
no PII in here. I want to make sure that we understand what we mean by kind
of the concern around privacy and PII. and let me give you an example of
where there's no PII in here but it ends up becoming incredibly damaging to
privacy when this document is fetched.

Isaac Henderson: Mhm. Yeah. Mhm.

Manu Sporny: So let's presume that this document that we're looking at
right now is published by a particular state a DMV in a state and the
verifier is going to go and fetch the list right they're going to get it
from somewhere for example in the United States there are certain states
that have very strong laws or rules against certain types of websites. So,
pornography is one example of some states having way harder rules on that
than other states. abortion clinics are another example of some states
having very negative consequences for people in those states. and then we
look at driver's licenses, right?
00:45:00

Manu Sporny: Those are typically staterun things. So, if we use a trust
list like this and it's published online, and someone goes to use their
digital driver's license, at a verifier, …

Isaac Henderson: Yeah.

Manu Sporny: what happens is that one, that individual has an IP address
associated with them when they access that website. if that person has to
prove to someone else that they are on the trust list, they will go out and
fetch the trust list. So now the state knows this IP address accessed my
trust list entry at this point in time. and then very shortly thereafter,
350, 500 milliseconds thereafter, you get another request from a p*** site
from Planned Parenthood or some kind of health care provider to the same
trust list.

Manu Sporny: that can be used to correlate in time which means that at that
point the state knows that there is an individual residing within their
state using a driver's license to access a service that the state is not
favorable of.

Manu Sporny: So that is the situation where we're really concerned about
these trust lists even though they don't contain any PII at all.

Isaac Henderson: Mhm.

Manu Sporny: A privacy violation has occurred at that point. And so I think
that's what when people say PII and we're concerned about PII and privacy
and you keep saying things like there's no PII in these lists. if we look
at a holistic protocol way, that's the privacy concern that people are
concerned about. does that make sense, Isaac?

Isaac Henderson: Yeah, I think that makes sense. I can understand from the
point you come from regarding the HTTPS and the IPs being stored. I can
really understand that but we also tried with IPFS way of doing it, So that
also worked. so yeah, there are different ways of doing it. but I can
understand that as a limitation.

Isaac Henderson: but I feel like current the communication in today's world
happens based on this HTTPS right and I know the dark side to it actually
also but unfortunately if there are other implementation consideration with
blockchain based approach or just using HTTP we can also try that actually
so we don't offer any just use HTTP or…

Isaac Henderson: these kind of approaches so that's not being mandated that
can be done in a different way but that's something out of scope or I think
that can be given as a security consideration as a part of the draft. Yeah.

Manu Sporny: Yeah, I think we can go a step f further in that we have
actually designed the verifiable credential three-party model to be
protective of individuals in that situation. So we have much stronger
language in VC API and the verifiable credential specification to use
things like oblivious HTTP enable the individual to fetch things
asynchronously so that type of time correlation can't happen enable the
holder to pull the information and…

Manu Sporny: store it with them and enable the holder to deliver the
information to the verifier so the verifier doesn't reach out.

Isaac Henderson: Mhm.

Manu Sporny: Those are all examples of things that we're pushing very hard.
Meaning that there are technical solutions. We believe they are the much
better technical solution and avoids the whole centralized lists approach.
It's partly…

Isaac Henderson: Yeah. Yeah, sure.

Manu Sporny: what Joe was speaking to before. So I think we need to go
beyond just like it being a privacy security consideration. I think we need
to very strongly suggest because of all the no phone home conversations
that have been going on now and because of the way MDL was deployed in a
way that it did phone home I think we need to be much stronger in
suggesting the proper way to do this versus saying you might want to think
about it…

Isaac Henderson: Yeah. Mhm.
00:50:00

Manu Sporny: but leaving the implementation of it more open. Dave, you're
on the queue.

Dave Longley: Yeah, I want to make sure that we don't close the door on I
want to make sure we don't move too far ahead using something that already
existed that wasn't designed for privacy for a protocol without considering
what we would actually do if that didn't exist. and what we would do with
the three-party model. I mean there's quick things that aren't fully
thought through. just concepts like if I go to pick up a credential from
this issuer, maybe they also issue me some important accreditations and
things at the same time and then I store those in my wallet and then I can
later present them at the time and then I don't have to go out no one has
to go out and fetch or do anything else chatty in such a protocol.

Dave Longley: In fact, with upcoming zero knowledge proof cryptography, I
might even be able to avoid presenting those things at all and just present
things that will match a certain circuit or something along those lines. it
allows us to move forward with more and more of the privacy technologies
that are coming out on a regular ba basis and it fits better with that
three-party architecture as opposed to everyone's going to talk to everyone
else because we have HTBS it's easy to do so let's just use it. let's be
careful with that so that we don't overuse that technology.

Manu Sporny: All we have talked about some of the requirements today. for
example and we probably need to write a lot of these start writing a lot of
these I mean we do have a requirement section but these are additional
requirements that I don't know if we really got to here and there's this
presumption here that there are these lists like that's the only way to
implement this stuff.

Manu Sporny: we might want to go down to credentials and…

Isaac Henderson: Yeah. Mhm.

Manu Sporny: then say that a centralized list is one way to implement this
stuff but has a number of downsides right so I think one of the
requirements here is to enable the data model to be usable when there is no
centralized list that feels like a core requirement and it avoids the
presumption that there needs to be a centralized list. We can solve this in
a decentralized way. that is the assertion that the specification should
make. and then you can use it in a centralized list if for whatever reason
your ecosystem wants to work that way. You can use it in a federated list
again and if your ecosystem wants to work that way but we believe there's a
better way to publish this information.

Manu Sporny: so that's I think at the core of it and then in exploring how
to do the decentralized mechanism if it works for a decentralized solution
it'll work for a centralized one right because the centralized solution is
just take the credentials that you're using in the decentralized thing in
this put them in a giant list and that'll address the more centralized use
cases. me that feels like the core requirement that could actually make the
whole thing work for the decentralized thing.

Isaac Henderson: Mhm.

Manu Sporny: mean the core requirement being ensure that the payload what
the issuer is allowed to issue or what the verifier is allowed to verify
those things are themselves verifiable credentials that can be issued and
then carried by anyone put in a list carried by the holder whatever and
delivered to the holder so that they can make the trust decision.

Manu Sporny: where they don't have to phone home or…

Manu Sporny: contact any external resource. does that feel like I'm just
trying to hear what Mhm.

Isaac Henderson: Yeah, I think that's a good point…

Isaac Henderson: what you mentioned but also I think it's comes with a
little bit of the use cases right so for example when you think about the
industrial use cases which you think when a company in Germany wants to
deal a business with Japan for example they need to find out where the
Japanese supplier whom

Isaac Henderson: they have no contact with till this point of time they
need to find out the verifier of Germany needs to trust some of the
Japanese federation or…

Manu Sporny: Mhm.

Isaac Henderson: the CI of Japan for example to find out whether this Japan
company is in part of their federation if not they don't deal business with
them then it also comes into the legal problems right for example so that's
where I believe or within a company for example within the departments when
they communicate they can have these kind of list among themsel. which is
easy to manage decentrally which is not publicly available to anyone but
still they are using across the employees and across the goods whatever is
being transmitted. I think there also it can help by which it just stays
within the ecosystem for example.
00:55:00

Isaac Henderson: So when you think in these kind of scenarios without
having those kind of decentralized approaches just it's belonging to the
ecosystem it also makes the value more richer for these companies or…

Isaac Henderson: for these use cases. So I'm just trying to think actually
bas it is completely depending on the use cases right or do you think it is
not?

Manu Sporny: Yeah. Yeah.

Manu Sporny: I think no, we should write down the use case, Because I think
there are two legitimate Yeah.

Isaac Henderson: Yeah. Mhm. Yeah.

Manu Sporny: at least two legitimate base use cases and the use cases are
basically pointing to maximize individual privacy but still allow the
verifier to make the choice on whether or not they trust the issuer and
then the other thing is I don't maximize trust efficiency and that
ecosystem has decided because it's like car parts and…

Manu Sporny: manufacturers and…

Isaac Henderson: Mhm. Yeah.

Manu Sporny: there's no people actually involved. They've decided that they
want to just have lists that they use.

Isaac Henderson: Mhm. Yeah.

Manu Sporny: Okay, we're almost at the top of the hour. I think we'll just
continue to have this discussion in this group. we do need to get to I
think some core use cases. Let's say that those two are the base use cases
for now.

Isaac Henderson: Mhm. Yep.

Dave Longley: Let's make sure that there are three there because the holder
gets to try to establish trust in the verifier too.

Manu Sporny:

Manu Sporny: Yes. Excellent point. we do have a use cases document and I
don't think Yeah, we've got this. I think we should probably take this
content and put it directly in the specification at this point and then
expand the use cases.

Manu Sporny: So that probably needs to be done. and…

Isaac Henderson: Okay. Yeah,…

Manu Sporny: then if there's anything that we need to pull in from train
Isaac, please, let us know. But I mean, it's just going to be editable, …

Isaac Henderson: Mhm.

Manu Sporny: sections there. So, We'll take a look at the cases. actually,
no, we have them kind of here. so we'll make sure that there at least some
core use cases that point to the more decentralized solution and…

Manu Sporny: then we can also have the centralized use cases, listed as
well. okay.

Isaac Henderson: Okay, sounds good. Mhm.

Manu Sporny: That feels like the next step. So hopefully we can get some
PRs in, pull requests in to do those things. And then it would also help to
have some PRs in for examples for particular use cases. I think we Digital
Bazar are more interested in the fully decentralized use cases and…

Isaac Henderson: Yeah. Mhm.

Manu Sporny: making sure that those are possible. and then Isaac, you've
already done some markup here for the other use cases. we'll meet again
next week. I think we'll talk more about use cases. Hopefully we can get to
some examples of a minimum viable credential in a fully decentralized
example looks like in a centralized list example looks like and go from
there. okay, that's it for the call today. Thank you everyone very much for
engaging in the discussion.

Manu Sporny: We will meet again next week to continue the discussion.
Thanks all.

Isaac Henderson: Thank you everyone.

Isaac Henderson: Thank you. Bye-bye.
Meeting ended after 00:58:58 👋

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