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

Hi Manu

apologies from both Isaac and myself for missing yesterday's meeting. We 
realise that the example VC in the draft is incorrect and needs fixing, 
and we are proposing to have a meeting sometime during the next week to 
fix this. We do hope to attend your next meeting

Kind regards

David


On 14/05/2025 23:03, meetings@w3c-ccg.org wrote:
>
>
>     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./
>