Meeting minutes
Meeting Logistics
Wesley_Smith: Good morning to you, Good afternoon to you, Phil Archer. Let's give folks a couple minutes to trickle in here before we get started.
Phil_Archer: Good morning, I've just got a very quick question for Greg. are you east coast or somewhere else, Greg? Sorry.
Wesley_Smith: Greg, you are muted.
Greg_Bernstein: getting off od. Sorry, I had a query from Europe right now. I'm on the West Coast,…
Phil_Archer: Okay.
TPACT Scheduling
Greg_Bernstein: California.
Phil_Archer: So, yeah,…
Greg_Bernstein: So yes, that's…
Phil_Archer: the reason I'm asking this is…
Greg_Bernstein: why we'll do it…
Phil_Archer: because I'm just setting up the agenda for TPACT so the best I can do for you in terms of scheduling this topic for TAC is to make it as late as I can on the Friday, which is still not late because it's at 9:30 Eastern. but it's the latest I can do. Okay, thank you. Yeah.
Greg_Bernstein: if I'm needed. I will be there. That's a once in whatever thing. That's like the IETF meetings. Last where was it? It was in Europe someplace. It was like something in the morning.
Greg_Bernstein: This coming one in November is San Francisco.
Phil_Archer: So, how's that old putting your feet up and retiring thing going then with all these meetings in the middle of the night?
Greg_Bernstein: Yes. My retired thing.
Phil_Archer: Yeah. …
Greg_Bernstein: Yes. Okay.
Phil_Archer: that's what I done. So, the last topic we're going to talk about in the whole two-day meeting day and a half is this one. Barcodes and DI as late as I can make it so that you could join without being horrendously early. Thank you. I'm not sure.
Greg_Bernstein: For remoting in, I wasn't sure if there's fees or things like that or does that not apply to remoting or…
Phil_Archer: I Right.
Greg_Bernstein: invited experts. I can't remember what happened at what we did because I attended in person and the one in Anaheim.
Greg_Bernstein: I can't remember what happened there.
Phil_Archer: It says standard rate for remote participation is 100 USD.
Greg_Bernstein: Okay, that's not a big deal.
Phil_Archer: That's it.
Greg_Bernstein: Okay, we'll work it out.
Phil_Archer: Okay, thank all the details and I will stop talking a minute, Wes, and taking over your meeting. I apologize.
Wesley_Smith: You're the chair.
Wesley_Smith: This is your meeting.
Phil_Archer: No, no, no, no, no. It's your meeting, not mine. I'm just here listening in. There's the link there, for all the details. Okay. Thank you.
Phil_Archer: Thank you, Wes. Thanks,
Wesley_Smith: You are most welcome.
General Meeting Announcements
Wesley_Smith: Okay. We have a good number of people, so I think we're good to go ahead and get started. Welcome folks to the October 5th, 2026 meeting of this task force with a very long name. we have much the same agenda today as announcements, introduction, process items. I want to talk briefly about the upcoming W3C press release that the BC working group at large has been working on and…
Greg_Bernstein: Thank you.
Wesley_Smith: that we're working with the W3C comm's team on and then other than that we will go through the other specification or the specifications under our view as needed to do poll request review and issue processing. Does anybody have any announcement, introduction or process items for the group today? Okay, I'll note that Ivon is not here. I know that he had slated to press the buttons for various draft note publications for threat models. I don't know if that has happened. Does anybody know the status of those things as it relates to this task force?
Wesley_Smith: Specifically, for example, the BC barcodes threat model,…
Phil_Archer: I do not.
Phil_Archer: Can we have a look on the cano and see?
Wesley_Smith: right? I had prepped that and presumably I am the person who should know the answer to that question, but that's not a huge issue. It's not blocked anything for us. Just curious if that has happened or not. Either way, I think in this group we are in a good spot with respect to the Anthony, do you want to give a brief update on the data integrity threat model where you're at with that? If you need any help,…
Greg_Bernstein: We're double muted there.
Wesley_Smith: you may be muted, Anthony, if you're talking. still no audio from you,…
Wesley_Smith: Anthony. no worries. We can circle back. there you are. That sounds great.
Antony_Mott: How about that?
Antony_Mott: Sorry about that. I think Greg's right.
Wesley_Smith: No problem.
Antony_Mott: Double muted. yes. not a huge progress except we did do with great help from Ivan and Manu. We did get not the barcodes one of course the one that I was helping those two with and I believe it's published and errorfree and going great and even though they're not on the call I want to say how nice it was to work with them and super fun. Ivan did point out that perhaps you already know this of course because're caring you're coordinating this meeting but it's going to become a lot easier.
Greg_Bernstein: Yeah,
Antony_Mott: So some of the tedious work I think is going away…
Antony_Mott: but I really appreciate working with the team on something like that and I think we got it out two days ahead of time.
Wesley_Smith: Wonderful.
Wesley_Smith: Thank you so much, Thanks for the update and thank you for the hard work there. Agreed. Ivon and Manu are both wonderful people to work with. and it sounds like the generalization of…
Wesley_Smith: what you're running into is that the tooling relating to all of these specs and process and everything is very much dynamic and alive. And we often work …
Antony_Mott: Yeah, I mean…
Antony_Mott: if Sorry, I didn't at all mean to cut you off. I thought you finished.
Wesley_Smith: no worries. I was just saying it evolves and grows as we work on these specifications. The tooling grows with it. So,
Antony_Mott: Yeah. I did realized that because I've done some of that work. It was really interesting the way it pulls in stuff. You probably know if you've done it yourself, it's quite technical, but at the risk of offering I hope I was helped to those two. I think I was in the end, but it was a bumpy ride a little bit of the way. But now that I've done one probably paving the road, no good deed goes unpunished, but if there was another eight to go, I could happy to help with another one because it looks like Ivan's fixed it for the future. So, point of the story was I could tell they really need these things out. And if anyone else wants a hand,…
Antony_Mott: least I've done one. So, I'm offering again to if anyone wants help.
Wesley_Smith: Yeah, that's hugely appreciated.
Wesley_Smith: And as you're running into a lot of that work regarding the tooling for our specifications and the publication process is really aggressively bottlenecked, bus factored on a people like Ivon and Manu. and so spreading that knowledge around is great.
Wesley_Smith: Thank you for the offer. I don't know of another threat model that needs help with that process, but you could totally bring this up on the working group call on Wednesday and offer your help and thank you very much for the engagement.
Antony_Mott: And it was really nice working with people too.
Antony_Mott: Such a nice group. It's important to tell that for a newcomer.
Wesley_Smith: It is.
Antony_Mott: It was really really nice. Okay.
Wesley_Smith: The group very much appreciates, newcomers that are interested in engaging and helping beyond just attending calls, helping with, some of the more the tedious button pushing and that sort of thing because it has to get done. All right.
W3C Press Release
Wesley_Smith: Thank you for the progress update there. I submitted V the VC barcodes throughout static snapshot for publication. I don't see anything that indicates that it's happened, but that's fine. It has a million of these things do and it will happen soon, I am sure. All right. I think that is that. Let's talk briefly about the upcoming press release. So, a lot of this will be repeat info for folks on this call, just so we're all on the same page, the W3C communications team has agreed that the topic of the blog post that we had written a couple weeks back, is topical, immediate, big enough to warrant a press release instead of a blog post. and so they're upgrading it as such.
Wesley_Smith: and we are working with them to nail down what the final language in that blog post is going to or excuse me in that press release is going to be noting that press releases have to adhere to a higher standard of all of the various things you might expect in a blog post. So we're finalizing that. No Archer, I guess a question to in a thread that you are on with the communications team, they ask who has the authority to perform final review of the document containing the change requests and suggestions and discussions.
Wesley_Smith: I've noted that I am happy to help with the technical and pushing the buttons and writing and all of that stuff, but as far as I know, I don't have any authority to perform final review on behalf of the working group.
Wesley_Smith: Is that something you can do?
Phil_Archer: I'm not sure…
Phil_Archer: what the answer to that is, I have looked through it myself again today and I've indicated my approval. I don't know whether Brent has had a chance to I know he read it originally. but that was last week. I think ultimately surely it's Curly. She's head of coms for W3C. so I mean for what it's worth, I'm not sure it's worth very much. I've said I'm good with it. I'm obviously very grateful to you Wes for not only writing this but for driving it. I think it's a very positive step and I'm very grateful to you. as I'm sure the rest of the group is.
Phil_Archer: But as far as I'm concerned it's done but currently it's the head of coms not me. Yeah.
Wesley_Smith: All right.
Wesley_Smith: That sounds good. So, I made clear to her that I'm available to help in whatever capacity I am able to help. but noting that I don't know the ins and outs of the process and requirements and authority and all of that things all that stuff surrounding this sort of thing. Okay, So that's it for that I think. we will see how that goes and hopefully have something to share on the mailing list pretty soon. That's exciting stuff. All right. anybody have anything they would like to add to the agenda today before or just briefly discuss before we get into specific discussions? All right. Greg Bernstein, would you like to take call time for data integrity today?
Data Integrity Salted Hash Approach
Greg_Bernstein: Particularly since Dave's here, we've got some issues on data integrity.
Wesley_Smith: All right,…
Greg_Bernstein: Okay.
Wesley_Smith: that sounds great. Over to you. you can take as much call time as you'd like is useful. we have nothing pressing to discuss that I know for the other specifications. so anything that's high priority for you, take as much time as you
Greg_Bernstein: And we've got some stuff from Anthony that I actually haven't reviewed yet. So, let's look at I want to share screen window. Getting better at doing this. Now, we're going to have infinite feedback for a second. And we're gonna go over to our issues.
Greg_Bernstein: Wrong wrong draft. That's a different story. Okay. Our issues, data integrity. Do we actually have two pull requests still? No. We were able to resolve the end of line CRLF thing. I think Monu fixed that. so we have a couple things going on with the salted hash approach. This is an efficient way to do selective disclosure with postquantum signatures because postquantum signatures most of them get quite large.
Greg_Bernstein: So the signed individual claim SIC sick approach which we do for EDSA doesn't work as well. So what we do is we do what's known as the salted hash approach. This has been done in SDJWT. and it's a reasonable way to do things. there were two suggestions. issue whatever number this is, issue 372, derive the salts in the holder from a salt seed instead of carrying the full array of salts. This can greatly reduce the size of the base proof when we have a lot of statements.
Greg_Bernstein: Okay, so that's one issue related to And the other issue related to this is using what's known as a Merkel tree to reduce the derived proof size. so those are the two issues. both add some complexity. I would say that deriving these salts, the approach to do it, this is my recommendation is to use standardized what we call a dist deterministic random bit generator.
Greg_Bernstein: These are specs by NIST and they're either based on hash functions or they're based on u u symmetric key cryptography and they've been standardized and they're fairly well known. Dave had some comments on these. Dave, would you like to indicate? what is that? Dave, hand up. Dave,
Dave Longley: Yeah. yeah. To took a look at this. my preference would be for us to try and minimize the number of additional primitives we have to bring into it. That doesn't mean that we can't go with some spec that's published in NIST and use that to solve the problem. what I was mostly talking about in that issue was hey if we reimagine how we describe this particular problem does that enable us to more easily go with fewer primitives and make it easier on implementers. I'm always thinking ahead to how much people have to implement to accomplish this and every extra new piece they need to implement is raises that bar.
Dave Longley: I realize that the particular primitive you're talking about is not necessarily a super complex thing to implement.
Dave Longley: I know you asked Claude to do it or something and it was 120 lines in some language like JavaScript. Mhm.
Greg_Bernstein: No, actually for that one I found one implementation in JavaScript and…
Greg_Bernstein: then I found another implementation in Python and they were both around that size and they had tested against NIST vectors. they were probably that long because they were doing the full general use versus a specific case we would not include all they take some extra parameters in some of these DRBG things.
Greg_Bernstein: And so somebody doing the full implementation would have to have more parameters and a little bit more documentation about how they take those extra parameters. if we wanted to we could write up something in an appendix on how to do it. there was a slid set from NIS that recommended why they had four of these things initially and only so I think three made it into the N spec but it kind of justified some of these things.
Greg_Bernstein: Some of them were designed to get very efficient for very large scale secure random number generation. others were basically the one based on a HMAC is kind of an output feedback thing. So it's just iterated and such with a particular setup. So, it's not horrendous, but they're very specific about the procedures because they want to make sure that they can't be broken and that people don't mess up. Dave
Dave Longley: So, if we're going to go with this other additional primitive, I don't think there's a whole lot of extra text we're going to add or that we would need to add just to use it. I think it's mostly linking to the specification. I think the text we're going to write and what someone will have to implement ignoring that extra primitive is the same or almost the same whether we have that extra primitive or whether we use HMAC directly. And I think the only hangup on whether or not we can use HMAC directly is how we define or express the problem.
Dave Longley: If we express the problem in a similar way to however we've expressed other places where we have only used HMAC for non-reversible unpredictable outputs …
Greg_Bernstein: a shuffle. Yeah.
Dave Longley: if we can define the problem that way I think we could probably just reuse what we have done before we've used HMAC and HMAC keys to deterministically generate blank node identifiers. And so if we can define the problem that way, I think we can save implementers having to implement this thing. If we feel like we really can't get there, the way I'm thinking about this in my head is there's something extra here that if we can cut out, it will be a better spec. If we can't cut it out, it's okay, but it's extra work. And so I think we should write everything up that we have to put in the spec And then we can figure out whether or not we need this additional primitive because we're either going to be calling this additional primitive with a key and an index or…
Dave Longley: we're going to be calling HMAC with a key and an index. I don't think mean when it comes down to what you have to implement for our spec, you're going to be doing that either way.
Greg_Bernstein: Okay. …
Greg_Bernstein: as far as wanting to do this, it seems like a very smart thing to do. I don't know why we wouldn't do this. Is there any argument against bringing this in right now? Approach.
Dave Longley: no I so just some additional history before we decided to do in the previous work before we were doing the postquantum stuff where we always had nice small signatures we examined using, the salted hash approach. And, …
Dave Longley: we realized we could do better than that by doing selectively disclosed individual signatures on individual claims. And yeah,…
Greg_Bernstein: Yeah, it is quite efficient for I mean it's good in all directions,…
Greg_Bernstein: right? Between the holder and…
Dave Longley: and when we Yeah.
Greg_Bernstein: the verifier and it's fine between the issuer and the holder. Yeah.
Dave Longley: before we were made that decision when we were looking at salted ashes we always had the idea of using an hmac to deterministically generate them but make them unpredictable non-reversible so that concept was in the mix back way back before we abandoned doing the salted hash stuff and I pretty sure back then everyone thought that was a good idea and so now that we're bringing this back I think we're also bringing back that concept and I think it has a number of different advantages that we've talked about and…
Dave Longley: are listed in these issues and it's not challenging to implement. though. I do think we should do
Greg_Bernstein: Okay, second question.
Data Integrity Merkel Tree Approach
Greg_Bernstein: We then had the Merkel tree discussion and I looked into it some more and I did get an algorithm going during the weekend that would produce what's known as mult multi-proof. So here we want to reveal all the statements that we would reveal form the leaves of this tree and so here I'm revealing three statements and to do that instead of having to do three times five for each of these paths through the tree you do one combined proof and it only involves the
Greg_Bernstein: sending the additional blue statement hashes 1 2 3 4 five. So it's quite efficient. However, it wasn't a It uses another recursive algorithm to build the tree and I haven't put together the full proof algorithm. the folks that kind of proposed this and that were participating in the discussion kind of ducked out after some little bit of contentious issues on what is a binary tree and what's a Merkel tree which are wellestablished concepts. So I'm not quite sure what that was about but it's an optimization.
Greg_Bernstein: It could be very advant advantageous if we get to large credentials. However, it's more implementation complexity. I would be inclined to do it as an optimization or as an advancement on top of the other if we got a call for it. I mean, I don't mind working through it kind of a little bit more, but I don't know. I'd like your opinion and any others about the complexity versus should we do it now, because I think we can generate the salt thing. We can evaluate that. Dave, go ahead. I should stop sharing again.
Dave Longley: So I think we got to think about use cases at a top level. and sometimes we can fail to be imaginative enough but some of the use cases for sele most of the use cases for selected disclosure that people have encountered thus far generally involve revealing relative to the total number of statements in a much smaller number of And we should keep that in mind when we're looking at how much savings we're actually going to get out of this. if the additional complexity you're talking about, Greg, is very low and I don't know, I haven't implemented
Dave Longley: in this. But if it's very low and…
Greg_Bernstein: Yeah.
Dave Longley: we get significant savings out of it, then it might make sense to do. But if it's significant complexity, I don't know how much extra savings we're actually going to get in the majority of use cases and whether or not that's really worth the value. It is important to remember that extra complexity is probably only going to be paid for by 8 to 10 libraries that end up getting into the ecosystem and then you get the advantages of that complexity everybody else using it forever gets all that advantage. But how much advantage is it really for most of the use cases…
Dave Longley: where you actually use the select or disclosure feature to reveal some statements? it might not be a huge
Greg_Bernstein: Anthony, I can't hear you.
Greg_Bernstein: Anthony. Yeah.
Antony_Mott: How about now?
Antony_Mott: Hi. yeah. I just want to say I might be able to help here a little bit. You know how I had the PR I sort of owe everybody that's the wrong word, but I'm redoing the SIC's for the examples. while doing that, I discovered exactly what you're both leading around to. Firstly, the Merkel tree. I think right, Greg, it's from 15 to 7. It's fantastic. But as Dave points out,…
Greg_Bernstein: Okay.
Antony_Mott: if it's two to three claims, these are things that might be maybe helpful after I push up the SIC for two or three claims because there's a whole bunch of other stuff for link unlinkable that's so exciting and also you'll want to look at that makes sense. And as Dave says, if most verifier situations that I've seen in the wild are often one, two, or three claims, maybe we can add that. although it's very exciting Greg what you did finding the way you can do it so efficiently and I'd also throw in I think it was Dave said about the discussion about HMAC alternative I would also suggest that I just use HMAC because that's what we were doing before as you probably expected and then if it can be substituted by the NIST approved better system I think as one person already said yes we can just bold that on or switch that out so I only wanted to suggest that I think by the end of the week I should have the
Antony_Mott: which I'm sure will have a whole bunch of issues that you'll all look at. But it reveals itself at least in the example I gave that we need to focus on larger things than optimization first in terms of the claim number and…
Antony_Mott: then implementers who have more complicated or numerous claims will look to the things Greg is talking about. Does that make sense?
Greg_Bernstein: I think so.
Antony_Mott: I think so. let me
Greg_Bernstein: Let me try and put some choices in perspective. We've got salted with the salted hash of claims, Right now, Let me see if I got this right. Has what has to be sent between the issuer and the holder would be the salt key and obviously the credential. Okay.
Greg_Bernstein: With the solid hash of claims otherwise what has to be sent between the holder and the verifier is actually the complete list of salted hashes because that's what's get signed. Okay. So, however many statements we have u non-mandatory all those get salted and hashed by the holder and sent to the verifier because it's that list that gets signed. So, that can get large as large as the optional claims or non-mandatory claims in the Merkel tree approach.
Greg_Bernstein: If you only want to reveal what one claim, you don't send the whole list of salted hashes, what you send is the root of the tree hash plus a inclusion proof that includes the whatever claim you're going to do and intermediate nodes up the tree so they can verify that thing works. that can be quite efficient. Let's say you had a hundred claims. so that's the Merkel tree approach. If you go with the Merkel tree approach, it makes sense to do what these things called multi-proofs in our case because we're not sending just one claim.
Greg_Bernstein: We're going to send two out of a 100 five out of a 100 and those individual little trips up the trees can be combined. And so people haven't used them this way because they're mostly using them for all the stuff is being actively pursued for dealing with certificates for websites under postquantum signatures that are large. So they're putting together Merkel trees and doing things like that, but they prove things one at a time. This multi-proof thing is kind of an extra thing on top of the Merkel tree construction standardized so that we're getting just a little bit innovative.
Greg_Bernstein: So to me there's a choice between do we use the miracle tree approach to produce that set of stuff that's sent between the holder. Do we send the whole list of salted ashes or do we send the Merkel tree root hash plus this proof stuff? And as long as that doesn't get bigger than the list of all those salted hashes and such like that. So if we're thinking about using Merkel tree, I recommend we take the time out to look at this if we're going to use Merkel tree we should look at multi-proof because it's very efficient unless it proves otherwise because I did a algorithm for it.
Greg_Bernstein: It was recursive, which always gives me a headache thinking about those things, but it was like, I don't know, 10 lines of code. And so then I need a corresponding proof algorithm that takes the additional information that gets combines it with the multi-tree proof thing, and then runs the hashes on it. But that's kind of where we're at. Do we use Merkel tree or not? Because if we use Merkel tree, we should probably go with these multi-proofs. I said, I don't think recursively. So when I have to sit down and do a recursive tree algorithm thing, I just have to sit there, draw pictures, write it up, do it slowly, produce little outputs. Maybe if I had taught data structures, but I taught cyber security and networking.
Greg_Bernstein: So, it's not in my head, but it can be done. So, I can show folks offline things like that. so that's to me Dave and Anthony edition. Do we want to bring in the Merkel tree? The algorithms aren't that long. they're compact and hard to gro. I mean, when I got one from this RFC that's being looked at by the certificate people. Initially, it looked very strange. So, being my son, I had him put it into Claude and it generated line by line. It said, I'm doing, this very short 140line bit of JavaScript so I could put it in with my examples.
Greg_Bernstein: So I let the AI help generate the tight little code and then I started instrumenting and seeing how it worked and how to extend it. So I mean this stuff is not super long. But anytime I look at tree algorithms or recursive algorithms, I never love to say that I am not the one to say that it's not complex because it always gives me a headache walking through tree algorithms and recursive algorithms. However, they're very tight and short.
Greg_Bernstein: So you can't say that they're complex as far as lines of code, but …
Greg_Bernstein: neither are encryption algorithms, and we know you got to be real careful when you work on those. Anthony
Antony_Mott: I don't know
Antony_Mott: if I'm off mute. I love the idea and I actually think even so far as it'll end up some in the spec I don't know if that's the right thing to say here for the actual thing that you're talking about reg. The reason why I suggest this is that I think there's going to be use of the spec immediately towards trying to make it fit into small things like QR codes where people are just going to solve it themselves if we don't do it for them. Does that make sense? And with someone like Greg already noodling it out, we've already got Python and TypeScript, you said. I can see it being a very very useful spec. Sounds narrow but it'll be useful and even if it has recursion provided I don't know is that right?
Antony_Mott: if it can be in some sample TypeScript or Python even so that people can just grab it, copy and…
Greg_Bernstein: Dave. lot. Yeah.
Antony_Mott: paste and it works. Is that outrageous to suggest that or it just would be so useful though?
Antony_Mott: It is. So
Dave Longley: So, we're definitely going to put the algorithms in the spec.
Dave Longley: And if we have an appendix, we can have an appendix that might give a short implementation of something if that's helpful. I think it is a good idea to take a look at things like a student transcript use case that might have a lot of claims and what you would save and then compare that against, we're going to have to write these algorithms. we would do them instead of doing the alternative salted hash approach. I think we would just have one of these. and so there would be one thing to implement. it might be a little more complex. We need to look at it. We need to see what the savings is.
Dave Longley: I don't want to be too much of a wet towel on the QR code thing,…
Dave Longley: but if we're you think one signature at all blows the QR code for a lot of these post things. Yeah. it's got to be ski sign and…
Greg_Bernstein: for post…
Greg_Bernstein: unless it's ski sign. Yeah. Yeah.
Dave Longley: we're going to use selective signature stuff for ski sign. and so that's how you're going to fit something in a QR code. That's your choice. so if somebody invents some super awesome multicolored some other 2D barcode that gets popular, then maybe we can cram some more stuff in there. But right now I think that's really the only viable option for that. But understanding these student transcript use cases where right now I think the only viable way forward would be for them to use Ski Sign.
Dave Longley: And so if there's an alternative that I don't know viable is maybe the wrong word. There's tons of extra overhead and we should really have put some numbers to it and say this is what would happen. This is what the savings would be and then we can analyze that to see what's practical and again I just want to remind people we're pro you if we end up doing this extra complexity it's probably only going to be eight to 10 times and then everybody gets the benefit of it. and…
Greg_Bernstein: Wesley.
Dave Longley: the downside to that is making sure that all the security proofs and everything work out and we don't want to introduce new interesting terrible security problems because of the additional complexity.
Wesley_Smith: So, I have a quick question slashsuggestion regarding the proposed comparison. not my area, so this might not make sense, but it seems to me that, we're talking about comparing options for these different use cases that have different parameters. this all sounds to me like something that can be simply expressed as a closed form function that can be evaluated for any use case. if that is indeed the case I would recommend that as a path forward maybe not to express in the specification as it's might be complicated but at least for this group internally to reason about what the actual trade-offs are I think a simple closed form solution that expresses the behavior of the options across all use cases would be the best thing.
Greg_Bernstein: Hello. Okay.
Wesley_Smith: So we know as opposed to just reasoning about a couple data points in a vacuum. That's it.
Phil_Archer: Just very briefly,…
Phil_Archer: Dave talked about different possible data carriers rather than QR. I thought, that's a subject I don't know a little bit about. the great thing is of course that you'll have a device in your hand that recognizes QR codes out of the box. there are options available that carry more data in the same space. data matrix is one you see that quite a lot on a letter proform letter that's often there might be four quadrants one of the most compact actually is a thing called the handshin code. which is developed in China by some people I know. and there are options. The thing to watch out for, as I think you mentioned, Dave, was the proprietary side of things. because for the only version that is not proprietary is the vanilla one that you all know and love.
Phil_Archer: Once you start putting colors in it, then You start putting logos in it, you're in proprietary world. You change it to circles rather than squares. You're in proprietary and so on. So the range of stuff you can use is broader than you might think, but that doesn't mean to say that it's completely open because a lot of what you might want to use ends up being proprietary. So yes, there are options and if you end up having to look for an option because isn't good enough, we might be able to help. But even so can you change the laws of physics captain and there's a limit to how much you can put in an optical code in a limited space.
Greg_Bernstein: Does anybody know exactly where some of the student record what is those Comprehensive learner records. What were they stood for? I can't remember. I looked at those when I first started looking into verifiable credentials and selective disclosure, but it's been quite otherwise I guess I'll have to go see what Do we still have an education subgroup?
Dave Longley: We definitely have a number of people that are part of that, including Phil, who just put his hand
Greg_Bernstein: So, I mean, if we're going to fish for examples, where should we go fishing for
Phillip Long: One edtech is the standards provider for the CLRV2 …
Greg_Bernstein: Okay. I'm taking notes.
Phillip Long: which is the VC compatible version of the comprehensive learner record. It's kind of a mashups to some extent between a transcript in its formal in its format including the rules associated with what you have to comply with and in what order that registars are so fond of usually only valuable to another registar. But it also include right it's called number one the URL is number one edtech al together and…
Greg_Bernstein: What you just said, the edtech with CLR V2.
Phillip Long: they're the ones who are the responsible for the open badge version three and the CLR standards along with others used in the education world. and in fact the CLR V2 workg group is going to begin looking at…
Phillip Long: what it to do with the next version of it since adoption has been relatively low. the universities are always questioning why they can't just continue to use signed PDFs.
Greg_Bernstein: Yeah.
Phillip Long: That's if you have any other questions just let me know or just ask. I'll be happy to answer. I sit on the work group for both.
Greg_Bernstein: Assign PDF. Yes. Let me know everything about you. Yes, that's in this day and age. …
Phillip Long: Yep. Sorry about that.
Greg_Bernstein: I understand. I mean, when I saw the CLR, it was big and a bit hard to gro, for an outsider.
Greg_Bernstein: that was the first stuff I looked at because I had been teaching and during COVID and I got very interested in verifiable credentials as applied to CO and so the first thing I started looking at was academic records. But I go, "Wow, it was a handle everything kind of spec, but it definitely was intimidating." I was going, "I understand class records. I've seen them, but I'm having trouble understanding this." Yes. Okay.
Greg_Bernstein: That gives me motivation to try and take the ne finish up this represents courses is OBV3s. I'm gonna thank you. this definitely makes this the Merkel approach sound worthwhile to look into. I mean and I think Dave's right. once somebody we get a couple good open source libraries out there for doing some of these fundamental things. I mean I did my own implementation of selective disclosure functions but I use the digital bizaar version for all my other work because there's a lot more people with eyes on that than my own personal version.
Greg_Bernstein: So it's kind of true that when you've got some good open source libraries, everybody starts using them and that, they're open source. So it's not the same as having to be bug compatible with some proprietary implementation if you recall for those of us who worked in networking, everybody had be bug compatible with Cisco. their stuff had bugs, but if you wanted to work in the certain ecosystems, you had to be bug compatible. So, that gives me my marching orders. one other thing to note is, for those who are interested in privacy preserving stuff, some of the log jam, and stalling of BBS has somewhat been resolved.
Greg_Bernstein: the chairs over at the cryptographic forum research group of the internet resource task research task force which is part of the IETF. it's finally gotten back to us about cryptographic review of that. They got the message that people really want to see these things finished and the core draft authors who have gone on to do other things have put me as a co-author so I can finish spec. So that's what's happening over in BBS land so we can get a privacy preserving cryptography before things are made out of date by quantum computers.
Greg_Bernstein: And that's a kind of the headlines here. and I will turn it back over to Wes unless there are any questions about any of the data integrity things and such like that. I think I owe Anthony a review of some of his postings over on Unlinkable Disclosure.
Wesley_Smith: All right. noting we have about five minutes left. I don't think it's worth jumping into a new topic which would be issue and pull request review on our other specifications. anybody have something for discussion for which the last five minutes would be appropriate? All right. thank you folks very much for your time today. as always, I will see many of you on calls later this week. And have a good rest of your Monday.
Phil_Archer: Thanks everyone. Good night.
Greg_Bernstein: Bye. Meeting ended after 00:50:04 👋 This editable transcript was computer generated and might contain errors. People can also change the text after it was created.