Patrick St-Louis: Yeah maybe I just wanted to say hi uh it's my first time on this particular call I've been attending the vcpi and the traceability specific uh interrupt calls um I work at the digital trust laboratory of Canada my name is Patrick I've been in the space for about 4 years and then IBEW IBEW twice and uh I'm mostly looking at sort of merging the unknown credits space with the W3 space uh. ✪

Patrick St-Louis: More specifically with the the new work with the hand on credits as a data Integrity proof format which is why I was interested by this call so happy to meet everyone on this call. ✪

Manu Sporny: Uh just just a couple um so uh let's see um the California DMV uh made some uh pretty interesting announcements last Friday I don't know how much I can share right now but everyone here got the invite for it right so if you attended um you saw some things I think they'll be some you know a press around uh um uh that stuff um uh this week uh or next week at some point uh so exciting things coming from California DMV related to work that this community uh had done um the second uh kind of update is the verifiable credentials working group is um publishing an old document but in a in a new form so we're generalizing the did core specifications kind of the the the heart of the did core specification into a a specification called controller documents uh primarily because that content. ✪

Manu Sporny: Was being. ✪

Manu Sporny: Copied and pasted across. ✪

Manu Sporny: 3 Different specifications and so we're trying to just put it into 1 specification so there'll be a new controller document specification um coming out by with uh VC working groups soon. ✪

Manu Sporny: Uh status list is going to be I think published as a wreck uh sorry not has a wreck as a candidate recommendation uh very soon uh as well um so good progress there there's a rechartering that's going on for the group that's going to try and extend uh the groups uh lifespan by another 2 years um to basically finish up the work that we've been doing and then maintain the specifications given uh the uptake uh from a variety of different uh organizations there um uh so you know plenty of time to continue to provide input to the VC especially as we try and finalize all that version to our work there are 10 10 1 0 specifications that the working group is now in charge of publishing um and you know we are we're in a good track to publish those um if not a couple of months later than we had hoped to um that's it for me. ✪

Kaliya Young: Um the internet identity Workshop now has a series of uh Regional events happening and the next 1's in Europe in Zurich. ✪

Kaliya Young: Digital identity unconference Europe. ✪

Kaliya Young: https://diceurope.org/ ✪

Kaliya Young: And it's the third week of June and we will sell out so if you want to come please buy your ticket sooner rather than later and I'll put the link to that in the chat. ✪

Manu Sporny: We do have um you know I mean we've been meeting regularly for the verifiable credential API um and for those of you that may not have heard um there's a new digital credential API that is in incubation at w3c. ✪

Manu Sporny: With the goal of porting multiple different formats multiple different protocols um things of that nature it's a it's a browser native browser API for like moving credentials around uh the the web uh they did some really cool demos at IBEW uh uh recently um uh and um you know are looking for um you know which formats should be supported which protocols which query format should be supported and that kind of stuff so there's been some requests for us to be more active in uh that work um for those of you that are interested in participating it's a it's a very active healthy group uh meets I believe Mondays and Wednesdays. ✪

Manu Sporny: Alternating um I should have I should I should find a link for people give me. ✪

Manu Sporny: Um if you search for digital identities. ✪

Manu Sporny: Um uh w3c it should it should come up sorry I don't have the link on me right now uh anyway just a heads up that there's some work item work that we're doing in ccg that's influencing um some of the discussion over there that's it. ✪

Benjamin Young: https://github.com/WICG/digital-identities ✪

Manu Sporny: Great thank you Harrison um thanks folks for having me um uh let me go ahead and share the screen. ✪

Manu Sporny: Uh okay so the kind of discussion today is on this concept called parallel signatures um uh it is a technology that uh I mean was incubated in this community group uh which then went standards track at the worldwide Web Consortium and is now in the candidate recommendation phase with M multiple people implementing and demonstrating interop through the test Suites um and so we're just going to kind of go over the basics today what is it why is it useful how is a different from the other you know signature mechanisms out there today um and then what does the future look like uh for this particular technology um as always please just interrupt me um uh raise raise hand or Q Plus or whatever uh as we go along if you have any questions um we can definitely make this more of a conversation uh then a presentation um okay. ✪

Manu Sporny: Let's Dive In. ✪

Manu Sporny: The things we're going to cover today is just kind of some of the security privacy and format challenges that exist when you're doing verifiable credentials or digital credentials of any kind uh we're going to talk about how the parallel signature solution tries to address some of those uh challenges we're going to go through some examples of like how it works like high-level examples of how it works and then uh discussion either during or or at the end um. ✪

Manu Sporny: Let's kind of talk about some of the challenges that motivated uh the work um. ✪

Manu Sporny: When when we have when you know when we're doing verifiable credentials or digital credentials of any kind um there are a number of challenges that we have to kind of meet we have to meet all of these challenges write 1 of them is the security challenge which is like how do we digitally sign. ✪

Manu Sporny: Verifiable credential in a way that follows government cryptography standards uh and there are many organizations that kind of publish cryptography standards that are used by government uh nist uh Etsy Triple E ISO all publish cryptography standards and then governments decide whether or not they're going to they're going to use it um in that decision tends to be somewhat separated from Private Industry like Private Industry tends to adopt cryptography more readily um um or earlier than than most governments do and when governments basically. ✪

Manu Sporny: They're going to. ✪

Manu Sporny: Pop some level of cryptography. ✪

Manu Sporny: They really mean it like that is they and they expect their vendors to comply and systems built to comply and all that kind of stuff um the reason is is because it has National Security implications if you choose a week digital signature format it could be a national security risk okay so 1 of the 1 of the challenges is getting the security right in a way that like governments and big organizations are going to adopt it. ✪

Manu Sporny: The other thing when we secure our verifiable credentials uh has to do with like privacy challenges um so. ✪

Manu Sporny: You know how do we digitally sign something so that an individual's privacy is protected um specifically how do we enable selective disclosure and how do we enable unlink disclosure uh so the difference between those 2 terms is selective disclosure allows you to like show certain fields in let's say like a driver's license so you can share only your address or only your date of birth right that's selective disclosure uh but the thing usually what's selective disclosure is it's not on linkable meaning like if you show that you're over 21 using like an mdl at 1 website and then you do it at another website well the digital signature on that um that credential that you send over the selectively disclosed credential is correlated with it's trackable so the sites could get together and collude and start tracking you as you go from site to site proving your age. ✪

Manu Sporny: Linkable disclosure on the other hand um makes it so you can't be tracked the digital signature changes every time you do that presentation and as a result it's unlink 1 website can't link your usage to another website so we have these privacy challenges uh and a lot of government cryptography today does not support unlikable disclosure for example so that's why it's a challenge to meet both of those at the same time. ✪

Manu Sporny: The Third. ✪

Manu Sporny: Thing of course. ✪

Manu Sporny: This is a format challenge um so we want to meet the security challenges and meet the Privacy challenges um but without having to like re-encode the verifiable credential for every single every different type of feature we want out of it right so there's there's kind of like this this uh Triumph of challenges that we're all trying to we're trying to solve for all of these uh at the same time um and in a way that's easy for people to use and and and so on so forth Okay so. ✪

Manu Sporny: Here's they're basically 2 ways of digitally signing information uh these days um 1 of them is called an uh enveloping format uh and the other 1 um. ✪

Manu Sporny: I'll go here is um um basically an embedded format so you can you have enveloping signature formats and embedded signature formats so we'll go on Option 1 talk about that which is the enveloping signature format um so the the idea with the enveloping format is like you have 1 verify credential um but you end up copying that um into different envelopes and the envelope is a security mechanism it's you can think of it like you know writing a message down putting it in an envelope and then sealing it with a wax seal like that's your digital signature um the nice thing about enveloping formats is like they're much simpler for security software implementers so the people that are writing the cryptography libraries have a easier time uh uh uh uh creating these kinds of signatures because the the the code that you write to do it is just kind of straightforward right um. ✪

Manu Sporny: That every time you want a new feature set you have to invent a new enveloping format right and so uh if you want selective disclosure well you have 1 approach but if you want on linkability well you've got to create a new enveloping format um and so on and so forth um so it's it's more complex for people writing digital wallets and verifiers to deal with all these different you know enveloping formats um there's a lot of protocol complexity that comes in uh because you know if you're going to issue for example a driver's license that is both selectively disclosable and on linkable and follows you know government cryptography standards um you would have to digitally sign this credential you'd have to you know copy it multiple times and put each 1 in a different envelope. ✪

Manu Sporny: In your hand over like the multiple envelopes for the to the you know wallet software so there's wallet complexity protocol complexity all that kind of stuff um some examples of enveloping formats are like VC jot 1 1 Vesey Hosey VC cozy SD jot jwp each 1 of those is a different envelope format requiring different sets of rules and different kind of encapsulating thing Okay so we've got enveloping formats and then we've got um embedding formats so the other option here is that we embed the digital signature in the message itself um the idea here is that you just you you just have the original verifiable credential. ✪

Manu Sporny: Time you want to add like a specific type of signature to it with different capabilities you just kind of attach it to the end of the verifiable credential so you have 1 payload that has multiple different proofs on it uh now the benefits here is that like it's a Json data structure so you can continue to process it as Json uh you don't have to like encoded in this envelope that's opaque that you can't you know see through um it's simpler to manage for most developers because most developers know how to just deal with Json um and the security format the the mechanism is the same between selective disclosure between full disclosure selective disclosure and unlabel disclosure the the payload stays the same it's just like the verifiable credential and all you're doing is kind of like attaching these proofs uh to it um it's also simpler for uh devs that have to manage and process VCS like they can take these things and just directly put them in the database instead of having to like. ✪

Manu Sporny: Have the security format and the envelope impact what they put in a database and what they pull out of it and how they verify and all that kind of stuff so it's like this 1 simple payload that can be that has all these different features uh security features um. ✪

Manu Sporny: That meets all of the challenges that I mentioned before um now. ✪

Manu Sporny: It is 1. ✪

Manu Sporny: Complex from a security implementation standpoint like the the people that write security software. ✪

Manu Sporny: Uh have a much harder time implementing it because there's more to it right this is about pushing complexity around right where are we pushing the complexity are we pushing it up so that every single developer has to deal with it or are we pushing it down and making the security software implementers lives you know more difficult um so an example of you know embedded um uh signatures is the w3c data Integrity uh work okay so we've got these 2 options and enveloping and embedding um okay and and as I mentioned the the question is where do you push the complexity it's not it's not getting rid of complexity right because both there there is complexity in both systems it's where you pushing the complexity to and who's got to deal with that um uh. ✪

Manu Sporny: Really what you know I think often this is uh discussed as a 1 is simpler than the other uh uh uh uh uh problem um but when you look at it from an ecosystem perspective you've got you know similar levels of complexity you just need to figure out um who's going to deal with and manage that complexity. ✪

Manu Sporny: Okay so we're just going to focus on Parallel signatures today that is the uh embedded proof mechanism it's the thing where you have like 1 verify credential and you just attach multiple different signatures multiple different proofs to that 1 verify credential um. ✪

Manu Sporny: The the actual like section of the specification which is linked to here. ✪

Manu Sporny: About this as proof sets so it's a set of proofs um where you can have 1 or more proofs attached to a verifiable credential um. ✪

Manu Sporny: Then with those kind of multiple proofs attached to the credential the holder um can then decide which 1 of those proofs they want to use when they engage with a verifier now clearly the verifier also has a support like selective disclosure or receiving an unlink disclosure or whatnot but the idea here is that you know the issuer issues a credential with multiple different options the holder has those multiple different options and the verifier says you know I accept you know option A and option C but not option b right so you can think of this as like you get it you're getting a certificate and you've got multiple different locks that you can use to prove to the verifier that it's you know digitally signed by the issuer but the holder has the choice in which lock they attach every single time they do a presentation. ✪

Manu Sporny: Fundamentally that's kind of you know how this works the issuer starts with a credential that they want to give to a holder um they choose what types of security features they want the holder to have so they decide whether or not they want the the um. ✪

Manu Sporny: Potential to be fully disclosable or selectively disclosable or unlink or all of the above. ✪

Manu Sporny: They generate those proofs they put them on 1 pay load and they send it to the holder. ✪

Manu Sporny: Beholder in their digital wallet now has that verifiable credential with all these different like security and privacy features um and then they go to a verifier and the verifier goes I want you know you to prove something to me give me a verifiable credential uh but then the verifier can say but I'm totally fine with you just selectively disclosing your birthday for example or I'm totally fine with you unlink disclosing that you're over the age of 21 right and then the holder and really it's their digital wallet software will will in an Ideal World pick the most privacy protecting mechanism when engaging uh with that with that verifier um. ✪

Manu Sporny: Okay uh so the what what the parallel signatures solution does and what the data Integrity work does is it it makes a conscious decision to push the complexity down in the stack like way down to the depths of the the securing format um and the reason that it does this is to simplify uh uh lives for everybody else up the stack which is most developers right there's a very small group of developers that actually write security software and they are typically more highly trained their code is audited on a much regular basis they focus on like sdks and libraries and they're just far fewer of them to focus on and make sure they get it right versus everybody else way up in the stack that may have to juggle all the complexity of multiple different on the loop formats um so that that's where kind of w3c data Integrity makes a different decision than. ✪

Manu Sporny: Has traditionally. ✪

Manu Sporny: Kind of the cryptography Community um we're saying don't expose web developers to all this complexity all this envelope complexity you know push it down way deep into the libraries and have the libraries uh and those highly trained developers uh uh deal with it. ✪

Manu Sporny: Okay so um let let me let me pause there we're going to start looking at like some code examples and and what it looks like. ✪

Manu Sporny: There any questions on like conceptually what we're trying to do um. ✪

Manu Sporny: Like you know the formats or the challenges we're trying to meet. ✪

Manu Sporny: Patrick please go ahead. ✪

Patrick St-Louis: Now for me there's like 2 angles that I might have question and it's more to more validate make sure I understand so in the data to get T spec it talks about proof sets and proof chains which are 2 different things but they're both essentially a parallel set of signature or are proof chains not considered parallel signature. ✪

Manu Sporny: That's a great that's a great question um. ✪

Manu Sporny: Let's see. ✪

Manu Sporny: So uh proof sets and proof chains are different um I would say that proof chains are not really parallel signatures um uh they they have different uses so a proof set is like you have a piece of paper in multiple people sign put their signature on that piece of paper like literally they sign the piece of paper um but none of their signatures are dependent on the other right it's just like you've got a piece of paper and you've got 8 people signatures on it and maybe you only need 1 of those signatures to prove you know what you what you want to prove so they're made in parallel they're not dependent on 1 another. ✪

Manu Sporny: Our signatures that are dependent on 1 another so you can think of like a notary use case where you go into a notary with a piece of paper and the notaries like show me your ID and you show me your ID and then they're like okay sign this piece of paper. ✪

Manu Sporny: They always have you put your signature on the paper before they put their signature on the paper because what their signature is supposed to do is proved that you signed that thing you know in front of them so that's an example like a notary is an example of a chained signature where you put your signature on it first and then the notary puts their signature on it and so there you can combine these things and like arbitrary ways um but fundamentally that's that's the difference between these things and and just today I'm only talking about proof sets I'm not talking about proof chains um would that help. ✪

Patrick St-Louis: All right yeah that help and that sort of leads into my second question which is do all signature need to come from the same issuer. ✪

Manu Sporny: Great question yeah no they know they don't they could come from totally different issuers. ✪

Patrick St-Louis: Right um because at the example you said so the issuer applies multiple proof when he issues but there could be a case that the holder could require an additional signature from another issuer on that same credential could that be a use case for parallel signature. ✪

Manu Sporny: Exactly yep yeah absolutely yeah I mean you could you could have I mean there's a question around like should you change those chain those signatures together or is it okay to have them parallel yeah the the verifier can say you know I want to verifiable credential that has not only been signed by like. ✪

Manu Sporny: This is. ✪

Manu Sporny: But like a. ✪

Manu Sporny: Credential where you have like the department issue the um uh issue the the um the degree and then you have the registar sign over that and then you have like the sort of cation body or the the you know accreditation body now that doesn't map very cleanly into the way it works today um so maybe somebody has a better example of like you know but but yes the general idea here is like. ✪

Manu Sporny: You could have totally different uh issuer sign over the same credential. ✪

Manu Sporny: Have an aggregation of signatures. ✪

Manu Sporny: A board making a decision would be an example of that like if you wanted um like the minutes of a board meeting We additionally signed by multiple people those are different. ✪

Manu Sporny: You know. ✪

Manu Sporny: Uh signatures that we go on. ✪

Patrick St-Louis: I don't know if it's just me but I think your sound is uh getting a bit strange. ✪

Patrick St-Louis: That's fine though. ✪

Manu Sporny: Oh sorry um let me know if it if it uh. ✪

Manu Sporny: Okay good um all right I think we have other other folks on the Queue um. ✪

Manu Sporny: That's an excellent uh question uh we will get into that in the latter part of the slide deck I'll have an example that goes exactly to that question. ✪

Manu Sporny: The answer is yes the answer is yes yeah. ✪

Dmitri Zagidulin: I might check can you hear me. ✪

Dmitri Zagidulin: So I would uh just as a brief aside on proof chains. ✪

Dmitri Zagidulin: I would caution people to model business flows and business logic as proof chains. ✪

Dmitri Zagidulin: Great the temptation of stuffing business model Fields into improved objects for any given example that has been given so far like for example uh in the University setting where it was first signed by the department and then approved by the register. ✪

Dmitri Zagidulin: In order to do something like that you you start trying to stuff for example approved by the registar into a signature object where it doesn't belong for any given. ✪

Dmitri Zagidulin: For any given workflow that you're tempted to model as a proof chain consider modeling it as several different credentials that just linked to each other that's it. ✪

Manu Sporny: Yeah that that's an excellent point Demetri I I think people you I mean people see like the flexibility that could be done with like proof sets and proof chains and like you know the Mind goes wild and you're like oh yeah I could do all these things but I think the meter you're absolutely right like just keep it simple at least these are early days you know the second as Demetri said you've got some kind of business process it's probably better modeled as a set of VCS than trying to overload the the signature mechanism. ✪

Manu Sporny: Yeah excellent point um. ✪

Manu Sporny: Yeah absolutely um 1 of the driving things 1 of the driving reasons um for this uh approach was we needed to be able to sign things in ways that governments would accept today in by and large that cryptography is just you are correl you are fully trackable it's like full disclosure type thing right um we can get to selective disclosure um with modern cryptography with sorry with with standard government issued cryptography but trying to do on linkable is there's it just there there are no accepted government standards for that so we needed to be able to create verifiable credentials in a way that governments would would receive but remember I said like private organizations sometimes lead governments like a decade in accepting new types of cryptography so we wanted to be able to sign these things in a way that a government would still accept it but Private Industry would be. ✪

Manu Sporny: Because they have mandates from like privacy regulation that says that they should be minimizing data so Private Industry can accept the BBS signature right when a government might not be able to and the reason we put the signatures in parallel is we're giving the holder the choice of like hey you have an option of doing an unlikable disclosure at this point you should definitely use that proof instead of the fully disclosable 1 right um avoid being correlated um. ✪

Manu Sporny: Go ahead I think Harrison you're on the queue as well. ✪

Manu Sporny: You you can but there's a technical limitation with all of the enveloping mechanisms where you have to repeat the information you have to repeat the data or you have to do this weird detached signature thing we actually in the the 2018 Signature suites we did use detached signatures um. ✪

Manu Sporny: But ultimately it was kind of like this weird hybrid thing uh that I think both communities ended up not really liking that much uh both the enveloping communities and the and the embedded communities um. ✪

Manu Sporny: Harrison but there are a whole bunch of kind of downsides with doing that um. ✪

Manu Sporny: All right uh I think we have a clear queue I'm going to keep going. ✪

Manu Sporny: Okay so what what does this actually look like we're going to actually look at some examples here and see how we you know build up the example so um. ✪

Manu Sporny: A very. ✪

Manu Sporny: Verifiable credential with multiple proofs on it this is what it looks like so you've got your standard like verifiable credential this is for a permanent resident card you've got you know some Fields here um and then in the proof you'll see that this is an array it's a set of different proofs and we'll look at look into the dot dot dot here in a bit but this is a verifiable credential that contains 5 different proofs on it with 5 different security characteristics and privacy characteristics um. ✪

Manu Sporny: There are links to examples like full-blown uh examples here that you can kind of go and look at um uh. ✪

Manu Sporny: So if you want if you really wanted to look at exactly 1 of these things looks like like here here are all the proofs right that's 1 proof their second proof third proof fourth proof fifth proof so this is let's see this is an ecdsa 1 accepted by all governments uh ecdsa for Selective disclosure uh accepted by all governments um eddsa uh this is the true age uh you know signature um which is accepted by governments but doesn't have a Hardware security module compliance program you know provided by nist yet sorry by fips yet but it will um eddsa same thing um as the above and here's a BDS 1 so the holder of this credential could pick any 1 of these um as the uh as the the proofing uh mechanism um. ✪

Manu Sporny: Let's look at how it works beta Integrity has a pretty straightforward pipeline you get data coming in from the left here and you end up with the data with an attached proof on it and each pipeline will do different things but the end result will be a proof that's attached on the original data um these are 3 different pipelines here there's ecdsa that is like tried and true government crypto as far as the US and Canada and the European Union and their uh you know partner uh uh organizations are concerned uh China and Russia have different ideas about what should be used here they used stuff called like sm2 um but the ecdsa is largely you know USA Europe um approved cryptography ecds ASD uses uh uh USA Europe uh approved cryptography to do selective disclosure you can think of this as kind of like analogous to sdot um with some. ✪

Manu Sporny: Or differences between the 2 um so this is the pipeline for ecdsa SD and then BBS is a separate pipeline this is used to do on linkable proofs. ✪

Manu Sporny: Data Integrity pipeline for all of that is is the same you get data in you put it into a pipeline the pipeline will transform the data in some kind of way to prepare it for digital signature uh it will then hash the transformed data in some way and then it will digitally sign the hashed data in some way in out positive proof that you add to the data now what each 1 of these pipelines does at the transform stage in the hash stage in the generate proof stage is different um but the general pipelines the same transform hash generate transform hash generate that's just what each 1 these pipelines does and that's what data Integrity uh does. ✪

Manu Sporny: This is the ecdsa processing pipeline so you get a what you know any bog standard verifiable credential and so you get a pick any example in the in the spec you get that in as data you put it through the ecdsa data Integrity crypto Suite it transforms it and this is what the transformed version of it looks like it turns every single it turns that Json into claims so each 1 of these is a separate uh claim like for example you can see that um. ✪

Manu Sporny: The card has a description of a government of Utopia permanent resident card uh the identifier associated with it is this identifier uh the name of the card is permanent resident card it is a permanent resident card it is a verifiable credential uh it was you know issued on this date it expires on this date and. ✪

Manu Sporny: Uh and then you take all that data that's this is transformed and then you hash it into a cryptographic uh uh hash and then you generate the proof and this is the proof value that pops out the signature size is 64 bytes um 89 when you put it in Json format and then you kind of attach uh that proof to the data if you look at ecdsa SD. ✪

Manu Sporny: The transform stage does something slightly different so the issuer um and this is going back um to the question that you asked Phil the issuer decides which statements are mandatory like whenever they whenever the holder discloses it they always have to disclose in this case the validity period the valid from and valid until and the issuer like they always have to they always have to provide that information but everything else can be selectively disclosed like this is a employee credential so like their name their job title the corporation that they work at which the division in the corporation they work with the employee ID all of these statements each 1 of these individual statements is selectively disclosable. ✪

Manu Sporny: Signature as you can see down here is more complex than a standard ecdsa signature um we did another presentation a while ago to cover like what each 1 of these things are but uh you'll see that there's 1 base signature on all the mandatory fields in every single selectively disclosable. ✪

Manu Sporny: Thing it has. ✪

Manu Sporny: Own signature uh that can be disclosed um and then you've got a total signature size that's larger BBS very much the same kind of thing the transform step is actually the same between selective disclosure and unlink disclosure but the cryptography that we use is different so the Jenner the hash data and the generate proof stages are different you got a BBS signature and there's a BBS header and a public key and and an hmac key to ensure privacy um we do have mandatory disclosure Fields as well um that the issuer can set um and then the signature size is is again uh uh different okay so those are kind of the 3 different processing pipelines and each 1 of those pipelines leads to a proof that's added to the verifiable credential so here is the ecdsa proof if you want to do full disclosure here's the ecdsa SD for Selective disclosure proof if you want to do selective disclosure. ✪

Manu Sporny: Um here's the BBS proof if you want to do on linkable disclosure right so um this is again it's just 1 payload you don't have to put it in multiple different opaque envelopes you don't have to juggle the envelopes it's like everything is in in here. ✪

Manu Sporny: And the digital wallet software along with what the verifier wants and what the holders willing to provide. ✪

Manu Sporny: We'll end up using just in theory 1 of these signatures they could use multiple of them um in some of the more advanced use cases Okay so. ✪

Manu Sporny: You can try. ✪

Manu Sporny: In fact this was launched out to the playground like a couple of months ago um there's a selection where you can get any of the credentials on the playground where protected by ecdsa uh eddsa I think ecdsa SD and BBs like you can put all the signatures on it you can look at them uh see that it's working and then you can go and like receive the credential and and present the the credential uh their uh okay that's that's largely it um uh for the presentation today uh any other kind of questions on. ✪

Manu Sporny: This technology standardization where it isn't standardization that sorts of thing. ✪

Manu Sporny: Yes uh yeah you're you're you're seeing that you're seeing yes that's correct so um and here's why um when the issuer issues a credential fundamentally it is them that's creating the credential for the holder so there so for example think of something like a revocation list some issuers might say you know what I want the verifier to know that there's a revocation list associated with essential because I might revoke it um from the holder and I do not want the holder hiding the fact that there's a revocation list from the verifier right so in that in that scenario the issuer might say it is mandatory to disclose the revocation list um as an example or the issuer might go you know what the the this credential has a validity period I want the issuer to know what that validity period is I don't want the um the holder to hide that information from the verifier. ✪

Manu Sporny: And the. ✪

Manu Sporny: All of these. ✪

Manu Sporny: Things come around. ✪

Manu Sporny: That happened because of like potential fraud use cases um so. ✪

Manu Sporny: But there's a market here right I mean like you know if issuers are issuing selectively disclosed credentials where you can only selectively disclose like 1 field and the rest of it is just like highly um kind of privacy invasive you know credentials. ✪

Manu Sporny: In an Ideal World holders you know or or you know organizations that hold issuers to account will complain to the issuers like hey you're doing a pretty bad job when it comes to selected disclosure right and so there's a there's a um. ✪

Manu Sporny: There is a natural give and take that we hope takes hold in this ecosystem um I think what we're the the guidance we're going to try and give and the verifiable credential working group is issuers should make every field selectively disclosable in a verifiable credential by default like that that should be your default position uh and then only if your legal council is like no you cannot make that selectively disclosable will you be like okay fine we'll we'll put some mandatory fields in there and the reason we think that's probably going to be okay is because for something like a driver's license which is standardized um uh the verifier will request like if there's a verification list the verifier will request a revocation list because they know that these types of credentials always come with a revocation list and so the holder is not going to be able to hide that information from a verifier if if. ✪

Manu Sporny: The verifier wants. ✪

Manu Sporny: Um so I think that's kind of where we're that's what we're trying to do but you know this is a big ecosystem we're going to see you know if there's anyone that pushes back on that um Phil did that answer your question. ✪

Manu Sporny: Great thanks Phil. ✪

Patrick St-Louis: Yeah just fine I really like that last part that there's also a responsibility component on the verifier to ask for a non word vocation proof of some sort even though if they both rely on the status list by having a status list uh selectively disclosable you then sort of flip the role on the verifier to ask for a proof of non uh revocation because it's not 100% and the holders uh control to not show like yes it is at the end of the day you can show not to show his credential but the verify your can also specifically asked for fields that have been flagged as effectively disclosable so I think that's really important my question was so you mentioned earlier that by having a credential with parallel signature the holder can then choose which signature to send to a verifier would you say that sending only 1 proof to the verifier it's is Falls onto the general League. ✪

Patrick St-Louis: Good practice or. ✪

Patrick St-Louis: Be a requirement that when it sends for verification it chooses only 1 proof. ✪

Manu Sporny: Um uh let's see. ✪

Manu Sporny: I so so I don't know what's going to happen in the future right so there there are exceptions to what the question that you asked but I'm going to try and ignore those for now so I think in general. ✪

Manu Sporny: You should only be sending 1 of these signatures right you should only send an ecds you you should decide if the if the verifiers allowing you to decide between unlined you should pick unlink like by default um and you should only and and in that case you should only send the unlink disclosure because if you send the other proofs you will end up being correlated right um however the the caveats to what that your question is like well what happens if they're like multiple signatures that are required well the verifier can ask for the specific signatures that they want so let's say you have a set a set of signatures where you require like 2 or 5 signatures um the verifier can say I want signatures from person a and or issuer a an issue or B an issue or a c like they can they can request that and then if you have those proofs then you know that the verifiers is not going to be happy unless you send all 3 different types of signatures. ✪

Manu Sporny: But then. ✪

Manu Sporny: That's mildly different. ✪

Manu Sporny: From like picking between the type of disclosure you you want to combine. ✪

Patrick St-Louis: So the you mean like the verifier you could request based on a specific verification method like if he knows you wants verification method that's suppose support selective disclosure. ✪

Patrick St-Louis: You could. ✪

Patrick St-Louis: Asked for this. ✪

Manu Sporny: Yeah definitely well I mean not only that it it's it's there's selection between the type of cryptography that's used right so the verifier can say I want this specific type of cryptography like for example I am the US federal government I only uh support ecdsa or ecdsa SD and I want you to tell me what your birth date is. ✪

Manu Sporny: That is the type of request that can come in from a verifier and then the holder can then go like okay I've got 3 of these signatures on here ecdsa SD and BBs they're asking me for either the the thing in purple or the thing in green so that either the the the ecdsa proof or the ecdsa SD proof and the holder software the digital wallet is like I'm gonna optimize for the holder's Privacy so I'm going to use ecdsa SD um and they're only asking for the birthday so I'm only going to disclose the birthday uh to them so that's an example of like what you know the verifier can ask for and how the holder can respond. ✪

Patrick St-Louis: And do do you sort of verify your negotiation we're talking about is there currently a somewhat specific way to do this because pedal signature are fairly new is there currently like a presentation request format specifically addressing like which type of proofs to include. ✪

Patrick St-Louis: Right okay okay. ✪

Manu Sporny: Yeah it's in the VP request spec um so in in here there's uh uh their examples of how you like requests um I think maybe and did authentication like um here it has accepted methods but it also can have accepted uh cryptography Suites see like. ✪

Patrick St-Louis: Yeah I see there. ✪

Manu Sporny: So so this is the verifier I can say hey I accept the did key I did method and the ecdsa you know 2022 uh crypto suite for example. ✪

Manu Sporny: You got it yep exactly. ✪

Manu Sporny: Yeah so every other field in here will not be included it will just be the the individual's birthday. ✪

Manu Sporny: Thank thank you Harrison thanks a ton for for having me as always really appreciate it. ✪