Decentralized Identity and the US Dept. of Homeland Security

Yes. So hello, I'm Marcus a from Daniel tech, we are a company in Vienna, working on decentralized identity technologies were generally quite involved in community and standardization processes. It's nice to be here again. It's my first in person conference in a long time.

And yes, I've been asked to talk about what the us department of Homeland security has been doing. And maybe it sounds a bit strange that a nation state or a government is heavily involved in decentralized identity, but it's not a contradiction. I think it, it does make some sense. The DHS in, in the us actually has been involved with decentralized identity from, from the beginning. They funded the initial development of the first version of the D specifications. So without them, this community and industry wouldn't have been able to, to come to a point where it is now.

And so what are they, what are they doing now about, about two years ago, they started a, a program. They have something called Silicon valley innovation program, which is a program where the us government works with startups, with small companies that have some unique or some interesting knowhow and products in, in an area that is of interest to DHS or to the us government. And they do this on a number of, or on, on a broad range of different technologies. So it's not just about digital identity, but specifically about digital identity.

They started program, like I said, about two years ago to try to basically apply these new technologies, DDS and verifiable credentials to use cases and problems that they have in their own day-to-day tasks and processes. And basically the motivation is the same as what we see with many other organizations and projects that use very fiber credentials it's to try and come up with digital versions of, of traditional paper based credentials that are more secure and more efficient. And in this case, DHS is dealing with credentials, such as citizenship or immigration related credentials.

The most interesting one in this program has been the prominent resident card, the green card, but also other things employment related at, at the stations or licensees, and then also more organizational identity and supply chain related things. So from a basic idea, how using DDS using very fiber credentials with issues and holders ands, it's quite similar to, to many other projects in, in this space, but specifically applied to what DHS as an institution is dealing with.

And in the course of this program, they, they funded a number of companies about 10 startups like ours, but also others that were working on these concrete tasks. And they could be roughly speaking the companies and the, the tasks in this program were divided into two groups. One of them is digital personal credentials. So that's the green card. That's the permanent resident card, also employment related credentials, proof of age credentials. So things related to individuals. And the second group in, in this program was more about digital trade supply chain, import of goods.

If the, if the, if goods are like steel or lumber or, or other things are important in the United States, then there's a certain process. There's a lot of paperwork right there, traditional paper based credentials or the second group, or the second set of problems had to do with, with that with trying to replace supply chain or trade or import related paperwork with verifiable credentials. And so over the course of the last two years, our company tenure take with about 10 others, we worked on in a number of phases. So there were two phases so far where we first built proof of concepts.

And then we expanded more and more trying to simulate these, these processes and trying to come up with digital equivalents to the traditional paper based approaches. We used the, a lot of the standard technologies that we also see in, in a lot of other projects and in initiatives, decentralized identifiers, verifiable credentials, chase, and LD.

And I will go into a bit more detail with some of them to see what, what exactly we've been doing, how we've been using them, link data, signatures, different types of APIs that have emerged in w three community groups, revocation different did methods. So because, because what is two different groups of, of tasks, right?

The more individual personal credentials, like a prominent resident card on the other hand, more supply chain, organizational credentials, the choice of technology was also different sometimes right in the earlier talk carton was, was talking about a spectrum of privacy and full transparency on the other hands. We also used different D methods. For example, in this project to address different use cases. One of the technologies that we started to work on in the, in the beginning was just the set of vocabularies, right?

So to model very fiber credentials, what you see here is an example of a digital permanent resident card using a citizenship vocabulary that has been developed in the form of a chase and LD context. And then we developed several other VOCA, other vocabularies that were used in the program related to vaccination related to employment related to appointment. If you have an appointment at a, at a DHS or immigration office, then that appointment could also be modeled as a verifiable credential vocabularies related to traceability for tracing import, imported goods and other things.

And all of this has happened in a W3C community group, the credentials community group, where a lot of specifications are being developed. This was one of the requirements in the whole program that vocabularies and also APIs API definitions had to be developed in the open, right? So the government was very insistent on, on the fact that there must not be any vendor locking.

There must not be proprietary APIs, proprie, proprietary interfaces, all the interface definitions had to be developed in open community groups so that any vendor could implement them and could provide and or could build a product here, here, you see something called chap credential, handle API. That's what we used for interfacing with the holder wallet. That's a specification for storing credentials in a, in a wallet and then requesting credentials from a wallet.

These, these two go go together, credential, hand API, and in the W3C credentials community group, and verifiable presentation request as a language to specify which credentials are being requested. So all of these things happened in open community group. Same for this one. This is receiving a lot of attention right now, verifiable credentials, API.

So this is an API for that, an issue or that a, that an issuing software or verifying software would expose if DHS, for example, they played the role of an issue when they issue verified credential, they may buy product from one of the companies in this program, and then product of that company must again, implement these standard APIs for issuing and verifying credentials. So that from the perspective of DHS, they could easily replace one vendor's product with, with another vendors product.

And this is also one of the pieces that we developed specifically within this program, DHS Silicon valley innovation program. And since then it has moved into W3C credentials community group, and now is receiving much broader contributions and, and, and interest.

Also, one thing that's been very important throughout the, the program is not just developing specifications in an, in an open way, but also testing them and having concrete approaches and strategies for testing interoperability between vendors. So again, this was one of the core principles in the whole program that I must not be vendor login lock in or proprietary interfaces, but it must actually be possible to, for different products from different vendors to be ient. So we tested really two things.

We, we tested on one hand standards conformance. So we wrote test suites where the products of the individual vendors could be tested for their standards compliance to actually issue standards, compliant, credentials, and can they verify them? So that's one thing we did, and there's a there test suites for that. But the other thing we did was also to test interoperability between vendors, basically in the form of a matrix where we said, let's try to issue a very fiber credential, such as a prominent resident card using the issuing software provided by one vendor.

Let's put that into the wallet, provided by a second vendor, and then let's try to present and verify that using the software of a third vendor. So to really build an ecosystem. And we tried lots of combinations, right? Like a matrix, trying to, to test all the, all the possible combinations of, of that.

And again, this has also been developed in, in the open and open community group. And by now also companies that are not part of the Silicon valley innovation program, but are part of the broader community, also contributing to the test suites and applying them to their own products. And this is, has been really fantastic. I think both for DHS, but also for the community itself. Often we found things that were not working, right?

So here you see a sample test report and you see actually some failures and that could mean it could mean that the product that is being tested has a bug, but it could also mean that the test suite has a problem or that the standards have that the standard has some bug. And this is really useful because if we, if we didn't do it like that, then if there were only proprietary products sold by by vendors, then they would still have bugs, but they would not be detected and documented in an open way when I'm moving in a, into a third phase, which is getting more concrete.

So in the first two phases, we've been building proof of concepts and trying out things. And now in the phase three, which is starting now, it's really about testing products and testing the technologies in a realistic settings. We will try to simulate integration of our products with, well, not with real data yet as early for that, but with a simulated environment, that's hopefully as close as possible to, to the actual existing DHS infrastructure and processes.

Again, there are these two groups, digital, permanent, personal credentials, digital trade credentials. They are now, now nine companies in the, in the program. And we will, we will look again at these different, different types of credentials, different use cases, but become more realistic.

And, and did you want to take a photo? Phil has the slide slide again, these are the, so here's a list of topics that we're probably going to phase now in this phase three, as everything is supposed to become more realistic and more usable. First of all, there's some ongoing work on reviewing security and privacy of deeds and methods. There's a company in the us Sri international that has sort of independently evaluated the security and privacy of DS as a technology. In addition to that, SBA research is a company in, in Vienna that we have worked with the evaluated different did methods.

You may know that there's a tool called did rubric, which is a set of criteria that you can use to evaluate different types of deeds. How decentralized are they? How secure are they, how privacy preserving are they? So we did some work on, on that.

And DHS, basically, they want to know which D methods should they use, right? Should they use deeds on sovereign, maybe as we we've seen in the last talk about travel paths, or should they use Ethereum as we've seen in the talk before, or should they use some other di methods like did web did key and they all have pros and cons, right? So probably in this phase three, there will be a focus on really deciding which did methods will fit, which government use cases.

Another, another field of work right now is the verify credential HTTP API that I talked about before. So the integration with issuing and verifying components, the APIs that enable that there's some open questions. So some community processes to, to evolve them. There's some questions around authorization who is allowed to use these APIs. How do they integrate with existing systems? That's going to be one of the topics. CBO LD is a interesting new piece of technology for encoding chase and LD based verifiable credentials in a QR code using some very advanced, semantic compression techniques.

I expect we will spend some time working on that. Also this one did resolve us public key. Reservers is something that we don't talk about so much.

It's, it's somehow always assumed always implicit, but it's something that's really a key, low level building, building block or fundamental process that happens all the time. When we deal with very fiber credentials or did oath or, or agents or wallets, there's always a process where deeds are being resolved, right? It's just as fundamental as resolving a domain name to N IP address.

And what, what has been mentioned by, by DHS is also an interest to consider it did resolve or not just as something that's built into some other piece of technology, which is what we see right now. Most of the time we see products that can issue and verify credentials, and they have a little did resolver built in because it's needed for that. But there's also an interest by DHS right now to start considering this is a separate first class built piece of functionality, just like many organizations, they host their own DNS infrastructure, right?

You can, you can do that. You can consider a DNS resolver as a separate piece of software and it's is going to happen. Also with did resolves that DHS, for example, could host its own dedicated, did resolver or public key resolver instance. And finally, some topics that I think we can expect what is phase three now, cryptographic standards, right? Every government also, of course, in the us has some idea of which cryptographic operations are allowed and considered secure enough or not in the us. There's a set of also called FIPs approved cryptographic standards and key types.

And you can't use anything that's not approved on, on these lists. So we will have to take that into account. There's some open questions now about wallets and which wallets will actually be used for holders. We haven't really spent a lot of time on that in the first two phases. So what we'll probably look into that more now in the third phase, and then I have to be open and transparent about this as well. Those of you have been following the work on, on deeds in the W3C may know that right now there's a process to promote deeds to official W3C recommendation.

There have been formal objections to that standard so that if there are some large companies that say that they think it's not a good idea for deeds to become a standard the same time in the community. We see some alternative ideas, some people, and some projects, challenging deeds and coming up with alternative proposals and something similar also in the area of chasing LD based verifiable credentials, they also other credential formats, other proof formats.

My personal opinion is that D send Jason LD based very fiber credentials are exactly the right technology and that these objections are interesting to consider, but should not really cause a lot of concern. But I put this here on this slide, because this is also something that we will have to address and analyze. And finally, I'm not sure how much time I have left, but just a minute, just the final concept is global interoperability. What we call network of networks, I think is becoming more important. We have a lot of projects around the world. We've heard about some of them date DHS.

What they're doing in the us is one thing that's happening right with specific use cases. But there's also for example, EBSI the European blockchain service infrastructure here in Europe. There's I union here in Germany, very important, many other SSI initiatives. And so one very important question, I think for this DHS phase three, but also for the community as a whole is interoperability also between these projects.

If the, if the DHS in the us issue a prominent resident card, and for example, will it be recognized by a member of the I union consortium here in Germany, or will it be recognized by a finished company that's on the EBSI network, that's promoted by the EU commission and similar in, in Canada and in other other jurisdictions. And that's it. Thank you. Here's our contact information. And some of the things that we're working on.