transcript.txt

Unknown Speaker  1:08  
Hey Brent, how are you doing? I'm good. I'm okay. I'm way too busy, but I'm clearing stuff off my plate for you like my plate keeps getting bigger?

Mike Lodder  1:26  
Well, yeah. I have started in Dave when he put the pairing based accumulator proposal he linked to my hack MD document. I'd appreciate a review from you even though it's still a work in progress. But it's basically the hack MD doc is the privacy preserving revocation proposal like a non creds 2.0 revocation proposal.

Brent Zundel  1:53  
So cool. That was some folks in the group were like, hey, these proposals are great, but I thought we're going to talk about BBs bus and replication. I'm like, I'm pretty sure there's revocation proposal in there.

Mike Lodder  2:09  
Yeah, that's that's where it is, I can put the link if people are interested.

Brent Zundel  2:14  
Well, we're going to talk about all of the proposals today. So when it comes up, just be sure to be like, this is the one that's about revocation. So people can

Mike Lodder  2:27  
write well, I'm still working on it. It's not done yet. But I'd say it's probably like 70% complete, like, the approach idea is there. It's just the description of it's not finished. That makes sense. Because I'm trying to make sure I cover all the negatives with existing approaches. And all the Oh gosh, I hate it when my Mac does that. And all the positives of this approach. So and there's negatives, of course, but every approach has a trade off. Has anybody else coming? Oh, there we go. We'll get a good enough group.

Tobias Looker  3:31  
Welcome, everyone to the weekly, bi weekly. crypto with crypto isn't great. We're just gonna wait a couple of minutes for open before we kick off.

Mike Lodder  3:46  
Tobias if you've been surfing lately,

Tobias Looker  3:50  
I have not it's winter here. So I tend to surf again for calamansi Well, water temperatures a little bit cold.

Mike Lodder  4:00  
Maybe this time of year surfing with the seals or the polar bears.

Tobias Looker  4:06  
Not quite that cold. So what is what is cold water temperature for New Zealand? Still about 10 degrees Celsius between sort of 10 and 15. And that's cool. Yeah, yeah. Yeah, that's a little chilly. Starting to drop a link and the working group channel. Okay. Hello. Can you go on dropped the agenda link into the call, chat today. So Can everyone record their attendees that their attendance that would be much appreciated. So welcome to the BI weekly applied crypto Working Group call. So today we have a we'll go through a little bit of agenda creation in a second. But we're going to start off with introductions and greetings. But before I do that reminder that this is an IPR protected call. If you have not reviewed the policy, please do so and sign in. If you haven't, please be aware that that policy applies around your contributions. And with that, out of the way, introductions and grading so is there anyone on the call that would like to introduce themselves or reintroduce themselves? Everyone's often pretty familiar on this call at the moment. Okay, so with that, we'll move on. I have a quick suggestion or a quick call for other items for the agenda. Other than the comprehensive list of proposals that have been created yesterday, is there anyone else that would like to discuss anything else in last week's call?

Jeremie Miller  6:35  
I don't have an item. But I do have a status update on paying, assigning the IPR, our legal team found a error in it. And that's going back through the TSC to get corrected. So as soon as that's corrected, we'll we'll get signed and be able to submit a proposal then. Probably in two weeks.

Tobias Looker  7:01  
Thanks. Thanks, Jeremy. Is is the is that the extra point? That bullet number seven that was pointed out this week? Yes, that is. Okay. Great. That sounds like it will be addressed soon. So thanks for the update. Appreciate it. Okay,

Dave Huesby  7:24  
well, I'll put the link to the agenda in the slack, because I shut up just two seconds too late to get in chat

Tobias Looker  7:31  
on zoom. Yeah, no worries. Thanks, Brian. Okay, so with that, I believe we will go through some of the some of the proposals that you have put on the table. So I will just, obviously, we'll go in chronological work, or considering you race or these proposals, is there a order you would prefer to go through or just um,

Dave Huesby  8:13  
we don't have to review them all today. The ones that I that? There's one I didn't propose that I wish we had. So we could talk about today, but we'll get it next time. But adding the language around the standards track work items, that's the very first one. That is probably the most relevant. And then we can take them in order. The ones that have gotten the most traction with people are like the policy of code language proposal. And there's also the pairing based accumulator proposal. That's that's the thing, that trust frame now cryptid ID, we're open sourcing, that's the thing, we filed a provisional patent on that we're going to not pursue and totally open source who want to talk about that. All the other ones I you know, whatever we can do them in order doesn't matter. This is our entire stack. This is our entire alternative approach to decentralized, you know, like authentic data, and it's all applied cryptography. At least what's here is Anyway, there's nothing extraneous. So let's start with the adding language around standards, standards track work items, because that was a task I took from last meeting.

Tobias Looker  9:33  
Okay, so I've just dropped that pull request into the chat. Are there any questions, thoughts or suggestions on the changes that have been proposed? Do you want to do you want to maybe for those that maybe didn't attend last week's call, just reiterating what their action was and what you've done?

Dave Huesby  9:53  
Sure. So the discussion last week was around the potential for This working group to become a launching pad for proposed standards to external standards bodies such as the IETF. And that got broad based support, specifically from Mike Jones from Microsoft, he was heavily involved in the IETF. And so I took on the the job of updating the work item template that you originally proposed, Tobias that was accepted last time to add some, like a section on identifying the external standards body that that work item, you know, is hoping to create a standards for, and I just put it in language in there. And also that just says, look, you know, if that's the goal of this work item, it doesn't have to be in here for acceptance of the work item, but we just want to document it. That that is the intention at some point. Because we might have work items that don't start this way and become like, oh, maybe we should standardize this. But then it's really just was to serve a lot of this, these other work items that I think are pieces that should be standardized, and I have reasons for each one of them. So that's it. I like Brent's suggestions, I'm willing to take them as as is I have no pushback on his suggested language.

Tobias Looker  11:30  
Okay, great. So it's essentially essentially what you're doing in this pull request is adding a section called external, external partner. Yeah. And specifying the intent of the work item. Correct. Are there any other questions about this? template change?

Okay.

Well seen as we discussed this process change, and it is really just about providing clarity around a work items intent. Unless there are any object and directions, we can wait for sufficient approvals and merge. I assume, Dave, that this piece is probably blocks the other ps?

Brent Zundel  12:30  
Yeah, it does. Right. I think it would be appropriate for folks to approve it

on the call. And for us to merge it now. If, if people are willing to jump in and do that as soon as Dave accepts my changes, I'll do the same thing.

Dave Huesby  12:50  
Just did. Awesome.

Brent Zundel  12:58  
It's nice to have the little green checkmarks for folks who approve it before we merge.

Tobias Looker  13:04  
Okay, well, I've approved it as well. So I'm going to merge that now.

Unless there are any objections? Okay, well, we can always it's that's the aim of a process, we can always revise it again. Thank you. Okay, so

Dave Huesby  13:24  
why don't we just go with the first one. Let's just work work through. Number six. So adding data encoding proposal. So if you go to the files change, and you view the rich diff, or not the rich diff, whatever. So this is related to something that's come up recently, in the sense that there's a whole bunch of software that's now going to be relying on cryptography. Now that we're securing the supply chain, the software supply chain that were, you know, securing the provenance of any arbitrary data, right. So any tool that processes data will rely on some cryptographic metadata, if you will, like data associated with the data it's processing. And so there's this idea that there are software software that consumes cryptographic services, and there is software that provides cryptographic services. And part of this is that the ones that consume the services need to receive cryptographic data and store it verbatim, such that they can then pass it at a later time back to a cryptographic service for further processing. So if a piece of data is digitally signed, the software has the data and it also then receives a digital signature. And then later when it works wants to verify the digital signature over the data, it passes the data and that digital signature back to the cryptographic service. And so what this does is formalizes a standard way of storing cryptographic data of all types in a way that's both binary can be binary or text based. So that the cryptographic data is self describing. And this is a proposal to do a an abstract data model for, you know, the self describing tag, and then the payload. And then encoding, like the framing, as well as adopting the multi codec de facto standard, as the list of types of, of cryptographic data, and also the multi codec governance model, or at least something similar to that, for maintenance of the list. And formatting all of this as an IETF standard proposal with a reference implementation. This goes beyond the existing JW k JW. T standards, to include all classes of cryptographic data. So it's not just keys. It's also things like nonces, digital signatures, encrypted data, like the lists, races here, ad constructs, pseudo random number generator, state, smart contracts, h max digests, they all are self describing in the sense that they identify the cryptographic protocol. You know, algorithms use formats, use whatever, such that the software that consumes cryptographic services, knows they can look at it and know what service would consume it. So it would be like, Hey, I'm a digital signature. That's an RSA signature. And I was created by open PGP. So if you want to verify it, you know which tool to run, for instance. And the idea here is that tools that consume services would have some configuration or command line switches that would identify what external tools map to what types of cryptographic data so that it would know how to talk to it. And this goes hand in hand with the next one, which is a protocol proposal for a standard protocol for talking to external services. Now, these came out of work to try to make get able to use other digital signing tools, like open SSH, or open SSL Phyto, tokens, things like that. And so we need like a formalized way to store digital signatures inside get objects that are self describing, so they get knows what tool to run on the outside instead of just PGP. And then the protocol, which is the next one, just specifies how Git would talk to that external service. And it turns out, it would be useful for all manner of, of tools now because it could be a database that is accepting digitally signed SQL queries or things like that. Right. So it was just formalizing the idea that there's a separation of concerns between consumers and providers of cryptographic services.

Tobias Looker  18:28  
Thanks, Dave. So and the process of describing that you kind of touched on seven, is that correct? Which is the protocol? Correct? Yep. Yeah,

Dave Huesby  18:39  
they're hand in hand, these two are hand in hand. And I'm really looking for anybody who's interested to be an owner, obviously, we need to have multiple owners to accept a work item. And, you know, it's totally okay, if, if this working group doesn't think this is, you know, appropriate for this setting. But I believe this to be applied cryptography.

There's tremendous use in this right. IETF just accepted a draft proposal for a trusted execution environment provisioning protocol. You know, the Tor project uses a control protocol. All of these, you know, this idea that there's a protocol that connects pieces together and then their standard self describing storage. That's that those two combined becomes the generalized solution for all software, right. GPG uses a protocol called the ASTM one protocol, and they have their own format for storing their signatures. And the Tor project has their own protocol, and their own way of storing keys and, you know, encrypted payloads. You know, obviously, email does as well. But this is a chance to try to settle on a standard we can put into git, which would adopt how many, you know, millions of users immediately. And drive this into all the software that we're all now, like at the decentralized identity foundation. We're all changing, you know, login systems and file systems and messaging systems and all that stuff. I don't think they should be doing cryptography directly. We should be doing cryptography close to where the key material is. And that's what these two proposals are like laying the groundwork for.

Tobias Looker  20:26  
That's all I have to say. I'll shut up. Sorry. Thanks. So does anyone have any questions with that long proposal, Section seven.

Brent Zundel  20:42  
I am wondering if there are folks in the group who may be interested in CO sponsoring the work item, because we need to at least two people from independent companies to adopt the work items.

Dave Huesby  20:59  
I had some initial support, not to call him out. But like, I know that Orie likes the idea of multi codec. And I was kind of hoping that he'd throw his name on here as a workout owner. Because this would apply to both the W three C, stuff for dids. And VCs, I mean, they could adopt this standard and be, you know, store all their key material, encrypted data, whatever. Using this format, it's basically standardizing multi codec is really what this is. Maybe I have work ahead of me of trying to find co owners, I understand that this may go, this may be true for all of these workouts. So we can always just table it for now to the cryptid, you know, trust free encrypted technologies, we intend to open source implementations of these and published white papers, regardless whether these are work items here or not, we just wanted to formalize the relationship with with the diff. And I'm hoping that other people would jump in on these so that we can consider other use cases, because I don't want to be driving these myself. We did a bunch of research. And we've done a lot of tests. But I'm hoping that other people would see these as useful and, and have other use cases so that we can move these ideas in a direction that is more general, and more deserving of standardization. But if not, I mean, not i guess i o part, I'm,

Brent Zundel  22:37  
I think it's useful. And I think, for me, I I need a little bit more clarity on what co ownership means. I'm a I, myself am unaffiliated and independent. And, and so I'm not sure whether like my co ownership, for example, the exactly meaningful, especially since I'm not necessarily committed, huge number of hours to this at this point.

Tobias Looker  23:10  
Steve, on that, on that question, I just linked the we have in the template, work on leadership responsibilities. And, yeah, that's basically, most most of the work item is designed to be stuff governed by the world kind of moments. But in order to provide visibility around the work item, to a greater kind of different organization is a couple of, you know, being able to provide visibility on how that work balance tracking. Yeah, sure that.

Dave Huesby  23:49  
And you'll notice that in each of these proposals, I just say, the bottom that the implementer updates are going to are presented at the regular applied crypto working group meetings, that meets the requirements, I think the first three bullet points of a work item owner, so we just give updates. And then the last one, it's kind of on us to work with that external like so in this case, the IETF to identify the external partner, like who's going to sponsor this work over at the IETF when it does transition over. This is pretty light lift. And we're gonna spike be sponsoring the development of this code. So like, I wanted to be more general. I wanted to inquire incorporate feedback from everybody in this group. But if not, I mean, we're still going to publish the code.

Steve Todd  24:50  
Well, you can put my name down. For that, I guess a an effort that I'm looking to ask So

Dave Huesby  25:03  
great, Steve, thank you. What's your what's your GitHub? I'll modify this after the meeting we can talk about in two weeks and approve these. Oh, yes. doesn't have to happen right now. I was put in the chat. Thanks. For both of these, Steve or just the encoding.

Steve Todd  25:31  
Both of them are interesting to me. And I think for valuable, so yeah, I can thank you both.

Tobias Looker  25:38  
Thank you. Okay, so that's the takes care of reviewing six and seven. Did you want to give a brief overview of

Dave Huesby  25:55  
eight I? Sure. I really am apologize, I apologize that I just slammed through all the these.

But so this one, I can just do 810 and 11. They're all related, actually, so is 12. So the first one here, we'll just start with a this proposal is for writing an IETF standards draft that establishes an abstract data model, and an encoding and file format for binary text versions of what we call provenance logs, provenance logs, or hash link data structures that track key state. So you can think of this as almost like a dead document over time. So each version of the document would be an event in a provenance log with hash linking and digital signatures securing that. But the way we have been using these in industry or in products is that they can also contain a smart contract for validating the next event and the provenance log. They also contain what we call anchoring receipts, which are proofs that the provenance log, and that specifically, that event, has been stored in some external trust anchor. So it's been included in an accumulator that has been recorded in a Bitcoin transaction, or it's in a SQL database or whatever, right. So whatever your trust anchor is, the provenance log contains a proof that says, you know, the proof of existence of this log. And the proof of completeness of this log is stored in that system. We use these for tracking key rotations, we do future key commitments, so that controllers have a provenance log can force rotate to a future key and restore control over a compromised provenance log. With the smart contracts, or the policy has code in them, we can do the payplug protocol. So this can allow us to create basically NF T's without a cryptocurrency. And we can tie it to external crypto currency payments. So I could use a provenance log to track the fact that I assert ownership over say, a photograph, and then I can offer it for sale. And I can transfer control over the provenance log securely, in exchange for, say, a Bitcoin payment or something. We intend to use these to track the provenance of all data, all data, it's not just key rotations. But it's, you know, anything in the in the use cases for these is, you know, we have a number of products that we're developing, but the use cases that are obvious are like automating compliance with regulation with privacy regulation, or with financial regulation, because these create cryptographically secure logs of a series of events over time. And so the reason I said these are related to well, eight, 910 11 and 12. A provenance log contains a series of events. Then, from a provenance log, you can calculate an identifier that's number 10. Which that is a proposal to create a URL in the universal resource name. From a provenance log they provide that's a self certifying identifier that provides end to end integrity. It's an integrity check, right? And provenance logs are added into pairing based accumulators which is proposal number nine. Which is also a proposal to create a white paper, documenting it at a reference implementation. I don't know that I've said that this should be a standard or not. I don't think so. Oh, maybe. Yeah, teach everybody the math for constructing pairing base accumulators in their application and decentralized crypto systems, technical white paper describing the technique, and one or more reference implementations. So this, these are scale invariant, meaning you can you can add any amount of data to an accumulator. And the accumulator value is only, I think we've got it down to 32 bytes now, and proofs of set inclusion and set inclusion are only on the order of a couple 100 bytes. And this is how, like, if you were to store accumulators in Bitcoin, we can do off chain Bitcoin transactions. And effectively make bitcoins transaction rate infinite.

But this is important because we can track any piece of data with a provenance log, then anchor them in an accumulator, and store that accumulator in say, Bitcoin or in a database or whatever, wherever trust anchor you need that spans your trust domains. Okay. And so then from if you need to be able to give somebody a look a URL to a prominent slug, that's number 11, which is a method for turning an identifier into a URL. So turning the URL into a URL in a cryptographically, secure way, it's basically taking the URL and putting it resolvable, you know, like HTTPS, colon slash slash, you know, google.com, slash and then the URL. And then as the parameter part of the query part at the end, so question mark, on the end is a BLS signature generated using the current public key. It's active in the provenance log itself. So you creates a cryptographically, secure closed loop. So if you're given a URL, you resolve to a, a, like a provenance log, you can look at the key that's active in the provenance log to check the signature on the URL, you can check, you can calculate a URL from the provenance log to check against the identifier in the URL, then you can look at the anchoring receipts in the provenance log to identify where they the accumulator values have been stored. And you can go get those accumulator values and check for set inclusion and exclusion, which gives you the ability to do proof of existence at a specific time, and proof of completeness through exhaustive set exclusion checks. So it's, it's a linear, if you need proof of completeness. It's it's an order. And if you only need to do proof of existence, that's order one. But this allows us to then basically assert authentic data. Data exists at this point, I assert, I'm the owner. And I can transfer control over the provenance log, which effectively transfers ownership, we can rotate keys to maintain control over the rights held over the associated data. So that's it. That's proposal, eight, 910 11 and 12. The anchoring protocol is basically how you talk to a completely stateless registrar is what we're calling him, or endorser, I guess. endorsers are completely stateless. It's just a it's just a convenience function to standardize how like, Hey, I have got this entered identifier from this provenance log, and we need to store it in an accumulator, and have that accumulator be stored in a trust anchor, like an external blockchain or something. And we need a anchoring receipt. So that protocol, standardization is proposal number 12. And like I said, whether this is adopted as a work item here or not, my company is sponsoring the development of the code, we're going to publish it all open source, we're gonna write the white papers, we're going to hand it all out all under IPR here in this group, or at the diff in general. I just, I would like to get feedback from other groups. And maybe this isn't the right venue, but I'd be happy to meet with anybody and walk you through all of the different use cases. Paying use cases, by the way, we're getting paid to implement all these things, and we have a number of products coming to market that we're able to make money on. So that's those 12 I don't think we should go through and ask for ownership. At this point, you can contact me like over the slack or whatever. And I'll add you if you're interested in it.

Is that okay, Tobias? I don't think we need to go through all these things. Thanks, Dave. So

Tobias Looker  35:15  
I would, I would suggest maybe to also raise, maybe raise a link to them in the working group slack as well to promote visibility of them so that people that may be are a part of that channel, but in monitoring the call today, couldn't see it. Are there any questions for Dave?

Jeremie Miller  35:35  
Yes, I did have one. And you've mentioned a little bit in the slack. I only what I know about carry I learned around the last II W. And I know that you were trying to work with them on these things. Could you just explain kind of the difference or how how this is now became separated again. Because this is sounds like the same pitch that I heard around carry a while ago.

Dave Huesby  36:05  
Right. So I did meet with Sam and I did meet with Adrian and we agreed on some terminology. And I did join the Kerry Working Group when we tried to work together, you know, I here in Utah had lunch with Sam in person, we really tried to, to, to Mercy's, and what came became obvious was that what we're talking about, is actually a subset of carry. And so I was pushing hard to try to extract out like the common pieces, and make them into work items, either here or in the carry working group that we could standardize the IETF. That effort was somewhat fruitless. I don't want to point any fingers, but like, the impression I got from the carry working group is that carry is a monolithic thing. And there is some effort to try to pull out some of the common pieces. But they're like, for instance, their Caesar encoding system is very carry specific, they're going to try to pull that out and make a standard. But Caesar would never be adopted by the Git community, for instance. But something like what I'm offering here in number six, wood. And the reason is, is that carry like the Caesar standard has a bunch of things in it that are very, very specific, like the notion of a witness and notion of lists of witnesses, those are like first order types in their in their encoding system. And that's not generic that's actually specific to carry. The the way a provenance log is, is constructed in carry is much more complicated, and has a lot of things that are related to the way the carry decentralized network is going to happen. And like wait, hold, carry its functions. And what I'm trying to do is to show that there is a way to do provenance logs that does not require central coordination does not require a network, like I can create a provenance log locally over any file I own without any central coordination. And then I can talk to any anchoring service, I can even run my own. And it can anchor in any anchoring. Trust anchor, so I could be in Bitcoin, I could be in Ethereum, I could be in the local database file, like a sequel lite file, it doesn't matter, it just that anchor just needs to span the trust domains in which the authentic data needs to be trusted. And, you know, the locators and identifiers, those can all be local, they can be global, it doesn't matter. Like the point here is that this is like what I call fully decentralized, which means that there are no requirements of Central coordination. And carry is more going in the direction of we're going to build a route of trust. And people can run their own query networks, as I understand it. But it sort of has its own flavor. You know, it's almost like what was coming out of hyper ledger where it was like, Oh, that's easy. Just run your own indie instance. Right, that becomes the central coordinator. And then you have to use all of these, you know, VC standards, everything to talk to indie, right? That's not a bad thing. It just it dictates the use and and actually affects the standards involved. Whereas this is just a pure notion of tracking the provenance or the history of data, using cryptography to secure it. And it with regards to the locator identifier and anchoring stuff, that's a completely decentralized maximum Is all of the options to a Deployer or user of this system, it does not prescribe any back end. Use of it, it's kind of like the SMTP protocol, right. And the way we identify emails and and the, you know, the URL standard for identifying an email and an email server, right, it's like, we don't care what email service you use, as long as it talks SMTP, we don't care, you know, where you put your email, as long as you use this URL format, when you want to refer to an email, you know, in a web in a internet setting. This is supposed to be sort of a pure core proposal for the idea of a provenance log. That doesn't prescribe any use case, like any parameters to the use of them. It's as simple as I can make these. Hopefully, that explains it.

Tobias Looker  41:07  
And let's get some contacts. Thank you. there any other questions or comments for Dave's proposals?

Brent Zundel  41:22  
As I said, they, I mean, they sound interesting, they sound in line for what we want this group to do. I, I, I'm not interpreting silence as disinterest I'm interpreting silence as the beginning of digestion. Yeah. And so I, I, I fully expect that a number of these will have co owners soon enough. It may simplify things if like a work item, like one work item doesn't have to, like one document doesn't have to be one work item, you could have one work item that kind of houses several of these if you wanted to organize them that way. That way, a work item owner can be like, yeah, I'm gonna work on these three draft specs.

Dave Huesby  42:13  
Right? So are you suggesting like I collapse all the provenance blog and related things into one work item?

Brent Zundel  42:21  
I'm offering that suggestion that may be a way to go? Yeah, somebody might be like, Oh, I don't want to sign on for five things. But if it's just one thing that has five, like, yeah, deliverables that might ease people's minds a bit. And but I, that's just an idea.

Dave Huesby  42:39  
I'm all for it. I think that if they're all collapsed in one than it would have broader appeal. And we might have, you know, four or five owners, even if they're only interested in a small piece of it, I'd be cool. Let's just let it go like it is now. And if there's not any interest in certain pieces, then I'll just collapse them. And we'll just end with the consent of everybody else to see if we all just want to take ownership of like the provenance log piece.

Mike Lodder  43:09  
Just a quick question. So the pairing based accumulator one, are you intending for that to also be the revocation that goes with BBs plus, or should that be separate item?

Dave Huesby  43:21  
Oh, I hadn't thought of that. I was not gonna I yes. I mean, actually, I hadn't even considered that. Well, okay. So then let's just all submitted the work item for that. That'd be great. And maybe those two go together hand in hand. Sure.

Tobias Looker  43:39  
So I, if we, if they were different work out of the puzzles could sum up because obviously, Could someone maybe clarify the boundary here, because obviously, an accumulator is essentially just the basis for a sitting on the set. You know, revocation started out with inclusion in a member state or, you know, proving you're not included in a seat. So are you saying my that the demarcation would be there? It obviously doesn't include how you prove that value is signed over and and maybe a signature? That would be what the separate work items form?

Mike Lodder  44:19  
Yeah, yeah. Because accumulators can be used for more than just BBs plus, like access control lists, or, you know, anything that requires a set membership test. So I'm thinking the pairing based accumulator approach is maybe should be a little more generalized and just say, if you're going to use accumulators, here's what you do with them. If you're going to do a proof with them, here's how it works at a general sense. And then if you're combining it at, say, for revocation purposes, or some with some other scheme, then maybe that's what this other approach that I'm proposing is.

Dave Huesby  44:57  
Well, proposed some changes, this might Can or a new work item? Because I did put in here under the deliverables, a technical white paper describing the technique and its related applications. Okay.

Mike Lodder  45:10  
I know I saw the link to my hack MB document, which is growing as I finish out the right, but I call it non creds. 2.0 revocation. Right.

Tobias Looker  45:25  
So yeah, so obviously, we have the we have the draft document via signature as well that I'll propose, keep it work item. So this would be another work item or another document that would exist between these two witches, witches and associate that to an accumulator?

Dave Huesby  45:44  
Yep, that'd be awesome. I'd jump on and ownership for that. Can we skip the policy is code language and go on to the next the last 214 and 15. Because those are both really exciting. Policy code as code language, we already have two owners sport and it's just the idea is to try to standardize a smart contract language that is specifically non Turing complete. And its associated like virtual machine, which is like the environment in which the scripts are executed. Wayne over at spruce said they're very interested in wanting to take an ownership role over that, as well. And our interest in this is really, this is what we put in the provenance logs to validate future events and allow us to do like deep regulation compliance, because we can, you know, let's say there's a regulation check on something, you know, like for a financial transaction, there's a whole number of external parties that get contacted to do checks of various things. And one of our proposals, or one of their use cases we have is that if we have a standard policy as code language, those checks results come back with not only the result, but the policy is code language, like the script that was run, and could potentially also have the data it was run against, along with the authenticity, proof. And so this comes about because even in decentralized identity, we need some standardization around what a credential looks like, not just the abstract data model of a credential, but like literally like what is in a digital identity, like what is in a digital driver's license, what is in a digital diploma, what's in a digital birth certificate? And then on top of that, there needs to be standards around what constitutes a valid excuse me, um, what constitutes a valid age check against a digital driver's license, or what constitutes a valid proof of dis being deceased against the death certificate, those kinds of things. Also, there's some interest in standardizing those. And those checks would have to be encoded in some way. And that's what this means, right? If we had a standard policy as code language that was abstract, and was easily integratable into systems, then this would be sort of the standard language that everybody uses, right, instead of inviting inventing yet another one, this could be sort of like the JavaScript of, you know, for lack of a better comparison, you know, the JavaScript of smart contracts. So there's already interested in that one, but the last two are the ones I want to talk about most. Number 14 is is to take a technique that was written about by Elizabeth and Anna, on doing delegable anonymous credentials, this allows anonymity. And it may not even be their approach. There's several approaches to this. But providing anonymity for both the issuer of a delegated credential as well as the holder. That's what this one is about. And then the 15 is a technique that Mike pioneered for. This one actually is my favorite out of this whole list. This is a new technique for doing non interactive authorization or non interactive, yeah, authorization protocols. It allows an issuer allows an issuer to issue an access token, a capability token, and then it allows the holder of that token to provide proof of possession of a valid token without revealing the token. So this allows for use cases where a service provider can get paid and can enroll a customer, but then they cannot track the customer's use of their services. So this makes sense in very privacy sensitive environments, which is basically everything now, you know, like, if I provide an email service, and they and the client needs to authenticate against my email service, they could use this technique. So that I, as the service provider could legitimately say, I cannot track my customers use, I cannot correlate, you know, connections to my service to my known customers. Right. It's very, very handy, because it allows for a lot of really cool things. Mike, I don't know if you want to add stuff on to this.

Mike Lodder  50:34  
Like, oh, you can talk in Oberon? Yeah, yeah. I mean, the whole point of it is that the issuer? Well, whoever signs the token, and verifying the token can be completely separate parties. And the verifiers can be anyone, all they need is a single public key, regardless of the number of tokens that have been issued. The reason this is better than just simple ecdsa signatures is that the sorry, the token is not revealed. As Dave said, it's a z Kp instead. And it's very, very, very small, like we're talking 96 bytes. So the token also allows you to do multi factor authentication without having to tie in my email that gets sent or text messages authenticators. You can build in biometrics, if you want. But the it's incredibly simple to add in multi factor. If you want this.

Dave Huesby  51:32  
Yeah, this also eliminates the traditional API token for, you know, for non interactive authentication protocols. So like hitting API endpoints, for instance. And so therefore, that eliminates all of the headache of managing API tokens, like making sure they don't get checked into Git repos, and making sure that they don't leak,

you know, all that stuff. So Mike, I have a quick question on this, because

Tobias Looker  52:02  
one of the kind of use cases that has been kind of spoken about previously with, say, BBS signatures, which is a group signature, what would the functions be beyond kind of more of a standard sort of short, short group signature in this context, right. So if I issued a BBs signature in the form of an access token, to a client, through any form of awesome delegated authorization protocols, such as you know, OAuth 2.0. And then rather than presenting that access token directly, when I make a REST, you know, call to a resource server that's protected by that authorization authority. I, you know, my token that I've got is a BBs signature style token. So I derive a proof each time with a nonce, right? So that protects me from being correlated. But equally, if that resource server can validate a BBs signature, they can validate authorization without uniquely fingerprinting me, What the What's the difference between, say, using a general purpose, group signature or short group signature like that, and oberon.

Mike Lodder  53:13  
The first is, this is much smaller to Oberon allows you to do threshold signing, whereas BBs plus doesn't without a very complicated protocol. So whoever signing wouldn't be able to do those. Number three, the blinding the, you know how I was talking about the multi factors. You could not do the same multi factor techniques that I propose with Oberon that you can do with BBs plus it's it's but it is a short group signature, it's just much smaller, it's only 48 bytes versus BBs plus, which is 112 bytes. So the proof size is significantly smaller. And it's a lot faster to compute it. But it does function very similar to be this plus signature. So I mean, you could use BBs plus signature in a similar way. But like I said, you lose the ability to do the multi factor approach that I'm suggesting you don't get threshold signing. And it's it is quite a bit bigger. So I was designing this more for API's where you may not want to do a BBs post signature because it's expensive and time consuming. And when I say expensive, like you're going from like maybe five milliseconds, whereas with O'Brian you're down to one millisecond, so it's slightly faster.

Dave Huesby  54:42  
What other data do you need to cite? What data do you need to verify and Oberon are a proof of token on for Oberon versus the BBs plus signature?

Mike Lodder  54:51  
They're similar. You just need the well, you need to you just need the proof and the public key. That's it for both

Tobias Looker  55:01  
Yeah, I just I just wanted to call this x. I do think there are some really interesting use cases here. Right. So, you know, in our normally with resource servers, and the way that protocols like delegated authorization like ours was conventional jadibooti tokens, the resource server is able to uniquely fund fingerprint the client making the request across multiple requests. This fixes that group signatures in general, whether it be or on or even just baby a signatures, offer, you know, novel capabilities to still prove your authorized, but remove that vector of correlation for the client. One other thing that I think is really important to call out here is what the group's signature, you also mitigate the without having any form of cryptographic binding to the client, such as requiring a public key key pair to be produced by the client and having the public key included in the signature or the token that's issued, you still have what I would call some form of men in the middle protection, even if that is not done, right, because the thing that goes over the wire is a proof rather than the actual token itself. So an OAuth two, if someone catches your access token, you're essentially unless you're using D pop your host, they have your That's correct. Whereas with BBs signatures, or any group signatures because you're deriving a proof and providing a non, essentially a random nonce, and you're not actually revealing the underlying signature, and that attack is mitigated. So I think this is a really talking about the attack on the issuance.

Mike Lodder  56:48  
Not always talking about attack on presentation

Dave Huesby  56:51  
club into an Oberon. You're not you're not presenting the token? Or you're saying that say, Yeah, you're saying that's true for both? Yeah,

Tobias Looker  56:57  
yeah, I'm saying that that's an important attack, that's mitigated, right, because most, most ways in which you prove mitigate a man in the middle style attack with OAuth against spirit tokens as you require something like deep hop, which requires the client to generate a key pair on request to the authorization server when it gets the token. And then it requires that, you know, proof of possession to be demonstrated. Whereas with this style, you don't you're not actually complicating that request for authorization more, you're still just getting a token. That's just when you go to use that token, you don't present the token directly, you perform a little cryptographic come in, and then you put the result of that proof in an HTTP here, which I think is quite elegant. And yeah, those two properties there, I think, are quite valuable and, and these authorization systems, so looking forward to discussing the more

Mike Lodder  58:00  
Yeah, well, so one thing I like I was saying with those blinding the multi factors, there's with Oberon is that you can store the token without using any form of encryption. And it'll still be protected. And even when you're generating the proof, the token is never revealed. And so it's side channel resistant. So anybody listening and memory for the token would still not get the whole thing. Right, versus BBs plus, which you can't do that with. So like I said, there's some little benefits to it. But I mean, if you want to use BB plus plus in a similar method, you could. Oberon, I think, is just much more simple for like if you're doing authorization tokens versus like authentication, which I think is better done with PBS plus.

Dave Huesby  58:51  
I'm really excited to combine these two together because if you use the Oh the Oberon technique with an Elizabeth delegated bone nonnamous credentials technique, you can get mutual anonymity between the issuer in the holder and the resulting like the resulting token plus the issuance of the token, I think is smaller than a BBs plus signature. So is this smaller? Yes, yeah. When you have that, because the payload of the Delta, the anonymous delegated credential is the Oberon token, right. And so you can have mutual anonymity between a service provider and the service user, which is quite interesting, especially if the enrollment process to a service is based on z. kp. So like, I don't know, I can prove to you that I'm a voter in Nevada, that I'm a registered voter in Nevada without revealing which one I am. And then the operator of the voting service issues me token as a delegated well, anonymous credential that allows me to cast my vote. It's been we're totally mutually anon So that means the issuer of that credential has no idea who I am, other than I'm a registered voter in the state of Nevada. And when I cast my vote, I don't reveal my tokens so nobody can impersonate me. Nobody can match the middle of me. And I can cast a cryptographically secure vote. I think it's critical for systems like that where maximum privacy is, is required, like mesh messaging platforms, for instance, would use this. Any kind of thing like can you imagine Twitter uses? Incredible.

Tobias Looker  1:00:39  
So considering we've got one minute to the top of the hour, does anyone have any closing thoughts or questions?

Dave Huesby  1:00:48  
Well, I'm the owner and all of these, so I'll be in the slack. Take my responsibility seriously. So if you have any questions, find me there. Email me, whatever. I would appreciate people taking ownership over these and any feedback. And thanks for listening today.

Tobias Looker  1:01:06  
All right, what's that then? Thanks, Dave, for leading the conversation, and thanks to the volume of proposals that you've put forward. We will see you in chat otherwise, and talk to everybody in two weeks time on the next Working Group call. Thank you.