Sam Smith: Hi my name is Wes I'm a software engineer at digital Bazaar and looking forward to working with you all. ✪

Manu Sporny: Uh hey everyone um thanks Harrison uh a couple of uh document Publications that folks should be aware of um we had 3 documents moved forward on the standards track uh last week and the week before the first 1 is the verifiable I'm gonna verify I'm gonna put it in chat verifiable credentials overview so there's now a verifiable credentials overview document which is an introduction to all of the specifications uh in the w3c verifiable credential space um it's a good it's meant to be an entry point and give people kind of a lay of the land on all the different specifications uh that we're moving forward um so that is now a work item in the verifiable credential working group uh the next uh announcement is uh bitstring status list is now a candidate recommendation so this. ✪

Manu Sporny: Basically means. ✪

Manu Sporny: Feature Frozen with bitstring status list uh it is published we are looking for implementers at this point of which they're already enough implementers um we're doing test Suite stuff like that but that's another big um kind of move forward and then finally there is a new document called the controller document uh sorry a new specification called controller document a decentralized identifiers document is a type of controller document and now there's a generalized specification for that that the VC is publishing um that is meant to go on to the the global standards track as well so lots of. ✪

Manu Sporny: Um just making sure this group is aware of those uh pieces of progress that's it. ✪

Anil John: Uh thank you Harrison I'm going to share and hope that things work as expected give me just 1 second. ✪

Anil John: Hopefully you are seeing my screen. ✪

Anil John: Perfect all right first of all thank you all very much uh for the opportunity to uh share details about our technical uh implementation requirements um uh good morning good evening uh good night whatever time zone that you're in um as Harrison mentioned my name is Anil John um I'm a technical director with the US Department of Homeland Security and uh the requirements that uh that I'm going to go over are you know uh the requirements that we have chosen for uh implementing our decentralized identifiers identity uh capabilities uh that meet our operational needs in particular the operational needs of 2 of the oldest parts of the US government US citizenship and immigration services that is in the business of issuing digital credentials that are relevant to uh those 2 things citizenship and Immigration Services think permanent resident card employment authorization document. ✪

Anil John: Um I I think uh certificates of naturalization uh and citizenship and the like and US Customs and Border Protection uh which is in the business of issuing credentials uh that are related to cross border trade and travel uh uh so think about uh all the trade documents uh that are needed to be presented to a US Customs in order to bring Goods into the country and to expediate arrival uh into the country like a CT path credentials for those who are familiar with that uh piece of it that's like trusted uh Trader dog uh credentials uh that are also credentials from the people's side of US Customs and Border Protection that you may be a familiar with like our Global Entry credentials are Nexus and cry credentials and the like and last but not least uh these requirements are also um you know coming uh from another organizations within DHS uh at DHS privacy office which basically was the. ✪

Anil John: First uh. ✪

Anil John: Office that was stood up as part of statue um um within the US government itself so uh you're going to uh you're going to hear about some of the choices that we're making I also want to be very clear um in saying that these are requirements and this is not a profile and the difference is important because requirements sort of give the outer boundary of what we will not go beyond and the choices that we will be you know anchoring our implementation on. ✪

Anil John: Still need to be profiled to ensure interoperability so that is important to consider as well. ✪

Anil John: Um as we are going through them um it's we're trying to balance you know a 2 um you know high-level approaches here um and implementation should be conservative in ascending behavior and liberal in this uh receiving Behavior Uh originally published uh in the discussion section of the TCP spec um by Jon postel back in the day it goes by postel's law it's also been rebranded as a robustness principle uh I think this was a principle that was really really important to ensure the what became the internet the a philosophy uh that that was very very important in order to ensure you know broad availability and uh you know implementations of flourished uh more than anything else so that is something that is important to us and we're trying to balance that as a public institution uh with the philosophy of and not or and what we. ✪

Anil John: Mean by. ✪

Anil John: Um we we do not have the luxury of pivoting into serving you know a very small segment of the population we need to serve everybody as a public institution which means that there are different communities who've made different choices in how they will Implement them and we as an institution and an organization that need to support a global touch Point need to be able to open the aperture in the choices that we're meeting are making as well so you will see that as you are going through uh this more than anything else. ✪

Anil John: Um as I'm as I'm going through these requirements it's also important to note that there are you know 2 types of you know credentials of a lack of a better word that we are involved in uh because of the uh business drivers for our organization there are the credentials that are uh credentials for people um and uh you know we are calling them obviously personal credentials but we are also dealing with uh you know cross ber trade and supply chain and organizational credentials because we are applying the same set of Technologies to that particular domain as well so we have uh you know supply chain credentials as well the supply chain credentials are typically um you know shared within the context of online transactions but the personal credentials obviously have both the in-person and a online presentation as well so um wanted to wanted to make sure that you understood the different. ✪

Anil John: Specific context that we are dealing with in the choices that we're making here so speaking to personal credentials um we are grounded in a set of implementation principles when it comes to personal credentials. ✪

Anil John: We want to ensure that the right to paper is something that is really really um inherent and important so digital for us will never be a requirement it is a choice if somebody wants a digital credential in addition to their paper-based credentials they need to request it and they will get it but we will we will be able to um engage with them whether they are uh you know using a paper-based credential or a digital credential uh uh with at the same level of fidelity uh with the with the ability to conduct the same level of transactions in any way shape or form we definitely want to implement IDs that do not phone home and provide um uh mechanisms that eliminate uh back Channel interactions between the verifier and the issuer without the knowledge of the um uh of the holder of the credentials themselves. ✪

Anil John: And an obviously you know supporting non-track selective disclosure uh you know to provide um you know granular control over data that is released it becomes really really important for us as well and you know and obviously you know that that um you know providing that uh uh non-correlated disclosure uh is uh critically important uh it um it was a challenge to figure out how uh uh our way forward on that but I believe that we have come up with a way that uh allows us to deploy this technology on a US Government Network while uh at the same time meeting our privacy commitments to do so as well and last but not least um. ✪

Anil John: We are. ✪

Anil John: Much interested in ensuring that there is a there exists an ecosystem that is vibrant interoperable that has Choice um in the marketplace of the technologies that you are using and the vendors that you are you know sourcing uh those Technologies from uh that are based on standards and are tested and interoperable we've been too often in the past been walked into vendor specific and proprietary implementation uh that uh did not meet the needs of anyone but the vendor that was selling is that technology we are not interested in going down that path uh in this journey and that is also 1 of our you know foundational uh uh uh implementation principles for our uh personal credentials here as well. ✪

Anil John: Speaking of uh you know in-person usage of personal credentials we're going a little bit differently than uh a lot of the conversations that are going on in the ecosystem. ✪

Anil John: Start with we fundamentally believe that we have a very solid uh uh uh paper-based credential uh we we spent a significant amount of you know time threshold and attention to make sure that it is you know secure um that it cannot be you know uh replicated uh without uh a significant amount of effort uh I will never say it cannot be replicated because that would be a lie um uh but at the same time you know in the current stage of paper-based credentials uh what we call read to verify. ✪

Anil John: It also has the benefit of being an inclusive um credential that is globally usable you do not need a thousand dollar mobile phone in order to uh use that credential um and even more important from a US Government perspective. ✪

Anil John: We have no awareness of how and where that credential is used um uh when you are using a physical credential there is no phone home that is happening so when we talk about in-person presentations we need those uh inclusiveness we need that Global usage uh we need that Comfort level with the technology for people who do not want to use a technical solution and we also want that you know counter tracking counter uh surveillance capability that is built into a physical credentials to persist in whatever changes or updates that we make to those physical credentials and the changes that we are making to those physical credentials in order to enable digital verification of physical credentials enable just that it doesn't change that inclusiveness um aspect it doesn't uh uh it doesn't change the uh uh uh no phone home properties what we're doing here as we're moving from our retail. ✪

Anil John: Verify to a scan. ✪

Anil John: Code uh is and I'll I'll get into the details of that in the next slide is providing that same capability in the physical credential um that uh you currently have um you know. ✪

Anil John: Capabilities for digital verification without the you know the the correlation piece that we have with the current physical credentials themselves um in the long term we hope to move to a tap to verify capability whereby the same property persist but you basically have a much more streamlined and a local digital verification using NFC uh that also routes around perhaps uh the constraints on the usage of NFC radio's um in mobile devices and the like so when we talk about scan to verify what does that mean it's very simple actually conceptually um the input to uh creating a digitally signed barcode um uh a digitally signed uh credential is actually the the mrz um on the back of this card uh the 2D barcode uh payload is the mrz or uh for those of those like me who were break. ✪

Anil John: Raised with the Kings. ✪

Anil John: Mrz uh that is the input um in addition to the decentralized identifiers that basically provides a mechanism to retrieve the public key that can be used to verify and validate the credential that basically goes into a process that generates a core LD mechanism AKA we call it a dehydrated verify the credential that is that can be represented in a 2d barcode um it continues to you know provide that uh inclusive Global usage without the need for a mobile device we continue to have no awareness of where that credential is used um you have the ability to you know retrieve and cache the public key that can be used to verify that digital signature um so that you don't even have to make a network cop you know to locally verify that digital signature um on the on the uh physical credential itself this is our pathway for in the near-term to midterm for. ✪

Anil John: In person presentation of our credentials now does that mean that we will not go down the path or providing in-person presentation for our digital credentials absolutely we will but we want to get that right and not fast we want to work out the privacy concerns around them we want to work out the uh the openness and the ability to use the technology in a manner uh that is not constrained by platforms and the like uh to be worked out so we are we are comfortable with this approach for our physical credentials more than anything else. ✪

Anil John: And obviously um 1 thing that we are obviously using here as I mentioned earlier is uh in addition to the verify the credentials data model as a credential representation standard we are actually using decentralized identifier. ✪

Anil John: Particular did web as a mechanism for us to distribute the public keys that are associated with us as an organization I want to be very clear did Webb in our usage. ✪

Anil John: Identifies the issuers of the credential AKA uh US citizenship and immigration service and US citizenship and uh US Customs and Border Protection it is did web web is absolutely not as an used as an identifier for people uh because that would be highly correlated and that is not a path to success so we use did web as a mechanism to distribute um you know keys at scale um and that is important to us uh both for the physical credentials and obviously for our you know online usage here as well. ✪

Anil John: The for the online usage here obviously we are using verify the credentials data model and w3c uh you know DS as well um as the core standards um I think it is. ✪

Anil John: Is it is. ✪

Anil John: Very important to sort of understand. ✪

Anil John: The sum of the rationale for why we beyond our participation here um in the w3c on why we um. ✪

Anil John: Uh what what we've Chosen and anchored our standards on the w3c standards themselves and I put something into the chat right now it was a presentation that was given by you know Daniel applequist uh a who is a member of the w3c technical architecture group um you know last month at the open source Summit in Seattle. ✪

Anil John: Uh the the horizontal reviews that are being done as part of any standardization process um uh a w3c that take into account uh International internationalization uh security privacy um and a variety of other aspects of uh on the technical architecture side as well. ✪

Anil John: In the current state of Technology it is not just important to just have um you know code that works and uh you know a some consensus that the this is yearly good we we are at the stage of Technology where it is really really important that you know standards creators and standards implementers need to understand the consequences of the standards um and the choices that can be made using those standards and the horizontal reviews and the wide reviews that w3c provides you know across um the domains is critical in ensuring that the standards themselves you know bacon you know those type of aspects into what is uh what is implementable uh that tends to be sometimes you know frustrating to you know technical folks but as a technologist who works for a you know public sector entity uh there is a absolutely a level of comfort. ✪

Anil John: In having those you know broad independent reviews and people you know poking under the covers on exactly what the impact of a particular standards and Technology are uh you know before you know people like us Implement that so you know that is you know if you haven't seen Daniel's presentation or if you've not you know if you do not know about the horizontal reviews that w3c you know um you know puts every standards through uh please do take a look at the uh YouTube uh recording of um. ✪

Anil John: Uh of of this presentation there. ✪

Anil John: So um you know getting into the uh the details here um as I mentioned these are requirements wreck requirements are not profiles there is still work to be done in order to profile the standards for implementation but I wanted to you know separate what you're going to be seeing um uh. ✪

Anil John: Into you know 3 buckets. ✪

Anil John: What are the expectations of a personal credential issuer uh implemented by DHS what are the expectations of a personal credential verifier that is implemented by DHS what are the you know and obvious and what are the implications of a digital wallet that is implemented by DHS and sort of go down deep into uh into them um. ✪

Anil John: Lab between them but I also want to be very very clear that this was you know the all of these are important to us so I I you know we definitely you know uh. ✪

Anil John: Clarified each of them rather than sort of getting them lost um in a in a wholesome medal there right um the. ✪

Anil John: Uh conventions that we're using are you know coming from ISO if you're in a you are seeing you're going to be C seeing requirements with the chillon shall not. ✪

Anil John: Recommendations um you know using should and should not and permission May and may not and possibility as you see fit so moving on. ✪

Anil John: Um we start with accessibility and openness when it comes to our implementation for digital credentials. ✪

Anil John: There is. ✪

Anil John: Only 1 shall not you will see in this document and that is that first 1. ✪

Anil John: A DHS uh you know issue or shall not Implement capabilities that enable tracking of holder credential use full stop we think um you know if you are a public institution this tends to be something that is often brought up and we wanted to make sure that the choices and the technologies that we are using and implementing you know down to the choices that we make at the implementation level uh bacon you know that particular requirement here. ✪

Anil John: Accessibility is really really important so for us um the ability to use um you know web content uh accessibility guidelines um which is actually the foundation on which the you know section 508 of the US uh rehab Act is based on uh needs to be incorporated into our issuer wallet and verifier implementations as well uh we lean into and prioritize open royalty-free freely available you know standards and specifications that can be implemented by a 1-person shop all the way to a state level actor uh as the thing that we will always choose first um we require that the wallet um um excuse me we require that uh if you are an issuer the issuer needs to give um the holder the ability to choose the digital wallet of the choice. ✪

Anil John: We support our dig. ✪

Anil John: Are implemented using both. ✪

Anil John: Platform Technologies as well as native platform Technologies as well. ✪

Anil John: The when it comes to the platform and software security uh piece of it uh. ✪

Anil John: We are we will be we require the use of cryptographic modules that have been validated by the cmvp program uh which uh for those of you who if you're on the cryptographic space you know what that is but as a join program that is run by US and Canada uh that validates cryptographic modules that can be used within government networks and obviously uh we need those cryptographic key storage mechanisms to the fips 140 compliant. ✪

Anil John: Implementations rights for the uh for the verifiers issues and wallets um it is really really important that we have a sense of and a clear idea of the components that go into those products themselves so a software bill of material that clearly shares information on the sub components that go into the building of an issuer a verifier and a wallet that we Implement is critically important because when vulnerabilities come up when problems come up we want to know if any of the components of the software that we're running are impacted and we want to make sure that we are able to mitigate them um so s bombs are really really important this actually is something that is driven um and there is common agreement both across the public sector and the private sector that uh software bill of materials and visibility into supply chain um of the software itself is critically important so this is something that is a requirement for us as well. ✪

Anil John: Now we get into the some of the details of the credential formats and the digital signatures that we have you know chosen as our implementation requirement we'll start with the first 1 when it comes to credential format uh we are choosing w3c where a barber credentials data model uh that is using Json LD compacted document form this is version 2.0 of the standard as you know version 1.0 came out in I believe on 2018 or so it was then updated to version 1.1 um in around 2022 and we are you know 1 Step removed from the global uh standardization of version 2.0 for uh bcdm so uh this is a standard that is you know gone through a significant amount of uh iterations and input and we are comfortable with choosing them uh as that our foundational model um before we. ✪

Anil John: Get into the. ✪

Anil John: Other piece of. ✪

Anil John: I wanted I wanted to. ✪

Anil John: A little bit on this I've often found that within our community um. ✪

Anil John: Was a little bit of hand waving going on over the choice between and the value word of the variety of different data models that are there and in fact as somebody who is um a reader of meeting minutes from way back in the verifiable credentials working group it itself I have been semi amused to note that whenever some somebody brings up uh a desire to put into the standard itself what is the value of the underlying data format itself uh you know that cans to be downplayed um and it seems to Die the death of a Thousand Cuts more than anything else so. ✪

Anil John: I want. ✪

Anil John: We are choosing vcd uh verify but w3c verify the credentials data model 2.0 uh as the uh the core um you know credential data format for our credential uh issuance more than anything else it it starts with something very simple um a lot of people in the identity world come to Identity from the authentication side of the house. ✪

Anil John: But at the end of the road authentication is only 1 piece of the identity equation is uh you know uh needed but it's not sufficient in know the grain access or to uh do a business process for that you actually need a lot of additional information uh in order to be conveyed from 1 party to the other from a uh from a credential to a a a verifier in order to make those type of decisions it need to be combined with other types of information in order to actually make decisions so the ability to represent information uh you know uh. ✪

Anil John: Data but information so that common meaning is understand understood on both ends of the wire is particularly a pretty critically important and that semantic um understanding is possible because of the data model of the w3c vcd. ✪

Anil John: Um and it also brings another benefit here uh the ability to publish that information to the public um whether it is as a context or uh uh whether it is as um you know human readable information such that there is very clear understanding of what terms are in a credential what terms are acceptable to an organization is becomes very very important um uh the term published and discover is not mine um I actually completely and totally stole that from um a wonderful person by the name of Nancy Norris uh who works for the uh government of British Columbia who is doing some fabulous work in crossborder trade for the uh government of British Columbia in Canada and uh she used that term with me 1 time when it when speaking to Json LD and uh and I thought that was so appropriate so the ability to publish and describe uh information uh is very becomes very very possible with vcd um. ✪

Anil John: Ability to provide. ✪

Anil John: Built-in namespaces and versioning using contacts is a clear um uh capability uh for w3c vcd and there's a whole bunch of other people and other credential types that are you know that that need to you know reinvent the wheels like uh in doing you know namespaces and uh versioning using oids and variety of other you know uh namespacing mechanism more than anything else this is built-in and comes for the ride with uh you know w3c vcm multi-language support um I think uh clear example of that I think uh sometime ago I think the um. ✪

Anil John: What is the California DMV published the open Credit platform they actually showed an example of multi-language capabilities that are possible when it comes to uh you know the use of vcd so I would I'd urge you to look at that um as you all know uh the verifiable credential data model supports multiple signature types uh you actually have you know uh enveloping signature types using you know Jose um and cos um and you also have embedded signature types are using um data Integrity proofs as well we actually end up uh using uh both but for different use cases so the ability to sort of use them flexibility is a a significant benefit uh to what uh vcd brings to the table. ✪

Anil John: The ability. ✪

Anil John: Know if you are comfortable with Json Json all the apis. ✪

Anil John: Go to town if you're not don't uh you have the ability to use you know standard uh Json apis provided that you are very very you know uh uh mindful about the actual you know structure of the credential itself as written in the vcd spec itself and last but not least an example of what I mean by dehydro dehydrated binary uh barcodes is our example of using you know sibo LD a dehydrated version of verifiable credentials uh that can be resident on a on a uh on a physical credentials all of this with the same standard the same specification incredible flexibility incredible amount of power and the ability to not come up with a new standard for every other type of credential um and new data model for different types of credentials is just amazing and is 1 of the reasons that we chosen bcdm as the uh the core standard for us. ✪

Anil John: We are. ✪

Anil John: Signature format um data Integrity uh proofs for personal credentials because it solves and addresses something very very important to us. ✪

Anil John: Which is as a US Government entity we require that the cryptography that is deployed on our Network needs to be fips compliant but we also are leaning forward to ensure that we are also providing privacy capabilities like selective disclosure uh that cannot be correlated on signatures and the like those at the present tend to be could be considered uh irreconcilable but we found a way to reconcile them by using proof sets in data Integrity proofs and what I mean by that is is the ability to basically apply multiple proofs 1 proof 1 that is using fips compliant cryptographic Primitives the other 1 that is using a non-correlated uh uh cryptographic Primitives like BBS a plus uh in order to sign the document itself the fascinating thing is that we uh you know we. ✪

Anil John: We had an extensive. ✪

Anil John: Technical Authority on this 1 and um it was discovered that this is. ✪

Anil John: Up to and including cmvp validation um uh dual signatures as NYS calls them a fully acceptable in fact if you take a um a cryptographic module that contains both a fibs compliant um cryptographic primitive as well as a for example a BBS cryptographic Primitives through the cmvp program um you will notice that the cmvp program will actually um is allowed to list the non fips compliant cryptography on the fips validation certificate below the line for 1 particular reason to Showcase that it doesn't invalidate cmvp um you know uh certification itself uh so a lot more details uh take a look at the uh the background um I actually have a provided to the the relevant authoritative references from nist uh in the on the background of the slides that have been shared with you so take a look at it. ✪

Anil John: So we are. ✪

Anil John: That capability uh in order to uh uh either provide both non-correlated with signatures and fips compliance signatures so that we are able to meet both our security and our privacy commitments in the credent that we are doing. ✪

Anil John: And as I mentioned earlier we're using an implementing uh in a w3c did standard um uh before I come back to biting status list um 1 change that I will note here because it is um it is a it is a recommendation in the did standard we actually require that the did document be digitally signed to ensure its integrity and its Providence but other than that we are using uh the did standards in particular did web as a mechanism to identify us as an organization and to distribute our public keys that can be used to you know uh review and um. ✪

Anil John: Ate a credentials. ✪

Anil John: We are. ✪

Anil John: Using w3c bitstring status list for for credential status um uh checks um there is again um I will stress again and again requirements and not a profile uh if you know anything about the bit string status list you know that there are multiple ways of representing how uh you know credentials that can be um what is it uh uh uh that can only be revoked and credentials that can be revoked and suspended how do you represent them there are multiple ways of doing them so profiling is needed uh implementations matter because when you implement a bit string status list as a verifier uh excuse me as an issuer. ✪

Anil John: Uh which we are um if somebody is calling in to check the status of a credentials we actually do not know about who whose credential is being checked that's 1 measure of privacy and um that is provided but implementations matter in order to ensure that we don't even have any awareness of who is calling us you need to make sure that the verifier implements that call through uh implementing something like you know oblivious HTTP so that the identity of the verifier is also hidden from the issuer so the choices that we make in these implementations still need to be worked out and that is something that we are you know walking through very very carefully you know here as well uh we've worked out in the open with the ccg with this group uh as citizenship vocabulary that that is going to be used in order to represent the credentials that we are using. ✪

Anil John: Um and that is something that is a requirement for us as well. ✪

Anil John: Um we are also some we are also considering you know something else here as well um we believe that it is important if you are if you're an organization that is an issuer that you. ✪

Anil John: And behind your identifier you stand behind the credentials that you issue so that when somebody says that hey did Webb uscis.gov means us uh CIS itself usci we want to make sure that there is um you know there is a mechanism that allows a counterparty to actually you know verify that that domain and that identifier actually belong to a legitimate US Government editing. ✪

Anil John: You can read faster than I can I also put into the chat um 1 of the things that we are looking at high Assurance did with DNS uh the in general at a very high level uh I mentioned earlier that you are signing the did document now in order to validate that the document you obviously need a you know public certificate uh this High Assurance did with DNS provides a mechanism whereby you can basically put that public certificate that signed the the document in the tlsa record of a domain um so like uscis.gov so that you have and the ability to ensure that a legitimate dog gov domain uh is indeed the authoritative owner of that um uh of that identifier that is then used to basically you know issue those credentials itself uh again uh take a look at the high Insurance did with the. ✪

Anil John: Piece that I put. ✪

Anil John: It is something that we are seriously considering um primarily because it doesn't require any new standards or capabilities you have the ability to use existing you know did uh uh Technologies as well as DNS Technologies to actually uh you know get to the capabilities that we're talking about here as well. ✪

Anil John: And let's see. ✪

Anil John: Issuance protocols this is all this is definitely something that we are we are going to be testing very carefully um. ✪

Anil John: Let's start with the in a Basics here we intend to support multiple issuance protocols full stop because we have a broad set of communities that uh that uh that we need to serve the choices before us tend to be on the issuance side VC API from W3 cccg and oids for VCI oid 4 for VCI from the digital credential protocol group at ovf. ✪

Anil John: Our choices when this moves from TBD to this is a choice is a contingent upon the issuance protocol actually supporting the credential format in the digital signature mechanisms that we've just talked about we're not big Believers and let's put it on paper or let's have a t-shirt or anything like that uh uh to uh to say that we supported we are going to test we are going to verify and only after we are confident that our credentials are security formats and uh the choices that ensure privacy for our customers and security for our customers are you know are supported by those issues protocols will we basically move from a TBD to an actual actual choices between them but the as as you note here this is something that the the the the the the 2 choices that we are actively evaluating are those 2 uh that that you see here. ✪

Anil John: So moving on to the credential verify piece I think a whole lot of this is you know is duplicative I will just call out the things that are you know different more than anything else uh the only thing that I will see here is the last statement on the verifier uh May Implement additional credential data formats and Associated proof mechanisms um. ✪

Anil John: We require the things that we are talking about about their for credential formats and digital signatures we have reserved the right to you know validate and verify additional credential formats are Downstream we don't have any at this point in time but this is uh we we are leading open that possibility and particularly for you know there are companies that are implementing these capabilities under contract to us we wanted to make sure that they have the flexibility based on their um you know customer needs and things like that to support not just our requirements but also the requirements of others as well that is why that language is there um. ✪

Anil John: Only difference here on the metadata is that obviously this is the reverse if you're going to sign the did document you better verify the digital signature on the did document there as well. ✪

Anil John: And you've seen this before. ✪

Anil John: From The Exchange protocol side the same caveats as before with 1 Edition here we are actively tracking the digital credentials API work uh in the w3c Wai Sig which I believe is um you know uh potentially moving into the Federated identity working group itself uh I think the the feedback that the w3c staff collected um from the community uh on what uh that work needs to Encompass is spot on and we support them um so we are actually tracking that as well so for the present presentation piece uh that is important we also hope that uh it will also include an issuance piece as well so um if that if that becomes real we it will also be a choice for our issuance protocol as well. ✪

Anil John: Um on the wallet side uh. ✪

Anil John: Same here. ✪

Anil John: Here uh nothing new that you will not see uh you know specific details around how you sort of present the credentials and things like that but as far as the credential form as a digital signatures uh you absolutely uh you know uh you're going to see consistency here and obviously in a wallet um we want we you know we are going through the process and we will go through the process on figuring out you know what is an acceptable wallet I don't think the community has done enough work to understand the security privacy and interoperability criteria that 1 can use in order to judge the quote unquote goodness of a wallet um so um so what that basically means is in addition to our own wallet uh that we uh that we would have we fully anticipate uh the ability to issue credentials into external wallet that we can all agree on a common based on of security privacy and interoperability. ✪

Anil John: Actually support credential types that are Beyond um what we have outlined as our requirements and that is perfectly fine so that last data uh last statement is very much focused on that um. ✪

Anil John: Insurance protocol and the exchange protocol piece is you know definitely the same um normative references for personal credentials but I also wanted to basically touch on our supply chain uh uh and organizational credentials piece as well. ✪

Anil John: You will notice that um when it comes to the credential format and digital signatures we actually have the same credential format Json LD compacted data form of w3c VC data model. ✪

Anil John: We are using a different signature format we are actually using you know w3c um you know securing w3c VCS with Jose and co uh specification uh and in fact using Jose as the uh digital signature mechanism it is very simple for why we are doing it on the trade side we do not have a non-correlated ability requirement and we do not have a requirement to simultaneously provide you know fips compliant and non-correlated signature if you know anything about the supply chain it is entirely about getting deep visibility into the supply chain of goods that are moving into the US um we want to you know go as far as far back to the origin of goods in order to understand whether uh these goods were created using forced Labor uh these uh these were transship to other entities in order to import them into the US so uh correlate with ability is something that happen. ✪

Anil John: Happens within the. ✪

Anil John: Chain credentials uh and organizational credentials so we do not have a non-correlated ability a piece uh within the supply chain piece we do not have a selective disclosure uh requirement currently within the the trade piece as well so that is the reason that we've chosen the other signature format uh for here and separately you know we are also again we're using the um bit string status list as the um uh revocation mechanism and we're using Trace vocabulary as a mechanism for sharing our vocabulary with the public and what we expect. ✪

Anil John: The 8 the actual Protocols are actually an A A variation on an oath based protocol that was defined under the w3c called the trace API links are in the normative guidance here. ✪

Anil John: So that. ✪

Anil John: That is that is something obviously fits naturally with the organization to organization credential flows for um you know uh for supply chain credentials so I know that that I've gone through again uh very similar variation on this 1 as well I know that I've gone very fast through all of them and I wanted to stop there just to at least you know take any questions that you might have on the line. ✪

Anil John: For sure and in fact uh I actually will punt that to minus Pony who's waiting on the line I'm sure that who can speak to that much better than eloquently than I can. ✪

Benjamin Young: https://json-ld.github.io/cbor-ld-spec/ ✪

Manu Sporny: Thanks Neil I don't know about eloquently um so Arin um the the specification was moved um uh into the Json LD community group uh so it's been adopted that's why the Old Link you're using no longer works there is a plan to take its standards track in the next iteration of the Json LD or linked data uh community group um it it does the their in 1 of the things that we're looking at is kind of the versioning of the compression dictionaries and and things of that nature um right now you kind of need to understand you know what type of credential you're going to be reading um before you pull it in um so all that to say happy to engage with you more on the Json l in the Json LD group or in the upcoming working group uh to you know um help with implementations I will readily admit that spec is dragging behind the other ones just because. ✪

Manu Sporny: There's so much other work um you know around uh the the current setup work uh in any case yes uh happy to happy to sync offline uh on that. ✪

Anil John: I I don't look at it that way so 1 of the things that is important to understand at least about the you know what what we call you know dot gov binding here right is that uh it's important to understand that the dot gov top level domain is actually managed by the US government in fact it's actually managed by a part of DHS cisa um and it's only uh available to you know US Government entities whether it is federal state local tribal or Territorial and there is a very stringent process whereby um an entity will be provisioned a.gov domain um uh uh you know uh. ✪

Anil John: Wanted to basically leverage that to ensure that if you are interacting with the US government entity you had full confidence that entity was a legitimate US government organization so um. ✪

Anil John: So the ability to provide a linked cryptographic link between the dead web and the dot gov domain that uh allowed for that verification to happen is really really uh a valuable for us so uh. ✪

Anil John: Stop there Phil I I know that if you read the spec itself um and I would recommend that you speak to the editors whether it is you know Tim Boma or the folks from Sir which is a Canadian registar as well as mattea's from northern block um it can be you know used with any domain so there is Broad applicability but we want to sort of Leverage The Real Estate that we have access to in order to ensure that we showed The Binding of ourselves as a legitimate government entity. ✪

Dmitri Zagidulin: Thanks um and thanks again Anil this is fantastic as usual I was really happy to hear you mention that you'll be signing the did Webb did document uh so that's always good and I'm hoping you're keeping an eye on some of the did Webb enhancement proposals like trusted did Webb method uh which basically. ✪

Dmitri Zagidulin: Had the signature to the document and then add a signed log of key rotation events. ✪

Anil John: I am absolutely uh keeping track of it um I I love the work that uh the government of British Columbia recently did on this 1 and obviously you know have you noticed there's a theme here uh this work came out of the Canadians as well um so um I'm really glad of the work and keeping track of it uh you know anything that sort of uh you know gives High assurances to the decentralized identity um uh dids uh is a good thing in my mind um so we definitely definitely keeping track of that. ✪

Anil John: Um my the requirements that I spoke about are the requirements of um the the entities that issue cross border trade and cross border you know travel within the US government which tends to be US citizenship and immigration services and US citizenship at US Customs and Border Protection uh those are the issuers of those credentials uh those credentials in general are used broadly um obviously if you are moving uh any Goods into the US you are going to be interacting with US Customs and using these credentials so that's public sector private sector you know globally um the our digital immigration credentials are used for everything from kyc to showing you know residency um and employment eligibility in order to apply for a job so the usage of the credentials tend to be uh you know both uh much broader uh but the issue. ✪

Anil John: We are the issuers. ✪

Anil John: Um this is where Anil John the technologists who works for a a a for a US Government entity becomes very very careful because you just crossed into the line of Regulation and law um and I prefer not to opine on that what I will note is for our verifier you will notice a couple of specific uh languages here that I'm showing here um we note that um in general when a negotiation happens between a digital wallet and a verifier on which you know uh cryptographic um you know signing scheme in order to use in order to share um information. ✪

Anil John: That the verifier should prioritize the minimal disclosure of data and metadata by the holder um uh when negotiating a mutually acceptable proof. ✪

Anil John: And I will leave it at that I think um there are I'm sure there are folks from the uh you know from the policy side from the privacy and civil liberty Community sides who can basically probably share more information on what it would take in order for verifies for that to be binding uh on it we do not have the equivalent regulation perhaps that the uh the the European Union or other countries have in not a sort of make that binding on a verifier. ✪