[MINUTES] CCG Incubation and Promotion 2025-05-14

CCG Incubation and Promotion Meeting Summary - 2025/05/14

*Topics Covered:*

   1.

   *Render Method Finalization:* The group aimed to finalize the render
   method specification before handing it off to the Verifiable Credential
   Working Group (VCWG). Key discussion points included:
   - Adding HTML rendering capabilities as a separate issue.
      - Incorporating functional operations within templates, specifically
      focusing on date/time formatting as a crucial example. Concerns regarding
      security and preventing network access within template functions were
      raised. The group agreed on the necessity of a PR demonstrating template
      function implementation and defining a date/time formatting
function within
      the specification.
   2.

   *Verifiable Issuers and Verifiers Specification:* This specification,
   primarily developed by David and Isaac (absent from the meeting), focuses
   on providing a mechanism to verify the legitimacy of issuers and verifiers
   of verifiable credentials. Key discussion points:
   - The current data model leans heavily on European trust frameworks
      (e.g., ETSI). Alignment with the verifiable credential
vocabulary and data
      model is needed.
      - There's a need for additional implementations of the specification
      to support broader adoption. Use cases in the US (education, first
      responders) were highlighted.
      - The group concluded that more work is required before handing the
      specification off to the VCWG.
   3.

   *VCs over Wireless Specification:* This specification covers
   transmitting verifiable credentials over NFC and Bluetooth. Key discussion
   points:
   - The need for another organization to collaborate on and adopt the
      specification.
      - Updating the specification to reflect changes in the render method
      specification.
      - The group debated whether to complete the Bluetooth section before
      handover to the VCWG or leave it for the working group. The use
of Web NFC
      and Web Bluetooth APIs was discussed, acknowledging limitations
with Apple
      devices. The group decided to keep Bluetooth for completeness,
      acknowledging its importance for offline use cases (e.g., first
responders).
   4.

   *AI and Verifiable Credentials:* A brief discussion on identifying and
   authenticating AI agents in verifiable credential systems occurred. The
   group acknowledged ongoing work in the data integrity call around
   pseudonymous attestation and proof of personhood, highlighting the
   complexities of addressing civil attacks in decentralized, pseudonymous
   systems. The difficulty of reliably differentiating between human and AI
   agents in a decentralized, scalable system was emphasized. A separate
   discussion on the delegation of authority within systems was also noted.

*Key Points:*

   - Several specifications are nearing completion and require finalization
   before handover to the VCWG.
   - Security and privacy considerations remain a recurring theme across
   all specifications.
   - Broader adoption and implementation are needed to ensure the success
   of these specifications.
   - The challenges of integrating AI agents into the verifiable credential
   ecosystem and maintaining privacy are significant and require further
   investigation.

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

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

Benjamin Young, Hiroyuki Sano, John's Notetaker, Kayode Ezike, Manu Sporny,
Parth Bhatt, Ted Thibodeau Jr, Tom Jones
*Transcript*

Manu Sporny: All right, let's go ahead and get started. I had invited David
and Isaac to discuss the verifiable issuers verifiers thing today, but I
don't see them on the call. but we can still kind of talk through it and
see if there's anything that we want to cover on it. so the agenda today is
largely verifiable issuers and verifiers and then the wireless we can also
cover the wireless specification if there's anything there that we want to
clean up before handing it off to the verifiable credential working group.
are there any other updates or changes to the agenda? Anything else we want
to discuss today?

Manu Sporny: Go ahead, Cody. Yes.

Kayode Ezike: Yeah, can you hear me? so I know we discussed a few weeks ago
that we wanted to want to finalize the functional operations that can occur
in a render method. So that before we were comfortable handing it off. I'm
not sure if that's something that we wanted to give back to. And
additionally, I made a bit of lesson to comment on the PR2 just because I
realized that he hasn't really added something there that might be
valuable, which is we discussed the web html templates,…

Kayode Ezike: but I didn't see that section in there just like that. So,
those are the two things that came to mind. method

Manu Sporny: Okay. yeah,…

Manu Sporny: in fact, let's put that at the front of the agenda because
we're trying to finish up the render method thing so we can hand it off. so
that sounds good. any other updates or changes to the agenda for today? All
right. if not, let's go ahead and jump into the render method stuff. let me
share my window here.

Manu Sporny: And I noticed I did not pull in that PR. I think you made a
comment on it. Coyote, I think you said you mentioned this.

Kayode Ezike: Yes, exactly.

Kayode Ezike: Towards the bottom. so basically just we have the SPG
mustache, we have the PDF mustache. you talked a lot about something HTML
or EGS. but I'm wondering if you wanted to include that in this PR2 or if
that would be a different PR, but it seems like a common thing that we've
discussed that we wanted to include. Yes, definitely. What you want to do
with that? I know there was a discussion about a web rendering method at
some point in the past. That seems to be what we would put there. And by
the way, if you're speaking, you're on mute, but

Manu Sporny: I think let's make this a separate issue. because there are
different security considerations around the HTML,…

Manu Sporny: EJS stuff. somewhat same for the SVGbased one. and maybe even
the PDF one. but yeah, I think what I'd like to try to do is just get the
base PR in and then we can build on top of that. So, Coyote, would you mind
just raising an issue on adding an HTML render suite?
00:05:00

Kayode Ezike: All right.

Kayode Ezike: And is that something you think you would do before passing
it off or pass it off and then take care of it.

Manu Sporny: That's an open question to the group. I think it would be fine
if we dealt with that in the working group. I think it'd be fine if we just
worked on it here.

Kayode Ezike: Okay, I'll create the issue in the meantime and…

Kayode Ezike: then yeah

Manu Sporny: All right,…

Manu Sporny: sounds good. And then it looks like I've got to apply some of
these changes for whatever reason. Did not get back around to this. thank
you Benjamin for the comments. And then I'll go ahead and make some of
these changes. But I think where we were last time is this was ready to be
pulled in as soon as those changes are made. I'll try to process all the
last time we went through render method, I think, yeah, we definitely got
through this. We did not talk about the functional operations thing. or we
kind of sort of talked about it,…

Manu Sporny: but not in any amount of depth.

Manu Sporny: Cody, maybe you could kick this off and we could talk about,
how do we provide some operations to go in these templates?

Kayode Ezike: Yeah. So this came up…

Kayode Ezike: because there was a time that I was playing around with SPG
rendering method when I was the thing and I had the desire to convert a
time stamp into a human readable format something like month day year
whatever you want it to be really and so the example is there actually on
the screen where this is technically valid JSON that's there but I think
that it's not valid if you try to put it inside of a mustache template
technically I have some issues with my test library so basically came to
the realization that it would be nice to have something like this
functional sort of operation ideally I think the best way would have been
if whatever template you're using already has that support for it

Kayode Ezike: then you can just use that and then you wouldn't have to do
anything different inside of the core data format of the rendering template
or method. But if not then I guess it's open how we would handle something
like that would it be like a new property where you have maybe an array of
djson not a type function that target certain fields in a credential or
something of the sort still kind of trying to think through what's the best
approach and if there are other operations that folks would be interested
in as

Kayode Ezike: But probably best not to, do a turn complete type of thing,
but more so just something where, these types scoped operations that,
people might want to try on common data types like, the ISO 81 or whatever,
really common one that you see throughout one that would be of interest.
But yeah, those are my general thoughts. I'm happy to hear mothers what we
think is the best solution. Yeah.

Manu Sporny: Yeah, I mean all good points. I think this is definitely a
need. I don't think we can, put these templated render method things
together without some way of providing text formatting functions. this use
case coyote the one you're pointing out right now is very specifically a
painoint for us in just about every credential that we need to nder. plus
one for functions being a necessary thing.

Manu Sporny: I thought mustache does allow for you to inject functions as a
part of the object that you send into the template renderer, meaning you
can actually attach functions. but maybe I'm misremembering that as far as
do we need to deal with this before we put it into the working group or
not. I think we do to just very clearly signal that this is something that
we need and was something in scope for the The working group can always
decide to kick it out of scope again but I think having an example.
00:10:00

Manu Sporny: So the spec needs at least one example and I think date
formatting is a good one where we would specify here's the function
signature and here is the algorithm that you follow for converting into a
human readable string.

Manu Sporny: I think at a minimum we just need one of those in the spec. go
ahead, Benjamin.

Benjamin Young: Yeah. …

Benjamin Young: mustache does provide views or ways to augment the view
with functions. they have to be ert. They can't look around. So you have to
pass in a value that you also have from the context of that moment in the
ars tree. and it's probably similar to what we're seeing here with the
danger with any and all of this is just the more powerful you make the
template language, the more dangerous it becomes. So, with mustache, we
would have to redefine them and inject them into the same JSON object that
goes into the rendering engine. but mustache itself does limit what those
things can do. They're lambdas that only work on the passed in values.

Benjamin Young: So, it's not like you could write a function that could
look around inside of the credential object and do more than what you would
see in the template, if that makes sense. Or it put differently, it is
incapable of modifying itself. It can't edit the content, which is the
biggest danger. with some more advanced templating languages like liquid
and things like that you can create new variables and change them and do
all kinds of stuff. handlebars would be the same way. So mustache
deliberately is essentially you can think of it as read

Manu Sporny: And I was trying to write down some of what both you and Cody
said. one function before spec is handed over to VCWG. I will yeah plus one
to everything you said, Benjamin. I think we will need to restrict this so
that for example we don't allow it to go out to the network and fetch
things. That's always the initial privacy violation that we're concerned
about with all of these templated things.

Manu Sporny: We're trying to make it so that the templates render based on
the information that they have right then and there that's passed into the
template and they don't go out to the network. They don't do advanced
processing that could potentially also as a side effect violate an
individual's privacy when the thing's rendered. I will note that Coyote you
mentioned Jason A. know that we use JSON as well in our more advanced
internal templates. but I think as Benjamin noted, I'm pretty sure mustache
allows you to pass in functions.

Manu Sporny: And if that's the case, I think we can continue to stick with
mustache for now. Benjamin, you've got your hand up.

Benjamin Young: Yeah,…

Benjamin Young: so the vast majority of template engines won't themselves
go to the network. you have to prepopulate the rendering scope with
whatever you've already collected. the bigger danger is…

Benjamin Young: what you can construct to the downstream CSS or HTML
renderer. That's where the network requests would happen. So you can use
the engines to create CSS that would include data in it or…

Manu Sporny: Okay. Yeah.

Benjamin Young: image URLs with query parameters that include data in it.
so that's where the danger is going to lie with any template language is
tucking it somewhere in a URL that is, meant to just load the logo of the
issuer, but you sneakily stick in some data there. that then goes off to
the server.

Manu Sporny: Yep. Agreed. yeah, we're trying to eliminate those side
effects.
00:15:00

Manu Sporny: We don't want any of this going out to the network and
reporting, back to the issuer when you're looking using your credential.
it's just a strict go zone, with all right. So, I think we need a PR for
this. we need a PR before we need a PR that demonstrates how template
functions work and define single template function and algorithm in the
specification for the presentation of a date

Manu Sporny: time in let's say datetime stamp in an individual's local and
this will of course trigger the internationalization folks to have an
opinion which is what we want. okay. I think This one's ready for PR. Do we
even have ready for of course. One second.

Manu Sporny: Ready for your All right. So, this one we need an example for.
I don't know if anyone wants to volunteer for taking this particular one.
If not, we'll go ahead, Cody.

Kayode Ezike: Yeah, first of all, thanks for the question. I maybe just
need to revisit this, but yeah, I can take a stab with the obvious copy
that I've tried it and…

Kayode Ezike: it didn't work. but if I might call on you behind the scenes,
that would be great. basically…

Benjamin Young: I missed the last part of that.

Manu Sporny: All right.

Kayode Ezike: if I could consult you at least for trying to see how we get
the bash version of something like this time stamp rendering great if you
don't mind.

Benjamin Young: Yeah, sure.

Manu Sporny: All So, there's one item then that we've got to pull in this
pull request and then there's one more PR and then we think VC render
method might be ready to go. okay. Anything else on render method?

Manu Sporny: I think we've gone through all the issue issues to just see
what we might want to do here. meaning I think we've deferred everything
for the working group to deal with except for this one item where we feel
that we want to address that item. anything else for render method before
we move on to the verifiable issuers and verifiers stuff? All right,
there's that all right. Verifiable issuers and verifiers. this
specification is largely developed by Isaac and David.

Manu Sporny: it came out of rebooting the web of trust get together in
Europe. there was a desire by a number of European folks that wanted to
ensure that their trust framework stuff the train stuff was supported by
verifiable credentials. The whole purpose of this specification is so that
when you get a verifiable credential you have some idea on you have the
ability to look up the issuer and the verifier and potentially chain up to
an authority that you trust which would then give you of an understanding
of who the particular issue and verifier is. this is very much kind of an
X509 view of the world.

Manu Sporny: which is fine it's one way of viewing things. dids and VCs
kind of tend to look at things in a little more decentralized way. But
sometimes you have, thousands of issuers in an ecosystem or let's just say
hundreds of issuers in an ecosystem. and you may want to have a trust
signal on whether or not those issuers are operating under a specific trust
framework of some kind. so there's quite a bit in this specification that
talks about lists of verifiable issuers and verifiers in how you trust
those lists and who's on those lists and how you put them together and that
sort of stuff.
00:20:00

Manu Sporny: there are use cases in here about who a verifiable issuer is
for the issuer of a diploma. there are use cases for verifiable verifiers
for example if law enforcement is demanding that you hand over a credential
you can check to make sure that there are in fact law enforcement that's
requesting it and not someone that's just dressed up as law enforcement.
specifically, this is most important online where you don't necessarily
have many signals that someone legitimate is asking for a set of
credentials. we've got requirements that are here. The data model and I
think that's where things kind of get a little debatable.

Manu Sporny: the data model currently is focused on train and Etsy and a
variety of European standards around trust lists and operators of trust
lists which is a perfectly legitimate use case that we want to support. So
I think it's a good thing. in Etsy and there are already a number of
properties that are defined on properties for list operator properties for
trust service provider so and ex expressing all of those things.

Manu Sporny: I think both Isaac and David have gone through and made sure
that all of these things exist in at least the specification. We need to
put them in a vocabulary. This example here is not a verifiable credential.
It's just kind of like what the data looks like today. So there would need
to be some alignment with the verifiable credential, vocabulary and data
model here. but it's just little stuff like lowercasing just some clean up
on the property names and then adding a JSON LD context to the top and
that's pretty much it.

Manu Sporny: and then you have this giant data object which as far as I
understand it has legal weight in the European Union. okay so there's that
part of it and then there's the other part of it which is we also created a
VC that has alignment sort of with the European thing but is a little more
structured like a verifiable credential. so there's stuff here that needs
to be align this thing up here and this thing down here are not aligned.
and on top of it, I think we've got new use cases.

Manu Sporny: so I think that the general concern here is that it feels like
more work needs to be put into this before we hand it over to the BCWG, but
at the same time, we really do want the VCWG to be working on this thing.
So I think right now we're kind of missing people that are fully committed
to taking this all the way through the standards process including doing
implementations of the specification. as far as I know it there's only one
implementation of the specification to date and we'd be looking for others
to implement it as well. education industry in the US might be one of the
most interested ones in doing this.

Manu Sporny: I know that we are also needing something like this for the
first responder community in the United States. in the US there are 22,000
first responder agencies. each of them that do issue physical credentials
to their first responders and they're all looking at going to verifiable
credentials for operational deployments and so they would need a way of
listing every single agency that issues verifiable credentials.
00:25:00

Manu Sporny: So, that's kind of I think probably the alignment that needs
to happen here. It's unfortunate that David and Isaac were not able to be
here today, but we'll pick this up with them in the following weeks when
they show up. are there any other on Any other thoughts about things we'd
want to do to specification before we hand it over to BCWG? All right.

Manu Sporny: If not, let's go ahead and move on to the C wireless
specification. so let's go ahead and close this down. okay, so VC's over
wireless. This is largely moving verifiable credentials over NFC and
Bluetooth. there I mean again this specification has existed since last
year. it still has not been adopted by the CCG. So we need another
organization to work on this specification with us.

Manu Sporny: we can go ahead and I don't think we ever sent out a call for
collaboration on the VCs over NFC and Bluetooth stuff. the spec does have
introduction use cases. it has this interaction offers bit that is also
detailed at a protocol level in the credential I specification. where you
basically communicate the list of protocols that your device can talk over
including being able to say I can talk over NFC or I can talk over VC API
or I can talk over OID4VP.

Manu Sporny: or some proprietary API. We allow multiple different
protocols. but this spec is specifically focused on NFC for tap to transmit
use cases where your payload is under 1 kilobyte in size and then Bluetooth
for anything where you need to transmit potentially megabytes of
information. there's also a definition of how you use NFC to bootstrap up
into the Bluetooth communication as well. we do have examples in the
specification about what a non-interactive NFC presentation can look like.

Manu Sporny: so this is for with a ticket number and then we use the NFC
based render method. We do need to update this. So, one of the things we
need to do is once the render method stuff is updated in the other spec, we
need to update the NFC render method here that's used to transmit. this
does have at least one implementation, two u with a writer and one with a
Different organizations working on that.

Manu Sporny: so maybe what we need to do is contact Credence who's working
on the NFC bits of this and ask them to sponsor this document as well. but
other than that, it's a fairly complete spec as far as NFC is concerned.
There is not a lot in here about what the Bluetooth interaction would look
like. so then the question is, and then of course security and privacy
considerations aren't filled out, but we'd expect the working group to add
those things.
00:30:00

Manu Sporny: So, I think the big question here is, do we want to fill out
the Bluetooth section before handing it over to the working group or do we
want the working group to just work on the Bluetooth stuff? I know the way
that we've implemented this today that NFC is done through the web NFC API.
We wanted this we wanted to make sure that you could use this purely
through a web browser today and you can with at least anything Chromiumbi
based, Google Chrome, Samsung, anything Chromiumbased can just transmit the
NFC over web- based wallet. the receiving end does need to be a native
application.

Manu Sporny: that is just the way the world works today. Unfortunately, the
host control part of this is not built into web browsers so you do need a
native app to read. but you can do a tag transmit read through a regular
website. so it works for web- based wallets as well as native wallets. the
Bluetooth stuff would probably follow the same thing. We would use web
Bluetooth. But the problem there of course is that Apple has not
implemented the problem with these wireless protocols is Apple has not
provided access to NFC on the platform nor Bluetooth in some cases.

Manu Sporny: so because this is W3C thing we would probably specify that
transmission happens over web NFC web Bluetooth or we would leave that
completely out normatively because we would probably need to I don't know
if we need to demonstrate different browser engines or not but
fundamentally that's a problem that's a browser and W3C and ecosystem
problem. it's not necessarily something we could deal with.

Manu Sporny: what we can do is just non-normatively that you can use web
NFC and web Bluetooth to move the data over and if you don't do that then
we can point to the lower level specifications on whatever protocols
low-level that web NFC and web Bluetooth end up using we can just site
those normatively if you have a native app you can use those protocols So,
that's where this spec is right now. it probably needs to be updated
slightly to the new render method stuff. it needs to be adopted in CCG. but
I don't see a super strong reason for us to have to sort the Bluetooth
stuff out.

Manu Sporny: It could be that BCWG just decides to drop Bluetooth for now.
or we could have multiple implementers come to import and implement the
Bluetooth u portions of it. Let me stop there. Any questions on anything
else we would want to happen with this specification before we moved it
over to the BCWG? All right. So, no other kind of strong feelings about
holding it back until we get something else in an ideal world, we would
have, more done on the Bluetooth stuff, but that is showing to be a little
used feature of these digital wallets. a lot of them are just going
straight to presuming there's a web-based connection.

Manu Sporny: it's of particular significance to the first responder use
cases because those must operate offline and that's where NFC and Bluetooth
have been of most interest and many of the deployments that we're seeing at
least in the first responder case if you can do it over NFC they want you
to do it over versus Bluetooth. and so, I don't think we have the only use
cases we can't solve using NFC are the ones that require you to transmit
anything over a kilobyte basically. really the ceiling seems to be around 2
kilobytes max.

Manu Sporny: and so if you have a profile photo of the first responder and
they're checking into a secured site, that's where you need the Bluetooth
functionality. so for completeness, I think we probably do want to keep
Bluetooth in there is what I'm trying to say. Any other comments on the C
wireless spec? anything else we need to do to it? Okay, with that said, I
think that's all of them. The other thing that we need to do, looks like we
have a poll request from Brian. I'll have to look through we'll have to
pull this one in.
00:35:00

Manu Sporny: I guess the other thing that we need to do is we have so many
new specs that are we're prepping to go over to the VCWG that I'm losing
track of it from week to week. So, I'm going to try and open a issue on the
CCG issue tracker to just list every single one of the CCG specs that we're
planning on moving over. I think there another at least five potentially up
to seven specifications that we're trying to move across. so I'll try to
get a full accounting of all of those in the next two weeks or so.

Manu Sporny: okay. I think we still need to have Leonard come in and
present on the PDF, stuff. I know that, Patrick St. Lewis also wanted to
come in and present on the overlay capture architecture stuff, but I think
those are the last two presentations that we have left on the work being
incubated. we'll need to process that that Coyote, you and Benjamin are
going to put together. but I think that's it. So, if we don't have
presentations next week or if there aren't pull requests to process next
week, we'll probably end up canceling the call. I think we're wrapping up
where we need to be.

Manu Sporny: I will also talk to Avon Herman and Pierre Antoine, our staff
contact as well as Brent Sundell to ensure that we need to put the new we
need to put text for the new charter together which includes all the items
that we are planning on moving over. so there's that. Tom, would you want
to u chat real quick about the AI topic or just, …

Manu Sporny: noted to the group what you're interested in getting feedback
on and things of that nature?

Tom Jones: So, the question I was talking to Joe about was whether or…

Tom Jones: how we could identify an AI or what it would take to identify an
AI so that an AI could actually participate in an interchange. And one of
the suggestions that he made is there might be a method that would be AI
friendly or we could generate a method that were AI friendly. We hadn't
gotten very far. I just wondered if anybody else wanted to had two cents
that they wanted to contribute.

Manu Sporny: Probably more than a couple of cents. Tom, just so you're
aware, there is work going on in the data integrity call around pseudonmous
at astation. It's really the personhood credentials. I don't know if you've
seen the work that some of us did with open AI on the paper or on proof of
personhood or personhood credentials. That's being able to pseudonmously
know whether or not the entity you're engaging with online is a human or an
AI or at least has a credential that identifies whether they're human or AI
or whether or not the AI is an AI and they're operating on behalf of
someone. and then whether or not that person is known can also be kind of a
pseudonym based thing.

Manu Sporny: So there's a lot of work that some of us are doing around
privacy preserving ways to tell whether or not the party you're interacting
with is an AI or not. So there's cryptographic work happening in the data
integrity call around pseudonyms and reducing civil attacks in systems
using verifiable credentials and things of that nature. some of us are also
briefing US federal government on AI safety and pseudonyms. if you're not
familiar with Steven Adler's done some really great work in that area, Tom.
So I'm happy to introduce you to Stephen or at least the papers he's been
writing. He's still very active in the area. He used to be at OpenAI and
their AI safety group.
00:40:00

Manu Sporny: he's since left and is doing great work elsewhere. and then I
think that there's also Kim Duffy from FF decentralized identity foundation
is active in kind of the proof of personhood stuff. I think there's some
proof of personhood work happening at DIFF. and I know that the community
group in general is interested in standardizing credentials around AIS and
proof of personhood privacy preserving ways of doing this.

Manu Sporny: but there's a big problem that we don't know how to solve yet
and if there are multiple entities that are issuing proof of personhood
credentials. The problem isn't like identifying an AI and an AI identifying
itself as working on behalf of an entity whatnot. that we feel is like a
fairly solved problem except for we don't have the credential for it yet.
the real problem is how do you prove that you're a human being without
strongly identifying yourself where you live, what country you're a citizen
of, and so on and so forth.

Manu Sporny: the problem is that if there are multiple issuers of proof of
personhood credentials and they're pseudonmous how do you guard any system
against a massive civil attack where one of the issuers decides to go rogue
and starts issuing all kinds of proof of personhood credentials to AIS
because the systems designed to operate in the pseudonymous

Manu Sporny: capacity. you can't know anymore, it's the big problem is we
think these systems we don't have a solution yet other than massive
centralization which we don't want that would prevent civil attacks in a
pseudonmous proof personhood system. hopefully those kind of thoughts
helped a bit. Tom, it is of general interest on how to do this. we are
talking about it, but I don't think that there's any specific work item yet
on one of these things.

Tom Jones: Yeah. …

Manu Sporny: We certainly don't.

Tom Jones: I looked at all of that proof of personhood and decided as you
point out, helpful. it's sort of the problem is that the whole concept of
not knowing whether something is an independent agent on its own when you
look at the identifier gets you into a world of hurt. And my suggestion was
that the identifier itself should state whether or not it's has agency.

Tom Jones: But that goes against all of the other stuff that everybody else
is doing. But unfortunately, if you don't know fairly early in the cycle
whether to expect agency on the part of the identifier, I'm not sure how
you process anything.

Tom Jones: You kind of run into all these problems you talked about.

Manu Sporny: Yeah. Yeah.

Tom Jones: It can't be something you Trying to defer it just does what you
just talked about.

Manu Sporny: potential. I mean so we do have these decentralized
identifiers and it has been discussed that maybe we have decentralized
identifiers that are specific to AI agents and ones that are not but again
the problem is how do you know that the nonAI identifiers are actually
being used by a human…
00:45:00

Manu Sporny: because humans for economic reasons can sell their, agency
effectively and how do you detect that? that's one of the challenges of,
putting it into the identifier.

Tom Jones: It's not just humans,…

Manu Sporny: Yep.

Tom Jones: but how many people here would trust the island of Malta to say
whether or not that it was a trustable human being? It's even worse than it
could be a perfectly valid credential and…

Tom Jones: still be false.

Manu Sporny: Yep, that's right. Yeah. Yeah. And so I think that the
scalability of AI is one of the things that's new here is that all of a
sudden you have the ability to scale to millions of people or synthetics
looking like millions of people and then how do you tell the difference? I
think that's one of the reasons that we haven't started work on anything
specifically because we don't know how to solve the problem right there's a
fundamental I mean we do know how to solve the problem I mean you create
one centralized system that can do pseudonyms but ensures that the
pseudonyms are not overused it is potentially possible to do that at scale

Manu Sporny:

Manu Sporny: still in a privacy preserving way, but you need to centralize
in that particular solution, which nobody seems to want to do, so there are
some more heavy-handed solutions, meaning you identify yourself completely
show your driver's license or national ID. Nobody likes that, of course. or
you do something where you centralize at least the pseudonym mechanism so
that you can tamp down syibles where people can only use their proof of
personhood at a rate of so much a day or a week. that has its own issues.

Manu Sporny: And then the solution we're really trying to look for is
something that is truly decentralized but protects against cybles and there
may be some fundamental information theory thing that prevents that from
happening which is kind of where we think we are right now. that the more
you decentralize the harder it is to fight against civils. and so we may
need to end up creating, a privacy preserving system that combats civil…

Manu Sporny: but is very controlled and open about the way it operates and
is, operated as a public good or something of that nature. it's not,…

Tom Jones: George Fletcher and…

Manu Sporny: …

Tom Jones: I started independently of each other working on delegation of
authority and I posted a link to one document that I'm working on.

Tom Jones: So if anybody's interested in you could let me know. And this is
where we're running into the problem about trying to figure out agency
which is a little bit different than what you talked about Manuel. I mean
we're saying does this identifier have agency to make a decision at all. so
I'm not interested in proof of personhood. I don't find it useful.

Manu Sporny: Mhm.

Tom Jones: If anybody is interested, you can let me know.

Manu Sporny: Yeah. Yeah.

Manu Sporny: This is interesting. And you're right. I mean, this is the
thing you're talking about here is a different class of problem that is a
little easier to potentially come to a actual solution on.

Tom Jones: Yep. …

Manu Sporny: Mhm.

Tom Jones: that's the approach we're looking at right now. try to solve it…

Manu Sporny: Mhm.

Tom Jones: because our assertion is that all of this stuff that's being
generated right now only applies to 20% of the human beings on the planet
and we're get 80% of the human beings on the planet. We're trying to get
deal with the other 20% that can't deal with the technology.

Manu Sporny: Yep. Okay. Good stuff. you may try posting this to the
credentials community group. I know that there are other people on there
that would care about this stuff.

Tom Jones: Yeah, I quit going to that a long time ago.

Manu Sporny: Okay. Okay.

Tom Jones: Little noisy for me.

Manu Sporny: No problem. Okay. Thanks, Tom. this will show up in the
minutes and…

Manu Sporny: everyone in that community will see it, too. So, Yep.

Tom Jones: Okay, thanks.
00:50:00

Manu Sporny: I think that's it for the call today. I'll send out an invite
for next week if we've got stuff to talk about and if not we'll cancel the
meeting. There's still a couple of things we need to clear up. okay, that's
it for the call today. Thanks everyone. have a good day. Take care. Bye.
Meeting ended after 00:50:26 👋

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