How do You Know Who to Trust?

All right, thank you very much Mike. Thank you all for being here. One correction, Mike, I am no actual, not actually any longer at Microsoft. I am an independent consultant and enjoying that role very much so. How do you know who to trust? It's a fundamental question and it has implications for both human relationships and the systems we build. And we'll talk about how we can do that using a specification in the Open ID foundation called Open id Connect Federation.
So there's two elements to trust online that are both important. One is securely identifying who the party is that you're interacting with. That's foundational. But for higher value interactions, you also have to know are you on the same page in terms of your legal agreements or your trust frameworks or your terms of service? There's this notion of large scale federation that's been around for, well more than a decade that the SAML people in the research and education world helped pioneer. Some of them are in the room. And so for instance, I, if I have a login at the University of Washington in Seattle near where I live, I could potentially access resources at the CERN Electron Collider in Switzerland. And it's not that the University of Washington and CERN have a bilateral agreement, they do not, but they're both signed onto a set of federations and inner federations that their lawyers and department heads did sign contracts such that CERN then would know with my UW login that who I am and that I'm eligible to access these resources, some of which may cost a lot of money or other coins of the realm. So there's both identity and compliance to enable higher value interactions.
An important point, and thanks again to Giuseppe DeMarco who's going to join for the second half of the presentation for putting a lot of these slides together. He made an important point that trust online needs to be renewed occasionally, just like trust and human relationships is renewed. I saw people here this week that I haven't seen in a year, some that I haven't seen in four or five years because of the pandemic. And it's wonderful to renew the relationship and build new ties together. And in the online world we do the same.
So a question gets asked, isn't TLS good enough that PKI certificates to establish who you are and to establish trust, it is enough to establish who you are. In some sense that open ID connect, which is one of the specifications I worked on, does use trust in the TLS certificates and some validation protocols that you control the URL to identify, for instance, an identity provider. And that's important, but you know, a spammer or a Fisher can get a TLS certificate unless you know some things about the party that they're trustworthy for your interaction, the fact that they can reliably encrypt material to the attacker's endpoint doesn't do you a whole lot of good. So open ID connect, as I was saying, does enable you to securely identify in terms of a url, the participant, that's great, but it doesn't answer the question of whether that participant should be trusted by you for any particular interaction. So a complimentary mechanism is needed to do that. So
I talked about this notion of federation where large numbers of parties get together to agree to cooperate and share resources. The prototype description of that is again from the research and academic communities, a lot of which is in Europe, the Netherlands, the Nordic countries in common in the United States, lets almost all the major research schools and research institutes have their students, their professors, their research scientists collaborate in real time. And there's some very simple practical, well not simple but very practical services like EDU gain for enabling the sharing of network services in real time. But if you had hundreds or thousands of parties that you wanted to interact with and that meant you had to sign hundreds or thousands of legal agreements, you pretty much just wouldn't do it. This notion of federation, let's use sign an agreement with an entity like in common or EDU gain or the NOR folks or what have you, and go to town.
So that brings us to the Open Id connect federation protocol that in all full credit to the SAML two people, they managed to establish large scale federations, but in such a way that for instance, they were concatenating all the meditated together into a file that just got really big and FTPing it out every night. They've moved past that and good for them. But it was partly that experience that led Roland Berg who did work on the SAML federations to say, you know, we can do this differently. We can let each party host the metadata about itself and those who need it can collect it in real time.
Another thing that's important in federations is enabling the federation operators and the organizations and the departments to apply policy to the way you interact with the protocols. The simplest one to explain is there might be a policy that you can only use certain signing algorithms and you can't use others. And there's ways of hierarchically applying that policy to construct the metadata that's actually used about the entities. The other thing that's important and the bottom line's gone on all my slides, but I can remember what we said, that unlike the SAML federations by design, this protocol and set of data structures enables you to be in multiple federations at once. So you might have trust up to in common in the United States, you might have trust to EDU gain, you might have trust to the Nordic Federation and those don't conflict with each other. They live alongside.
So trust here in these federations is hierarchical, it is not decentralized. You are deciding that a federation operator, the trust anchor operates a community that you want to participate in and you sign their legal agreements and in fact the organization probably signs it then maybe your department is controlled by your organization and there's different kinds of entities that can be under each. Here I'm showing open ID providers and relying parties. It could be also oof authorization servers, et cetera. And we designed it in such a way that if you wanted to host SAML metadata that way, you certainly could. It's an extensible metadata structure. This is a related diagram that indeed shows the fact that participants can be parts of multiple federations with different trust anchors. This diagram is inspired by the Italian federations note multiple federations, which some of the colleagues in the room will talk about in more detail in another session, but it's not in conflict to be in both federations or just one or none.
So what is the core thing that this protocol and data structures do? It's trust establishment. The ability to ask the question and get a cryptographically provable answer is this party that is seeking to interact with me in a federation that I'm also in so that we have a legal and trust basis for interacting or failing that a legal basis to choose to decline to interact. This all happens via something called trust chains. Remember those pictures I showed you that you have say a relying party that's part of an organization that's part of a trust anchor and there may be multiple levels of intermediates. So you get a set of cryptographic assertions where parties sign things about the parties below them and you can build those up in real time. And this is a graphic illustration of the different data elements that are part of that trust chain ending up in the trust anchors and starting down at leaves.
And so for an identity provider, you'd have one trust chain for a relying party, you'd have another trust chain, both of which are cryptographically verifiable, just like in some sense an X 5 0 9 certificate is also a sequence of cryptographically validatable statements, some attributes about the trust chains, it expires. There's expiration dates on the signed data structures. They get renewed asynchronously to each other by the participants. No centralization is required to do that. Everybody can update their own signed statements at a time of their choosing. Once you have a trust chain, the only keys you need that aren't self-contained in the data structure to evaluate it are the keys of the trust anchor. Also, it's interesting that these data structures can be verified years in the future. So there's non-repudiation, you can't say as long as the keys are held in the future that you didn't participate or you didn't make this statement because you can inspect the statement in the future.
So more about the trust chain, I'm gonna go a little faster so that gspi gets some time. For those of you who know Jason Webb tokens, this is a redacted snapshot of a trust chain. And the point is that the keys are in the chain, the JW K, what's shown there is just the key IDs, not the actual keys. The real data structures have keys. And so you can look at the trust chain, you can check each of the signatures using the keys in the chain and you're off to the races I mentioned before. Another aspect of this is you can apply policies just like you can in the SAML federations.
And you know, once we started deploying this for real, we discovered, oh well you can always walk all the data structures by doing HTTP gets, it's more efficient to let the participants prefetch all that and send it as a parameter. You can always go out to the public internet and check the stuff, but being able to prefetch makes it more efficient and that's used in the Italian federations among others. I'm now gonna turn it over to Giuseppe after I say that this is being deployed or is has been deployed both for classical federations but also in the open ID gain globally assured interoperability network prototypes again for trust establishment and some of the people in the room are involved in that as well. Gibe, take us away my friend.
Thank you Mike. Hello everyone. And well, Mike, thank you for your awesome presentation. Well, can you hear me?
Y we can. And when you want me to change slides, tell me
Thank you. I assume that we should start from the slide 17 and well first of all, I want to apologize to everyone for not being today with all of you in Berlin. And sincerely, I want to thank the organizing committee of this wonderful conference for having hello me of being able to speak remotely today. Well, I'm Giuseppe DeMarco and I work for the Department for Digital Transformation of the presidency of the council, of the Minister of the Italian government. The mission of my department is to lead the strategy for national digitization and the theme of digital identities is fundamental in our s Well, today I have the pleasure of sharing the experience we have gained in Italy with Open Connect Federation. I want to tell you how we discovery, what we were looking for and which requirements we had in mind and how we appreciated what it offered us.
Please, Mike. Next slide. Where we have speed and cheer. Well first of all, I'll tell you very briefly about the two digital Italian digital identity system, the so-called speed and Shia, whose main difference lies in the number of identity providers and the organizational model. Speed is managed by a government agency, therefore by the public sector, but it's identity providers are a private organization operating in the free market. CHI is greater governed by the Ministry of Interior and is linked to the electronic identity car. This two identity system are technically similar. Born with the SAM two protocol, I had the pace for contributing to the maintenance and evolution of this SAM two base infrastructure. And then later on I had the opportunity to contribute to the consolidation of the open id connect technical rules based on the open id connect IGO specification. Well, this technical rules about the Italian Open ID connect system had everything needed to work, only one thing was missing, which technically can be indicated as the secure mechanism for the distribution of metadata. But more generally I prefer to call it as the trust model which goes far beyond metadata alone. Please, Mike. Next slide. Therefore, together with my colleagues from the organization that govern speed and sh we started looking for a solution. Then we start for our analysis from the requirements. This were basically three. The first one is that all the participants of the federation had to publish their metadata in a public resource, not only the identity providers. Mike, did you say something?
Your Italian friends are helping me be on the right slide. Do continue,
Yeah, thank you. We are 19. Well, but the Orion party as well have to publish their metadata on a public resource. And then the metadata needed to be certifiable by trusted third party, which Mike explained to us as the trust anchor or intermediate. The second requirement is that we have to identify interation mechanisms such as to enable trust organization in the accreditation and testing procedures of new participants on behalf of the federation authorities following the principle of delegation. And the third requirement is that we was looking for a way to issue sign attestation that are verifiable over time, even when the participant cryptographic keys would've changed a profile that would not any participant to replicate an action even if they occur years later in the past. Well next slide. Thank you guys. The first thing I like to mention is that thanks to Open Deconnect Federation and its historical key registry and point, we have a revocation mechanism and also the history of the status of no longer user keys, even if expired. Considering that an open Deconnect Federation trust chain can be validated with only the public here of the trustco, we have found by that by storing an ID token issued by identity provider or an authorization request issued by our line party for instance, with the trust chain related to the issue that signed artifact, we are able to validate in the present I in the present a digital signature that occurred in the past. Even if the key has to,
We have two minutes. So do do what you can in the two minutes.
Yeah. Okay. Well, well what we found next slide. We found a single endpoint for publishing metadata seen assured by party and also we found a specification that clearly defined role of the federation terminates. And also we got intelligent mechanism to specify Porwal information of federative technical or administrator administrative nature without inflating the open ID collector metadata with extreme customization. Precisely, I'm talking about the trust marks with a sort of verifiable attestation that certified the participant compliance with certain profiles such our online party that came and data for underage user for instance, please. Next slide. And also we discovered two things that we didn't think exist. The first one is metadata policy. Mike talk about this, but I would like to give a quick example. Thinking for one day a signature algorithm were to be broken and consequently expose the entire federation to danger. In this case, the TRUSTCO only needs to publish a policy that decide disables the vulnerable algorithm within all metadata.
All participants upon updating the trust chain by the participants, the application of the policies would remove the vulnerability with, with certain times and without sending massive emails. And we finally have discovered that it's possible to give all participants the freedom, the freedom to modify their own metadata. We don't require bureaucracy or notification to third party please. Next slide. And while and having learned so much thing, we wonder if in fact, open a Deconnect Federation is a public infrastructure on steroids. And while the answer, the answer was no, but also yes in this slide, I enjoyed making a comparison with a well-established technology called X 5 0 9, which in turn had already introduced the concept of chain in what it defines as a certificate chain. The question is what are the differences between a crossing PK infrastructure based on X 5 0 9 and the new infrastructure based on federation?
Well in Deconnect Federation, the could sequence of the attestation are not certificates but signed jot. So they cost less in terms of storage. The funny thing is that technical federation may also publish X 5 0 9 certificate chains, but probably once implemented correctly would this would no longer make sense. And then the vocational mechanism are not some kind of extension, but they are already implemented in the Court of Federation specs. And then federation comes with a rest API that allow to navigate the relation of trust between the participant in a transparent way and and then metadata policy. And definitely definitively it is a jolt. So it is simple. And if we assume that simplicity is a feature, well JWT has always a feature more than other technologies. And while I've completed with the last slide, well the time has come to say goodbye. And I want to say goodbye by looking to the future, which is what we look into when we talk about digital identity wallet and the new digital identity paradigm.
A place that we want to reach with our robust and scalpel model of trust, the guarantee citizens that they can trust, those who value, trust and mechanism, how to establish it not as something extra or or engineering, but as a requirement without which all would be lost. After all, we know it is well known that the, when there is no trust, everything fails and not just the markets. And I'm aware that how necessary about how necessary it is for European citizen to be able to trust their wallet, just like a blind person can trust their walking dog because the risk of digital are not visible to the eyes of everyday life. And I learned a lot from Open Connect Federation and I can say that it is thanks to this specification that when I think about wallets, I think about how the trust model should work according to a concrete decentralization mechanism to artist trust, which is technically verifiable in years to come. And today I was really happy to have told you how the trust chains and method policy play when managing large dynamic changing environments with the requirements of the highest possible level of security. Thank you.
Okay, thank you very much Michael and gpp. And I think this illustrates how this fundamental technology is so important and really we didn't have enough time in 20 minutes to go through it. So I'm going to ask one simple question. So Mike, is there anything left that keeps you awake at night?
Gosh, yeah. Come to my keynote tomorrow. I'm talking about Kim Cameron's vision of building the Internet's missing identity layer and we're on the path to do that, but, and we've made progress, but there's a lot to do and it's very multifaceted and I'm pleased to be here with Giuseppe and all my friends to do the work.
So thank you again, Michael in Gue.