Harrison_Tang: Hello everyone so welcome to this week's w3c ccg meeting so this week we got already here to actually talk about different selected disclosure mechanisms in the past few months we have invited several experts in different areas to talk about different selected disclosure mechanisms and I think it's a good idea to actually have another expert to kind of give us an overview about these. ✪
Harrison_Tang: Laughs oh thank you hungry for taking the time to jump in here and then actually be the kind of overview presentation in regards to these different mechanisms and options all right before we get into it just a couple quick things first of all just call it back legs and professional compel reminder just want to make sure that everyone you know respect each others opinions I think we have been doing that very very well so but yeah I'm just as a. ✪
Harrison_Tang: A quick reminder at the beginning of meeting a quick reminder on the I denote anyone can participate in these calls however all substantive contributions to ccg work items must be member of the ccg with full IP our agreement signed make sure you have a W3 account and if you have any questions or encounter encounter any issues feel free to just reach out to any of the cultures. ✪
Harrison_Tang: Quick hold now these meetings are being recorded and automatically transcribe we have been publishing them probably within the next 24 hours to couple days so that we encounter some issues technical issues if you notice anything wrong just let any of the cultures know and we'll try to fix it as soon as we can. ✪
Harrison_Tang: 2q the speakers and you can type in cubed plus to add yourself to the Q where Q - to remove and you can do Q question mark to see who is in the queue. ✪
Harrison_Tang: All right introductions and reintroductions if you are new to the community or you haven't been engaged in the community but want to re-engage please feel free to just unmute and introduce yourself. ✪
Harrison_Tang: So quick saying so due to some personal reasons Mike couldn't continue his term as a culture for the w3c CG so Kimberly and I will work on sending out an email and then kind of separating the nomination and also the selection process for for a culture so usually we have three cultures for the WDC Gigi and just. ✪
Harrison_Tang: Just like the new one and if anybody are interested please feel free to just let us know. ✪
Harrison_Tang: Any other announcements or reminders. ✪
Harrison_Tang: And I think we have a cool hybrid Open House Event last week and I do so thank you for all to attend Korea please. ✪
Kaliya Young: I don't know who's in London in this community but I'm actually coming to London for like a day on my way to the ietf meeting and there's an identity social at Newspeak house on the 2nd of November so I'll put a link if folks are in London or know people in London that want to come. ✪
Harrison_Tang: Any other announcements and reminders. ✪
Harrison_Tang: Yeah I was going to say that you could come across a cool presentation or discussion that happened at iwi police feel free uh police actually just reach out to me I kind of want to schedule some of these are interesting talks and bring it to the ccg. ✪
Harrison_Tang: All right any updates still work items. ✪
Harrison_Tang: Cool let's get to the manage ende so. ✪
Harrison_Tang: Today again we are very very happy too and thank Ori to take the time or is the CTO transmute one of the most active contributors to the ccg work items and today just want to thank him for taking time to present on different selective disclosure mechanisms and all they're also they're different trade-offs 0 or E the floor is yours. ✪
Orie Steele: Awesome let me figure out how to screen share and jitsi. ✪
Orie Steele: Is this share video is that the key word for this. ✪
Orie Steele: I'm sorry I don't figure it out every meeting software is different can you all see selective disclosure 2023 awesome so this presentation is going to be kind of an overview of selective disclosure in general and then comparing SD J WT to ecdsa SD but really like the kind of general purpose. ✪
Orie Steele: Um selective disclosure approach that works with data Integrity proofs as my understanding that there's been previous presenters who have already commented on this but I didn't attend that presentation so I'm not sure if there's any details that I'm going to get wrong here but you know feel free to interrupt if you see something that's not correct or you're aware of something that I'm not aware of regarding. ✪
Orie Steele: The sort of selective disclosure Primitives which are shared in the data Integrity proof approaches. ✪
Orie Steele: So first I'd like to kind of introduce the topic of know what is selective disclosure and you know in general authors want to protect parts of documents using various Technologies later parts of the documents might need to be disclosed how do we know that the disclosure is consistent with the original redacted document and so we know one example this would be you know government documents that are redacted and made available to the public and so I've included. ✪
Orie Steele: Snippet from the NPR website on the molar report and to interesting example of selective disclosure there's you know sections of the document that have only minor redactions sections that have major redactions and another interesting piece there is that you know they provide reasons for redactions so you know one question that you know we might have as we think about building digital representations that can support selective disclosure is is the reasoning. ✪
Orie Steele: Around what was disclosed or not disclosed important to this. ✪
Orie Steele: Infrastructure we use to build selective disclosure capabilities and then on the right hand side you can see the classic CIA triangle confidentiality Integrity availability and selected disclosure fits into this sort of the triangle it's about protecting confidentiality protecting Integrity the availability piece is a usually the thing that you. ✪
Orie Steele: Ice when you care about protecting. ✪
Orie Steele: Confidentiality and integrity but nonetheless it's still an important part of the CIA triangle and information security in general. ✪
Orie Steele: So I wanted to give just in the context of thinking about redaction some examples from the declassification archive fourth action codes so if you're looking at government use cases one of the things that you'll see is that there's these different reasons why information might not be made available to the public and it could be that it's related to you know military plans or Weapons Systems could be foreign government. ✪
Orie Steele: To protect a foreign government that we have a positive relationship with or maybe not so positive relationship with could be related to intelligence activities scientific information weapons of mass destruction and you know vulnerabilities so there's lots of reasons why we don't share information and sometimes it's important that while information be protected we. ✪
Orie Steele: The parts that are safe and keep sensitive the parts that are not safe to share you know wider audience. ✪
Orie Steele: So I've taken the classic 33 role model that we're all familiar with from verifiable credentials and expanded it to show some purple bubbles which are emerge as you try and apply Progressive disclosure celac selected disclosure data minimization when you when you want to enable those capabilities you end up having to modify parts. ✪
Orie Steele: Party model 3 Role Models process so as the issuer before you can make a credential or a document with security if the think about what elements in the document should be disclosable and which elements should not be disclosable and that's different than the traditional approach you might take where you would say you know everything the documents going to be disclosable I'm going to sign the entire thing. ✪
Orie Steele: So now you have to think about okay. ✪
Orie Steele: K but these fields you know we should be able to decide if we want to redact them or not. ✪
Orie Steele: And I've given the name commitment you know to that but you know different people use different words for that and there's different software techniques that are used at that stage where you're the issue or and you're starting to organize the information in the way that you need to in order to secure it another important part there is like. ✪
Orie Steele: Required to commit to disclosing you know in a mandatory manner certain Fields so some fields in the document every verifier that cares about that credential needs to be able to see them and you don't want to give people the ability or you know you don't even want to hint at the idea that they might not share that particular field so you know when you think about profiling verifiable credentials. ✪
Orie Steele: Is aside from you know schemas or representations of the claims structure you might also think about annotating those claims with redact ability know is this a field that user should be able to control disclosure of or not. ✪
Orie Steele: All right oh and one other thing you know feel free to ask questions as we go through this like this is a short presentation so we will definitely get to the end and we can we can have a conversation but I don't mind taking questions as we go so once you've gotten the issuer's committed to the claims they've created a structure they've created the credential and they've delivered the credential to the holder at that point the holder gets to decide what kind of information do I want to disclose. ✪
Orie Steele: Mum that the holder might decide to do would be I'm going to disclose only their mandatory Fields I'm going to redact everything that I can and that's going to support this concept of data minimization which is really important and a lot of use cases it protects the holder if the claims are about the holder it protects you know the subject in the case the holder is acting and guardianship role for the subject so disclosure is an important. ✪
Orie Steele: A subset of what the issuer has allowed right so the issuer says you have to disclose your social security number of the holder won't have a choice but if the issuer says you have the choice you can disclose your social security number or not now the holder can decide you know maybe I disclosed my social security number when I'm talking to the government and otherwise I don't and again disclosure the structure that you use to enable that feature kind of varies depending on the system that you're working in. ✪
Orie Steele: Then the final piece is this verification piece and that's that's always been a part of the three role model but it's a little bit different in the case of selective disclosure and that's because you have not just checking of a digital signature you have reconstituting the issuer's claims but Modified by the holders intended disclosures so you end up having a data structure that is not. ✪
Orie Steele: Of safe as just a verified digital signature payload it's there's been other stuff that has happened when you're looking at that final verification structure and that's a place where implementation detail could cause you no harm like could implement the verification of selective disclosure incorrectly and now verifiers going to see claims that weren't actually committed to by the issuer disclosed by the holder it's easier to do that. ✪
Orie Steele: Of disclosure schemes because they don't just reveal sign bites from the issuer in the holder they there's processing has to happen in order to construct that final verified format. ✪
Orie Steele: Right I think that's it for this slide. ✪
Orie Steele: So I wanted to just sort of try and make a apples to oranges comparison here between data integrity and sdj to DT and I fixed the elliptic curve and the hash algorithm so that you can see that those are in common their shared between both of them and then I've included implementation details here for both of them as well based on what I'm aware is available and. ✪
Orie Steele: Change right so they're not part of their not a fundamental property of the cryptography or the standards their choices that Library developers have made to try and make the technology consumable and easy to use so on the right hand side one of the things you'll see with sdj to be T in particular I should say yes DJ to be T is a oauth working group adopted token format Builds on top of Json web tokens and salt of hashes. ✪
Orie Steele: It's it's a pretty simple to implement we're going to look at the details of it you know and subsequent slides one of the things that is interesting about the sdj to be T implementations that I've seen is they tend to use the animal which is another language entirely and the reason they use yeah mole is because of that need for the issue or to Mark things as disclosable. ✪
Orie Steele: You have key value pairs in objects and the keys are always strings so if I wanted to communicate with you all that only a certain key should be disclosed and not another key I need a way to annotate the key in the key value Pairs and yamo provides a semantic tagging functionality that's very useful in that regard. ✪
Orie Steele: Can see some of the building blocks behind data Integrity proofs in particular ecdsa SD and just speaking to that annotation you know value proposition like how do you accomplish that data Integrity proofs the libraries that I've seen use Json pointers to do that so they point you know what the field that is intended to be mandatory to disclose or selective to disclose and then there's some other building blocks that. ✪
Orie Steele: Excuse and I one thing that both of these techniques have in common is they are media type specific so they don't work over arbitrary content they work over Jason or rdf json-ld which is which is rdf so they're not like a general-purpose cryptographic structure or like you know Randy opaque B that you might sign and verify. ✪
Orie Steele: So I'm summarizing here you know high level some of the steps that you take it during issuance and so the first part is this sort of labeling claims that are disclosable I mentioned that before the issuer is going to have to think about what claims should be disclosable what claim should not be disclosable. ✪
Orie Steele: You need to compute Jason pointers SD job you need to annotate to me animal on the sdg outside you're going to walk the object tree in the animal you're going to salt and hash any disclosable members you're going to encode the result as Jason base64 URL encode the Jason sign a JWT like you normally would and then you're going to help and all of the disclosures that you computed that's the issuance process. ✪
Orie Steele: On the data Integrity proof side you're going to. ✪
Orie Steele: She's an rdf operation that's going to produce rdf triples which are then going to Blind because you don't want to accidentally disclose information that you don't intend to you're going to generate a proof key sign the mandatory to disclose feels there's some other details here around like you know how do you construct the the proof object I'm going to kind of just hand wave over that for a. ✪
Orie Steele: And essentially you're creating a proof game. ✪
Orie Steele: Disclosable pieces and the mandatory pieces and then your encoding all of that information together in a bundle which your then including as an embedded Jason proof in the Jason all day and that's going to allow in the future you to kind of take that bundle apart and disclose the parts that need to be disclosed only. ✪
Orie Steele: So on the presentation side you're going to have to derive the presented form for both of these so on the SD jot piece you see you're going to walk the tree you're going to filter the disclosures to the ones that the holder has indicated they want to disclose so just walking the disclosure tree is different than walking the issuer's commitment to the payload the disclosure tree communicates which Fields the holder intends to do. ✪
Orie Steele: Walking that tree allows you to sort of fill figure out which parts of the disclosures you need to remove from the list if you don't remove them it'll be full disclosure every disclosure you choose not to give that is present in the payload is a redaction and then you may need to demonstrate proof of possession over a private key for which the public key may have been committed by the issuer that's the topic of. ✪
Orie Steele: Confirmation or confidence or holder binding. ✪
Orie Steele: So on the left hand side on the data Integrity proof piece you're going to unwrap that bundle that we created at the end of the issuance process decode see War you're going to compute a json-ld frame from Jason pointers apply the json-ld frame obtain the revealed document from the frame filter the signatures to match the frame re-encode the proof is see bore and then basically you're just modifying the proof object that was embedded in the Json. ✪
Orie Steele: So I've decoded we have an implementation of the ecdsa SD approach but it uses a different proof structure which kind of shows you in kind of Standards terminology the different components that go into the proof technique but you can see in the center piece here all of that Jason on the left-hand side gets smashed away when you encode this is Seaboard so the data Integrity proofs format that. ✪
Orie Steele: And then it's a string of encoded B inside of that string of encoded b b you're going to have the commitment to the mandatory to disclose Fields you're going to have the hmac keys all the signatures that kind of thing so it's just a alternate way of expressing the same kind of information. ✪
Orie Steele: And SD jot side you'll see the in the Respec sort of rendered version of this the red piece is the JWT header the Greenpeace has the JWT payload which will contain weird-looking claims that are going to be present for any field that could be redacted and then the signature in blue and then the. ✪
Orie Steele: And just to sort of show you know when you're parsing this kind of structure the first thing you're going to do is separate apart the JWT and the disclosures so the JWT is the issuer of signed representation with full reduction in place and then the disclosures are each of the possible redacted fields on redacted and you can see an example here of that where you have this. ✪
Orie Steele: Ellen coated salt the 18th this 18 literal and then false so 18 is the key and false is the value here and this array of key value Pairs and the salt has to be put back into the payload in order to get this nice verified looking result and that's that purple verification process those talking about before. ✪
Orie Steele: Dijon you're kind of seeing it in this decomposed structure in order to get it back into a readable view you have to process it and that's a little bit different than the data Integrity proof proach where you're kind of always looking at the structure and a nice readable view but there's all of this complexity in terms of ensuring the Integrity of that readable view so it's just different very different design approaches here between the two. ✪
Orie Steele: This is my last Slide the main conclusions I think you should take away or you know both of these approaches they show the verifier Jason that's computed from some intermediate representation so there you're looking at verified information that is always computed from some secured representation both approaches have performance issues that are tied to the input size and the. ✪
Orie Steele: That tree walking process that we talked about earlier if the tree is really large that takes a long time and it's different you know they are the performance issues are you know they're very different depending on the approach that you take and it's not just the CPU time to walk the issue inside tree or the presentation side tree it's also the B used to represent the information in the secured formats that's another concern that you should have. ✪
Orie Steele: Both approaches support the w3c json-ld data model S DG W can secure arbitrary Json data Integrity proofs as far as I'm aware cannot secure arbitrary Jason without doing context injection that's just so that you can get application and quads that you could then process with the algorithm there is a see bore approaches for both of them so in the. ✪
Orie Steele: Case where you did want to get Beyond jstor. ✪
Orie Steele: Into a more compact representations their Seaboard approaches for both there's SDC to Beauty which is basically just the cwt version of sdj to beauty doesn't do anything other than change out objects for maps and you see board instead of Jason and then there's Tibor LD for data Integrity which compresses json-ld using semantic dictionaries and sort of other other details. ✪
Orie Steele: Neither sdj to be stcw T or C bar LD or standards track documents at this point as far as I'm aware. ✪
Orie Steele: I think that's basically it so I'd love to take any questions you all have about selective disclosure you know the topic and if you don't have any questions I'm also happy to have time back. ✪
Harrison_Tang: Thank you Ari so my first question is like question tuitions will you use like SD job or is SD job more appropriate in your situations we use the data Integrity group. ✪
Orie Steele: Well I'm I would tend to use SD jot for any case where I was trying to secure Jason I would use data Integrity proofs in cases where I was securing an rdf data model expressed as json-ld. ✪
Orie Steele: And you could use SD job to secure that data model and if you're just securing json-ld a I think SD jawed is actually a better way of securing json-ld because it's actually securing the Json representation it's not performing this transformation to rdf and that that means it's sort of faster to secure json-ld with SDG&E than it is to secure it with data Integrity Bruce because you. ✪
Orie Steele: Presentation but you're still well you have to go through an intermediate representation but it's not content type transformation. ✪
Orie Steele: And in the case where I guess one other important detail here is like what is the verifier learn the end of the process the verifier learns the same information in the case you've secured both of them in the proofs are both verified so if the verifier learns the same thing you know we should ask well how expensive was it for the verifier to learn it and then I think SD job is in general a more cost-effective way of securing json-ld claims. ✪
Orie Steele: Verified it learns the same information at the end of the day that's just my personal view of this obviously other folks may have different opinions on that and there is some aesthetic preference that folks might have where they really liked looking at Json objects instead of compact and Kota Json web tokens and for those folks they might really prefer the data Integrity proof piece because it uses embedded proofs in Json which are always readable. ✪
Orie Steele: Able of course that also comes with security. ✪
Orie Steele: Because you're looking at stuff that you haven't yet verified and you might never verify it and you might just trust it as the encoded representation. ✪
Orie Steele: I think there was a hand raised so David go ahead. ✪
Orie Steele: So that's being debated right now in the verifiable credentials working group as some of you know I worked on the early versions of the BBS data Integrity proof approach and did take the same kind of approach here so it produces application and quads the application and quads are then secured with BBs algorithms has a different set of capabilities. ✪
Orie Steele: Proving that a message with sign you can you could reveal individual messages and you can do link signatures and these other techniques the verifiable credentials working group is still trying to figure out how to. ✪
Orie Steele: How to take the approach that's being used in easy to say and apply it to the BBS and I think Greg is cubed answer and I think he's probably the best position to comment on it so go ahead Greg. ✪
GregB: Good overview summarizing the bigger processes so one thing that did happen with those SD Primitives is we they got rid of the framing stuff so simpler step okay and as so we go from describing what's mandatory describing what we would like to. ✪
GregB: You're just using Json pointers producing this list of statements and that's what we feed into whether it be the ecdsa approach or we turn that into the stuff that we can feed into BBS because what we are talking about is what is this list of statements all are selected to. ✪
GregB: Work with these lists so that's what we're trying to make sure we can get into BBS and by having some Primitives. ✪
GregB: It made it easier to get things into BBS and that's what I've updated that Speck on note that there are other ways to get those lessons so more ways potentially of using BBS besides just the one based on The Primitives okay there's Json web proofs that are being proposed and things like that but what things work from. ✪
GregB: But I just wanted to point out that the steps have gotten a little simpler and I think we are on track to be able to get stuff into BBS and the bbbs work is advancing nicely at the ietf and we're going to be talking to miss tomorrow about it at their crypto Club thanks. ✪
Harrison_Tang: Sorry like just to kind of is it fair to to say that the major difference between the SD jot and data Integrity is the design side of things like one is focused on one started from Json the other ones sorry from this slide click that link data RTF kind of coaches it fair to say that the major difference were in my mischaracterizing something. ✪
Orie Steele: I think that's probably the major difference me you confirming different things if you canonicalize information before you confirm it you're confirming also that the canonicalization succeeded but yeah I think general in general like one is a way to secure rdf and the other is a way to secure Jason. ✪
Orie Steele: Brian you have your hands raised you know you're you're an author of STI welcome to comment here. ✪
Brian_Campbell: Yeah and one of the maybe mention the clarify a couple things are just reiterate and then a context with what you're saying so I pulled myself off but here I am I did want to just strongly mention that the llamo you mentioned is not at all a requirement of SD job in general it just happens to be a technique that the reference implementation uses to mark up its its data. ✪
Brian_Campbell: To help put some choosing which claims to make selectively disposable or not as you know something that is half going to have to be exposed of the API interface for whatever Library this and gamble is not at all a requirement just worked well in the context of that particular reference implementation which in turn is used to build examples and so marking up and animals saying what you want out of the examples is a convenient way to do it maybe that was created from what you said but didn't want to. ✪
Brian_Campbell: overstate the requirement there. ✪
Orie Steele: Yeah I think it's worth repeating so I did mention that the animal piece of s t Joshi and the Jason pointer piece of data Integrity I think are both technically their implementation details now the Jason pointer piece might not be an implementation detail and data Integrity now it seems like things have changed and data integrity and so Jason pointers are now like a mandatory portion of it but in the context of St John the animal pieces like 100% And. ✪
Orie Steele: Implementation detail and eight high level consideration. ✪
Brian_Campbell: And while I'm here as far as the performance considerations you're definitely correct it there's overhead in number of disposable claims that are in that but it's a it's a fixed or linear increase in the overhead because the only thing you're adding is is a little bit of additional data around the encoding and a hash check so there's not performance implications of like doing additional asymmetric operations or anything like that but when you're doing this DJ. ✪
Brian_Campbell: odd issuance for verification it's a. ✪
Brian_Campbell: Negligible additional processing overhead and a little bit lessening what would still make visible space overhead. ✪
Orie Steele: Yep I'm happy to comment more on the performance cost stuff if that's a topic of interest for folks but I want to make sure I cover the questions folks have I can't tell who's up first David I think you're I think you're up. ✪
Orie Steele: I don't think that's true I'm not sure. ✪
Brian_Campbell: So strictly speaking you can hide nested content but if you want to reveal something that's a lower level you're right you do have to disclose the things that preceded in the. ✪
Brian_Campbell: The tree down to it otherwise it will that's sort of just how the algorithm works but also you wouldn't have the context of where that exists in the structure so we're doing it now. ✪
Orie Steele: Yeah that's just generally true of all commitments the issue or might make as well like the process of organizing commitments in a way that supports the redact ability of the holder is the responsibility of the issuer if I build you a claim structure that forces you to disclose things I can do that as an issue or that's my my choice and my right. ✪
GregB: I wanted to confirm that the higher level procedure of using the Json pointers which are standard that did get put in as part of the standard for the part of the procedures so it's standardized so one of the things is how much do we tell people how to do things and so with the current selective disclosure ecdsa stuff. ✪
GregB: Use Json pointers an array of Json pointers which tell you what parts of the Json this doesn't apply to it doesn't matter if it's LD or not and that tells you what statements you want to reveal arbitrarily nested whatever and use that same pointers on the holder side. ✪
GregB: Save what do you want to selectively disclose so that was that's not a implementation decision anymore that we put into the standard so it's kind of nice it works nice no framing anymore of the Json linked data framing stuff so it's all kind of Json processing for that selected document and things like that. ✪
GregB: Also when you look at perform performance I'm a networking guy and so sometimes the first thing I think about it is the size of things. ✪
GregB: You can look at it that from that point of view but you can also look at it from cryptographic operations okay and so that's where as much as I love BB SBB s does elliptic curves and pairings from a computational point of view you're never going to be something that has a signal signature and a bunch of hashes okay so that's the SD jot point of view so make sure we understand that there's. ✪
GregB: And things like hashes are just super efficient then their size things right so like a BBS signature from an issuer super small irregardless of the number of messages so you're more concerned about the network it's one thing if you're more concerned about how many times somebody has to process things so just don't mix your apples and your oranges when you do look at these things okay because I will admit I'll admit that. ✪
GregB: that you're not going to beat hashing Merkle trees are. ✪
Orie Steele: Cool yeah I totally agree and I would just sort of summarize you know what you said like the curve operations are kind of expensive on my understanding for ecdsa SD versus SD J WT just you know putting the pairing friendly curve stuff to the side for the second ecdsa SD requires the proof key to be created which then that's a key generation operation you want to make sure that was fast but. ✪
Orie Steele: Random enough to be safe and then then you have signatures multiple signatures and that's different from the SD jawed approach where you have the holders key that you're going to commit to but you don't have a separate like a new proof keeper St John generally and you have one signature on the issuer disclosure to build the issuance token so. ✪
Orie Steele: Have to sort of similar to The Salted hashes you know in terms of computation cost and then on the sdg outside you've got a single signature and multiple rounds of salted hashes so just from a crypto operations perspective I don't think you're going to get a better performance from data Integrity with multiple signatures ever based on that but you might get other properties and you might get a generic that you can reuse in the case of BBS. ✪
GregB: Yeah I mean it's if we've ever in BBS land we've been looking even at variations to that may reduce the amount of computation on the holder if you're looking at secds ASD you can say that. ✪
GregB: Sighs of what the holder may have to send to the verifier cryptographically that scales differently than in the BBS case or the SD John case because you've got individual signatures you only have an overhead for what you reveal rather than overhead of what you don't reveal which happens in the BBS case so once again I don't think that it's bad to have options. ✪
Orie Steele: At some point you know hopefully we'll have a presentation here on unlink ability and it'll be ecdsa that little bbbs data Integrity proofs vs. Jason Webb proofs and we can compare Connor closer to Apples to Apples on the unlink ability property like the purpose of this presentation was just a focus on the selective disclosure peace and so you know with BBs you can get selected disclosure and unlink ability and you. ✪
Orie Steele: An get that in support of multiple different and. ✪
Orie Steele: You know like an rdf envelope or Jason envelope or Seaboard envelope but you know this comparison here is mostly just comparing json-ld and selective disclosure like I didn't I didn't go into the details really around on link ability at all here because just another dimension and also it's very under specified at this point I'm sure you're going to fix that Greg though. ✪
GregB: Yeah we need we need a lot of advice we also would need advice to the issuer's on how to make sure we keep the unlink ability as we go along so it's an important area not needed in all cases but if you're going to have it you know we got to make sure that you don't throw in something as minute. ✪
GregB: When something unintentionally that's going to be an identifier. ✪
Harrison_Tang: Sorry Greg if you don't mind can you clarify a post the problem of think ability I think some of us probably are not familiar. ✪
Orie Steele: Sure so this presentation is been on selective disclosure which you can think about as redaction or you know Progressive disclosure revealing more information over time or removing information from a representation there's this other topic called unlink ability which is under specified in. ✪
Orie Steele: A newer concept it's embodied best in the Privacy pass work at ietf at least that's the what I consider to be the best current version of it there's work at ietf to make a general-purpose sort of structure based on BBs for it and then there's work to apply that general-purpose structure to serialization formats like Jason and Seaboard and in general the on linkable property is like if I go to a gas station and buy beer. ✪
Orie Steele: And then I go to a different gas station and buy. ✪
Orie Steele: You know a different kind of alcohol and I had to prove that I was of age in both of those cases if those gas stations collude they should not know that the same person bought alcohol at both places they should know only that something prove that it was over age in both places and that would be unlike ability as in the verifiers cannot link a particular. ✪
Orie Steele: To another particular presentation of a clam. ✪
Orie Steele: Now like there's there's lots of details inside of that and there's cases where like it's important that you you know for example like if you're applying for drugs you know you asked one doctor for hydrocodone and then you ask another doctor for hydrocodone and then you ask another one like you kind of want some link ability for some scenarios there but it is also an important property of building the highest level of privacy into the holder and the. ✪
Orie Steele: Act and there's cases where you really want that property. ✪
Orie Steele: Think you know it's arguable that you should have a constitutional right to that level of privacy for certain use cases what those use cases are is you know that's contentious it was it Firearms is it drugs is it freedom of religion freedom of speech you know other scenarios. ✪
Orie Steele: That kind of area gets difficult but what Greg said is true unlink ability is really easy to destroy any time you present a stable core relatable identifiers to multiple parties you've created link ability so you need to be presenting something that is indistinguishable from Randomness kind of consistently except for the claim being you know over 18 from a trusted issue and and that's kind of hard to do. ✪
GregB: The web advertising business is very good at grabbing pieces separate pieces of information to fingerprint us and track US especially with third-party cookies going away so it's we're almost able to kind of look at that as a counterexample and say Hey you know do your cryptographic artifacts. ✪
GregB: The equivalent of unique identifiers and when you do a hash or something or you do regular signatures those things are very unique it's only through these Notions of zero knowledge proof switch sounds scary do we get some of these things where we can have this unlink ability and BBs supports that but once again. ✪
GregB: Got to use it right and that's why the more challenging part of me of this spec about BBS coming up is. ✪
GregB: Riding up the advice about how to preserve unlink ability and giving that advice to the issuer's and the holders you can. ✪
Orie Steele: Yeah I really like the thing that you said about tracking like I think you know we say selective disclosure and then we say redaction and kind of two sides of the same coin you can think of unlink ability and tracking is being two sides of a different coin. ✪
Orie Steele: And people don't like being tracked it's hard to get rid of some of that tracking infrastructure once it gets widely deployed another example of like you know harmful tracking you know besides just advertising in general would be the detected on wanting location trackers work at ietf where you know people who are fleeing domestic violence or having the sort of find my phone are tagged functionality turned against them. ✪
Orie Steele: To be property rights or to assert dominance and to do other harm tools tools have to be used carefully and when we build tools we have to be thoughtful about how they will be misused and the are tags that are find my phone you know find my find my hair tag Network thing I would never work off that that would have been used in the way that it is being used and it's. ✪
Orie Steele: The bag at this point at the same time if it's that technology becomes democratized and standardized and on linkable and still achieving its mission objectives gets even harder to defend against so you could be careful in trying to protect against tracking or trying to enable unlink ability you don't accidentally create a Unstoppable surveillance system that is non-observable where you can't. ✪
Harrison_Tang: Cool thanks for the clarification both Orion Greg one last question in regards to Performance is it a performance difference between using SD job versus data Integrity or is the performance implications mostly on what kind of cryptography your you use. ✪
Orie Steele: There's a performance difference at the application pre-processing layer so with SD job you have to walk the object tree and then you have to perform Hash A operations so we'll just all will call walking the object tree the application processing process of peace and we'll call the hash operations the cryptographic cost the total performance for SD jawed is all of the application processing cost. ✪
Orie Steele: Just the same thing is true for data Integrity the data Integrity algorithms are much more complicated than walking a Json object tree you have to convert at you know json-ld to application and quads you do that by applying the rdf data set canonicalization algorithm that's exponential in the input size in the worst case and vulnerable to maliciously crafted payloads that can make it take as long as possible intentionally that. ✪
Orie Steele: Pensive for data Integrity but what you get for it is commitment to the canonicalized information which is slightly different than commitment to serialize B now I would argue it's much safer to get committed to serialize B than it is to do the data Integrity application processing peace but I think you without a doubt you're paying a different application processing cost between these two you're paying a higher. ✪
Orie Steele: Processing cost for data Integrity because it's ensuring. ✪
Orie Steele: The information that's committed is consistent and then you're also paying a higher cost for data Integrity because you have per message signatures which are curved operations and elliptic curves and those are also expensive so in general both the application and cryptographic operations are more costly for the data Integrity approach and what you're getting for it is just a slightly higher confidence that the issuer's intention and rdf has been preserved. ✪
Orie Steele: All things being held equal and all issuer guidance being properly observed the verifier is going to learn the exact same thing from St John for way less computation so I mean my preference and you know in terms of performance here is probably very clear at this point but you know you can have different. ✪
Orie Steele: Verification side versus the issue inside and whether the performance trade-offs are worth it in those contexts when you're doing a very specific minimal disclosures so there are scenarios where you know if you if you graph it out a verify might learn the same information but the commitment to the issuance process would be higher for data Integrity but the verifiers process might be lower than SD job well I do. ✪
Orie Steele: Possibly that would happen if you really measure very very different input payloads very very different output disclosures and you compare the total cost of the application processing to the total cost of the cryptographic operations. ✪
Harrison_Tang: Thank you that's very very clear thanks a lot alright any last questions we're almost where we have one minute. ✪
<orie> thanks, by all
Harrison_Tang: Right thanks again Lori and thanks everyone for making great insightful comments I think this concludes today's CG meetings and know so there's there's a great great presentation clarify a lot of questions I have in regards to different selective disclosure and mechanisms and so just want to say a big thanks again. ✪