 All right, I think I'll get started Welcome all my name is Steven Curran I'm from five comps computing and I work closely with the government of British Columbia and have been for several years on hyperlinder Indie Aries Self-sovereign identity trust over IP and all sorts of related issues So this topic is about traversing the web of trust How do you determine as a verifier whether you or not you should trust the issuer? So that's what we're going to talk about today I'll start with just a brief reminder of the trust over IP Verifiable credential triangle and the interaction so an issuer provides in the paper world provides a credential a piece of paper to a holder that holder holds on to that and that ends the Conversation the interactions the transaction between the holder and the issuer Sometime later the holder is asked by a verifier to prove that they have been issued a credential Whether that be a driver's license a passport a membership card a loss of you know Proof that you're a lawyer proof that you're a real estate agent They're asked by the verifier the verifier looks at the card They're given the piece of paper and they decide if they trust it And so they're basically deciding if the documents been forged if the piece of paper is a forgery If that person that's giving them is likely to be Someone they can trust once you go to verifiable credentials That problem changes and that the part of it of what the verifier has to do changes and that's what we're going to talk about today To remind everyone of the verifiable credential model a issuer writes Cryptographic material publishes it somewhere often is to a blockchain or a ledger something like hyper ledger indie But could be using Microsoft stack to Bitcoin or anchored in Bitcoin or a pterium The issuer then is able to use the private key associated with the public key They publish to sign credentials find verifiable credentials digital documents that they give to the holder and once again Just like the paper model the transaction between the issuer and the holders complete the holder then Connects with and and is asked by a verifier to prove that they have possession of that credential and maybe some data from that credential So they're asked to provide a proof So they don't provide the credential itself, but they provide proof that they have that credential It's cryptographically signed the verifier leads the public key information that the issue were published and uses that information to verify The document that they've been given the cryptographically signed digital document Once they've done that they verified that The issuer did indeed issue the credential that the holder has it that it has not been tampered with and Potentially that it's not been revoked so all of those things are known that gets rid of the verifier having to inspect the document and Decide if it's real But what that doesn't get rid of is the issue of does the verifier trust the issuer and it becomes a little more opaque although When it's done digitally, but in any way it becomes much more feasible Again related to the ability to forge the documents takes away that ability for Somebody you know on the internet to construct a document that looks like a driver's license and sell it to somebody that Looks to the verifier like it is a driver's license They can still do that they would have to simulate they're the issuer and that's what we're trying to prevent and ways to prove that the issuer truly is Who provided the document so basically the trust challenge then on verifiable credential is you've got to know your issuer There's real-world methods for doing that. We're going to talk about those, but how do we transition those to online? It isn't a slide here that We do want to keep the Verifiable credential model, which is I'm not going to talk about where the issuer simply asks the or the verifier asks the issuer for the for the credential data We don't we try to avoid that model Generally because We don't part of the privacy and we want is that the Issuer gives the credential to the holder and then they use it wherever they want without having to Ping back to the issuer to ask or you know, Steven wants to go buy some cannabis mr. Governmenters is the old enough to do that We don't want all those transactions tracked by the issuer Basically the login by Facebook problem Okay, so what are the approaches we have for determining whether we trust the issuer So one approach is simply as a verifier We only accept credentials from known issuers people we already know about and this is done in in one of two ways Within Aries and within the software you can ask in the proof request You must provide a credential from a specific issuer of a certain type So a BC driver's license or your Canadian passport and that's specified and so only those credentials would Satisfy the proof the issuer is already known and and you must provide it from those issuers a Reactive way to do that is to have a list of issuers you accept and then tell the person I'll accept any issuer I'll accept a driver's license from any province in Canada But I know who the 14 issuers are of driver's licenses in Canada because there are only 14 and and I we're gonna make sure both that your Credential passes the cryptography works, but also that one of those issuers is is been used So that's the small scale Approach that is currently common But of course that the problem that is scale it doesn't scale when there are many and For global use cases many many issuers and if those issuers are constantly changing if there's new issuers being added If there's issuers being removed and so on that causes problems with this approach. You just it just doesn't scale You're back to just looking at inspecting the issuer So examples of this all sorts Academic credentials is where a lot of the work in in verify the credentials started and and it's a very real problem The solution in academic circles is generally you go whenever you must know that a person graduated from University You require you you call back to the issuer and you get them the vaccination providers has been a big one obviously in 2021 being able to prove That you have a proof of vaccination and being able to Know that the issuer that provided that is a a genuine issuer of that Business licenses and business licenses are generally municipal across the world. You know each city issues them Knowing it's a business license is difficult even in a relatively small area where there's many communities Supply chain huge Where customers might want to check to see who issued a credential about a product? So that's a another big place. There's all sorts of them across across anywhere that you go beyond local problems The second way you do it is you just outsource the problem You just create a have a central place that you check on a list of issuers and verifiers can subscribe to that List and they can get it. So this is basically the public model. I add the Travel association has a great system for it called tomatic But I never knew about but I learned about in the vaccination world as I've sort of Investigated in that and tomatic is a critical system for travel rules. Basically, they collect all the data from nations As as rules change about what travel is allowed between different places So if a place becomes dangerous to travel to that would go on a list of dangerous places to travel and so tomatic let's an airline contact about a passenger who was flying on airline X going to Going from place X going to place Y and what are all the rules associated with that combination of things? So they maintain a central database and the airlines use an API to get that information So that's another common way to do it in a way that is likely to be be very Common initially so not inherently bad, but it is centralized and and part of the goal We've got is to decentralize things making making it easier as well Because verifiable credentials allow many use cases They can be much smaller than can be justified in putting together a Centralized database of these things so there's operation of overhead. There's governance and technology involved security All the things you have with a central registry that you that is gotta be maintained. So We'll go on to look at the centralized ways of doing that So that's what we're gonna focus on from from this point on in that in the conversation Not to say that the other ways are bad But let's talk about the centralized ways to do it where where we don't have that central registry and and if we have a scale problem Today if you got a paper credential from an unknown issue or like this Diploma that I've got on the screen there, which is actually from the University of Suffolk, which I didn't even know existed in Boston, I believe It's a lot of great You Google the issuer you figure out who the issuer is you Google them you decide if their website looks real You look for correlating data this this candidate for a job. It's presented this credential from a from this university And you have no idea if it's real You might even if it's important enough contact the issuer to see if they are indeed Real and then ultimately a human decision is made I'm I gonna trust this or am I not gonna trust it and and and you go from there You make that decision. So that's kind of the model. We're gonna look at as well The the natural state of things that has evolved is that you have local hierarchies that build up Authorities to issue credentials to issue to be authority over topic So if you think of universities of lawyers say for example, or real estate agents You would have a local group that would self-organize and then ultimately there'd probably be a regional authority that says Oh, this is the way that within the province of British Columbia We decide who a lawyer is and of course British Columbia is part of Canada So we probably have an organization across the country to do that Locally we get consistency and this is why this this approach has built up It's because when we're dealing with paper and we're dealing with people we interact with in person That makes sense. It's locally consistent, but very different across jurisdictions and basically every time you cross a Jurisdictional line in these silos You you create this trust just because a lawyer is allowed in British Columbia. That doesn't mean they're allowed in Alberta As we go, you know beyond that into the state. Well, then it becomes even more Questioned, you know, what what does it mean for British Columbia to authorize a real estate agent? That versus what is done in Nevada say, you know, it varies across jurisdictions and jurisdictions are less You know, I have different rules and different trusts of other jurisdictions. So what does authorized issuer mean? so Decentralized KYA know your issuer with verifiable credentials. So this proposes a Protocol that can be used for figuring out if you trust the issuer So I'm going to talk about that for a bit and then talk about another way to apply that and perhaps a more practical way So first our starting point when we've when we're a verifier. We've got a credential from from our Prover From that credential, we know the data of the issuer. We don't really know who that Identity, you know, who that identifier represents we just know We know resolvable identifier. We have a public key Generally that we can use and we have an endpoint to contact the issuer and with Aries That's enough to be able to actually establish a connection with the issuer and ask them Have an exchange of information messaging and including in that the ability to request proofs from that entity So that's one thing we've got We know that they issued a certain type of verifiable credential, but we're trying to figure out whether they're authorized to We also know they're allowed to write to a given ledger because they Put their the anchor their information in that ledger. So That also gives us some information if it's a closed ledger if it's not a public ledger that actually may be enough there's a program in Canada or known traveler That's a combination of the world Economic Forum Transport Canada, which is the authority for transportation at the federal government federal level and Netherlands authorities Dutch authorities and the same, you know transport Dutch whatever Transport Netherlands, whatever the organization is called there. I'm not as familiar But basically they have a closed ledger that only certain people are allowed to write to and only allowed to verify with and so That actually would be enough to know That we can trust the the the issuer. So I'll set that aside, but just wanted to throw that out of that's another option Traversing the web of trust what I thought about in doing this is sort of Recursively figuring out who has the authority To do this so start with the issuers did so the idea here is that you're going to Figure out what authority the person that the entity has to issue the credential and so an Algorithm for doing that is basically this I have the issuers did because I've verified it and I know it's a real You know the real issued verifiable credential that the checks out so the verification work I might have a cache of known issuers that I Either is empty or I'm building up as I go and I have their status of trusted or not trust trust it Basically, I do this I recursively find look for the did and the status in the cache if it's there I'm all done. I can just take whatever it says If if it's not in the cache yet What I've got it what I can do is use the information in the public did for the entity to connect to them and ask for their Proof of authority to issue that credential. Why are you allowed to issue the credential that I receive? I May get a response and and if I get a response I get another verifiable credential back and I can actually check start the whole process again with that did If I don't get a response I Then have no option but to pass it to a human to make a decision on what it happens and again That's the end of the recursive algorithm Either way either I find the did in the in the cache or I Pass it to a human either way I get a decision out of that either trusted or not trusted and for any Recursion I've done through that I can apply that same result to all of the other Dids that I've encountered in doing this and so I update the cache with the resulting chain of issuers So how does that look? This is another representation of that basically I start with my issuer did I Check to see if it's in my cache if it's not I ask the issuer Hey, what's your authority for issuing this if they give me one I loop back If they don't give me one I either make a human decision or perhaps I just reject it out of hand If if I have to go to that I might just reject it and say it's not trusted then I go then I'm going back to the holder to say hey that That credential you gave me I can't use it you need to provide something else and now you're into negotiation with your older Out of the picture The other one is you do find it in the cash that ends your process and you have a result It's either trusted or untrusted and then as I said once you get a result if you've had to traverse Other entities you would add those to the cash So that's the algorithm there Example of that so I get a I get a credential from a university. I'm a company. I'm hiring. I get a transcript from university that university when I asked them gives me a Credential from a regional consortium of universities. So it might be the British Columbia Post-secondary associate schools Association or the University of universities and colleges of British Columbia So I've not heard of them. So I go back. Oh British Columbia came from British Columbia Well, actually I'm somewhere in the States and I've never heard of British Columbia or at least their authority to issue credentials But that's part of Canada and Canada has Is a trusted entity? I do know about Canada. So I now have a decision I have a trusted that I trust the issuer And so I can accept the presentation from the holder So I'm good to go with that and along the way I can update my cash for these three things And the next time I have to go through this type of process. I can stop at level B I can stop at that first level and and provide that so it's a recursive way to figure out. Do I trust the issuer? So enablers for making this concept happen Obviously, there's got to be use cases where verifiers are accepting presentations of verifiable credential from arbitrary users One of the things we talk about when when we talk about getting started With verifiable credentials and the use of trust over IP is start with use cases where you know all the parties Where you don't need to have this problem and you know who the issuers are the verifiers already know that so they don't have to worry about it So obviously you wouldn't get this going until we have arbitrary issuers the Proof of vaccination boy. There's a case where we need it and we need it fast if these Proof of vaccinations are going to be used for travel or for crossing jurisdictional line Come we really want a Human machine readable authority to issue protocol I'm going to want to be able to go back to an issuer and send them a message saying hey Tell me your authority of why you're allowed to issue that and they understand it and respond to it in a machine way Also like a human way to do it so that the human if it does come down to a human decision that they collect information along the way to do that Oversight organizations need to issue authority to Need to issue those authority to issue verifiable credentials Basically, we wind up for each silo local silo building up to a national one a quasi-certificate authority Authority governance framework. That's really what we're creating is we're we're Building out the trust by having an authority issue a credential to an issuer saying you're allowed to issue this Credential and I've talked about fairly obvious ones, you know governments Academic organizations, but it it can go into IOT. It can go into ISO Certifications, there's all sorts of governance authorities around that that would benefit from this type of capability We would also want to be able to do automated data collection if we did enable human if we did have a human decision point on it The document can have it also known as attribute which can be a domain name And so that could be used as a way to enable human decisions You can collect additional information. You can do the Google searching beforehand So that when you pass all the data to the human that's going to make the decision that that searching has been done They're not, you know getting online and doing that searching at least, you know They can at least know who to contact if they're going to do that part of it Challenges Need a common authority to issue Verifiable credential a decentralized authority if you will so that's one of the things that We're hoping to get to with some of the work we're doing in in British Columbia around that Next up Definition of what authority to issue means so there's a couple of things looks like I missed the link in here to add but Aries RFC 430 is called machine readable governance frameworks and the idea there is that You can run this protocol to figure out what governance framework the issuer is a part of And how to determine if it is behaving properly within the governance framework guideline So again, it can contribute to your trust decision The pan canadian trust framework, which is the link that I missed in here. I'll get that added is a framework that defines Levels of assurance what what that means what it means to issue an identity Credential for example for government to issue such a thing and and and how a verifier should interpret it and things like that so Expanding out on these idea on the authority to issue Issue words have to be always on to respond to that authority to issue proof request And a human decision may be needed anyway So there are some challenges in there Um potential optimizations is you start not with a full cash But just a partial cash of you know in the example. I gave you know, canadian the canadian and bc level things the um national governments across the world and uh coming from an authority like the uan or something like that and then the Regional authorities within a national authority. So provinces and things like that that can be a partial cash that would allow you not to have to Fill up the whole tree yourself the whole cash right from scratch I throw this out there just if if a human decision is made you want to put an expiration on that and you want to Figure out when to revisit that decision You want to you know, at least every six months or every year we re-evaluate that Issue word to see if they still have a good reputation if they still can be trusted um, one of the things you can do is include a potentially this isn't there yet, but potentially prove a Proof of an authority to issue inside the credential that's presented by the holder This is the thing called chain credentials. There's a really super interesting areas rfc 104 You can take a look at where you actually embed a proof within a proof So that the authority the proof The issuer puts a proof inside the proof given to the holder. So that's an interesting way to look at it Trust over ip has a group a working group called authenticated chain data container that is associated That is the same issue And then we can look at Decentralized trust registries. This is the last thing I wanted to touch on Which is sort of a combination of the central registry and Decentralized authorization. So you do have registries um, they're registries of verifiable credentials of bcr authorities would run those and then the vc that you gave instead of Containing a proof itself, which would be even better But you could have the vc contain a url to a vcr where you can look up the The authority of that issuer to issue a credential. So as part of the vc itself, you probably here's how you check on this Um, the verifier may have to know valid vcrs, which takes us right back to our original problem How do they know, uh, which vcrs they trust which uh, credential registries they trust Requesting proofs from the vcr to do that and then they're back to figuring out how they trust those The idea here though is this is a much smaller unit of things and so these are things you could collect ahead of time In a reasonable amount of time and effort um, good health pass, um, the work done at trust over ip for verifiable credentials related to vaccinations and and covid testing Released its interoperability paper This past monday the trust registry is section 7.2 This image is actually comes out of that and I credit them for putting that together So that's a way to do that basically the same sort of idea. I have but without I provided earlier with the Traversing web of trust idea But comes out to a trust registry basis, so you you're going to a a quasi centralized place, but that is Decentralized in nature and with that That's what I had to talk about. Um, you know You want an approach that is assessing issuers that is both decentralized and scalable Aries and verifiable credentials enable a model for that web of trust Great governance is needed. So even though you've you've got Mechanisms to do it the technical mechanisms. You really also need to have the governance around it And with that, um, that's the presentation I had. I'm a couple of moments early. So I don't know if there's questions over there I see there's something there. Will has posted some information. I didn't get a chance to read Where is the cash initiate instantiated? Um, so probably by now you've got to figure it out. So the original cash is with every verifier and so in you know from a From the lowest common denominator model. It's every verifier sort of builds it up from nothing Ideally you pre Pre-populate it with it with data. You already know and then the other side of it is that you can use um That these trust registries idea where you can not have a single central a central authority, but you could have Groups of authorities and and figure out and constrain your trust problem to trusting the vcrs and the managers of the vcrs Um Well, I don't want to that's a lot to write Um Good stuff and and there's a good link in there. I can add that to this um But I don't have to I don't want to read it while I we're sitting on on the call. So Um with that, um, I think we're over. Uh, so I will end the presentation now. I hope uh, I hope that was helpful