Manu Sporny: Uh yeah just a quick 1 um we announced this on the mailing list but we have a new specification out uh which is VC's over uh over Wireless. ✪

Manu Sporny: And I'll put the link. ✪

Manu Sporny: Uh in the chat Channel there um basically uh in just a a share real quick um basically what this specification does is it allows the transmission of verifiable credentials uh over uh Wireless protocols like uh Bluetooth um or NFC uh it's pretty fast uh there's a quick demo that we put to the mailing list and this is just using 2 phones using a verifiable credential where you literally just tap the phones together for half a second and you get a VC transferred across um we'll be adding uh support for this uh over the next couple of uh weeks to the VC playground uh so that other people in the community can play around with the technology. ✪

Manu Sporny: That's it from us. ✪

Manu Sporny: Uh yeah I mean the probably the easiest thing that we might do is just um sort them by activity in cut them off um you know based on like if there hasn't been any activity in the last 3 months they just don't show up on the list of active things the group is working on um and activity could be anything from like new comments uh and you know on issues um you know PRS that sort of thing I think that would cut that list down uh pretty significantly and would help us get kind of a better view on what's active and what's not just a suggestion though. ✪

Manu Sporny: I mean I can speak to the credential refresh stuff that's not done um I think there there are a number of these that go into hibernation for like 3 to 6 months at a time while the people working on them work on something else higher priority um and you know I there there are situations where that you know there there's a there's a question on like should we archive some of these repos and that's a much longer discussion right because we've got like a hundred you know a hundred of them that that we're gonna have to have discussions with the people that that opened them um. ✪

Manu Sporny: Depends on you know depends on how much cleanup you want to do we we might get quite far by just um. ✪

Manu Sporny: Focusing on you know things that have been updated in the last 6 months and those are. ✪

Manu Sporny: Better or Worse the things that the the community is you know focusing on um. ✪

Wayne Chang: Harrison thanks so much for the invitation here and for giving some space to talk about this important topic it's awesome to see so many bases old and new uh or at least profile avatars and um it's great to be back here uh I'm here to talk about proof will be forgot signatures I will start sharing my screen so that you can see I just have to. ✪

Wayne Chang: Move this to present mode. ✪

Wayne Chang: Will be sharing this. ✪

Wayne Chang: Window sorry I'm just looking for. ✪

Wayne Chang: Okay great so can you confirm that you can see my screen. ✪

Wayne Chang: Very good so I'm here to talk about a topic called privileged forgot signatures it's a way that we can add privacy to many of the digital credential and identity systems coming out uh a little bit about me my name is Wayne Chang as Harrison mentioned um I was a former ccg co-chair a really amazing group I got pulled away by some work responsibilities unfortunately so it's been hard for me to make this uh time slot but you know really appreciate being here my background is an engineering and product management I'm the founder and CEO of screw ID and I'm an advocate for utility security privacy and interoperability um at the company that's how we make a lot of our decisions is this going to be useful for people just the most important question can we do it safely and securely and privately and is going to work with other Solutions out there uh to prevent lock in so that you can let the market do its thing in a constructive way and we've been working with public sector customers and also institutions uh for a while so you tend to adopt a lot of the challenges that your customers have when you're solving problem. ✪

Wayne Chang: Problems for them. ✪

Wayne Chang: This is where we thought a lot of. ✪

Wayne Chang: Privacy in the context of State identity and other things. ✪

Wayne Chang: So the main problem that um you know you've probably heard of or thought about is um this idea of linkability that as you use these digital credentials in the wild to prove things like age or you know residency or anything you can think of right maybe there are these unique identifiers that are flying around and there could be some surveillance Potential from those right just unintended consequences of moving to digital systems right um if you are to use a physical license or something right and show it around sometimes the bartender will glance at it and just kind of move on uh maybe the hotel staff will look at it and uh you know move on sometimes they creepily make a photo copy but that's a different uh you know topic um but when we move to digital systems that have all these unique identifiers everything from literal unique identifiers to digital signatures that are for all intents and purposes you need. ✪

Wayne Chang: To create some tracking potential right and we're going to talk about how these uh arise in different production systems and some ways that people have thought about mitigating them and also presenting an approach that can work in some pretty I call it um lockdown constraints. ✪

Wayne Chang: That's the problem we're trying to solve linkability being able to use these identifiers to track someone inadvertently um or by you know a bad actor. ✪

Wayne Chang: And uh eliminating surveillance potential. ✪

Wayne Chang: So why does this matter why do we have to think about it this way there's a lot of digital systems booting up but I'm sure you've seen the news of different states enabling the mobile driver's license in the US uh the EU architectural reference framework is talking about uh European commission member states uh having programs live in production by 2026 right um looking at research by nist that will standardize for the industry how do you send these things over the Internet um and just there are a lot of prolific digital identity systems out there today such as that hard for example so um really in the past like 1 to 2 years the momentum has increased for this kind of stuff uh and adoption is increasing as a result too um so uh more specifically uh a lot of advocates for privacy and user Freedom have talked a lot about the potential of um you know how can we produce the maximum privacy right there are discus. ✪

Wayne Chang: Discussions with cryptograph. ✪

Wayne Chang: ERS and privacy Advocates and. ✪

Wayne Chang: A whole bunch of. ✪

Wayne Chang: Um you know what additional privacy protections can we build into the protocol because um it's much more convenient to be able to um just know that it works at the protocol level and the stuff is impossible to link back versus uh kind of moving to a model where you're trusting a bunch of intermediaries to uh you know uh Delete the stuff properly or everything else right so. ✪

Wayne Chang: Going to go over some of the problems and solutions that have been proposed. ✪

Wayne Chang: But 1 of the problems is called verifier verifier collusion if you read some of the feedback to the Department of Homeland Security's request for comment for the mdl um there have been some responses calling out verifier verifier Collision explicitly and the problem is like this where you're trying to share your information with a bank might be a different set of information than what you would share to a Content website that's hated um whether or not those are good ideas to have as policy in the first place totally separate topic right but it is true that there are some laws that do require it now for certain content and for banking regulations. ✪

Wayne Chang: Knowing that we exist in that set of requirements um the bank might need to know your full name and your exact date of birth the content website might only need to know if you're over a certain age right so those are different sets of data. ✪

Wayne Chang: And 1 common gotcha when implementing these systems is recycling these unique values such as digital signatures when you're showing things to the bank and content websites right so this uh in this world the content website might be able or content websites plural right might be able to retain the signature because you've gone and disclosed it as part of the verification process and the bank might get the same signature even though you shared different data sets with each party it may be possible for the bank to I don't know purchase the data from the content websites or there could be a coercive Force many issuers tend to have a power imbalance when it comes to the verifiers and they might have some coercion power right so there are many ways for this to create surveillance potential meaning that 1 day it might be used to tie together activity to an individual right and um basically uh that can create a bunch of unintended social consequences not only violations of privacy but the you know knock-on effects of. ✪

Wayne Chang: That can the. ✪

Wayne Chang: Make a different credit. ✪

Wayne Chang: You know basically. ✪

Wayne Chang: Right these are some uh pretty uh profound social implications for it and um we think that potentially the responsible thing to do here is just make the interactions how they were as much as possible in the physical world so that V that expectations are not violated right so um some ways that people have approached to solving this is to just make more signatures and different unique values that are basically 1-time use it's less efficient um because you have to make a whole bunch of these things and then you have to remember to discard the signatures after you use them in the wallet or accept some kind of probabilistic risk but it is a way to get rid of this specific kind of collusion uh I believe this is how some mdl wallets are implementing it uh today in production uh where you have a different signature cycle per use. ✪

Wayne Chang: So another um trickier form of collusion which is a lot of the topics that people talk about is this issue or verify or collusion so let's say we use different signatures from um you know different uh relying parties or verifiers right so we we're trying to get rid of verify or verify our collusion with that and let's say we've successfully done so um well there's another thing to consider here. ✪

Wayne Chang: If you are sharing the signatures at all right and the issuer is to retain the signatures uh then basically uh the issuer could still 1 day you know surface those signatures even if you just shared over 18 right if the issuer keeps good records of uh what signatures they issued for what individuals in their system right this might be a state Authority or it might be an Enterprise or something um then 1 day the issuer could potentially match these up right so this is also um why like you know posting signatures in the public comes with certain uh expectations right because if signature is to retain the signature sorry if the issuer is to retain the signatures and you create sort of these uh unique values and you put them in places 1 day if the issuer is to learn about those signatures or someone is able to combine the data sets then they might have a really good record of you know the usage going on right so that's. ✪

Wayne Chang: The issue. ✪

Wayne Chang: Or verify collusion. ✪

Wayne Chang: Can't just make more signatures of the same kind for this 1 to solve it um you need to consider other options. ✪

Wayne Chang: We're going to review some options that people have proposed which are valid options um. ✪

Wayne Chang: 1 Is using zero knowledge proofs which I'm sure that you've heard a bunch about especially the BBS Signature suites there have also been a non-red you prove ZK snarks and ZK snarks all of them have different properties but they roughly want to do the same thing they want to just demonstrate the minimal level of disclosure possible uh to prove the checkpoint and you're on your way right so that is from the right issuer without even disclosing a signature that you're over 18 without disclosing and a date of birth right um so these I think are probably the solution of the future and where we should look towards but there are some areas that we have to consider uh when you're trying to implement systems for um States institutions and highly regulated entities right that these things are challenging to implement and get certified. ✪

Wayne Chang: 1 Of the. ✪

Wayne Chang: A big areas of challenge are compliance with the federal information processing standards um so none of these uh to my knowledge uh the elliptic zero knowledge proof based uh Technologies including BBS uh are not considered uh you know nist recommended and what happens with the nist recommended curves is that they eventually make their way into Hardware security modules which meet certain standards of physical and controls based security to have a cryptographic module in the system it makes a lot of sense from the security perspective because if you're issuing state level identity right you want to meet certain qualifications for the hardware that's doing the key management right so that's just generally a good idea to have that level of security but uh we see that the BLS curve for example is not Nest recommended um and a lot of the other curves um. ✪

Wayne Chang: Uh and. ✪

Wayne Chang: We think that a lot of. ✪

Wayne Chang: IC based cryptography um used for the current zero knowledge work will not become a standards track uh Technologies anytime soon or potentially at all because a lot of the air has been sucked out of the room to focus on post-quantum resistant cryptography right in the elliptic curves uh have not demonstrated be practical in that use case. ✪

Wayne Chang: So I think that there are some zero knowledge systems that are based on hashes uh that can be post-quantum resistant but I'd say that they're pretty experimental at this point and uh there is a growing industry shift away from many of the items mentioned above for example I believe that uh a non-red and you proof are both based on RSA and because of how easily quantum computers can Factor uh large primes uh there's been a shift away from RSA signatures in general which those things are based on right and then if we're also seeing less popularity for elliptic curves as the new nist recommended post-quantum cryptography gets into production systems their official recommendations at this point I believe um then you know we're going to we're going to see a a desert of the ZK things that we can use that will have strong Hardware support for and therefore meet requirements for high Assurance systems so we think that like eventually we need to go down the zero knowledge. ✪

Wayne Chang: Proof in circuits route. ✪

Wayne Chang: Said earlier you know there's already States deploying these things right and that have to meet the requirements today so are their approaches that we can also consider to solve this problem and that's the topic of properly forgotten signatures. ✪

Wayne Chang: So the idea is that can we just make sure that the issuer forgets the signature and that is does not retain and have evidence that they don't retain it this would be using a trusted execution environment uh a lot of considerations when deploying a trusted execution environment we'll get to those considerations in a bit but um if the issuer doesn't know about the signature or the other unique values then even if they're given you know a stack of these things hey I clicked these digital signatures can you help me match who it was the issue or should be able to say you know no I can't because I just don't have that recorded right so um we think that this could be a pragmatic approach to solving the issue or verifier Collision problem today. ✪

Wayne Chang: Um this is how it would work uh this is an imperfect diagram but hopefully a helpful visual um uh describer with some rules um but the te The Trusted execution environment is actually on the issuer side um sorry it's not totally clear from this diagram but we have the issuer the holder and then also The Trusted execution environment and it's pretty simple idea that at the last step of issuing additional credential. ✪

Wayne Chang: Verifiable credential protected by the many forms whether it's an envelope protection or um an embedded data proof right so those could be all be supported could support the MDOC from ISO anything where we have signing and this problem you know we could find a tractable solution using this approach and again these are production systems today so we have to look at what's there. ✪

Wayne Chang: But the general approach uh is that as you do the final stages of issuing the digital signature the unique values that we don't want the issuer to be able to record or see right um are basically computed exclusively in The Trusted execution environment. ✪

Wayne Chang: For people not familiar with the te it's kind of like a separate computer that is meant to hold things confidential it's also called confidential Computing uh for that reason uh things are encrypted as they are being processed inside their um many teas will have their own set of public private keys that you can encrypt things to and only the tea should be able to decrypt it. ✪

Wayne Chang: All that stuff goes into the te and the computation happens there. ✪

Wayne Chang: A nice property of teas is that it can give you an attestation of computation the fact that hey this computation did happen inside the te and uh you can verify it. ✪

Wayne Chang: So basically this is the general approach um and then when you complete the signature and other artifacts you need for issuance you would re encrypt that whole payload to the user's key. ✪

Wayne Chang: So that it would only be encrypted inputs to the te going in and then you would get encrypted outputs to the user's device coming out and then the issuer would be none the wiser and the holder would have uh a proof of computation happening in the te so the trust model uh shifts from just the issuer to they trust the issuer and they also trust them Hardware manufacturer of the te um that it has not been tampered with and we'll go into some considerations around where that assumption might not hold but um that's the general idea again we're looking for something that can uh help us uh with existing systems today without uh necessarily changing any of the cryptography but could be Quant post-quantum compatible going forward and uh requires a small upgrade in 1 of the components to add on linkability as opposed to again trying to rethink it wholesale which is difficult not from the technology side necessarily. ✪

Wayne Chang: But from the policy. ✪

Wayne Chang: When people have a sunk cost in the multi-million dollar project and you're asking them to be work entirely you know that's another battle to fight. ✪

Wayne Chang: If you really. ✪

Wayne Chang: Care about this. ✪

Wayne Chang: So the benefits are that um you protect against collusion because you're able to segregate those cryptographic operations and we can prevent uh issue or verify or collusion that way uh specifically we would still potentially issue many signatures to protect against verify or verify our collusion. ✪

Wayne Chang: Privacy and security are added and we could potentially do this within the context of being compliant to fips 140-2 or -3 which is which basically are the hardware um standards for cryptographic modules by the federal information processing standards. ✪

Wayne Chang: That are required for many issuers trying to work on state Identity or other things. ✪

Wayne Chang: Our considerations of course every you know engineering decision has trade-offs right so basically um. ✪

Wayne Chang: Have been known to fail that's the top 1 that we really have to consider and think carefully about and and many of the failure modes it's when the interfaces are connected to some alien systems or it's when someone's side loads an application to attack the te from like the mobile device many Android devices uh the modern ones have trust Zone from the AMD processor and I think a lot of the security assumptions for that te um were not made to protect against attacks from the same device right like a app loaded on the side or something so there are a lot of weaknesses when you plug a tease into these arbitrary systems so as an issuer you might have an option to not do that right and you might have the option to have a defense and death strategy around the te and it becomes more of a matter of having third-party audits to make sure that the architecture is set up correctly how it was designed and the controls have not been tampered with so a lot of it would be adding in the Privacy properties using tees. ✪

Wayne Chang: And also. ✪

Wayne Chang: Mechanisms in place too so it would have to be as part of defense and death strategy teas alone are not enough. ✪

Wayne Chang: Um it's also a shift in trust model as I mentioned uh instead of just trusting the issuer to get everything right now for the critical part of it you can also uh add the trust for a te manufacturer right and again this can be subject to third-party audits. ✪

Wayne Chang: And uh 2 more considerations sometimes guidelines from for implementers and laws requires certain retention periods fraud investigations Etc right so there could be uh basically privacy preserving ways to meet these guarantees or people can decide to change the requirement for those if they value privacy more right so um these can uh be implemented also using uh secure Computing or confidential Computing to uh make sure that the retention periods hold uh after let's say 30 days if that's the requirement things can be erased right. ✪

Wayne Chang: Uh and then finally um 1 more consideration is um now the issuer doesn't know the signatures that they made right how bad could that be um 1 of the only downsides we've identified so far you know subject to more research but is it's harder to tell if your key was leaked and there are a bunch of erroneous or fraudulent signatures being created by someone else right when you had the signatures you could detect that if it was from your issuer list but when you don't have the signature could be more difficult um there are once again other methods to detect this without requiring full knowledge of the signatures uh such as cryptographic accumulators or even leveraging the te again for a similar task of the retention period we just need to really know the requirement for that and be able to engineer. ✪

Wayne Chang: Just that amount to basically find the balance between you know accountability and auditability and also privacy for then user. ✪

Wayne Chang: So this is not incompatible with zero knowledge proof Solutions it's also not compatible with. ✪

Wayne Chang: Both can be you know implemented simultaneously there are many approaches that want to use a zero knowledge proof from the wallet to demonstrate to a verifier that indeed you know I have a signature from the right issuing authority and here's the attestation that would solve the problem too but in this sort of evolving landscape you know I think that picking many different defense and death strategies uh might be the best way to achieve high security this methodology that I proposed only requires the issuer to opt out right when you're looking at zero knowledge proofs made from the wallet user proves uh that they have an artifact from the issuer you need holder and verifier Buy in to implement both of those parts and that's totally valid solution right what I'm saying is that you can have this production from the issuer side and you can have another protection that requires holder and verifier opt-in so uh I think that that's why we have to evaluate a plethora of solutions that can interlock and be compatible with each other all adding another layer. ✪

Wayne Chang: Of privacy guarantee. ✪

Wayne Chang: Um and this 1 Special is meant to upgrade existing systems or work with an existing constraint environments uh under regulation right and um leaving the door open to shift to zero knowledge base systems as they become available off the shelf. ✪

Wayne Chang: And also um if we want this enshrined in the policy to not create linkability right for digital identity systems it is a bit incumbent on the industry to demonstrate its possible in the first place right so this is a pragmatic way to achieve that requirement uh much legislation gets thrown out because it's considered not implementable. ✪

Wayne Chang: So I think eventually this could be standardized um don't know where it would go but 1 of the goals was to be compatible with a variety of data formats credential issuance and presentation approaches including a lot of the great work here at w3c but also other areas where they may evolve. ✪

Wayne Chang: And that's um the call to action is uh formalizing this work into a more rigid set of requirements algorithms that can have correctness or you know um flaws discovered right because uh an idea is great but when you really get it into a set of analyzable equations or just algorithms that can be evaluated that's when we start to get to real security and getting towards prototypes of this that can run in teas of today um also evaluating the support for post-quantum cryptography this could also result in policy language that could ask for this kind of thing right so policy language could support policy that is like legislative uh policy for democratically run governments um or agency rulemaking creating the requirement for a linkability and how we can satisfy those with something like this or is there a knowledge proofs. ✪

Wayne Chang: Formalize this more. ✪

Wayne Chang: Uh potentially you know incorporated into some implementations. ✪

Wayne Chang: Um and. ✪

Wayne Chang: Thank you for your time and listening to this I can open it up to any questions or feedback connect on LinkedIn or send me an email. ✪

Dmitri Zagidulin: Explain that as always this is really cool and informative I have. ✪

Dmitri Zagidulin: A quick question about. ✪

Dmitri Zagidulin: You don't mind going back to the verification part um uh how does the so in the issuing The Trusted execution environment uh is involved on the issuer side and how does the verification work again. ✪

Wayne Chang: It works just as before so you just present you do all the regular steps and um the only difference is if the verifier was to retain the signature and present it back to the issuer saying who's this this year would say I have no idea who you're talking about. ✪

Dmitri Zagidulin: Got it got it. ✪

Manu Sporny: Um yeah a great presentation Wayne thank you um I think you know utilizing these trusted execution environments is um as you said like a really good layered approach that um. ✪

Manu Sporny: Is a is another layer to the security onion um I'm wondering you know so you're saying there's a the shift in trust that happens and I I think I understand what you're saying you're like the the issuer needs to trust that these tees are doing what it expects them to do are you expecting there to be like I don't know formally audited um te run times um that are used so so for for the for those that might not be aware you know a lot of these teas have ways of like digitally signing and verifying the executables that run in the teas so that when the issue or runs 1 of these things they can be assured that they know what programs running in there and they trust its execution to do you know something uh uh specific um and that trust can also go to like the holder or other verifiers where anyone can check to make sure that the issuer is using like a known te that does. ✪

Manu Sporny: Known things. ✪

Manu Sporny: In a certain order. ✪

Manu Sporny: So Wayne are you the the the 1 thing so 2 questions the first 1 is are you expecting there to be like a a vetting process and digital signatures to these programs that run in the te so that everyone can kind of know that the right programs running um and then the second thing is you said that there is communication uh between the holder and the um te but the issuer also has to provide some data like for example in a driver's license the issue is definitely going to I think going to uh provide all the driver's license uh data in there um can you elaborate more on like like I I get it where like a holder key is sent to the te but were you thinking other things like you're you're saying like the issuer doesn't have any idea about this thing that's being issued um. ✪

Manu Sporny: Does that mean. ✪

Manu Sporny: Any of the information that it hands over or does it mean like no just the like the private key that the the uh the holder might use for doing like holder binding um that's it. ✪

Wayne Chang: Yeah great questions uh so to your first question um attestations for computation right so how do we know that the te is running the right code um we think that this is the part that could be made open source um where you have the code running in the te that people can evaluate and uh basically many teas this would have to be a requirement When selecting a te can produce these attestations um sign off by the you know Hardware down key inside the te the fact that this particular program ran um with you know this kind of inputs and produce this right and that happens all within the the secure protected part of the um of the Machinery uh producing like a certification that it happened there. ✪

Wayne Chang: And the. ✪

Wayne Chang: Ability for people to evaluate that open source code repository or maybe it's an audited by a third party or something like that a lot of the times they'll even accept like a Docker container or something I think some of the t's support that right so it would be a certain image identifier um that was running here and we got these inputs reduced the output the wallet would be able to evaluate uh that attestation to know that it came from the te um manufacturer uh for example AMD and how it changes the trust model is that instead of just trusting the issuer uh you can trust you would in order for someone to include it against you you would either need like AMD for example or whatever manufacturer to collude with the issuer to uh basically create a flawed system right and then um. ✪

Wayne Chang: Would have to. ✪

Wayne Chang: Protections of the te so it just again adds more um guarantees and securities and the onion model as Manu mentioned so that's the first question man does that answer your first question I can move on to the next 1. ✪

Wayne Chang: Great so the second 1 um the issuer already knows a whole bunch of stuff about you right so your full name your driver's license all these things are already personally identifiable information and if you're sharing those things then this approach can't help you right so then we need to rely on data policy like gdpr or CCPA in California and other similar ones that are emerging around the world to really limit the sharing information I think that's definitely a huge problem to do consent management at scale and a machine readable manner I think that's a very exciting problem space to solve and get right um but this approach doesn't help with that um here we are optimized for if you're proving that you're over 18 I mean there are ton of people over 18 how do we make sure that doesn't create a correlated event. ✪

Wayne Chang: So that's more of the problem if we're sharing pii in the semantic layer as part of the interaction then yeah this approach is limited in that. ✪

Wayne Chang: Yeah yeah it's kind of like how many people need to plot against you right to get 1 over you and in many models you have to have a lot of trust in the issuer if you want to prevent this issue or verify or collusion but in this model we've shifted to well not only does the issuer need to be nefarious but also the hardware manufacturer either needs to be nefarious or destroyed by the protections or destroyed by the issuer. ✪

Wayne Chang: Um so the um the issuer doesn't even know the signature coming out um so and you're correct that the all the user unique values from their device including um maybe a device key would be encrypted uh to the te uh many teas have functionality where there's a key that only they can access right it's because it's protected in the same Enclave for environment. ✪

Wayne Chang: Would encrypt to that key so that the te would be the only 1 who can unpack that value operating in the secure context. ✪

Wayne Chang: Yep and what the um all the issuer would see is um well they they would probably do some brokering of a connectivity to the device but they would just see an encrypted payload in an encrypted payload out I would say an analogy is kind of like trying to monitor a network uh over TCP when they're like TLS connections happening you see that there was a connection some data payload sent and that's it. ✪

Manu Sporny: Yeah I mean this is a this is all like super fascinating uh topic uh Wayne so so you're you're saying you know for the use cases where we really want on linkability um like you know over 18 uh is a member of this Bank um is a member of this club things like that that the the individual and wallet you know would would go to an issuer and start some kind of issuance process and it's some point the issuer goes like hey I've got a pretty you know I've got strong I know who this individual is like I've I've set up a secure Channel with them and like they are who I think they are um but for this next step I want you the te to generate a membership credential for them or generate an over 18 credeur and I'm going to be completely out of the. ✪

Manu Sporny: Loop there right. ✪

Manu Sporny: I want you to. ✪

Manu Sporny: Generate a note. ✪

Manu Sporny: Credential for them I'm going to hook you up to them and they're going to provide you a known set of inputs that I as the issuer am okay with them sending you um and then you do your thing te get them the credential and I the issue are none none the wiser so if that credential ever comes back to me I'm gonna basically be like yeah I issued that but I have no idea which 1 of my members it goes to all I do know is that I did a process before issuing it that guaranteed that it went to a legitimate party is is that a fair summary of what you're suggesting. ✪

Wayne Chang: Yep that's fair so you're asking the te to finish issuing this credential and the te says to you issuer you know I need these things from you okay I'm gonna expect these other things from the user but you're not going to hear about it and I think 1 of the nice considerations of this model is that um you know in some future iteration the te host doesn't even need to be the same entity as the issuer right so if there's a common entity that you both trust or something that's running a strong root program to for public key infrastructure then you might designate them as uh you know managing the cryptographic attestation of issuer data. ✪

Wayne Chang: Yep great question um so the the issuer would still disclose its public key or its root key um the public part of it of course um and that would be included in you know a trust framework so that if a signature is created by this uh the private part of that key then we know it's from the issuer right so um that part is still shared with the verifiers and you could use something like did web or otherwise to establish that but the point is that the actual signatures as part of the credentials are not retained so the issuer is none the wiser. ✪

Wayne Chang: The issuer could see a signature and it could verify that oh it looks like my private he did create this right but it wouldn't have prior knowledge of that signature is the idea. ✪

Manu Sporny: Um what standards do you feel like this group or what what standards do you feel like need to be put in place Swain for this thing to like um for us to make progress on this. ✪

Wayne Chang: Yeah so I was doing the research in the different ecosystems like what's the closest thing to this and I think the closest thing to this is actually the Acme protocol which is used by let's encrypt a provision x509 certificates for the let's encrypt program but it it might generally just be a way where you check things and issue stuff in terms of like this this would be a general protocol that hopefully can support a bunch of different formats um I think that formalizing some of the expectations like what do we need the te to support for this model to work right and then uh where are the different criteria could be really helpful homework to that point that helps. ✪

Wayne Chang: Yeah definitely so I think that um encouraging multiple entities and fortunately there there are uh I'd say not plethora but there are much more optionality when you're looking at te vendors so making sure that there's some separation of concerns there and the right degree of auditability would be pretty important to making sure this runs correctly right. ✪

Wayne Chang: There are also some open Hardware teas that are making their way to production which I'm excited about but also you know fortunately there's a bunch of production ready stuff today too. ✪

Wayne Chang: Yeah I think there's a certain strategy credit for Hardware manufacturers to play this right because they protect so many payloads with their te stuff right everything from the data pipelines used for AI and everything else so if they were to collude and you know backdoor a te then I think the brand would have some very negative impact uh right and that that would be painful so I think that like the game theory around it is like pretty interesting that we're able to shift to a different model. ✪

Wayne Chang: Great thank you so much for the time here um yeah I definitely uh appreciate this and I will note again teas are not perfect you'll look at sgx fail to see some failure modes of late so have to be part of a layered approach but you know it's a step in the right direction I think so appreciate everyone's time. ✪