Hi. There's no possible way I can live up to the hype that Katrina has created about my presentation, but I hope you come away with from this, with something having learned something other than the fact that I was probably correct in abandoning my early career as a graphic designer. My music career is another question, which I still regret. So moving on, back in, in the beginning, the early days, we had simple trust relationships on the internet. We had identity providers like Google, who you were a relying party.
You went to Google, you signed particular terms and conditions, you got a client id, you managed to connect to Google. Everything was good.
So simple bilateral relationships based on some sort of contract.
You know, we grew some fairly large SAML deployments and other things, you know, but I think on average, connecting a SAML SP to an IDP was taking something on the order of three months in some cases, which is one of the reasons why some people moved away from manually provisioning SAML connections. But this is the, the trust relationship here is at least understandable. So that developed into sort of hub relationships or using proxies to mediate the trust.
So this could also, you could also think of this as a credit card relationship where you have visa in the middle and you have issuing banks and acquiring banks that you know, all have contractual relationships and you know, one contract, everybody agrees to it, but all of the transactions have to physically go through, go through the, the central mediator.
Then thanks to people like Scott Cantor and Eve Mailer who's here, we developed a way of separating the trust layer from the protocol.
So we developed SAML metadata, and I have some, an example of this is not how actual authentications work at the protocol level. At the protocol level, you can be at Duke University using their IDP to log into the large Hadron Collider, assuming that they give you credentials or you've broken in, which would also expend explain the end of my academic career.
The, they didn't really need the mainframe all the time. So there are direct relationships.
You know, the protocol allows you to log in from an IDP to an sp and the trust is a hierarchical relationship between these entities. In common, which is the US Research and Education Network has roughly 600 IDPs and 6,000 sps. We have swed, which life is not paying attention because he already knows all of this.
And one call out to Umea yay umea and 60, 62 entities in swed. There's 76 other national research and education organizations, and I have no idea how many thousands of five, 25,000 entities.
So this is a lot of trust relationships, and this is, you know, compared to most other identity systems, this is, this is as far as I know, the largest and most complicated deployment. And this is possible and entities move in and out of this fairly quickly because there's standardized trust infrastructure that that happens outside of the sort of inline, outside of the sort of individual transactions. And one of the other interesting things about this is that at the edu gain layer, we have something called entity categories. So not all entities in this federation are actually treated the same.
So you may get different attribute bundles, SAML attribute bundles, depending upon whether or not you're, you have a trust mark saying, I am an educational institution as opposed to I am a crappy commercial retailer who like Microsoft, who just wants, gets to know whether or not you're a student to give you a discount.
So that's not unlike some of the things that we may want to model in wallets because perhaps maybe not everybody gets all of the, the attributes, but the metadata that exists for these federations and the inter federation of them carries that sort of additional trust information in a standardized way.
So now we've taken that sort of SAML two party federation and made our lives far more difficult by adding other parties.
So this explodes the number of trust relationships that need to be modeled in our trust fabric because we have an issuer who is, say the German government in, in this case we have a wallet provider who provides instances of wallets that people have in their hand. The wallet provider needs to be able to trust the wallet instance, the issuer needs to trust the wallet provider, that there's a correct correctly operating instance that it's going to give the, the national ID to the verifier needs to trust the issuer. So we've now exploded the number of relationships.
So people keep saying, oh look, we have, this is distributed, isn't this great? It's going to be simpler.
No, it isn't. It's probably an order of magnitude more complicated with all of these trust relationships.
So my, the, the beginning of my thesis is we need to also think about separating out the trust layer for wallets and verifiable credentials from the actual protocol. So as an example, no, let's see here, the, you know, I'm working with Apple and Google on a W three CAPI, which is going to hide what wallets you have from relying parties because knowing what kind of wallets you have on your device is a really great fingerprinting technique.
And you know, so all of the advertisers who would love to sell you stuff, would love to know what wallets you have, especially if we wind up in a, an ecosystem where you have one wallet per credential. It be, be a great way. I know that you live in Estonia, I know that you have a relationship with CVS and on and on. Do you operate in Estonia?
Not yet. Okay. We have an Es eston. There's one Estonian.
Okay, who knew the, so we don't want fingerprinting. I think everybody agrees that would be a bad thing.
So if we, if the relying party doesn't know what wallet you have or what credentials, they don't know how to describe themselves to you, to the wallet. So as an example, I want to get a German EID and you know, they're a bit retentive about how information is disclosed. Wasn't that funny?
The, but you know, I believe that there is an intent to perhaps have certificates per relying party, which describe what attributes that particular relying party is allowed to get from the German EID. This is how the original German EID worked. And one of the reasons why, maybe it wasn't as successful as some people had hoped, but the notion of having fine grain control over what relying parties asked for is not unusual.
If we talk, try and tie that permission. So in some, some people's minds, all of this is simple.
What you do is the relying parties go to the go to the, to the national government and they get a certificate that they put on their website. And then when they do TLS, the browser can look at the certificate and get a list of the attributes that that party is willing to work, willing to accept.
But okay, as a relying party, how the hell am I supposed to know what TLS or certificate I'm supposed to be putting on the site? Because it's unlikely that Estonia is going to have the same certificate trust policies as Germany, as the state of California, as Uruguay, or all these other jurisdictions. Tying the trust information to the TLS layer, to the dynamic part of the protocol is problematic because you don't know who you're going to be talking to, so you don't know how to describe your trust.
So we also have, so the wallet needs to act as the proxy for, for the issuer.
I believe one of the missing pieces that we have in the Open ID specifications, and I've been talking to people about this a bit, is that besides the protocol layer saying this is an MOC or an S-D-J-W-T, and this is how you blind particular attributes, if we're going to have actual wallet interoperability, we also need to describe some sort of policy, the issuer's policy about how that credentials should be handled and disclosed to the wallet so that you can have a generic wallet that can take different kinds of verifiable credentials from different issuers.
And by being certified, as I understand this particular policy language, I'm going to treat your credentials properly. I'm going to store the private keys for the proof keys in the appropriate manner. If we wind up building the logic for how these credentials are disclosed, et cetera, directly into the wallet, which is the current situation.
If you have, you know, in Europe, you know, I I, you know, I've heard discussions here where you know it, you're never going to have the same wallet be able to deal, be a deal with two pit issuers because essentially they're gonna have to build custom logic for each of those pit issuers and they're gonna have different trust frames. That doesn't really sound scalable to me.
So I think that we need metadata or policy language so that the issuer can describe what the wallet needs to do once it's actually received that credential so that it can take credentials from multiple issuers, whether they're gym memberships, CVS, discount cards or PIs. So how the wallet processes that needs to be abstracted.
Oops. Did I go backwards or what? Why is it moving without me? I'm not touching anything. Okay. How much time do I have left? Five.
Well, okay, I didn't need slides anyways. I prefer a whiteboard.
Okay, scrap that. The, so we, you know, we need a, a way of describing for, you know, in open Id Connect Federation as an example. And you know, I'll, I'll leave Giuseppe to get into the details of how all of that works with you later.
The, I don't know, it's just randomly going back and forth. I'm not gonna look at it again.
The, but one of the ways that this, some of these problems can be dealt with is if the verifier provides an ident, an identifier, an entity ID to the wallet, the wallet can then dereference that and find trust marks for, for the, that the issuer has or that the verifier has gotten also at signing and encryption keys.
So we actually have a fairly good experience around OP with open ID connect around relying or IDPs going and getting relying party metadata and rps going and getting identity provider metadata. So part of that metadata can, in fact, you know, it isn't an, an exclusive thing.
European trust lists around who can issue assigned attestation or certificate or whatever you want to call it. I mean X five oh nine is just a signed blob of data. I mean yes, there are some religious cults around it, but at the end of the day it's really just a signed blob of data that says this data subject has these attributes and one of those attributes can be a cryptographic key. You don't actually have to use the key, it's just a way of con of communicating signed attributes. Somebody has set, made an attestation about this subject has these properties.
So there's no reason why we can't have a trust list for, I'm a European entity, I conform to GPDR and I'm, I get something more than just an over 18 claim. There's no reason why that can't be an X five C trust element in an entity's metadata. And that way we, a relying party can without having to mess with anything in the TLS layer or do something specific in its request to the wallet API, they can then have a list of trust schemes, trust marks that they participate in, which could be very widely around the, from around the world.
They can participate in whatever the California scheme is, whatever the European scheme is. And without knowing where that person is coming from, fingerprinting them in advance, they can provide the appropriate information to the wallet selector and the wallet so that the wallet can then provide the correct attributes or at least provide the correct guidance to the user about what attributes they should or shouldn't disclose.
'cause it's not an absolute thing.
So the issuer gets to decide, okay, for this category of relying party or a verifier, under no circumstances do give them a national id, a tax number. You may give them an address, but allow the user to deselect the address. So being able to provide guidance to the person who's going to be using this wallet is I think a fairly critical thing. If we just say, you know, Eve Mailer did a, a presentation on consent is dead, I think there is still some role for consent, but it has to be informed consent.
And really it's the role, the fiduciary res duty of the issuer to make sure that the user has the contextual information to know whether or not they should be releasing attributes. And the issuer needs to trust that the wallet is going to match their policy against whatever the certifications of the, of the relying party are of the verifier.
So I guess in summation, I don't see trust list as being mutually exclusive to federation information.
I think it, in order to scale, we need to have some combination of trust list or trust mark, along with being able to dynamically receive, dynamically resolve information about the various entities so that in real time they are able to trust each other. Federation also allows, if you, not everyone trusts TLS surprisingly enough, that's one of the reasons why the research and education networks have an independently signed hierarchy of, of metadata.
So federation also lets you do that, but it's not just because you don't trust TLS, there's other good reasons for having that chain of trust, being able to express policy from the root. This guy is allowed to do this, this guy is allowed to do that below me. So being able to express that, being able to say independent of the federation hierarchy trust marks may be coming from external organizations cross. So you may have trust marks as a university from a bunch of different jurisdictions, which are sort of independent of the trust chain for your metadata.
We need to be able to represent all of those combinations. And am I, I'm out of time, aren't I?
Well our four next experts come up.
Any questions? Who would like
To put John on the
Spot?
Oh, everybody would love to put me on the spot, but you, do you have questions? Nothing.
How hard is all of this, John?
It's much easier since you, since you contributed the Open Id connect Federation spec to the world, making it a much sunnier and happier place as, which is, you know, one of, one of the potential, you know, I'm not necessarily pre-judging what the best way to solve this problem is. I really want, what I want you to take away is there's a problem that we need to think about and we need to come up with a way of coming up with a scalable solution.
Connect Federation is a plausible solution that should be considered, but there may be other ones.
Thank you, John.
You're very welcome.
