 All right, well, everyone, welcome to another edition of the Hyperledger Health Care Special Interest Group here. My name is Michael Koy. I'm our chair of the organization. Just want to be able to make everyone be aware. I'm going to share my screen real quick as we want to go over kind of an intro stuff and housekeeping items. So within the Hyperledger Health Care SIG, we want to just have a, to let everyone know that this is an open, free working group. If there's anything that may be under NDA or anything competitive to you and your startup or your federal entity, please do not disclose it here within the group as this is an open source group and we don't want to be held liable for any trade secrets or any industry knowledge that may not be widely accepted to the world. So just so you know, that's the rule I have to say before we do these sessions, as well as we want to be able to have an open space where all ideas, comments and suggestions are made free, especially questions. There are no dumb questions here. Please do not down anyone for having a question that may seem elementary to you. We're all trying to learn in this space and this is mainly for educational purposes as well. So thank you for your courtesy and thank you for your respect in all our presentations. Today we have a very special guest, one that is John Walker from the COVID Credentials Initiative, the CCI, and which is also a partner of the Linux Foundation Public Health Team. He is a solution architect. You see his bio here, you probably read it before coming into here, but John has been able to inform me and others of a special kind of digital signature that is technically wrapped in JSON-LD that supports BBS signatures. We went over this about two weeks ago, him and I as a preliminary discussion and I thought it'd be very helpful for the group to understand what this technology is, how it works, how it operates and how it can be implied to help true decentralization and help imply, like I say, I guess safer guidelines and more interoperable guidelines in order to transact and showcase digital signatures and digital health passes as there are many different companies looking to build on this architecture, build up these solutions. And we even had a company in Provechi about a month ago that'll present their findings on this as well. So I give the floor to John. John, thank you very much for coming so early in the morning for you where you are on Pacific time and please take it away. Great, thanks, Mike. Great to be here. And as Mike said, I just have a discussion deck to go over today, like to introduce the COVID credentials initiative being hosted by the LFPH and then talk about a particular type of zero-knowledge proof that can be applied to JSON-LD data and the implications that has in the generation of privacy-preserving credentials that can be applied in health passes. So let me share my screen. And I'm taking through just a few, some discussions slides and please, it's really important to have an open discussion and talk, this is a pretty nascent space. So there's a lot of discovery and early work going on. So I hope we can dig into that. So folks, let me know when they can see my screen. We can see it. Great, okay. So as I said, I'd like, we'll talk about, I'll give some high-level contact to really the detailed topic, which is JSON-LD and zero-knowledge proofs and the implications that that technology has in verifiable credentials. So first, let me say something real quick, just about the CCI, folks aren't providing with that initiative. It's really, it's been a community group that sprang up in April of 2020 and basically just grassroots, international technologists, public health experts and other related domain experts joined. We've had 400 participants. The goal of the group was to really have an open community where we can help deploy privacy-preserving, verifiable credentials in order to mitigate the spread of COVID-19 and basically strengthen our societies and give the economy back on its feet. So again, as I mentioned, 400 individuals have participated, over 100 companies. And that work went on throughout the summer and ultimately we were able to formalize our community a bit more and get support. And we've got basically a team of three folks that have been, that are working with the Linux Foundation Public Health to strengthen the effort. And basically I'm working with Nusie Yang, who's our community director, myself as the architect and then Clea Young, who's the ecosystem's director, she's a very deep background in the identity space. So fortunately for CCI, we're very pleased to have been brought into the Linux Foundation Public Health back in December and LFPH builds, secures and sustains open source software to help public PHAs combat COVID-19 that the GAIN initiative is very successful last year. And LFPH has obviously the range of relationships with public health authorities and is a trusted partner in the emerging technology space. And so we feel very fortunate and been very lucky to be working with them. Our work streams and our structures are basically we have three work streams. We have a use case implementation work stream where we take demos from community members who come in and basically show us how verifiable credentials and digital health passes can be implemented and they map back to use case work that was done back in the spring. So that's very active. We also have a rules and governance work stream that is put together in governance framework. We think that because of the societal and kind of the technical societal implications of verifiable credentials that it's very important that it's, this technology is balanced with ethics and across disciplinary view and review of what's being proposed and potential implications. And then finally we've formed a vaccine credentials focus group. So given the recent need and interest in vaccine credentials, we've decided to create a focus group that's gonna work just on that and go basically jurisdictionally based starting in the US to try and develop POCs and pilots with the jurisdictions within the US. So that's how we laid out our work. Our goals are really to create and develop open source software. And that software will be applied to, you're not familiar, SSI has basically a trust triangle that all of the software and the actors operate in. And that triangle is basically you have an issuer, a holder or a user who has a wallet and a verifier. And so we're really looking to identify opportunities or vendor or individuals code where we can come up with basic user wallet and verifier apps. And so we're looking for the to confirm the minimal requirements for those and then make them available. So basically in the public health context of little no cost, we can roll this technology out and apply it to the pandemic. So drilling down into this trust triangle a little bit, I just wanna point out that this is basically the essential entity model for the self-sovereign identity and verifiable credentials. So working from the left, you have an issuer, which is a governing or some responsible entity that is willing to incapable of creating a schema or a definition of data that will be used for the implementation of a credential, in this case, a vaccination credential. That issuer with that data definition of the credential, lever keeps those definitions in a verifiable data registry, right? So the keys, the definition of the documents that go in there and their schema definitions go into a verifiable registry. The most common implementation of this these days is you've probably heard of dids and did methods, right? So this is where the keys and the schemas are defined and kept in the documents in a verifiable registry. The holder is the individual and that holder has a wallet, but more importantly, the wallet is where obviously the credential presentations and any public keys being used are stored and also the credential, but most important is really the holder agent, right? So that's really that the smarts that has to be applied to the credentials that they're used and that correctly for presentations. And then moving finally to the right, basically a holder presents their credentials to a verifier, right? So I want to get on an airplane, I want to get into a store. And so the verifier can read the presentation digitally, read the presentation the holder has and confirms its veracity against the verifiable data registry without ever actually having to go back and hit an issuer database or hit some kind of a, again, another centralized source for verification. So that's really the primary model for the self-employed identity entities. Any questions on that or? Hey, John, I'm sorry, this actually prompts a question and I think it's just me, it's not your graphic. The verifiable data registry, I mean, that can be anything, right? That's essentially pointing to the whatever ID proofing mechanism or process that's in place. Exactly, in the, you know, in the, in so particularly in the hyperledger context, right? Very popularly, that's going to be hyperledger Indy, right? And this agent, the software that that's represented in is, you know, hyperledger Aries. But there's nothing about the conceptual or logical model that requires, you know, those are implementations, right? So that's implementations of how to do this, but it's not a requirement. Great, okay. So the, let me go back to this slide. So there are basically there are three main flavors of these credentials that are leveraged in W3C standards. And so we want to talk about those real quickly and we're going to focus on the JSON-LD. But be known that there's the three flavors are JSON-LD, JSON, Web signatures or jobs. And then a, a VC that's basically has a JSON representation but it's called a ZKPCL. It's got a particular cryptographic signature that's applied to a JSON data structure. And there's, you can, there's a whole world of information to drill into about these three flavors. I refer you to a paper that my colleague, Clea Young has just written on, on just that. And what the pluses and minuses are. So for our discussion today, we'll focus just on the JSON-LD with BBS plus signatures. So there's the key functional advantages of the JSON-LD ZKPC with BBS plus signatures is that the zero knowledge proofs can leverage JSON-LD data structures to create what's called link data signatures. And those signatures allow basically a, allow the credential, the whole data structure to be broken up into individual messages. And this is really, this is really key because what this enables is what's called selective disclosure. So by, by having a very well articulated JSON-LD data structure and then breaking its properties into an array of messages, we can apply basically proofs to the individual attributes, right? The individual object properties. And this is really, it has a lot of really positive implications, particularly in health related data where again, you want to be, you want to have an absolute minimum dataset that you present for proof to anyone. And then again, ultimately this provides the ability to have a very specific and discrete digital signatures applied to credential attributes. So I'll give an example of a flow of how basically, let's say fire-based data regarding an immunization administration or vaccination administration event could be transformed in some of the technologies involved. So working from the left to the right, basically we assume that access to the data would be a fire-based data source. So that could be an EHR, could be an IIS in particular jurisdictions. And the structure of the fire-based data is what's called a bundle. And so basically any processing assumes a valid access to what's called smart on fire protocol, access protocol to that R4 bundle. And there's a very key transition that takes place when we're doing this. And in the context of verified credentials in the EHR world, in the clinical world, that data is active, what we call it. Basically those EHR records are being updated, immunization and vaccination events, that is active. Once we pull that data, once we query that, we're really in a read-only world. So it's very important that we can demonstrate that there is no change to the data and that it represents exactly the transaction or transactions as they existed in the EHR world. So the first important thing is that we can demonstrate that there's a valid, let's call it immunization bundles in this example. And that immunization bundle of data might have patient immunization, let's say practitioner, in this case the practitioner is the clinical practitioner. So with that valid data set, basically we want to get to JSON-LD data. And so we want to transform that bundle in R4 is natively in a JSON format into a JSON-LD. And then identify all the personally identified information all the attributes that are in there. And with that kind of pre-processing, then we're in a position where we can actually take a, or apply an issuer schema and via Aries and a dead method processing, we can apply these cryptographic processing and algorithms to the data. What that gives us then is a very privacy-preserving presentation of the vaccination credential and that same data can also be, again, we're outside of the EHR world now. So we can persist that in any kind of a semantic container or read-only data container. So that's kind of the flow from the SSI perspective of how one would create, of your viable potential with BBS plus signatures. Any questions on that? So I have a question that may help broaden other questions. So before in this group, we kind of lightly reviewed the smart health.cards VC model. And to my understanding, they have that connected to an ION-DID method that is connected onto a blockchain. So how does something that smart health.cards differ from this model, which uses a ZKP, JSNL, DBBS signature? What is the main difference? And how does this help for interrupt purposes or if it does or does not? Actually, let me jump in real quick and say that Josh has stripped out the ION public did reference and is focused only on a JWT potential now. Okay, that's good. So the couple of great questions, a couple of key differences there. One is the, in the smart card model, your, it's really the format of the potential, which is the JOT. And what the JOT does not, it takes multiple steps of processing. You can kind of create a selective disclosure, but basically you end up doing a lot of permutations on the data to create a selective disclosure potential. You can't apply the zero knowledge proofs. You basically need the JSON-LD data structure or structure of the data to apply the DBBS plus zero knowledge proof. So that's probably the biggest key right there. And the other difference is that in this model, the smart card model works inside the EHR context, but you're really, you're given just an instance of a credential that was based on some EHR transaction. You're not able to, in this model here with that vaccination record, you could permute and have several different privacy preserving credentials or presentations of your credentials. So you could, with one set of data, you could create the presentation to go into a store versus the presentation that you would need to get on an airplane, right? Those could be different attributes. And it's really the JSON-LD data structure and the processing on that that allows you to do that, to create those different presentations and all without having to go back and permute it again and again against the same data record. Does that make sense? Yeah, so, yeah. I have a question, if I could. This is Doug Bullitt with the Fireblocks Consortia. We're still operating over just raw fabric hyperledger. Could you discuss, or maybe this is just two in the weeds for today's conversation, but could you discuss what the essential differences and value-added attributes of Indy and Aries are in this scheme? So Indy is the blockchain, right? The ledger for the did documents and all the keys, all the public keys. So you could write those documents too. You could write that to fabric, you know? The biggest difference is, it really with Aries is as this agent, right, that allows this processing, allows the communication between the schemas from issuers, holders and verifiers. You need methods, right? You need a definition of the functions you're going to use, which are the did methods. And then the schemas for what data is going to be processed. So that's probably the biggest difference is that there's a lot of functionality in Aries. And you would have to either adopt that and write to a fabric, you know, DLT. And John, if I could add. So Doug, one of the biggest differences is that several years ago, the same folks who are involved and John, correct me on any of this, but a lot of the same folks who are involved with the sovereign foundation and the principles of self-sovereign identity and identity world also looked at hyperledger fabric as a foundation and then said, you know, what can we do to apply the principles of self-sovereign identity, which means decentralized identity identifiers and the ability to disassociate specific individual attributes to the transaction record that you'd see in fabric into a new flavor of blockchain. And that's where I guess really John, Indy came along first and then Aries was built on top of that to have those attributes around the agent. And now in the trust over IP foundation, our perspective is that you have these different layers of the architectural stack and typically Indian Aries reside at layer one to support layer two, which is the decentralized identity foundation didcom protocol. And then associated on top of that is the agent, which are W3C verifiable credential standards. Fabric as designed is really good at what it does, but it's a bit like applying a Corolla to a situation that needs a Nissan Frontier pickup. And it was specifically tailored to meet the principles of the sovereign foundation's principles of SSI. Thanks John. Thank you. That's correct. So Kamlesh here, I have a question. So it means like as a hyper leather fabric can't be used for building the SSI and verifiable condition solutions. Or if some of like suppose I know about the verified dot me from the IBM, there isn't fabric to build that similar kind of SSI and DID solution. Yeah, so IBM fabric is writing their own did spec rather than necessarily using an open standard and nothing against them. I mean, as John knows, Marie and Eric Cassini from IBM are part of CCI and they're involved in good health pass, but basically engineered their own workflow. And when I say engineered their own workflow from a LeMete perspective, we've built this as well. And we've had it reviewed by the compliance folks from a HIPAA compliance perspective at Providence Health. So it has gone through some measure review as well as the fact that the Indie areas community has a tremendous number of contributors to the RFCs aligned into various standards. Nothing necessarily wrong with what IBM's approach is on their health pass system, but they kind of have this middle layer that they architected themselves and then write to fabric. I can't say authoritatively whether or not what they've engineered aligns in the same way that the RFCs from Indian areas were designed to map to SSI or that HIPAA compliance has reviewed our architecture using Indie areas and found it acceptable. Okay, so, okay, that got it. So for example, like, what are the W3C DID and whatever credential is spec? If someone, because at the last, we need some kind of verifiable registry, some kind of decentralized registry of the credential. So that laser could be the anything, maybe the blockchain, maybe DLT or could be anything. It could be anything, but the ledgers themselves have properties and attributes that when looked in the context of the overall architecture may violate principles of self sovereignty based on how you're able to associate individual attributes back to transactions on the ledger. And so Indian areas, and this is where I start to get in the limits of my understanding the RFCs to be honest, but Indies and Aries architected out or abstracted out those architectural considerations specifically for like SSI and for GDPR. Okay, okay. Yeah, I mean, the one key design principle, right, is that you don't want to duplicate or you don't wanna duplicate the personally-identified viable attributes that are in a credential or the definition, the DID doc of the credential, on like multiple chains or in multiple places, right? You wanna minimize where they exist and minimize the access to that. And so that is Jim talking about the abstracting out, particularly in Aries, right, is where a lot of work has been done. And that's just, again, to have the Aries agent which work on how an Aries agent would work or write to any blockchain, right, is certainly possible. But the pairing of Aries and Indies was very advantageous and architected. Okay, thank you. So again, just to go back, I think the key enabler, right, for the ZKP, BBS Plus proofing is being able to get this health information in, and we think the best way to, the best information to leverage or the best format to leverage is a fire-formatted data is to get that into a JSON-LD format. And so I have, from the guys at a company at Matter, I have done some really good work on this. They basically, they have produced the BBS Plus, ZKP BBS Plus libraries and signatures that are used in use. And so this is a, this is an example, right, of what a W3C credential looks like. And this is for a vaccination record with a BBS Plus digital signature. And so you can see at the top, basically, it's setting the context with JSON-LD, excuse me, so we can identify the properties and the attributes below and then it leverages the did key method, just in this example. So it basically is using a persistent did for the functions, the methods and the documents. And then the key is at the bottom, it is leveraging the BBS signature library, right, which allows us to get this type of signature and it's the related encryption. So the goodness is that these guys are, it's early on, but they are actually really, really using these libraries and it's pretty exciting. So what I wanna point out here also is that this is for the vaccination vocabulary, you see we've got all these, for the subject, we have all these properties. And then by using selective disclosure, enabling that with this signature proofing, the next slide, we can see that there's a subset, right, when I would go to, this is a presentation, that there's just, I can limit, right, the subject can be defined with a subset of those attributes and yet the proof value below when a verifier would look at that, the proofing demonstrates this full definition of a subject is valid, but I'm only disclosing, if you will, a few of the attributes. And that's really, and that can be permutable, right, against an overall vaccination record. So there's a lot of power and privacy preserving capability in that. So these are just examples. This stuff is out there today. Highly recommend folks, check out their links. And really good work in a lot of, you know, there's a world of educational background that you can grab onto there. And I just touch upon something that someone brought up in the chat that John said, next on Java presenting the JSON LD verifiable credential in W3C standard, that credential can exist with or without a decentralized infrastructure below it. And so, and John can comment on this too. I think he and I both know a number of people, including Kalea, that are on the WHO expert review committee. They haven't officially decided anything as yet, but I think that the global trend is around verifiable credentials, which is their objective and the use of JSON LD as that format. But there are countries that were considered doing that based on where their information is in a centralized way. So you have an application in a mobile wallet who will present that credential for verification of vaccination, but it's using a centralized system. This approach is specifically built on an Indie Aries framework to offer decentralized. And the real reason being is, as we consider in LeMedic is, because you should have the right to enforce privacy principles and personal protection of data as part of presenting that credential and not be dependent on a centralized governance authority. All right, and great point, Jim. Again, the issuer, there's nothing about this, the logical model for implementing verifiable credentials that says that the verifiable data registry has to be distributed or has to be a blockchain. So as long as it sufficiently meets the requirements for authorization and security, and you're using it in this model as far as what the store did documents and the public keys, then that's, yeah, it's entirely implementable and viable. Yeah, and that's where an organization or a governance authority may choose to use hyperledger fabric as a blockchain control mechanism for the verifiable credentials. What becomes another conversation then is whether or not they want to enable self-sovereign identity capability of which fabric would not be the choice for that, but you could still get many of the positive values of having a blockchain managed infrastructure for credentials and just use fabric instead. Yeah, I mean, again, the good news is that these entities can be implemented right in using different technologies. So it's entirely viable. So that was really my presentation. I just wanted to tee that up and engage in the discussion. John, if we could go over in particular how potentially a BBS plus signature anchors to the subject name of the subject in particular. So, and what that means, so we're all trying to understand, okay, great. We're having computational trust. We're able to then verify to different data points, user remains and logic. How does that BBS signature or ZKP differ or add a specific benefit to the overall solution? So the, so zero knowledge proof is allowing you to present a fact without presenting some of the detail below the fact, right? So you can, we have a presentation of saying, you know, I'm older than 18, but you don't have to present the date of birth, right? And so in the verify of the person who is by having the verifier use that schema and accept that presentation, you're able to not disclose too much information. You can be very discreet about the information you disclose. So that's the net benefit of zero knowledge proves. And then BBS plus also allows the selective disclosure. So you can have tribal all my immunization records. I can selectively disclose the relevant pieces of that or attributes on that that I want for a certain instance right to go to my allergist versus, you know, getting on an airplane, right? Those are there are different parts of that record that are relevant for disclosure. So you can have zero knowledge proofs which leverage selective disclosure. So again, you can be very discreet in the and who could be able to see that exact point. Exactly. And then so some people, it's really all about the rule engines, right? It's about what rule engine and what method you can are able to trust in this type of technical architecture. In particular, we've mentioned before the smart health.cards and the common pass methodology. Someone may be okay with the rule engine that common pass provides, but for something else like IATA or good health pass, there are different permutations because you have different access rights, whether they're global international access rights and other things. Could you elaborate on technically how this architecture may make that more feasible or may more make that more applicable to the solution? Well, it gives so if you have different requirements from IATA again, then just getting in and out of an event within your country or crossing a border crossing versus an international travel requirement. You wanna issue the credential once and have it be secure, but you wanna recognize that the individual, right, is responsible for creating the presentations. So they control, right, what the subset of attributes that I present to IATA, meeting their requirement versus the customs guard. And it's not, you don't have to go back to some central database and recalculate or recompute your data requirements. You can create it once and then the presentation. So that's really the agent software against a wallet that could be used against the schema to create these different permutations, right, of the information you wanna disclose. And it's under the individual's control. The jurisdiction and the verifiers have agreed this is the minimum set of information. So that schema is out there, you know, the data exists, data attributes exist, but you, the individual, right, have the ability to, again, have selective disclosure of what you present. One other question I have, and I'd love to open it to others who may have questions as well. How does a JSON-LD bundle differ from a JWT bundle? I know they're not exactly the same, but the different schemas, how do they compare contrast in overall, in the field of oscillation? Right, so there's, this slide is relevant. So first, the JSON-LD, right, is you're gonna be able to leverage, so I've highlighted here, these all the different schemas. So think of, here, we're leveraging the W3C credential format, and then there's, these are exploratory vaccination and BBS security schemas, but this allows you to configure, right, again, what the entities are that you're gonna describe, in this case, the credential subject. In a JOT, it's basically, you have, you're going to a IATA, you're going to a registry, right, for the definition of entities versus having the World Wide Web, right, and all the different consortiums that can provide a scheme of authority, right? So one, you've got an open access to data definitions versus one registry, and then two, again, you can be very selective. Your data structure is less baked, if you will, and in a JOT, it's really permuted just once, and you can't, it's harder to manipulate, basically, you have to have additional steps to manipulate the JOT. It's an absolutely valid data structure used in many places, but it's not open to all the system or registries of record, if you will, that you get with JSON-LD. And that makes a very good point. So in a way, JSON-LD gives you more choices, and then another way at JWT, if you have a network or even a central organization or group that needs to make sure that you're not having many data schemas, you're just following this one, either centralized or given data schema, then it'll be universally accepted or it'd be harder to be universally accepted, but it'll be more secure and it'll be more streamlined in your kind of analysis, evaluation, or authentication method criteria. Is that fair to say? I mean, to me, the JOSCMA, it's just more brittle, kind of, when you create that structure, it's, you're locked into that, right? It's just harder to permute of that, certainly from a credential generation perspective. Would love to hear other opinions on this too, if anyone would like to chime in, if my understanding's incorrect or if I'm maybe missing a specific detail on this. You're not, and of course, John's overview is excellent. It is important to consider that about, it's easily understandable or, excuse me, easily interpretable that JSON-LD is, quote unquote, better than JOTS, but to John's point, like for instance, Josh made the decision to go with JWT for the smart health cards model because he's approaching the use case and the framework, governance framework, to be deriving the credential from a certain place in a certain way for the user's wallet. And JWT does have what I'd call some advantages in terms of it's, if you know where you're going to, you know, it can be lighter weight. And so it's, hey, I have a small yard, so I'm only using an electric weed wacker. I can't go across the street to use my weed wacker for my neighbor's yard because my neighbor's yard is twice as big, but for me, electric battery-powered weed wacker is just fine. It has the same properties as the gas-powered lawn hog that my neighbor has, but his is bigger and has greater versatility to use in my yard or anyone else's yard. Same thing with JSON-LD, if you dig into it, there's some good discussion about the size of the payloads and, you know, how do I get the attributes of a JSON-LD down to a QR code for easy scanning? And those are important things, but in terms of, you know, a global standard or something that would be adopted as a global specification, I think we'd all agree, you want something with maximum flexibility in a credential environment. And that's what JSON-LD has kind of settled to become within the W3C community. And John, like I said, correct me if anything I said there was wrong. No, I agree, that was great, Jim. And also, I mean, JSON is more in terms of the libraries and just its pervasiveness in software, you know, it is more pervasive and has a longer history than JSON-LD. So there's, you know, you have technical capabilities and availability. Technical docs to help out understanding. Right, exactly, Jim. Yeah, I would consider this an extension of our 20, 25 year conversation around XML where we started, which is the same thing, right? And then we moved to JSON and said, when you have a small web browser JavaScript communicating with the web, I mean, a server in the backend, why do you need to talk about extensible schemas and, you know, they're so fatty that it becomes fairly unusable. And then we switched to JSON, but then also realize the value of structures, especially for something like verifiable credentials. So I think we are just kind of trying to find the medium kind of going back and forth between these objects based like what Jim said on the use case. And JSON-LD is now emerging as very powerful for what we'd like to do, I think. Yeah, and what John hasn't shared, he's here obviously represent himself in his Linux public health CCI capacity, but he's actively involved in TOIP with myself and some other colleagues who are doing great things in terms of extending authorization and consent in FHIR, again, another JSON representation. And John, correct me, but I think some of the things we're looking at for being able to extend consent models which are in line with the Data Protection Act and things in Europe are really only or are most facilitable in JSON-LD. They're not something you attempt to do with JWT. That's correct. And if you look at the roadmap for FHIR HL7 FHIR, right now it's R4, their roadmap is going to JSON-LD and for much more interoperability with JSON-LD and basically even a graph model and RDF model behind, which really unleashes all kinds of very powerful ontological and analytical work you can do. So we're trying to, before we're thinking there and position ourselves as exactly as Jim was saying, it's not just the data payload, it's also the consent and authorization that goes with that you want to have completely aligned with any credentialing that you're doing. So we're just trying to be directed to the front of that conversation. And if I could ask you that also, is there going to be a need then to be able to have FHIR, FHIR's mobile data, right? And then for those that may not have a mobile service, we're then going to just tie into just HL7 messaging connected by QR codes or someone can scan like an NFC card to go represent themselves, right? Are we going to need more translators and compilers to then be represented in BBS credentials or in other type of schemas and formats? Like, how are we going to be able to not only make it, not just FHIR adjustable, but is there ways to be able to write another HL7 message or a DICOM image to then be represented in a JSON LD translator? Is that possible now? Or is that something we need to be able to build and make? Well, as far as messaging goes, at least the tack that the FHIR community is taking is there is a standard basic implementation guide to get from HL7 messaging to FHIR. So their suggestion there is to not leverage the, basically get it into a JSON format, right? Get it into a FHIR-based format and then manipulate it from there. As far as the compiling, I know the BBS Plus has libraries in Rust, Node, and Python, I think. So there probably will be a need. I can't speak to the DICOM how that would work, how that would be manipulated, putting a... Because I could see images being associated, whether it's an image of a person, just with their facial scan, or there's different biometrics you could be able to use imaging. And if it's a verified and appropriated by a healthcare entity, you may have to have it in a specific format. But it could be mentioned in FHIR too, but it's just pretty much getting it to that JSON method and then being able to extract it and send it out. And there's some real interesting, I suggest everyone, if you come and join, the LFPH Slack dialog, there's some real interesting work going on with biometrics and again, other representations, right? Or cross-channel representations of verifiable potentials. There's some great work going on with simmering down the BBS signature to get into a QR code and talk of how do we get these credentials represented just on a piece of paper? If that QR code could basically have a BBS signature embedded in it, there's some really interesting discussions. John, if you could, could you send a link into that in particular right now if you could take 30 seconds to do something? Yeah, sure. Yeah, if you go to covidcredentialinitiative.org, John's that correct? You can sign up for free and you can get access to the Slack channel there too. But Mike, to go back to what you're saying, that was a great discussion. And from a healthcare perspective, what we're looking at is each of the use cases. So imagine, if you will, you're associating in the verifiable credential the JSON-LD VC with a patient identity. That patient identity is then associated within the EHR to the record and then FIRE is the means of transport for the healthcare information. So you may have a JSON-LD representation of FIRE information, like with the vaccination credential, or you may just be using it for authorization of brokerage of FIRE messages between one or more EHR instances or systems as part of a healthcare transaction. You couldn't embed a DICOM object into a JSON file because it's just too hunk and big. But what we're exploring next in the Lumetic Exchange in the working group is, can I associate DIDS with DICOM objects and image files so that I have a decentralized identifier that then associates back to my identity? I present my verifiable credential for authentication and authorization. It's associated with a DID to a particular image. And then maybe the notes or the clinical details associated with that image are a FIRE message so I can share both. That is very interesting. And that is something I would be very... I'm sure all of us would be interested in talking about more at some point. Yeah, no, that's great info. Maybe we can talk about that in two weeks, who knows? Any other questions before we head out, everyone? Please, thank you, gentlemen. Thank you, John. And thank you everyone for the great questions in the back and forth. Thanks, John. My pleasure. Thank you guys. It's a very broad topic. I'm happy to further just to drill down into different aspects of it and come back and share with this group. Because there's nothing better to talk about than healthcare data. That's right. Oh my, it wakes me up in the morning. Exactly, frost my flake. John, I know it's early where you are, but we'd hope to have you in future sessions as well to help have a conversation, dialogue like this. And did you add the link? You said it's covidcreds.org. Is that how you can join the links for public health discussion group? Well, there should be a link there to get to the LFPH. Should be a link on the site. All right, well, I'm going to stop.