Welcome, great to have you all here and kicking off the Open ID Foundation workshop. I think this will be my third E I C as executive Director. Oh, maybe I'm getting slightly more practice at this, but not that I can ever live up to Don Tebow, but I do try my best. The for today, we have a very rich agenda. Before we jump into that, obviously we always like to share that this is an open forum, and so anything that shared is assumed to be in the public domain. So obviously no technical contributions that you don't intend to become public information. And we also would like to run you through pretty rich content for today. Going through many of our working groups. We'll, we'll kick off with some strategy and new news that I'll share with you. Then we'll have Christina Yasuda, Dr. Torsten Ltk coming in on open ID for verifiable credentials.
Then we'll go into a couple of different FPI sessions and, and certification update. We'll carry on through some of the working group updates this afternoon and conclude with some white paper reviews, an update on gain, and one of our partners from the Open Identity Exchange. Nick Musha will come in and give some headlines for his organization. So definitely a lot to cover in terms of new news for the foundation, it is a hive of activity. We'll start with just a little bit of a taste of how the board thinks about strategic initiatives for the foundation. And if you actually start on the right hand side of the page on moving to internet scale, many of you're familiar with Open ID Connect being widely adopted by billions of people and used by millions of applications. More. More recently though, in the last few years, our standard for fpi open banking and open data has gained a lot of traction with nine countries selecting that standard for private sector or government-led implementations.
You'll hear more about which, which countries and implementations are driving that effort around the world at the moment. And then our certification program led by Joseph Heenan, he'll share some of the work they're doing to support many of those ecosystems and other requirements for, for certification across our stack. We'll talk about things that are happening to cross the chasm. So open, ID connect for verifiable credentials. Open Id connect for identity assurance are a couple of our newer standards that are gaining a great deal of interest by stakeholders on many parts of the planet. So we'll, we'll share headlines there. And then a tool who's in the audience will share a, a shared signals framework and the work that's happening to, to share signals across ecosystems in terms of building the foundation. So some new capabilities that we're more focused on. One of them is a initiative on next generation.
So really bringing in young talent from across the world into the community and into the identity domain and really supporting that effort. We'll talk about gain, which is an initiative we announced here two years, two years ago now, gosh, September 18 months ago. And, and the progress in that last 18 months. And we'll give a couple headlines on igov in Moderna during my update. And our friends at the Open Wall Wallet Foundation have a concurrent session to this. So I know we're dividing many, many friends in interested parties between the our two, our two groups. And we'll talk a little bit about about that in a moment. Don Tebow, we'll share some of that that work. There's some work on several white papers that are of strategic importance to the foundation and to the community as a whole. And we're using some of the white papers to help underpin our mission and our vision.
Our mission is to help lead the community and developing standards. And in that context, we know we're just one foundation of many that are working on standards that are making a meaningful contribution to the work in identity right now. So we want make sure that from a thought leadership perspective, we're coordinating with our peers and we're helping the wider community understand what the trends are and what our recommendations will look like. So we're using white papers as a tool to, to synthesize our, the, the, the collective viewpoint on those trends. There's also some work on health where we'll share some of the headlines, particularly from Steiner, who will talk about the Norwegian experience. And you can see there are some other topics we won't get into today, like some reports on web three and ai, as well as some reports on IOT and identity, where the board's trying to kind of get our hands around what we can do to contribute to those specific spaces.
And we're also bringing on some, some new expertise in terms of a technical ambassador and a, and a marketing director, and another other initiatives which we won't have as much time to cover. So very active, very active in the foundation at the moment. I also wanted to take this, this opportunity at EIC to celebrate a milestone. For those of you that have been following the open banking and open data work, you would probably have heard of fpi and we'll talk more about it later today. But we did wanna announce that the first FPI two certifications have come in. We are grateful to our, our one of our members who's provided directed funding to develop those tests and is also certified Connect id represented by Dima pos pov, who's gonna be with us later today. And certifications from OTH Athlete Cloud identity Ping and radium. What's not up on the screen at the moment is also another certification from from PayPal.
And they unfortunately didn't get to us in time to be able to use their, their logo on the screen, but they have, they do have a public public certification. So really great to see all that work of many years of the specifications group as well as many of the, the thought leaders in the, the global community working to enable the next generation of work on fpi. Some other bullet points on new news around the foundation. We have submitted Connect ID and the Open ID foundation itself for ISO publicly available spec status. So we're going through that due process. And many thanks to the co-chairs Natura and Mike Jones for their work to set that up. And Mike Jones will be helping to shepherd that through the formal ISO process in the next few months. And we hope to conclude that by the end of the year, the government requests for comment have been fast and fierce.
So work to support the O E C D and their draft recommendations for digital identity has been shared. We support the work of the OE O E C D and I think, Nat, if I can steal your words, you, you equated some of those recommendations on digital identity to being a bit like GDPR for privacy and that this was a, an interesting moment to see that leadership from, from O E C D providing that those top level principles. We've also provided feedback to many NIST initiatives on cyber securities considerations for open banking. So clearly there's work from the US Consumer Finance and Production Board rulemaking this year. And we also wanted to provide not just the guidance to CFPB for their request for comment, but also for the NIST work that's been happening in parallel. Also work on 863 dash four. I guess not all of you will know the numbers, but that's related to the, the guidelines for government entities for accepting digital identity credentials.
So, or not just digital identity credentials, but accepting recommendations for, for identity acceptance. We've also been supporting a NIST with their N C C O E, that's their Center of excellence work related to mobile driving licenses. And the ISO 18 0 13 dash five standard and dash seven work. And that's work that many states in the US are issuing under that standard and which DHS and TSA amongst other government entities are looking to accept. So excited to, to take part in that work. There's also a whole bunch of white papers, a few of which we'll talk about this afternoon, and also some important work with liaisons. So new relationships with the European Commission related to their EU identity wallet. And we're delighted to have been invited by them to take part in the expert working groups and the open identity exchange. You'll hear from Nick Mother Shaw later this afternoon about that relationship. And I wanted to just ask Don Thibo, if you could just say a couple of words around the work with the Open Wallet Foundation that we have taken part in as we are now associate members, right Don? We are in the, you wanna take a mic for those remotely?
It's all right. Hi, I'm Don Tebow and you'll see people going back and forth between this session and the Open Wallet Foundation session. And while that's awkward, it's indicative of the relationship that the Open Wallet Foundation has with standards organizations like Open ID Foundation. What we hope to do at Open ID Foundation is to really kind of organize community feedback and community projects on behalf of the Open Wallet Foundation. Open Wallet Foundation will do three things. You'll hear about code, code and code and nothing but code. What we want to do is to be able to enhance that code and the awareness of that effort through the Open ID Foundation. So last takeaway from that is the way the Open Wallet Foundation will be working is they'll be accepting project proposals from the community at large and from members like Open ID Foundation. So we hope to organize some of those conversations and projects very early in the process. So thanks for your time and attention and here you go, gal.
Thanks for the quick update, Don. Much appreciated. So since this is an opportunity to meet with our, our members, we thought we'd share what we consider, you know, good news as well is that we've been going through a bit of a global recession in the last six months, 12 months, depending on where you've been. But we're pleased to, to confirm that our membership has been holding steady during that time, which I think is, is great. And it's a recognition of the traction and the importance of the work that we're doing, that the, even under those budget pressures of many organizations, they have, many companies have committed and remain committed to the work of the foundation. So thank you to those of you who are members, and those of you who are not yet members, we hope you'll seriously consider becoming a member as an individual or as an entity and an organization.
Obviously warmly welcome. More participation from the community. I don't think I have Heather in the room might come back to this privacy white paper with some headlines from her in a moment. I know she's pulled in to the Qatar session at the same time, but she, we are pleased to have an announced the publishing of a white paper. Last Friday, the government issued digital identity and digital government issued digital identity credentials in the privacy landscape. Bit of a mouthful. This paper is targeted to government officials predominantly, but also to civil society and the wider stakeholder community to help them understand the movements and digital identity and specifically the privacy considerations to look the landscape of privacy laws in different countries and different implementations that are emerging right now. Cuz many of the co the challenges with privacy are consistent across different jurisdictions and the trade offs that one has to contemplate, you know, will, will need to be taken in the context of the values of individual countries or jurisdictions that are implementing these programs. And so Heather's thoughtful work, which is I think 166 citations, we were joking about the volume of those citations. Do you wanna say something, Heather? You wanna come up and talk about it?
Well, Heather, you'll hear from Heather in person in her session on the 11th on Thursday at three 30. So I hope you'll come along to her session. But you can see on the page many of the, the key areas that she's focusing on. And I think one of our, our common jokes is that where is it in here? Cryptography is like a basic requirement. Anyway, I ch I changed it or you changed it. Okay, things have changed. But yeah, a lot of key considerations across jurisdictions. So hopefully you'll have a chance to read this paper and have a grounding in the work of digital identity and privacy if you've not already been exploring those issues.
Also wanted to, let's see if I've got, that's the one I wanted to look at. Happy to recognize Rochelle, if you're in the room, Rochelle, feel free to stand up. And Amir, if you're also in the room, please do stand up. I thought I saw him walk in. So great to recognize you as a Kim Cameron awardee and Rochelle actually for the second year running. And their, their peers, Isaac and Charlie, these are our four candidates who have received the recognition of a Kim Cameron award. For those of you who are not familiar with this program, it was the brainchild of Don Tebow that to recognize one of the major contributors to the Open ID foundation and to the identity community as a whole and to recognize his legacy through bringing in and young, young, the next generation of individuals who are either early in their careers or still in academia and recognize 'em for, for their work to, to this date.
And also help them engage with the identity community more broadly. We're in, as part of the award, we help them to sponsor, sponsor their trip to one of the key identity conferences, both EIC or iif first or the two leading conferences at this point. So help them with the travel. And then the conferences, including EIC, have been generous enough and iden I generous enough to offer a pass for these individuals to take part at no cost. So thanks. Thanks to E eic, thanks for IIF and recognition to all of those awardees and to Don Tebow for helping to run that program.
So we don't have a couple of our speakers today for working groups. So just wanted to share a couple of headlines for Igov Working Group and the Moderna Working Group. So on the igov side we have some great contributions coming in from Mire in the US looking to create some updates to, based on OAT 2.1, there's also some contributions from Italy that have selected the IGOV profile along with Connect Federation and we wanna make sure we're supporting the Italian government and their work. And then there's a new implementer's draft plan for later in q2. And as we have that final, that profile moving to final, we wanna develop the certification test to go along with it. So if you're a government entity and you're trying to make sure you have the right profile requirements for for connect, then you wanna keep track of what's happening in the Igov working group For Moderna, this is our group that's focused on the mobile network operator community and a profile specific to mobile network.
So if you're in the mobile network domain, then the work of Moderna is gonna be where you wanna focus your attention. And we're pleased to confirm this week we had a constructive meeting with Kamara, which is a OP is a Linux Foundation project. They've selected Open ID connect to support that project work and this is looking at a API capabilities for the mobile network community and their stakeholder group. So looking forward to learning more and how we can support them through a kind of formal relationship in the, in the weeks and months ahead. And as you can see, lots of good work happening in terms of final drafts, implementers, drafts and working drafts that are in flight at the moment. And with that I want to see if Nat, would you like to many make any introductory comments? We're welcome to the group before we jump into the next session.
Hi, interactive, right? I highly recommend you to voice and come international.
Thank you to Nat, our chairman. So again, encouraged to be interactive and pose questions as we go through. So Dr. Torsten LTE and Christina Yasuda, thank you for sharing a bit about the work of the open ID for verifiable credentials.
Thank you Gail. Welcome everyone. The first topic we have today is open ID for verifiable credentials. Where do you have the clicker? Gail, you took the clicker. 1, 2, 1, 2. Thank you. So first things first, openly for verifiable credentials, we have a nice friendly family that has some additions. Originally when introduced a topic last year, the course three specifications are openly for fiber credential issuance for the issue, a credential from the issuer into the wallet and to present the presenta that credential to present it. We have openly for roof presentations, the specification, but using credentials for authentication is not always a good idea. So here we have a selfied open ID provider specification for sudani mass authentication. And to those three we added openly for roof file presentations over B L E over Bluetooth. So whenever we talk to the governments who are really interested in our work, they ask, well great, what?
But what about offline? So for those use cases, we are working with Moip who is really, really active with governments in India, Singapore now largely expanding into Africa. And we do have a prototype actually running. So come talk to tourist in if you're interested. And last but the least, we do have a formal security analysis starting a document on security and trust. And in essence this document focuses on ability for credentials, but in essence it does the security and trust analysis for the entire issuer holder verifier model. So it's actually a really, really useful documents. So again, if you're interested, please come talk to us.
We've made a lot of progress from last year. Like last year I think at EIC we published a white paper called Open for Fiber credentials, which has been really influential and within a year, well first of all, how many of you know ei that's 2.0 and European digital identity work while at work, if you've skimmed through the document three specification we just talked about openly for five credential issuance openly for presentations and are in there mandatory for the version 1.0 of a R F of architecture reference framework for EI e i. That's 2.0 European, I don't hear applause.
Well that was a great milestone, right? Obviously the next step is large scale pilots, reference implementations gonna come in. So you know, the standards are, you know, we don't claim zero final, so they're still work in progress. So you know, you have to see implementer's feedback incorporate, but it's been a huge, huge, huge achievement. And then we have a lot of big implementers, big and small private public government sector startups implementing finish IDs entirely based on open id. E B S I stands for European blockchain initiative. Stan European Blockchain service infrastructure, right? Apologies, German ID Union, Microsoft European Identity and Gen Digital tele. So, and most importantly we have a lot of open source libraries emerging in different languages in RA type script. I'm Conlan Swift, whatnot. And just actually last week, Monday, well you know, good things happening, but we have to make sure quality of specification is good.
So last Monday we published the second implementers draft openly for our presentations and the next step is we are planning an implementer's draft for the issuance specifications and after issuance this startups coming. And yeah, we've made a lot of progress in with the specs work and security analysis, sorry, and California for which one? The top adoption? Yes, and California dmv. So if folks ever been thinking about how, you know, OCS and TRACK is diverse receiver fiber credentials, California dmv so is doing some amazing work. So I would highly recommend talking to them. Oh, forgot dimension. When we say open for raw fiber credentials, we absolutely do not mean only W three fiber credentials data model. Like we're trying to account for all kind of credential out there. And again, usage of blockchain or DD is not mandatory at all. It accounts for any kind of identifiers that pki, you know, X 5 49 if you want. I'm serious. So yeah, that's a really important topic. So the, one of the superpowers of openly for VC family is that you can use it for both M docs and there is receiver fiber credentials. And doesn't matter if it's you know, Jason OD or if it's signed using some fancy crypto or not. You
Can even though ACRs if you want.
Yeah, you can know what that means. All right, so security analysis, university of Guard starting, I already mentioned the Bluetooth work and we have been started some work on conformance testing with our favorite open ID foundation on conformance team certification team. So yeah, there's some first profiles coming up. We are planning to start with MDOC and SD I'm, if that's a credential form that you're familiar with, that's another thing referenced in a F. So yeah, a lot of, a lot of good work happening and some opportunities, challenges or mentioned European ai, that's 2.0. NIST n CCO E stands for Center of Cybersecurity, center of National Cybersecurity, center of Excellence, national being America, of course they're starting to write conformance testing and working on MDOC over open ID for bp. So that's the profile of how to use open ID for, for our presentations and issuance with MDOC is in iso. So if you ever heard of the, you know, complicated number, so both 18 0 13 dash seven or 23, 2 20 dash seven dash four whatnot, like that's where those mdoc work is happening. So we are actively collaborating with those two parties.
And so yeah, we are trying to, so one of the superpowers of these issue holder very far modern fiber credentials is we believe is making bridging this physical credentials and digital credentials and making that experience really, really seamless. So this work we are doing to provide credential exchange protocol across online offline is actually really, really powerful in that context too. And yes, maybe one really recent development, there's proposal from the browser vendors to build the browser API to mediate the presentation of these credentials. And, you know, how do you get your request into the wallet is an interesting topic. But so recently the chromium published intended to deprecate the usage of custom U URL schemes. So that costs a bit of a bit of a discussion right now they got a confirmation that there are no immediate plans to dep deprecate, but this is a, yeah, this is a topic. So if you, if you are a regulator or have you know no other regulators and are interested that we are not having a future where the only way to present to issue or present credentials online is fully controlled by a few companies, come talk to us, you're really interested. But,
And I would like to add that it just cost us four sessions, four sessions at Internet identity workshop to get that confirmation. So if you can help us with that, please do so.
So yeah, should I say something?
It's very important. Yeah,
That too.
I'm not talking as the chair of the Open 90 Foundation, but on my other hatch, the, the special digital advisor to Japanese Fair Trade Commission.
Thanks a lot now, yeah, this is, this is a growing concern that the privacy user experience, the protocol details like assurance levels, whatnot, could potentially yeah. End up in the hands of select companies. So yeah.
Christine, if I may just chime in. Yeah, of course. Yeah. So one of the things that we've started working on as a community is like a few key messages to share with Apple and Google who are kind of driving some of the fears. There's no, they may not act upon what people are worried about, but if unless we share clear messages of what we think good looks like and why it's important to make sure that it's a fair space, it's pro it's becoming progressively relevant to think about this in the context of government issued credentials as well, which are perceived of as a public good in the physical sense. And when they go digital, they're still a public good. So if there are artificial barriers on how residents are able to, to assert those credentials or how relying parties can consume them, then that could be very problematic for governments and for society writ large if only two entities have too much control. So we're working on some key messages to share back with them. If that is a topic of interest to you as a regulator or as a stakeholder in the community, please do let us know.
Thanks a lot. You, thank you. Yeah, so I got over excited. I was supposed to only two slides, I already did three, so I'm passing over to Tona here.
I feel so useless without speaking. Alright, good morning. So let me share with you the next steps we are planning as a, as a, as a group. So first of all, we, we plan to migrate our tooling from Bitbucket to GitHub. That might not sound pretty exciting, but I can tell you anyone that really contributes to the specifications is absolutely excited about that because if the tooling will help us to, to be much more effective than we are right now. The second point is, is also very important. We wanna, we wanna charter a new working group right now, the work on open ID for verifier credentials is hosted in the open Id connect working group and we are very grateful for that. But given the, the number of specifications and the, the character of the audience, we, we think it's, it's, it's it's time now to really spin up a new working group and have a publicly visible place where people can go to, to contribute and, and find all the specifications and, and, and help us with, with evolving it.
So it will be the open ID for airflow credentials working group, we're working on that. And Christina already mentioned we will also working on implementers drafts for the specifications I of V two and Verifi verify credential issuance. We already have gone through the process, the review process and the voting process for the verified presentations back. And we will do so for CIP and issuance as well. And based on those stable versions of of the specifications, the certification team will also start to work on conformance tests for those specifications. And a reasoned, a reasoned work item is the so-called high assurance profile. We were quite often confronted with, with the fact that people are sometimes struggling to adopt the specifications that we do because they are modular and flexible. I mean, modularity and flexibility is first of all a good thing, right? But if you want to build a system, you need to meet some decisions.
In the case of open ID for credential, it is, for example the credential format. We intentionally designed the protocol to be credential format agnostic because there are a couple of different credential formats available today in the market. Last time I counted there was close to 20, right? So, and there are also different ways to manage keys and different maze to manage revocation and so on. So it's quite complex. And due to the adoption, for example, by the Californian DMV and by the European Commission, we were asked to help those implementers to come up with something that they can implement in an interoperable way. And we presented the first ideas at the internet identity workshop two weeks ago, two weeks ago, and started to work on that, on that profile. The profile will tailor open ID for VC and SD jot VCs to the needs of those regulated environments, but can be used for other, for other use cases as well. So for example, in the German ID Union project, if you're familiar with that, we will be adopting that profile as well. It's, it's a huge piece of work. We met together with a couple of other folks yesterday in a working session and planned to work for that. But we will, we assume that we will have something ready for, for, for review pretty soon. So stay tuned and, and have a look and, and give us feedback on that topic.
So the ambition here is that this high assurance profile becomes really successful. We are entering and we, you know, collaborate with, oh probably we should mention we have a new liaison with European Commission and the foundation. So, you know, there's some really good work happening. So if you manage to onboard European Commission, nest California, we're getting closer to the future where you can use your verifi fiber credential issued in America and in Europe for example, right? Like that's the real goal of this, you know, high assurance profile, this global interoperability and you know, implement of shelf.
Yeah. And what we are serving is the, the community and, and, and this whole market is, is settling around certain protocols and certain formats. And so now it's the right time to really come up with something that can be implemented in inable fashion. We would like to make you aware of a couple of sessions that you might want to join this week if you do not have enough from open a for verifiable credentials. So Christina and myself, we will give a presentation and we'll go more into the details of the protocol on Wednesday. And there will also a interesting session about different credential formats and, and and issuance protocols at Wednesday afternoon. And we, we gonna present in that session, for example, results and insights that we collected in, in, in community initiatives such as the credential com credential format, comparison metrics, and also some, some work that we have done in the ID union project in Germany around comparison of of of different credential exchange protocols and so on. So if you want know more about the space in general, come and join us in that session. And on Friday we are really pleased to have Paolo with us. He is, he is working at the European Commission in the context of the architectural reference framework and he will be presenting together with us about the, the European Union going decentralized in the context of the IDAs V two initiative and what that means from a technical standpoint.
That's good. Okay. They're good. Yeah.
So, and the last piece, call for action, please implement our stuff, give us feedback, contribute to the work of the working group. Thanks a lot.
The good news is yeah boss Tristan, the good news is we have 15 more minutes, so is there any questions from the audience
While they think about questions? Mark could share a few
Thoughts. Yeah, so Gail just suggested I had a couple of thoughts here as well in the thank you. Thank you, thank you, thank you. Yeah, I know bad man. So there's another little piece of work which is going on which may support what's going on here and help deliver high assurance credentials in a, in another, in another dimension, which is that there's a crossover between the work we're doing in the E K Y C and identity assurance working group. Defining how we can describe all of the metadata of identity assurance, like the evidence used and the processes that we, we went through to do that identity assurance and take what we've done there in the context of open Id connect and move that and make it available in the verifiable credentials data model as well. So there's an element in the VC data model 1.1 called evidence that we're allowing we're, we're creating a, a little link spec that allows use of the data model described in the identity assurance spec inside the VC data model 1.1. And then following on from that, I'm reliably informed, although not directly involved, that when a VC data model moves to a new version, I believe version two is underway, it should be natively supported without an additional interim spec in some manner. Is that more Yeah, that's a, that's that's
A good point. So if we go back to the, to the high assurance profile. So the high assurance profile will utilize selective disclosure jot, which is for those that are not familiar with it is as the name suggests, a new, a new kind of Jason web tokens that can be selectively disclosed. Why is that important? I mean Jots, as we all know and love them, at least I do. You do too. Okay Mike, then we got two, at least as they are used on open ID connect do not need to have a selective disclosure capability because they are minted on demand for the relying party, right? This is, this is how the federated trust model works. But in the decentralized identity or issue or hold or verify model, you spit out that thing and store it in the wallet and then you wanna present it in different places.
So you need to have a mechanism to only present those claims that you want to present to the relying party, right? Something that a challenge I never came across with Open and Deconnect, but no, it is a, a challenge, right? So, and we solved that and Christina is one of the co-authors of the specification of selective disclosure chart and we will utilize that for doing verifi verify credentials in conjunction with Open ID four VC in, in that high assurance profile. And we decided to base that work on the, yeah, on the new 2.0 version of the verifier credential data model because as I would say, it allows to be a JO to be AJA again. So it's super simple, it's much simpler than VC 1.1 if you're familiar with that. You can just use all the claims that are in the claims Jot claims registry. You can use all the work that has been done at the E K Y C working group for doing or adding metadata into the credential without any, any need for, for for yeah. Bridging right or adaptation. So we are pretty excited about that ongoing work and yeah, we hope we can share results pretty soon with you guys. Yeah. So any questions?
Good morning everyone. So in the absence of any questions Gail asked if I could just say a little bit more about what's happening with certification for open ID for verifiable credentials? So as Christina said, we are starting to work on tes for that. We've been working with the working group, we have at least one implementation that have given us the necessary software to actually be able to test our tests against and we've also got various conversations going on so that the California DMV have actually just joined as an open ID foundation member, which is great and obviously guys, so we are talking about them to, about how they're going to use the specs and how our testing might benefit them. Cuz obviously spinning up new specs and a new ecosystem, having interoperability and actual tests that actually prove you're interoperable as well is obviously the only way you're gonna get these ecosystems up and running and actually working quickly. So I think we've, we've got a good groundswell of movement there and I think you
Doing the test from missed.
Yes. And we've also got a conversation going on with NIST as Gail just reminded me, who are also looking at testing in this area. So we're looking to see how we can cooperate with the NIST on that, hopefully with code going either way or contributions or some kind of joint working but early days. But yeah, there's the momentum is definitely building here.
There's a question over here, there's a question.
Speaker 10 00:38:16 Yeah. Very excited to hear that, that the testings tests are coming. Is there already like a first version of that publicly available?
No, everything we have is sitting on my laptop just there, so can I have a look?
So yes, but there will be soon, if anybody is interested in testing the tests with us, absolutely drop the certification team and email certification at O idf. Sorry, open, open id oh O IDF org one of them. Yeah. Or just find me on LinkedIn. But yeah, absolutely do get in touch and we'll make sure we keep you up to date with what's going on. And as I say, yeah, having as many people as possible actually involved and testing the tests is definitely good. Although, and I think the, the high assurance profile that Tosta mentioned is hopefully gonna help because as Christina said, there's a lot of modularity in the specs, there's a lot of optionality, which makes testing really difficult. And the higher, higher assurance profile is definitely gonna help us with that and with interoperability as well, which is very key.
And I think the, the profile can also be used as a segue to the workshop that's going on on the other, on the other end of the hall over at Open Open Wallet Foundation. We are also gathering contributors that want to yeah, actually build, contribute, donate code for open ID for verify credentials. And I'm also helping Open Wallet Foundation with that. And we already have a couple of companies committed to contribute capacity, development capacity and also source code to that effort and that will also help us. And the high assurance profile again, also is a way to, in the end yeah, reduce the, the, the, the future of feature scope to get started. So that's one thought I would like to share with you. And the other one completely different topic, as Christina mentioned, we have started to work on the open idfa VP over Bluetooth floor energy and that's really exciting because that bridges the gap between physical and cyberspace, right?
So we are aiming at a, at a future where you can use the same credential in both channels. I mean, we already have digital credentials that can be used in physical channel like our COVID certificates for example, but those cannot be presented when checking in to a flight, right? So, and there's also right now not, not very, very much support for presenting a credential. Yeah. In, in, in scenarios like ticketing, point of sales and so on. We are seeking for help. What we realize is that our community is pretty good in doing online protocols, but we are not very experienced in doing proximity protocols. Right. And BLE is, is a, is a, is a special beast. So if you are familiar with Bluetooth low energy and you can help us either with implementing the stuff or helping us with the spec, please come talk to us. Right? Right now we have people from MOIP involved, we also have people from Bosch involved that are very interested in that, in that, in that space. So we are really gathering people that have the experience and also want to implement the stuff to help us to involve, to evolve that. So if you want to contribute, please talk to us
There. Any other questions
Suggest announcing if you guys are interested in selective disclosure? If you can, if you go the, the other organization I'm helping out called Begin has just published study report on selective disclosure. It's only 13 pages long and it goes over current theoretical backgrounds so to speak. You know, on the selective disclosure, it's done by Professor Kazuko of Waseda University and I highly recommend it. I'll give you the Bitly link bitly slash all capital SR study report 0 0 7 capital SD selective disclosure,
Thinking that there's also a really good set disclosure report coming out from Etsy as well in European Union. There any other questions?
Gave was another topic for me to cover, which is, you see the part in that, right? I'm just kidding. It is a relationship with iso. So maybe some of you know ISO have been working on a specification called 18 oh dash five, which does, how do you present mobile driving licenses offline mainly? So it covers how the demo driving licenses over Bluetooth, nfc, it actually does have a session on how do you do MDL over open? Id connect Core, not open ID for vc, but the open ID connect core as well. So after that specification got published, the market feedback was, okay, gray, I can present, the user can use the wallet to present directly to the, you know, police officer, whatnot in, but in person, right? And it's only over NFC or Bluetooth and NFC is locked on one of the mobile os anyway, so the question was how can I do this presentation over the internet using HTPs?
So that's how that work started. And one of the options to do that inside the ISO documents coming out of ISO is the open ID for our presentations. And now the work for issuance has started. I think the current market reality is the same vendor built for wallet and the issuance. So the issuance is not exactly interoperable, but now that's a bit more standardization work on issuance side has started as well. And that has a profile of opportunity for credential issuance side of things and IO having its process, those specifications are currently only available if you are the member of say the working group or I'm the member of the working group and before those specification gets published, I have a right to, you know, send it to folks I want the feedback from. So if you are willing to provide feedback, come talk to me, you might be able to get a sneak peek of those two zeroes and 18 0 13 that you have, you know, heard. So it's, it's, it's not like they're not inaccessible at all. Like there are ways to take a look at those specs. Yeah. Did they cover everything with that? Yes,
There's a It's not publicly available. You have to become a member of working open native foundation to leverage the, the, the liaison relationship.
So come join us. Yeah, I think we're good to go. And yeah, if you want information, the URL to go to is really simple, open id.net/openid, four as in number four, vc, open id, four vc and that's it. And we have a dedicated page.
Speaker 11 00:46:01 Thank you.
Thank you Toten and Christina and for taking the pot shots from me on the sidelines. So much appreciated. Happy to welcome up Steiner, who's gonna take us through some of the Norwegian experience in implementing fpi. So here is your CL clicker. Thank you. And your power.
Speaker 11 00:46:24 Hello. Nice to see you. Nice. Hello Mike. All right, so I'm talking about FPI and FPI in context of e-health or health information and Yep. So the context for this is the Norwegian health sector. We're a small country, like about the size of a mid-sized American city. I guess we have two areas. It's the primary healthcare area, which is covered by 365 municipalities and around like 8,000 general practitioners. We have four health regions where all the specialist healthcare providers are organized and we also have called the health network. And the health network is an ecosystem and it sort of existed before we started talking about data sharing ecosystems. So it's basically also a physical fiber line. So that's the context and we need to share information between these different participants or actors in the sector. So just a little bit more context, the, the health network in Norway, as I said, it's a, it's a ecosystem and I'm working as a consultant for, for them. I've done that for eight years now.
Speaker 11 00:48:12 It's kind of, it kind of laid things out for us when we started working on sharing health information. So it requires membership by law and it offers an existing broad range of services. So that's sort of the basis for what I'm talking about today. Alright. I also wanna talk a little bit about what it is we do. So I'm hoping to evoke some emotion when you look at this, oh sorry, that was the wrong laser. When you look at this, isn't that great? That's the way we want it to be, you know, being in the center of attention when you're feeling bad, but it's also the opposite of what we want if we're not getting medical treatment. So we want to share when we need treatment. And from the health personnel's perspective, you need to be able to give the right treatment at the right time. And to do that we need to be able to share information in a secure and timely manner. So, so basically I'll give you brief history first and then I'll start talking about our experiences with fa.
Speaker 11 00:49:29 So back in 2015, we were hired by the Norwegian government to do a analysis of how we were going to solve the problem of, of authenticating and authorizing health personnel in Norway. We spent some time on that and we recommended, so the like open ID connect is sort of like the technical recommendation. We also recommended an approach which was kind of inspired by other countries initiatives. Our main approach was to be kind of agile when it comes to the organizational legal part as well. We went for the technical approach first. So in 2016 and 2017 we did technical tryout with some EHR systems with open ID connect and some national systems. It went great because the original thought was using SAML of course, and basing a lot on pki. So instead we, we decided on going for existing e i D providers, like the banks bank idea of Norway.
Speaker 11 00:50:43 And we had two other certified providers that was sort of the plan for us. And then adding more IDPs from the sector as as we went. So after doing the technical tri tryout, we, we wrote some papers on our experience and the sector said, oh yes, we love it, let's go. We wanna do this. So in 2018 we had a national Federation gateway running in production. It's an open ID connect provider. It was integrated with one idp, which was a national idp. It worked great, everyone was happy and it was a big, big demand. So we rapidly grew a lot of like the, the National health services were able, and that's due to open-ended connect. Of course it was, it was easy to connect. And then also we started looking at the advantages of oof riding on top of, of, of this setup. So in 2019 we did a new analysis where we looked at I am, we were looking at how do we actually authorize these health health personnel when we consume APIs.
Speaker 11 00:52:01 So we ended up with a recommendation. So the starting point here was, oh, let's do saml, no sacl service at the center of Norway and everyone will do that. So we ended up saying, we don't think that's a good idea, let's do a trust model instead and try to build up a trust framework based on that model. So that was exciting. So I started working on the trust model and the trust framework and then I suddenly came across the FPI working group and I was really envious of those damned financial people, people, they had a great tool. So, so I was lucky enough to be able to go down to Stuttgart in the O S W and I met these wonderful open Id connect people and they shared with me some thoughts and knowledge about how things are and I thought, well what the hell we, we can use this.
Speaker 11 00:53:01 So up until then we've been sort of trying to figure out our own way. We did have some tools, I must mention we had something called hardworking group that has a security profile, but now we sort of had a, a more thorough analysis, we had a different approach than Hart did. So we were really, really happy to find that. So we were working on this for a couple of years and then in 2021 we required FPI 2.0 and now the specification or the profile says that this isn't actually only intended for financial services anymore. And so it fits us.
Speaker 11 00:53:54 And like in 2022, we have had a lot of the national services actually using this. And right now we are finalizing a trust framework for data sharing through APIs and FPI is a central component of that. Alright, so our use of fpi, I've probably mentioned all this before now already, but the National Fed Federation Gateway requires it. That means that basically if you are to share data between legal entities, health, personal working for legal entities in Norway, you need to go through the National Federation Gateway. We are also an as for the sector. So if you are to consume service somewhere else, then your own company, then you need to get an access token or also of course do authentication through our gateway.
Speaker 11 00:55:04 We have a lot of current relying parties implementing this. And I see Victoria here is is here. So I'll try to be very careful when I, when I talk about relying party and client, they're often the same in our case, but it's, so the national eHealth systems like the, the, the National Emergency Response Center was based, you know, we, we came in early actually on that project, so we're requiring FPI as a security profile. So they have implemented that. Also, we have the e-prescription system, a new e-prescription system and a national patient summary application. And right now we are having the big thing that's also happening in eu, which is called European Health Data Space. We have our own little version of that in Norway. So we're now soon sharing journals across legal entities. It's, it's actually really exciting. All right,
Speaker 12 00:56:10 How many entities are participating?
Speaker 11 00:56:13 Every, every
How many entities participating was the question and I are, oh, are they all onboarded or you're still migrating? No,
Speaker 11 00:56:18 Everyone is required to to, to use it now. And
How many is,
Speaker 11 00:56:22 Is everyone? Well, I'd say like roughly 18,000 legal entities and around 500,000 health personnel. So that will be the, the end goal. Right now, I'm not sure, but we're issuing she low, so tokens, so yeah, a technical term, right? Yes, that's a very technical term. Yeah. Okay. So like the sum up, this is like my sum up of our experience with fpi. Well, it provides invaluable help and I really mean that because this stuff is difficult and there aren't a lot of people who are actually working on authentication and authorization in the depths that we're talking about here. So making all the right choices is made easy by FPI two, instead of sort of trying to figure, figure everything out yourself, you have like a, a recipe, but you also have explanation for every choice that you do. So you don't have to figure e everything out yourself, which is fantastic.
Speaker 11 00:57:35 It's also like privacy angst medication, as I've said here, it makes it easier to sell when you say, well we have this covered. We, we we're, we're pretty sure that, so I, we talked about the yesterday, we're a hundred percent sure you're, you're safe. Well, we don't say that, but we say, listen, we, we, we try to cover every sort of possible way to attack the protocols by using the security profile. So the ecosystem and the ecosystem national providers are safe. You just need to make sure you do stuff right on your side. So in our case, it's been, it's been great and it's been really nice to sort of be able to point them in the right the direction of the background of the specification, you know, pointing to other specifications like security, best practices, documents, et, etc. Et cetera.
Speaker 11 00:58:41 All right, so that's, I guess that's us in the superhero. We're not FPI 2.0 superheroes yet, but we are getting there. So I just wanted to talk a little bit about that because we have made some experiences, we have had some experiences during this, this period. For instance, we started perhaps a little bit early, so we have some implementations that are sort of lagging. And the reason was that when you do something in the health sector in Norway, you tend to need to do it because it's very close to the political decisions, which means that we weren't able to wait for everything we needed to do something at the time. And it means that we are, for instance, using signed request objects and client assertions, et cetera, for transporting information instead of raw. We, we don't have pushed author authorization requests and for us it takes time to sort of do the final lift, but it's, that's the way it has to be. We're we're in it for the long haul or I don't, I don't know what that's the correct term in English, but yeah, something like that. Yeah.
Speaker 11 01:00:01 So another thing that's problematic for us is that we have very many different systems. So we have everything from like large platforms that are huge, 50,000 servers. I don't know, we have complex patterns for using these protocols in, in these different, different systems. But we also have, like the other side of it, we have the other, other side of the coin, the, the standalone applications that are easy to do web applications, the apps, which, you know, we're kind of, of facing different problems for every vendor that comes along. And we also have a very high turnover, like a time to, you know, from the vendor does its changes until you have it in production. Sometimes it could take like two years. So it's the lead time is, is very long and this is required, has required a lot of effort from us because we need to help everyone with, you know, discussing the different architectural patterns using the protocols and security profile.
Speaker 11 01:01:11 Also we are, we're seeing that the changes that are happen happening right now with the, the new specifications going on, it it, it affects us because our core systems, the, the open ID connect provider, et cetera, needs to be updated and then every other system needs to be updated. So right now we're waiting for par. We will have it during the autumn. I think Depop will be in production for us in May now. Cool. Yeah, that's good. And then we have the problem of some vendors are being early adopters while others aren't. So we need to handle things at the same time, which means versioning, et cetera. We still do require FPI two and we will continue doing that because in our minds or in our way of thinking, we, we, we think that it's better to actually do the requirement, but mark everything as something that's missing. So we can have focus on that when we get there.
Speaker 11 01:02:19 All right. So right now also we are facing some channel challenges when it comes to centering token tokens. It's the Depop and mutual TLS part. The mutual tells is a bit problem problematic for us because we have infrastructure, which is not easy to control. It basically means that it might not be possible for us to control every header or every, you know, they, they do things differently in, in every organization. And making like a joint lift proves to be difficult. And it also sort of stuck in all times when it was strictly forbidden to share health information between entities. It's kind of strange that now you're actually required to do that. So let's see. I'll jump a little bit forward now. Seven minutes. Seven minutes. Yeah, that's good. And gives me just enough time. So another thing that weighs heavy on my heart, looking at Joseph now, we're not, and I'm very sorry to say that we're not using Fay's certification yet, and we really want to, because that's one of the major things that's fantastic about the Open Id Connect Foundation is that you actually have this certification program.
Speaker 11 01:03:49 So what we do to leverage that problem or mitigate our problem is to do code reviews. So every single software vendor that is going to be used in the health sector in Norway needs to come to us and do a code review. And it takes time. It's not scalable at all, scalable at all. Also, it's kind of, you know, it's, it's a little bit difficult to know what they actually do. So you do a code review. Sure. That's, that's a really good way of looking into the, to what's happening, but it's in runtime where you actually see what's happening. So we're looking forward to doing that. Hopefully we'll get there soon.
Speaker 11 01:04:29 So I just wanted to mention at the very end of my talk now, I do have five, six minutes, so I think this will be good. As I mentioned, we're, we're establishing a trust framework and I think this could be interesting for you guys to know as well, because what we find is that working on the trust framework requires not only like the, the the common things of, of terms and agreements and contracts and the interpretations of the loss, but it, it, it also weighs heavy on the need for common technical standards and the common semantical standard standards. So that's what we've been building in this trust framework. And what we find is that we do have a lot of benefits from using fpi because it actually allows us to sort of leverage the technical mechanisms to cater for juridical or legal requirements. So I have some examples here, but you know, the, the accountability thing is a very important thing to solve. You know, being, being able to, to have accountability ability for every action when you're doing health information doesn't need to be prescriptions, but it can just be looking at a journal. It's enough.
Speaker 11 01:05:59 Also, we have the GDPR things, you know, the, the legitimate interest is really hard. It's really difficult, but, but using RA for instance, in the, which is, you know, it's, it's spawned from the, the FPI working group, you know, the, those specifications in i f or perhaps spawned by someone sitting at the back end, the of the, so the thing is that we're able to express things that are happening on the relying party side and passing that through. And it helps us to explain to the patient what has happened, what is your legitimate interest, what's your legal basis? In our case, it's never, it's never used your consent. It's always law, it's always through some kind of, of a legislation. So also, as I mentioned, the, the semantical requirements, being able to express things in a common way and using the open ID connect provider is essential to us. And that's some of the things that we get from the FPI requirements using the, the specifications. Also, we have the organizational requirements. That's typically perhaps the most important part of, of a trust framework, but it's, you know, through fpi we're actually able to cater for some of the requirements there as well. So yeah, it's, for us, it's been very, very helpful and I'm happy to say that it's not only for financial APIs, it's for any api.
Speaker 11 01:07:44 Alright, thank you.
So thank you. So while the audience considers, if they have any questions for you in the last couple of minutes, Steiner, just wanted to thank you for that, you know, tour de force through the Norwegian eHealth experience. You know, clearly a, a massive journey over the last several years and a great example of how FPI can be applied to not just financial services, which we'll hear more about later, but to health and to other verticals as well. So really, really great example. Are there any questions from the audience for Steiner? So, no
Speaker 13 01:08:19 Difficult questions, only simple questions. So Steiner, are you utilizing the fact that there's a security analysis when you talk to people about why they should feel good using these protocols?
Speaker 11 01:08:35 Yes, to a great extent. We, we have, you know, as you mentioned, we have the security analysis by the stud card university. We have the experience of the industry, like the joint experiences from the industry. It gives us examples and we're able to be very precise when we say why we do this. It's based on the, on the analysis that, you know, no one else has. So for us, that's probably one of the biggest selling points to, to use that phrase. Yeah, yeah. So very important. Yeah,
Speaker 13 01:09:12 That was an easy question.
Speaker 11 01:09:14 That was very good. Thank you.
Can I ask one as well, Dina?
Speaker 11 01:09:19 It depends on how difficult It's, okay.
What was, what was holding you back from using the certification tools from the Open ID Foundation?
Speaker 11 01:09:30 Well, we started a bit earlier, as I said, so right now we have some discrepancies. We're not able to do the testing, so I, I guess we could do testing, but we will always have some red points, which we don't pass. So until we are able to sort of lift everyone up and we, we will, because in Norway we, we are, you know, luckily enough we have the, the national services where we can post these requirements. So we are actually able to lift everyone up. But yeah, we're, we're hopefully very soon we'll be able to do that.
Yeah. One of our homework assignments, right, for a conversation, definitely with your, your friends. Yes.
Speaker 14 01:10:17 Was there anything that you had to do in order for the end users, the citizens to, to understand how this technology was being used and adopted from an awareness perspective? And then same thing with the, the physicians, the doctors, the medical professionals, or was that really on the healthcare system to roll out that communication?
Speaker 11 01:10:39 Yeah, it's a very interesting question. It's actually both, but what I can say from like the, the privacy perspective, like open ID connect and FPI is really privacy enhancing because it allows us to, to transport information in a different way than we could earlier. So we have the ability to sh to inform the patient. And in Norway we do that through a Porwal. So every inhabitant of Norway can go into what's called . They can log in and they can see what has happened with their journal. And that's, you know, part of it is, I guess there are many ways to solve it, but using the protocol extensions that are specified in fpi, it makes it more trustworthy, the information because it's, it's been the, the sources of information has been authenticated and yeah, secure, secured in a good way.
Yep. Great. And last questions, right? Fantastic. Thank you Steinar for sharing this deep case case study. Yeah, much appreciated. Thanks for our next speaker, Joseph Henan is gonna share some of the progress in the certification group and here is your clicker for all the power.
Thank you Gail. And hello again everyone. Right, so we've already talked a a little bit about certification this morning. I know we do have a few new faces in the room, so I'll, I'll just very briefly introduce the certification program first before I talk about what we've been up to over the last year or so. So the Open ID Foundation certification is well over five years old now. We have a massive number of certifications, which I'll show in a minute. The program is very much an open program. It is very high integrity as Steiner can contest, you are either compliant with the specifications or you're not. And if you're not, you're not gonna get certified, unfortunately.
Oh yeah. And I never like going after Steiner cuz his slides are much prettier than mine and he uses English words that I've not heard before. So the, the certification program is based off an open source test suite. Everything's up on GitLab and note that I said GitLab and not GitHub because every time people says where do I find it on GitHub and it is actually on GitHub, but we do the development on GitLab. So yeah, and our, our aim is really to have tests for every specification within the foundation suite, but we're obviously not there yet. If there is a protocol that we don't have tests for and you want to have tests, then do talk to us because yeah, it was, we prioritize things as best we can like everyone else. So this is the latest update on our certifications. So last year we had 805 OP certifications. So the majority of those are banks that are now FPI certified and you'll see the, there's a lovely upward trend in the figures in general, bit of a blip in 2020 for some reason. If anybody can think of anything that happened worldwide at that point.
And yeah, we've already made a strong start to 2023 as well. So just amazing continued growth. So a bit more about what we did last year, firstly the usual support and bug fixing maintenance of the, the suite continued. That's something we have to do but it often isn't that visibility an activity but it does take time just to keep things ticking over. We have initial tests for open Id connect for identity assurance. Currently we're targeting draft three, but one of the things we want to do this year is to update to the, the newer draft or perhaps even final if it makes it to final this year when when, when it makes to fi it to final this year, I'm told by one of the working group chairs.
But yeah, so we do have the tests for that if you want to run them, do get in touch and I'll point you in the right direction. We don't have a certification program for that yet as we're not quite there with the tests and the spec. But again, hopefully this year we will be there. We created the initial test for the FPI two security profile and also the, the first set of tests for FPI SBA relying parties. We've had FPI SBA tests for a while for the kind of bank, the OP side, but this is the first time we've had relying party tests for FPI sba and that was mostly inspired by Brazil as that they're gonna mandate FPI sometime this year we believe. And we also created a profile of the FPI one test for Brazil open insurance. So I think that's the first open insurance ecosystem to actually go live. So the, the team in Brazil are doing amazing work actually getting these open data ecosystems up and running and we've made all kinds of enhancements to the tests over the year just to pick out a few across every test we have. We are now doing more validation on the ID token actually looking into some of the standard claims and making sure that if they are present, they're the right format, the right type and so on.
And we, we also added a, a check to make sure that pixie code verifiers aren't reused. And again we added that across all the, the tests we have that actually use pixie and that that's a particular particularly important one cuz although for the most part pixie is something that's enforced by servers and clients just have to do it. The one thing clients can do wrong is to reuse code verifiers. So we now pick up that and if a client isn't actually creating a nice random code verifier each time they're not gonna pass the tests. We've also made some improvements to the, the process for submitting certifications. So reducing the amount of time it takes us to actually process a certification, making the process easier for submitters so that we get more certifications that are actually right first time which is good for everyone.
And last year we also saw a, a big increase in the number of re-certifications that we're doing. So in both the UK and Brazil, the banks are mandated to re-certify annually, although it's not all banks in the UK yet. So what we've done so far this year, so we've already added one team member. So that's in addition to myself, Edmund Dominguez and Marcus who some of you may have interacted with if you've ever asked the certification team for help or put a certification in. So we now have Alan on board as well. And we are all only part-time, most of us have day jobs as well. So it's kind of amazing that we actually did everything that was on the last slide with just four people working part-time and it's also scary how much we're trying to get done this year. Oh come on to that in a minute. So we also added a FPI one profile for the kingdom of Saudi Arabia and we've had our first set of certifications from both vendors and banks over there. So again, great to see more ecosystems mandating FPI compliance and getting their ecosystems rolled out.
And we've also been addressing various technical debts. I think there's any of the engineers in the room can appreciate, yeah, it's great having code but there's always those things you have to do just to keep on top of all your dependencies and so on. So we've been putting a bit more effort this year into actually getting some of the dependencies up to date cuz yeah, last year there was a big focus on actually doing tests and some of these things didn't get as much attention as they should have and obviously we've also been working on the FPI two tests this year and actually launched the certification program.
I, I believe this is probably the fastest that a spec has ever been from the initial creation to actually getting implementers drafts out and getting tests launched. I think this is the fastest we've ever done it. So yeah, really proud of the team there. We've been doing a lot of work with the FPI working group to actually resolve various spec questions in the the FPI two specs and trying to brush them up so we can hopefully move to, to final this year for at least the security profile. And as we mentioned earlier, we've we've, we've started getting the open ID for verifiable presentation tests on the way.
Yeah so the plan for the rest of 2023 continuing supporting all the existing ecosystems, which we have enough now that that, that is a pretty big task in itself. Just keeping all the regulators happy and aware of what's going on in their ecosystems and what they can or should do better. We're gonna continue just addressing our technical debt. We've got plenty of up and coming ecosystems that we're gonna be engaging with and explaining all the benefits of certification and how they actually adopt the tests and get everyone through them. We've still got some work to do on the FPI two tests. So we haven't yet launched a certification for Depop, which is one of the options in FPI two for sender constraining tokens just cuz we have some tests for it but they're just not quite there cuz it's a specification we'd not worked with before. And there's, there's a few nuances that we just need a bit more time to finish implementing.
We're gonna be creating open banking Brazil profile of the FPI SIBA test. So we're just waiting for them to actually finalize their, their profile of the spec, which has unfortunately been a little while we've been waiting on that. Now as we mentioned, we're gonna be looking at the the open ID for verifiable presentations and for credential issuance to create tests for those. I think it's quite likely that we're gonna be looking at tests for open Id connect Federation as that spec is also getting a lot of attention at the moment. There's quite a few ecosystems that are talking about adopting it so it looks like it's gonna be pretty important to have some tests for it in the relatively near future.
And as I mentioned we've got more work to do on the E K Y C IDA tests as well to bring those up to the latest spec with fingers crossed, get a certification program launched and lots of people running the tests and passing them and I'm sure there's much more that I don't know about them we're gonna have to do this year as well. So yeah, people do come to us with new requirements all the time and we do our best to cater for them. So to talk in a bit more detail about the FPI adoption already hinted at some of this but we've already got the, the UK is has been lifer five years now I think and mandating annual recertification for the the biggest banks, Brazil Open Finance mandatory certification everywhere for relying parties and open ID providers and Open finance have now sort of come on board to the Open ID Foundation as a board member, which is brilliant. So we get a very close relationship with them now again Brazil open insurance mandatory certification there as well. And that that's still an ecosystem that's coming together so we're, we're still working with them quite a bit.
Australia CDR also been live quite a while now. The Australians actually stepped up and co-funded the security analysis for FPI two, which is brilliant. I'm sure that's probably gonna mention that in his talk. But yeah, FPI two now has a, a formal security analysis which it passed so that serves as a great foundation for the spec and I don't think there's any specs outside of FPI that anybody has actually ever really done that kind of formal analysis for
Last one point.
Yeah I was the, the TLS specs as Mike said, the the I TF did but particularly in the OAuth space, FPI is unique. Yeah,
So Saudi Arabia already mentioned we're having a lot of conversations with the, the Canadian regulator as well. It looks like they're going to put out some open banking regulations later this year. Not quite clear exactly what scope that's gonna take at the moment, but we remain pretty confident they'll be adopting a version of fpi, not clear if it'll be one or two at this stage. And they're also talking quite closely with FDX in the US who are the, the market led people actually defining the APIs and all the other things you need to put an ecosystem together in addition to the security profile. So we're also having conversations in the, the US with the the CFPB and some of the other bodies as we mentioned. Yeah, fdx themselves have put their weight firmly behind fpi so that's mandatory in their latest security profiles. And as Steiner mentioned, we've got Norway as well who are hopefully going to be doing some FPI two certifications later in the year.
So other ecosystem updates particularly. Yeah, Australia Connect ID we're very grateful to for funding the FPI two spec development. They've also certified their official sandbox as Gail mentioned earlier, if you weren't in the room. So we now have a, a whole bunch of people that are FPI two certified and published, which is brilliant progress cuz we only finally launched the certification program a bit over a month ago. I think Australia, I think we're expecting more movements on them on certification. We've had conversations with them and they've acknowledged that they have some problems in the ecosystem that look to be, that certification looks to be a solution for. So that, that's always a nice to see that when people don't follow your, your advice that they should probably be certifying people that things don't quite work out in the way we often predicted unfortunately that they might not work out.
I think I've mentioned most of these already, I think particularly in news from the uk is that they're looking to update the security profile they're using in the uk. They were one of the early adopters of fpi so they're technically still using one of the implementers drafts, but it looks like we're gonna get a decision from them to at least move on to FPI one advanced final, which is great cuz that'll let us retire the tests for implementers draft two cuz they're the only people that are actually using those still. And there's also been some chat from the trustee of O B I E just as she made her final reporters. They, they technically completed their, their their original task this year.
But one thing they particularly noted was that they only have the, the CMA nine, the biggest nine banks in the UK that are actually mandated to re-certify annually. And one of the, the things the trustee noted in her final report was that perhaps wasn't the, the best choice. And what they're seeing is that the banks outside that nine, the fintechs aren't actually integrating with them as much because they're not actually quite fully compliant with the standards because because they're not required to certify there's, there's no easy forcing function to actually make them fully compliant with the standards, which gets into a bit of a vicious loop where the fintechs only really concentrate on integrating with the big nine banks cuz the ones that aren't the Big nine banks aren't certified and are more difficult to actually integrate with. And that can become a bit of a vicious cycle and it it's against the original aims that the competitions and markets authority had when they actually set up open banking, which is to actually make the UK banking system have better competition because they have recognized that the biggest nine banks really have control of the market.
So yeah, so I think the trustee has made her recommendations, but we don't have to see if the regulators actually pick up on them and mandate a wider certification, which is a political thing rather than a a technical thing. They, they know all the technical things.
Two minute warning. Yeah.
Thank you gal. This is my last slide. So Japan, we've got our first cert FPI certification from Japan now that's live from Mina Noko and they're live with the FPI two, oh sorry, FPI one with some of their partners. It's great reach out in the various LA Latin markets as well. And basically we're talking to anyone that will listen to about certification and FPI and how great they are and that's me done. So any questions from anyone?
Well, while, while people think of any last questions for you, Joseph? Clearly very active, right? So a lot of work in terms of selecting the f p specification. Our attitude is the foundation is really to just support private entities or government if they're going through this process of enabling open data in any way, shape or form to make sure they're familiar with FPI and that it's in their mindset when they're thinking about what is the right fit for them in terms of standards to make sure they have all the facts. And if they do happen to choose our standards, then to make sure that they're aware of what we can do to help support them on a day-to-day basis and answering their questions as well as supporting them with any certification they might require. But they've controlled all the governance, right? It's up to them to decide how they implement, how they configure, how they set their rules for onboarding people into their ecosystem. That's completely with them. We're just here to help and clearly it's working right? There's a lot of countries and a lot of implementations that are seeing the value. So we're, we're seeing continued momentum and really excited to see what happens in the next chapter and where we are by next year this time. Right? Yeah. Any, any final questions for Joseph? All right. No, thank you very much appreciated Joseph. And now our last brief before our break will be from Mike Jones talking about Open ID connect and the project of Connect id.
Speaker 15 01:31:20 Hello, welcome. I'm Mike Jones from the Open ID Foundation and I'm here representing the Open ID Connect working group.
Speaker 15 01:31:33 So the working group has been in existence longer than most of the rest of them. We are coming up on the 10th anniversary of finishing open. Id connect in February, 2014. The 10th anniversary will be next year in February. And we have a bunch of final specifications including the leading one, open id connect Core as well as discovery and logout and the like that said, it's still a very active working group. For instance, the Open ID Connect Federation work is very active in getting adopted in places like the Italian national federations. There'll be two talks later in this conference about that work as well as you've heard about the verifiable credentials work that's also in the working group.
Speaker 15 01:32:39 So what have we achieved recently? A lot. We decided we're gonna finish stuff. There'd been a bunch of small specs that do one thing well that had been hanging out as implementers, drafts or drafts, and we decided where it made sense to finish them. So unmet authentication requirements is one, initiating user registration via open Id connect the native SSO for mobile apps, became an implementer's draft. We finished just earlier this month, the second implementer's draft for the verifiable presentations specification. We continue advancing Open ID Connect Federation, I think there'll be another implementer's draft soon, it's et cetera. So challenges and opportunities facing the working group. So an opportunity is the, that Connect Federation is in production use for not one, but two Italian federations.
Speaker 15 01:33:53 There are discussions on extending the trust model in federation to enable the use of trust based on web P K I, the T L S certificates as opposed to only self-signed entity statements. And that has to do with sort of philosophy of who are you willing to trust under what circumstances. There's a deeper discussion to be had on that, if any, if you'd like to have that with me or others during the hallway conversations. There's relationships between the digital wallet work as Gail and others have said. The Open Wallet Foundation is somewhere across the conference center and doing work that's related to this.
Speaker 15 01:34:51 And finally we've decided to submit our final specifications, hello York, to ISO as what are called publicly available specifications, meaning that we will get ISO spec numbers for the open ID connect specs, which helps in procurement in some jurisdictions where legally or legislatively they're required to use ISO or ITU specs when available. So what are some of the things we're doing? We're working on next implementer's drafts for the federation work. And again, there'll be a session tomorrow on that work that I and g DeMarco from Italy will be presenting there. There's a bunch of unglamorous stuff that you nonetheless need to do. While we're proud of the connect specs, they weren't perfect. Little errors were made places that, for instance, we typed HTTP colon instead of HTTPS colon and you have to fix those things or you will confuse implementers and that's the erota process.
Speaker 15 01:36:09 And that is something where most of the way through, but there's still 26 issues of little things that people found. We talked about the past submissions and I personally really hope that we get to Final Federation spec later this year. As Joseph said, there's increasing interest in deploying that even in places that we didn't initially anticipate that it would go. So some of the EI desk deployments and whatnot, for instance, are interested in using it to establish trust, which is actually a great validation of the work when people see that it fits a problem that they have, even though the inventors didn't think of their problem. That's a confirmation that maybe we're doing something right.
Speaker 15 01:37:05 So there's a lot related to this working group here at the European Identity and Cloud conference. So I won't read this whole slide, but I will leave it up for a little bit for you to read. And if, if you've been a good boy or girl and installed your app, you could add these sessions to your personal schedule. I was doing that in the last little bit ago. With that, are there questions or comments that people would like to inject into the conversation? And Mark Hain has a microphone, a magic wand for communication with that, unless Gail would like to do otherwise, I could free you for your break. When do we come back from said break? Gail?
I think we have some time for chit chat amongst members and friends who are here. So I suggest coming back by about 10 35 and we'll kick off again at 10 40 for the remainder of our agenda. Just to refresh your memory, we'll go into the specifics of FPI and the standards work in fpi. We'll also talk about E K Y C and IDA Working Group, which is the open ID connect for identity assurance work that Mark referred to earlier. There's also gonna be a brief on the government white paper that's been developed with several other nonprofits we'll speak to gain in the progress and gain in the last 18 months. And Nick Motheral will join us for brief on the open identity exchange. So please do come back and join us. Feel free to hang out and chat or get a coffee and restroom break and then we'll we'll come back in around 10 35. We will resume. Did you
Mention shared signals as
Well, Gary? Oh, shared signals. Apologies. Yes. Also shared signals. Yeah, another awesome update. So looking for,
Speaker 15 01:39:09 Oh, before you go, the last bullet on my slide, we have a call scheduled for 4:00 PM on Thursday for the working group. You don't have to do it now, but I would like it if you would look at your calendars and those of you who are in the working group, give me a thumbs up or thumbs down or to Nat about whether we should hold the call or whether we should cancel it in favors of sessions here. Okay, we will decide that based on your input. Thank you very much. All right,
We may is do I gotta click it? Okay, where's my clicker? All right. And over to Nat Samore, our chairman and working group co-chair of fpi.
I happen to be the open Id connect working group chair as well. But anyways, so you've, you've already heard a lot about FPI today, so I'm not going deeply into it. And we are expanding our scope. It's been deployed in, it's expanding the scope of deployment all over the world pretty nicely and some, some of them are legally mandated and that's all good. And our, all our spec are actually trying to be ISO directive compliant so that we can actually ship it to ISO directory as well, which I plan to do anytime now. And that's quite a bit, quite a bit different than pass. We could actually do the proper ISO in International standard as well because we are in their format. And we have been, we have published three specifications as you see now on your screen and that's FPI 1.0. And then we are working on FPI 2.0, busily the relative specs like client initiated, B channel authentication profile, SIBA profile, FABI 2.0, security profile and grant management for 2.0.
And we are all of the above is the implementer draft, which means the I P R is locked in. So it's safe to implement now. So, and we are marching towards final, so please do implement them and if you find any problems or any difficulty in reading the specs, please come back to us so that we can fix them. Before we go to final active drafts, we are working on FPI 2.0 message signing. And this is leveraging a new HTTP signing specification, which is worked on in I e tf. It's becoming RFC anytime now. So once that's finished we could also, you know, go finish 52.0 message signing. I believe right now the message signing is undergoing the public comment period for implementers draft for the 45 days. No, actually it's now, it's now in the voting period I guess. So if you're interested in it, please do have a look at it. And if you're a member, please vote Ari. And then five 1.0 lodging intent has changed the author, par and author and so on and so forth. So there's a fair amount of movement in the specification process as well. And adoption, I have already talked about it and you've heard it before, so I'll skip that. And we also have been, you know, cooperating to write white papers like open banking, open data and financial grade API and open banking and open data ready to cross border, which we are going to touch on it later today, right? The, the white paper? No, don't think so. Feel free to talk about it or, oh, would you like to, you know, give like three minutes summary of what it is? Yeah, sure.
Speaker 16 01:43:51 It's gonna be one minute, one minute summary, but so open banking, open data, ready to cross the borders white paper. So the first white paper there on FIP P is a really good source of information, how FIP P evolved and how open banking evolved and how they helped each other in a way. And the second white paper there, ready to cross the borders, is focusing on the potential next steps with open banking. And the hypothesis there is cross borders. Open banking is one of the possible directions and it goes a little bit deeper in the use cases for cross border open banking and potential, how it can be done. There are links on Open ID foundation website block and we can probably post them as well somewhere if someone is interested. Yeah. Can you also talk about funding the specifications while you, so one of the developments in, I think that's probably related also to the certification discussion, certification presentation that was presented a bit earlier as I'm coming from a practical implementer background.
Speaker 16 01:45:05 So I'm trying to implement ecosystem that uses multiple standards. And one of the things that we've discovered that the certification in the past was focused on individual specification certifications and we trying to bundle them up. For example, we would like to use Open Connect, we would like to use Open Connect for identity assurance, we would like to use fpi, we would like to use Open ID Federation and other specification. It becomes prohibitive from a cost perspective and time perspective to certify them separately. So one of the things that we're working on right now is potentially bundle them together. So each checker system might have a profile which has multiple certifications of multiple parts of multiple certifications together bundled, and it simplifies significantly technical onboarding of participants. Probably,
If I can add one last point since deem as a co-editor and we don't have Dave Tong here with us, I think the greatest compliment that I've heard in the last couple of months about these two white papers was from the head of open banking in Canada who said he had read every word and that that was very helpful for them to understand, you know, this evolution and the standards and how everything fit in in the marketplace. So thank you to Dima as for being a co-writer and to the FPI working group, you know, for editing those papers and making sure that they were on point. So if you are interested in FPI and you're trying to get up to speed, those two papers are really fantastic resources before you get into the, the detail of the specs.
So we've been putting fair amount of time to, you know, obviously you put a lot of time to, you know, write a paper and then the working group has been actually putting a lot of time to review them and refining them and this kind of, you know, prudent approach is one of the feature of this working group. And that prudent ness is the most, like in the next topic, which is formal analysis at openly foundation, this is the working group who started doing formal analysis. I think it's is the, the beginning of formal analysis in entity authentication started from ISO 97 98. I'm a, a good friend of the project leader of 20 97, 98, and they commissioned the work to the university of what was the, the, the other one. But anyways, that, that person was and, and yeah, no, before, before that. Okay. Yeah. But the, the, anyways, so you know the, the university where David Basin Hughes, anyway, sorry about that.
The, it just slipped, but, so the, the, that paper was done by David Basin, Cass Kramer, who did the TLS 1.3 formal verification, and we presented that in the oath security workshop there and, you know, made a call for contribution for formal analysis and eventually the, the University of Stuga people came up and did it for us. And for, for one FPI 1.0 for FPI 2.0, it's showing our global breadth. The Australian government is actually sponsoring the work for the formal analysis. And we have finished the phase one for 2.0 security, you know, the core, the base. And we are now doing it for other parts of the, you know, suite. And you know, Steiner earlier today was talking about the importance of formal analysis for the, for his selling process, right? And when I was listening to that, you know, the new acronym just came up in my mind for fpi.
I mean the, we in the FPI working group, we have been, we have agreed that FPI stands for nothing, right? FPI is just fpi, but it's proven, it has proven to be pretty hard. So for, you know, to say FPI stands for nothing, right? And then there are the listener's eye goes like, just gray, but, so maybe we could actually leverage formal analysis there. And I, I, I have just created a ticket in the working group that perhaps we could make a new acronym like formal formally analyzed protection interface. Fabi, right? Might be good. Anyways, so it's just, you know, throwing it out to you and if you think that's a bad idea, give a thumb done if you think that's a good idea, thumb up in the our ticket and so on so forth.
Maybe Nat, we can also ask for co-funding for work package three.
Oh yeah. And you know, so we, this formally, formally analyzed protection interface working group is asking for the father, fundings for the father works that we do. So we are still producing new specs and we intend to do the formal analysis for everything we produce. That's the kind of rigor that we are giving and it's, I think this is very rare in the, in the internet API field and that's one of our value. And if you are capable of funding that kind of, you know, academic project, please come up to us and speak to Gail. Alright, certification we have spent, we had a dedicated session for certification. So I suppose if we can just skip it and working group brought them up.
So I've got deliverables, aspirations, aspiration wise, F 2.0, message signing, fast implementers draft being done by the end of June. I think we are on track on that. So that's good for q3. Former verification five 2.0 message signing and SIBA to be finished hopefully. Do we have any delays? Not yet. Right. Sometimes, you know, we get, we hit the roadblocks in this formal analysis and it's usual and if that happens we have to delay the schedule. But for now I think it's good for q4 we do F P 2.0, message signing, second implementers, raft and fpi siba, second implementers, raft and grant management for all 2.0 second implementers, draft and Q1 2024. Hopefully we can come up with a final for five 2.0 specs. That's our aspiration. No promise, but that's what we are targeting. Art, I mean we value the quality more than the timing. So timing might shift a little bit, but that's what we aspire two. So that's from fape working group questions?
Yep, we have five minutes for questions now.
Okay, good. All right. So I must have done, did you have any questions?
It's a bit of a loaded question. Do you know if anybody's going to be talking in more detail about the technical details of fio T I C?
Is this comfort us like that?
So yes, tomorrow at five 30, Daniel Fe and myself are giving a presentation entitled High Security and Interoperable O or two, what's the latest? And we will be making heavy mention of fpi.
Huh? I didn't know that you were going to talk about fpi. I thought that you were talking about Orth 2.0 or something like that.
The latest in high security oath two is fpi. Okay, that's
Good. That's good to hear about that. And those a tweet during the today's session, that was you asking all 2.0 actually to include a statement that it shouldn't be used for entity authentication or user authentication, a z and should be combined with something like Open ID Connect or fpi.
I have a question as well, if I may. So we've mentioned the security analysis, which is incredibly important to fpi, especially for governments and ecosystems that are looking to adopt these standards, to have that rigor, mathematical analysis of, of the specs. But it's, it's one university and it's one way we're engaging academia. Do you have any thoughts around what good might look like, you know, for the foundation and for the identity community to engage with academia more generally?
Sure. I mean, so now the name came back, it was ECH or Technical University of Zurich that all, you know, this journey actually started. I think Daniel was at ET at the time or something like that. I don't know, but the suddenly the David Basin was that there, so we could probably engage them as well. And you know, we should expand the, the, the, the, how can I put reserve of in in academics, right? So that we can tap in to, you know, expand the breadth and scope of the, you know, formal analysis. We, we are kind of resource constrained right now because there aren't, we are not very much in contact with any other teams, but if you guys know them, please
Be great. I've got a contact, I'll add in na I think Napier in Edinburgh would be a good place to go.
That that'd be good. That'd be good. Yeah.
All right. Any last questions for Nat? All right, then we'll move on. Thank you Nat very much. And we'll move on to Markin talking about E K Y C and ida, a working group and the open ID connect for identity assurance or open ID for identity assurance. Thomas, you got one? Alright, thank you.
And sorry, I think I was late for my original build time. Was I? No, I'm on time. That's fine. I was along the corridor, the open wallet foundation speaking there. So green button. So yeah, this should be a fairly quick update but we'll do okay. Oh I'll stand there. That's good. So the objective of the working group if, if people don't know is to extend the content of the ID token or the user info endpoint to include a standardized schema for expressing all of the identity assurance metadata. Things like which pieces of evidence were used when the identity assurance was done and which processes were run through. So for verification and validation of the digital identity in question, we've got the polar specification there Open Id connect for identity assurance version one currently at fourth implementer's draft. And we, on the kind of achievements side of things, we've had our proposed jock claims registry update accepted by the IATF and the registry updated, we've got a bunch of other spec documents kind of underway and, and other components.
So we are, as I corrected Joseph earlier, going to get to final this year. I'm confident it feels like it's been a really long time coming. These are the hard yards of finishing specs off. Some very annoying people, you know who you are. Keep finding little niggly problems and I keep having to say, oh, okay then we're gonna fix that before we go to final. I'm pushing them quite hard. But thanks to the really hardworking contributors in the working group for finding those things and helping fix them, it's going to make a better spec at the end of the day. We also have an early-ish draft going on called the Advanced Inax for claims. It's not directly to do with identity assurance is actually more widely applicable to open ID connect and it's about more rich data minimization. So Daniel Fe's leading on that one with a bit of help from me and if you're interested in that area, please give us a shout.
There's another one which is even earlier in its life cycle called Open Id connect for authority that's looking to provide a really small standardized adjacent structure for representing on behalf of use cases where on behalf of applies to on behalf of another person or on behalf of a legal entity. So we allow for both of those cases. And then I think in common with quite a number of other of the specs, we're looking at doing profiles which lock down the optionality and make it easier for implementers to build something that's gonna be interoperable in our space. That means very specific definitions of how to represent a particular piece of evidence like a driving license or a passport or what have you. And also very specific definitions of how to represent assurance profiles, sorry, assurance processes in various regimes around the world. So Nest 863 springs to mind the IDAs assurance levels and all of the associated processes.
We need to make sure that implementers in Germany and implementers in, I dunno, Greece are describing I assurance levels and processes the same way if they wish to be interoperable from a progress perspective since the last workshop kind of already said it, but it feels like we're in the final mile. It's, it's the hardest mile though. We have got the Jock claims registry updated, as I said, and there have been a number of editorial changes pushed through. It's not sexy, it's not great fun, but it has to be done and we're getting there. It's a slog from an external perspective, we've, a couple of us have started working on a, a little bridging spec under the W three C, which takes a significant proportion of the work we've done in IDA on the schemer of verification and make that available under the evidence type of VC data model 1.1. So there's a crossover into the open ID for VC work that to and, and Christina and others are, are working hard on so that we can do high assurance identity in a verifiable credentials context. The open identity exchange has a thing called the Global Interoperability Working Group and as part of that, they're very keen to have the schema that we're developing under this working group as the, as the basis of a much wider interoperability layer to kind of identity assurance data level. So that's super, super support. Mark, could you talk a little bit
More about protocol being protocol agnostic in that work and particularly with O I
X? Yeah, so on the Global Interoperability working group, there's, there's a big kind of realization there that a lot of the data definitions, you know, the, the data dictionary used to describe all of this complex digital identity and all of the associated meta associated metadata to date has been quite vertically aligned with protocols. And really the drive to get the support that they're giving to us is to say, well that data layer and the semantics around it should be transferrable into other identity protocols as well. You don't need to, you know, redescribe all of this stuff. We've got a, you know, a nicely defined and you know, fairly rich Jason schema for all of this complexity. Why can't we just use that, you know, under verifiable credentials or other potential future identity protocols.
There's a, is that sufficient, Gail, would that answer the question? Good there, we've got some significant projects moving forward with the open Id connect for IDA Spec, although we're not quite final yet. So there's one called the Investments and Savings Alliance in the UK that's been doing some significant work to, to do a digital identity scheme under the UK Digital Identity Trust framework. And that's gonna be building a scheme involving banks and insurance companies and other relying parties that needs to be able to understand, you know, some of the richness of the assurance process that went on behind establishing the identity of the person. There's Connect ID in Australia, which is using a, a simpler version of what we're doing in the, the TISA project in the uk, but using FPI and Open ID connector Identity Assurance in in concert right Dima? Yeah, I'm good.
I'm representing you well. And there's a project in the US a sub unit of block is looking at using the open identity connect for open identity connect for identity assurance schema inside the VC that they're working on. So they're wanting to produce high assurance verifiable credentials using the, the IDA schema that we've been working on. And I discovered two weeks ago at i w from one of our working group members that we actually have an open ID connect for identity assurance service in production, in concert with FPI one advanced in Japan. And that's minko, you can see the, the branding there providing assured identity data over to the Fukuoka Financial group. I hopefully pronounced that reasonably well and I dunno if anybody's here, but I should have if I'd remembered to also add in the OSTE logo to that one because that is built upon a very active contributor to the working group's service that's provided by olet. So yeah,
And the, the insurance partner there as part of Sumitomo, I think people are familiar with Sumitomo.
Right. Thanks Galil, where am I? So yeah, some challenges we've been facing, I think I've kind of alluded to this, the balance to needs to get the spec to final against the, the lessons being learned by the implementers that we have using the, the spec. The, the challenge is to work out when we should stop doing the fixing and move to final. We are getting quite a lot of comments from potential implementers saying we want to do this, but we want you to be final before we commit. So there's a, there's a real tension there that we're having to balance. We've talked about the OI x about being perhaps the schemer that we've defined in IDA being evolved to protocol independence. We've talked a bit about the profiles, we haven't really got artifacts defined in that space. So there will be a bit of a challenge there and how to govern those profiles going forward is gonna be an interesting area for us to look at.
And then we keep finding little things that we might want to add in. But again, we've got this challenge of, of moving to final as soon as possible from some implementer's perspectives and from an opportunities perspective, we've got the, the idea schema with verifiable credentials, which I've probably said enough about. Maybe just to expand on that a little bit to see if anybody's conversant with the, the VC 1.1 data specification. It's the evidence property that we're using to put the verification element of the IDA in to express this. So it's a super skinny spec that just says, take that bit of IDA and put it in that bit of vc.
And yeah, just to reinforce the point, we have entities in both Japan and the US that are awaiting final before pulling the trigger on the use of the IDA spec. So that's kind of great news, but at the same time we need to get to final, how am I doing time wise, Gail? I'm doing good. Okay, so just the usual table here that we've got. So moving to final q2, that's the plan. We'll see whether there's some bumps in the road along the way. We also in Q3, aim to have an implementer's draft for the advancement tax for claims focused on data minimization in open ID connect and the open ID connect for authority implementers draft first implementers draft. The aspiration for Q3 is that we have got to final and the profiles begin to emerge. I'm pretty certain that's going to happen actually just, you know, based on the projects that are ongoing and in q4, I'm pretty optimistic there'll be more projects going into production and it's time to hand over.
So we have two minutes for questions. Okay. If anyone has them. And while you think of your questions for Mark, I'd like to also announce it amongst Mark's many special skills, he also can make stickers. So if your computer is a little bit more naked than you might like, we've got stickers for you
Fake tattoos as well.
Yeah, yeah. So you can also do the QR code of the tattoo on, on Mark's arm. So thank you very much. Mark, any questions from the audience before we move on to the next section?
Can I have a sticker as a perfectly acceptable question? Yeah.
All right. I'll walk around, put your hand up if you would like stickers while we introduce a tool who's hopefully come in great in the back. So introducing a tool who's going to give a demo as well as take you through the Shared Signals framework working group efforts. Thank you so much, Atul.
Speaker 18 02:09:13 I, I got this so I don't need
Thanks.
Speaker 18 02:09:36 Sorry, I'm gonna switch things up a little bit. I need both my hands for if we get time for a demo, so I'm just gonna switch to the computer,
Speaker 18 02:10:02 Right? I think we are there. So hi everybody, thanks for attending this session and thanks to GA for having me here. And I'm a, I am CT of a company called Signal, and if you want to know what we do, you can go upstairs for to our booth. But I'll get started on, you know, the presenting the update from the Shared Signals working group until recently, this working group was actually being called Shared Signals and Events. And that's one of the things that we've changed is to just call it Shared Signals. And so the basic idea behind Shared Signals is to be able to provide a framework with which you can convey events that are maybe of interest to other parties, right? And you do that in a asynchronous way. You do that with the ability to, you know, publish whatever you choose to publish to a certain provider and the ability to subscribe to only those events that, that you might be interested in.
Speaker 18 02:11:14 So sort of this negotiation aspect of, you know, what, what are you willing to share and what you're willing to, or what you would like to listen to, right? Because we think that this, the world is not just an IDP and an SV anymore, it's like a multi sort of multiple sources of truth. You may have device management services, you may have credentials providers or you know, credentials, scanning services, you may have endpoint security services and things like that, all of which may contribute certain events that affect the security of the whole system, right? And which is why you need a framework that can enable asynchronous communication in such a system. And that's sort of the Shared Signals framework. Now, based on the Shared Signals framework, we have what we call two applications. One is the continuous access evaluation profile. This earlier used to be called the Continuous Access Evaluation Protocol.
Speaker 18 02:12:13 The same acronym CAPE now applies to the profile, which is now a profile of the shared Signals and Frame Shared Shared Signals framework. And then there is a earlier application that is called Risk Considered Sharing and Coordination or Risk. And that is the other profile. So I'll tell you what each one of these does. So the, the key is mostly about sharing information about Sessions, user sessions, and risk is mostly about sharing information about account, you know, account related events like account compromise or account, you know, suspension and stuff like that, right? So these are the two current applications. The framework is basically written in such a way that you can, you know, add more applications if you would like. And there's, there's some interest in that as well. And just, we are a relatively new working group in the share in the Open ID Foundation.
Speaker 18 02:13:13 We've been about, I guess three years as a shared Signals framework working group. Before that, it was the Risk working group and the CAPE effort actually started independently. And then that got merged into the, the Open ID Foundation and sort of the combined group is called the Shared Signals Framework or Shared Signals Working Group. And that's what led to this architecture of, you know, having these sort of common framework and then two applications on top of that. So why is this relevant? You know, like to start with the buzzword that all of us love and sort of, everybody has their own meaning of for it. But I'd like to say that this, what we feel is that this is important to achieve zero trust, right? And why that is so is because you can, you know, independently, independently assert your observation or your decision about certain shared things.
Speaker 18 02:14:13 Like you may be sharing a user session with, you know, and if you're an identity provider, you may be sharing the session with the same user session with a service provider, right? So you may wanna say that, hey, for whatever reason, I do not believe that this session is valid anymore. And so I'm gonna send out a session revoked event. Now somebody who's interested in that event can subscribe to it. And if you are, if you're willing to convey that information to that party, that party will get to know that you've revoked the session. And so they make, they can make their own decision. Now, the important thing to note here is that everything in Cape and Risk is about asserting your state. So it's not a recommendation for somebody else to do something, it's just about describing what is happening on your end, right?
Speaker 18 02:15:03 And so we call it like, it's a descriptive approach and not a prescriptive approach, right? So unlike some other protocols where, you know, you, you bind the receiving party to do certain things when you're sending them some information, there's no binding. Here is just a description of what, what you've observed. And everybody's free to make their own choices, right? The same way you can have a credential change event. So sometimes you run into this situation where let's say you have a SaaS service in the cloud and then you, you have authenticated using your enterprise directory. Now the user has changed their password at the enterprise directory, right? And so what the SaaS services are interested in knowing is that, hey, if you've done that, you gotta reauthenticate with us, right? But that may be one SaaS services policy. The other other services policy may be completely different, right?
Speaker 18 02:15:56 And so that can be indicated through this thing called credential change, right? And one more use case, which is interesting, is the authorization or access management use case, right? So when, when you log into a service, you may be provided access to certain resources based on something in the token. Like for instance, if you're logging to an Amazon web service, you can be saying that, Hey, I need access to these resources, like these resource numbers, as they call it it, right? Later on, you may say that the same user now should have access to these other resources and not these resources. You can do that through, through Cape, right? So and so all these things can be done using, using shared signals. So let's talk a little bit about the updates. Like what have we, we've been doing since the last few months, we have been working on a new implementer's draft.
Speaker 18 02:16:56 The, the great thing is we, we got a good implementer's draft about a year back, but there have been some important changes since then, right? So the first thing is we now have the ability to have multiple streams doing the same transmitter and receiver. And that's important because certain receivers may only want to have a certain subset of the events or a subset of the, the users that they process. And so as a result, you may want to separate things out a little better, right? And that's, that's the multistream thing. The other one is, we were getting into this crazy nomenclature conflict with an Analyst firm in the us. And because they use SCC in a different way, our name, which was Shared Signals and events, we changed that to just calling ourselves shared signals so that the spec is now shared Signals framework and not, not SSE anymore, and a few little changes after that, right?
Speaker 18 02:17:51 So, so right now what we, where we are is we've gotten a good bit of the feedback about the implementer's draft. There are some 22 ish issues that we are working on right now. I would say two or three of those issues are, are what we can call as bugs, which means that if you're trying to implement the spec, you'll, you'll be a little confused about what does it mean, right? And so those two or three are the most important ones that we are trying to solve. The rest I would say are, some of them are questions, some of them are kind of, you know, nice to haves, like, this could be done better this way or that kind of thing. But largely I think the spec is, you know, getting there. And we are, we are trying to do the clean cleanup of the spec as a result of that.
Speaker 18 02:18:41 And then we are trying to engage with the industry. This workshop is a great place for us to, to talk about shared signals. We have a, I have a session tomorrow at 11 over here, and so you can attend that. And then we are gonna, we talked about it, I mean this, the, the Analyst from Gartner has introduced Cape as a innovation trigger in their digital identity hype cycle last year, 2022. And so there's great engagement and recognition from there. We are talking about it here, we're talking about it at Iver. I have a, I have a session with Microsoft at Iver on this. Now let's talk about the real problem, right? The real problem is adoption. And although risk has been adopted by Google, they send out millions of events to hundreds of thousands of applications every day. So that, that's a success story.
Speaker 18 02:19:41 But you know, as far as Cape is concerned, Cape Events themselves are being used by Microsoft and they're being used within the Microsoft services, right? So this is public information that, that I can share, which is, you know, various Microsoft Services exchange about 25 million cape events every day, right? So these are the, some of the busiest, busiest services that that company runs, right? So the protocol and the events all make sense. What we are seeing is a little bit of resistance to doing this across companies, right? And there are a few things I've heard, and we can talk about it, but let me get through some of this. What we are doing in terms of adoption, right? So one thing we thought would be good to have is a sort of a website where you can actually get KP events on demand, right? So if you wanted to build a transmitter and you would want, you wanted to say, Hey, I want to test my transmitter, I just need something to send me an event.
Speaker 18 02:20:45 So you can go to cape.dev today and, and get your own sort of transmitter to, to send you events, right? And we've, my company Signal has developed this in partnership with Open Foundation and I can show you a demo if, if time permits, but let's, let me talk a little bit about the roadmap first. So this next quarter we expect to be able to have a second implementer's draft. That's, that's our main goal that are those 22 plus issues that we are working on right now. There's good sort of this converging dialogue in our weekly calls, which we've now accelerated from being biweekly to weekly, just so that we get to that implementer's draft, and then hopefully by the end of the year we can have a 1.0 final specification, right? So this is kind of where, where we are, right? How much time do I have?
Speaker 18 02:21:46 Five minutes, four minutes. Five minutes or so? Yeah. Okay. Alright. Let me try to do a demo in five minutes. And this is, I just wanted to show you how easy it is. One of the criticisms I've heard is, Hey, Cape is too complicated. I wanna show you how, how easy it is, right? And so what I would like to do is, this is cape.dev, let me increase the font size, if that makes sense. Okay? So there's, you know, you can, you can learn a little bit about the specification. There's an instant recipe, like what you need to do in four steps to get yourself up and running. There's an FAQ and there's the introduction to the specification. There's, you know, all kinds of things that, that can help you get up to speed about Cape. Right? Now let me register myself as a, as a user and I'm gonna do that and that, and I'm not a robot and register, okay? I should have received an email. I'll quickly go over to my email and get, right.
Speaker 18 02:22:57 So I'm gonna just complete my registration. We are a small company, we are implementing Cape, and that's my phone number. And I'll just give a URL as a unique identifier for my receiver, right? It doesn't have to be a real url and I'm gonna complete my registration. I get an access token, right? So I download the access token, I open it, sorry, this is, okay, so I got the access token here, I'm gonna copy that code, okay? Right? And so now what I can do is I can, what I've now got is an access token that will help me test my receiver, right? So, but I don't have a receiver right now. So what I'll do is I'll just use the Postman collection. So this is just two methods, two like h acdp methods that you can run on Postman. I'm gonna download this Postman collection and I'm gonna import this into my postman. This is, you know, everybody uses this. So I'm gonna just import this collection that I just downloaded. Mm, sorry, this one.
Speaker 18 02:24:32 Alright, so when you import this postal collection, you get two things, right? One is to create a stream. Here's, here's how you open a connection with your, with your transmitter. And then you pull for cape events, right? Any new events that are coming your way. So when you create a stream, all it's gonna need is it's gonna ask you for a access token. And I just copied that access token from the email that I got. So I'm gonna do this and I'm gonna say, Hey, create a stream, right? And so it created a stream and it gave me a stream ID here, right? And now I go to the transmitter and I say, I want to transmit an event, right? So I paste my access token, I want to send an a session revoked event to my, with, for whatever reason. The e event, the session with this user has been revoked.
Speaker 18 02:25:33 And so I send the Cape event and it says, okay, this event has been queued for your, it gives you all the details of what the event that you, you will get. And now if I go to my postman, I can actually pull for that event, right? And so this is the access token, and I do that and I say, now the receiver is now pulling for the event, right? So I do the post and what I get back is a Jason, which has the, let's see, I think I need to make this bigger just so that even I can see this.
Speaker 18 02:26:21 So it has the name of the, you know, there's a unique identifier as the value as the key name. And then there is the value, which is your, the, the set, the security event token that you got. And I'm just gonna format it so that I, I can see what it is. All right, so here you get the, the actually event, the session revoked event with that user email address that, that you, you said you wanted, right? So the reason for me to show this demo to you is it's so easy, it's ready for you to use and there's nothing stopping you. So please help yourself and build a transmitter and receiver.
So bef, while we see if anybody in the audience has questions for you, clearly one of the challenges facing the, the working group, the initial implementers is kind of crossing the chasm a tool, right? And part of that is the familiarity with the tools and reference applications like this, but also thinking about the business agreements and the relationships and how to scale. Because that could be a whole lot of transactions if it's every ecosystem, public run, government run, we've talked to Mir, there's interested in the US government, like there, how do you think about crossing the chasm and adopting this type of, these protocols?
Speaker 18 02:27:49 Yeah, I think it's sort of the, what I would think is the pressing use case, right? Like what is the killer reason why somebody would like to do this? And I think everybody is adopting zero trust. And today it is appalling that we don't have a way of revoking those sessions, right? So if something goes wrong, now you don't have a way of sort of conveying that information. And that is where I think this becomes really important. And as we start seeing more adoption of a zero trust architecture, I think you're gonna see the demand for this naturally arise. There's a lot of interest. I I talk to so many people who say I would, I would have a transmitter if there was a receiver or somebody would say, I would build a receiver if there was a transmitter. So it's gonna happen, it's just a matter of time, right? So, and all we can do is just keep, keep beating the drum, right? So, and that's what we are doing. So
Yeah, it certainly does, does feel inevitable, you know, from the conversations I'm in. Any questions from the room? Great. Well thank you for the demo. We'll, much appreciated.
All right, so next we'll be talking about the government white paper. And Elizabeth Garber will talk about the work on this one specific white paper out of the series of seven that we flashed up on the screen screen earlier. So glad you got in off the plane in time to be here. Yes. All right, I'm gonna go find the clicker thing. This seems very straightforward. It just says back and next. So I feel like this can be done, but we have to get through shared signals again first. So while I do this, I'll just explain who I am. My name is Elizabeth Garber, I am the co-founder of a small startup called ID partner, and I'm also the co-chair of the gain technical proof of concept at the Open ID Foundation and also the co-editor along with Mark Hayne, the guy with the tattoos of, of a white paper now dedicated to exploring the landscape of government identity systems.
So this was a massive, massive scope, and I'm just gonna give you a bit of a tour of where we're at with the paper so far. It's not yet out for a public comment, but it will be very soon. And I'm really interested to take your questions and your builds as we go along. So the first thing that we started with was, goodness me, what is the role of government even? And how can Mark and I, in our Anglo-Saxon sort of culture speak to anything universal and globally applicable to governments around the world? And so after a bit of soul searching and how, how can we ground this paper in something that is, is fairly universal, we ended up deciding to ground it in the Universal Declaration of Human Rights and the associated UN covenants where 173 nations have signed up to these. And even if they don't deliver them perfectly all of the time, it seems like a pretty universal stance that we can take and say, this is, this is how we want identity systems to, to look.
And then the second question is, well, what is the role of government issued identity anyway? So part of the paper is gonna be exploring what, what does identity do for people? What does identity do for society? And so for any given person, it helps them when it comes to registration of birth, which leads to the attendance of schools, the issuance of a diploma. It's, it's, it's something that stays with them throughout their life cycle. And whatever system is in place within a jurisdiction needs to support them in all manner of, of things through their life cycle.
And of course, it needs to be designed for people at the edges. We can't ignore the edge cases in the design of digital identity systems. We need to design for people with disabilities who are seeking asylum in a foreign land or who have immigrated as children, fled an abusive partner. What happens when you enter witness protection program? Does the digital identity system support that? Does it enable you to stay safe in all of these contexts? And so we recognize that there is a lot of literature out there, and a lot of the literature talks to the tremendous opportunity of digital identity. And you'll also find a lot of literature about the tremendous risks in digital identity. And you can read more about some of the risks and and benefits in a privacy context with he, Heather Flanagan's recently published digital, oh, what's it called? I've forgotten the title.
Speaker 12 02:32:28 Credentials and the privacy landscapes,
Government issued identity credentials and the privacy landscapes. Very good. Very, very wonderful paper. This paper is taking a broader view of the landscape, but I do recommend reading Heather's. So we built our paper around a range of literature. We did a lot of reading before we scoped out what we were actually gonna say. You got things from the World Bank, the World Economic Forum, you've got ID 2020 consult. Hyperion did an amazing a hundred and no 200 and something page document. And then recently, just as we were preparing our draft, the O E C D came out with their draft principles and their, their principles that we can really stand behind. And so we're looking to make sure that we build our recommendations and weave the, weave those principles into, into what we speak to. Another thing that we did was look at what are the different archetypes around the world?
So we explored, and this is just a summary of, of what's in the paper here, and I'm sure that people will be dying to move my flags, but I'll I'll tell you why they are where they are, and we can, we can have debates about these things. So we looked at along the X axis, you can see different forms of technical architectures, beginning with government issued digital identity with biometrics. And then you've got sort of state issued where, where the biometrics are local on device or, or not at all. And then on the other side you have personal more self-sovereign style systems. On the Y axis, you can see that the, it ranges from pure private governance, which would be a pure commercial trust framework up to the top, which is pure public governance, where a public body is fully governing a system end-to-end. And what we do in the paper is explore the kind of risks and trade-offs inherent with each of these approaches and try and talk to how one might mitigate those risks.
And those trade offs, as I mentioned, we, we built off of, in large part the O E C D draft recommendations. We also aligned those recommendations to things that pre-existed. So the ID four D principles, the ID 2020 principles, and we, we kind of looked at what's common across each of these, what are the themes that run across all of them, and then where can we build upon it? And so in the paper you'll see that we'd speak to a few different things and I've grouped them sort of together. So we've got recommendations about needing to have a holistic strategy when designing digital identity solutions, needing to understand what it's gonna do for the, the government itself and its population understanding how it delivers human-centric design principles. So designing four people to ensure that it's, it's enabling them to, you know, reap benefits across their life cycle and avoid the pitfalls. And in order to do that, it recommends strong community engagement. I'm gonna pause here and see if there's any questions so far. And Mark has the microphone. I do have a couple more recommendation slides. These are just, I'm just pausing at each grouping
Speaker 19 02:35:45 Regarding your last slide with the flags. Oh, I knew it. Why the, the European Union flag is there for the IDAs, the trust network. Indeed,
Indeed it is. Is that wrong? No. Okay, good, good. Anyone wanna challenge flag? I was gonna say
There's, there's two Canadian flags there because we looked at two different identity schemes existing in Canada as well. Absolutely. It's not a mistake.
Same with the us. Two different schemes that, that we looked at. Does anyone wonder what any of those flags are? One of them is the nation of Bhutan, kingdom of Bhutan. That's
Elizabeth's favorite. Geek is nationalities and flags.
I do, I'll totally geek out of geography any day. Okay. So these are the kinds of discussions that we have in the paper. And then the next set of recommendations are around tools and rules and institutional protection. So it's incredibly important that technology doesn't move too much faster than the tool, than the, than the rule book, than the institutional policies that that protect people. There are lots of examples and they're, they're sort of outlined in the paper, lots of examples of nations where systems have been implemented prior to the development of privacy preservation, privacy preserving legislation. So we explore that and then we've also got some more technical recommendations, including the need to find ways of establishing trust between counterparties at scale. So how does this wallet not to trust this relying party and vice versa, how does this individual know to trust the wallet or trust their lying party or the issuer? All of that is a, is a very deep technical challenge. One that we're working with at the gain proof of concept. We've got interoperability. Anyone know what my picture is of you? Do it's rail gauges? It absolutely is. Mike Jones, you got a prize?
I like rail gauges. Sorry. And then we have recommendations to government about engaging in emerging standards and maturing those standards, getting involved in communities and standards bodies. So all of these recommendations, I mean it's it's a lot, it's a lot to cover. And we can drill down into more detail if you like, if you have questions specifically about any of them or you can read the paper. Do any of my colleagues want to add any color or flavor into any of them in particular?
Speaker 20 02:38:37 It would be good to get input from everyone on that flag slide.
Mm,
Speaker 16 02:38:42 That flag slide requires definitely requires some input from Australia, which I'm happy to contribute, but I think everyone else can contribute as well to either shift the flags where they belong to or to add more flags.
More flags. Yeah, more flags. I'm very happy to stick Australia on the, on the slide,
Speaker 16 02:39:01 Definitely.
I'll just chime in to say, in the nature of the work as executive director, I speak regularly to government officials and I think there's a strong appetite for this work at all different levels of government, you know, states, provinces, national entities looking for guidance as well as civil society to like come up the curve. What is the, the thought process for sharing this with the public, right? So for experts, other experts like those in the room as well as for governments to review the initial draft and to provide their own comments. What's the thought process about? Yeah, when, when will they be able to, when soon. I think May 25th was floated recently, wasn't it as a, as a date for the, the public draft period? Is that, or maybe a few days earlier. So maybe a few 20. The ID for Africa, maybe a few days earlier than May 25th.
Yes. Soon, soon, soon it will be available for public comment. We have quite a solid draft now, but this is a complex paper with lots of, lots of, lots of ways of presenting the information. So yeah, I look forward to having your feedback. Any questions from the group? No, thank you very much, Elizabeth. Thank you for that review of that particular white paper. Much appreciated. I know you're about to, to pick up the batam for for gain, but I will just kind of sign post again that we've had seven papers over the last year. In fact at iden we're gonna do an overview of all seven of those papers in a talk. So we talked about two for FPI earlier in this session. We've talked about one that was launched last week on privacy, so government issued identity credentials and the privacy implications. And we're getting already some rich feedback on that one.
And we might find we need a version 1.1 coming out very soon. So a lot of demand for that particular paper. Obviously this one taking a wider view on government. And then we also have some reports on IOT and AI that we're, we're, we're working through the board process right now, so thank you for that work. Yet another area is a white paper on gain and what's happened in the last 18 months. So please, Elizabeth and Mark and Dima, please look forward to hearing more about gain. Yes, none of us is Dr. Toten lte. I I could go and find him. No, no, no, no, no. Okay, he's not here. We're gonna do this without him.
He's missing out. Okay, so my other hat is one of the co-chairs of the gain technical proof of concept gain stands for Global Assured Identity Network. And as I've just been talking about it, identity system interoperability serves a lot of crucial purposes around the world. It helps to deliver a great user experience when you're traveling across borders or between sectors. It helps to ensure national security, it helps deliver financial stability when money is being transferred across borders. And as I've just been talking about the underpinning of human rights. So interoperability is, is essential. The Global Assured identity network began as a paper written 18 months ago and it was calling for a just that, a globally assured network for high trust identity information and it was underpinned by four key principles. Although as you can see we've added a fifth one and not changed the heading.
The first being global interoperability that sort of speaks for itself. The second being technology agnostic, the third being built on open standards. The fourth being distributed governance, this is the one we added. We wanted to make it clear that we're not calling for any new central nodes of governance and the the last is that it needs to work at internet scale. And although we say we wanna build on what has already been built to leverage the reach of what's already been built, it's important to put that little asterisk on there and say over 18 months and and into the future what's been built will change. New standards are emerging, nude tools are being adopted and we wanna ensure that we're always moving with the times. The governance of the global Assured identity network sort of steering group rests around six organizations. Now you have the global, or you have, excuse me, the open identity exchange and I, I think you're gonna be hearing from Nick very shortly, Nick Mother Shaw.
And they're really looking at the interoperability of policy frameworks. And then on the other side you've got the Open ID Foundation, which is housing the technical proof of concept, which is what four of us in this room lead and Dr. Toten LTE is not here to speak to with us. So we're testing the technical standards that will enable interoperability and I'm gonna let Dima talk in more detail to that in just a second. The other organizations that work with us are the Global Legal Entity Identifier Foundation. And if you don't know who they are, they they govern the use of the legal entity identifier, the l e i around the world. And this is gonna be a crucial tool for ensuring that entities are able to establish trust, establishing trust in the entity itself is what I'm trying to say. You also have the Cloud signature Consortium, which sets the standards for e-signatures, the Secure Identity Alliance, which does a whole lot in the space ensuring that IDE identity systems are secure in building best practices and standards.
And then the Institute of International Finance with speeds for the financial services industry. So we have all of these organizations building standards, testing standards, and in particular the ones that are leveraging all of them, sort of weaving them together in different proof of concepts if you will, would be O I X and the and the Open ID Foundation and these organizations sort of loosely form a, a guiding body or steering group and have signed a memorandum of understanding to work together and collaborate towards the vision of gain. So what is it we're looking to connect islands of trust, I think I've already explained that and we'll go into more technical detail about that, what that means right now. So we've got the control plane, this is how do we ensure that different entities in the ecosystem can trust one another? What's our, what's the mechanism and the protocol for ensuring trust at an entity level? And for that we built on open Id connect Federation, we're gonna speak to that in just a second. And then you've got the data plain. So the protocols for the transference of data and we've been using Open ID connect for identity assurance, which you've just heard Mark share the update on. So with that I'm going to pass over to Edema and Edema is going to regale you with the technical
Speaker 16 02:45:59 Is it one slide on it or do I need to clicker? There's
Another I didn't know if you wanted say more about that one before you got into that one
Speaker 16 02:46:06 But Hi, I'm Dima, one of my heads is co-chair of the Open 90 Foundation gain POC technical working group. And I will continue this on a bit more technical level. So if you think about identity interactions between two parties, between two different islands, you need, you need a couple things, couple layers. One layer is to establish the trust between the participants. How does relying party in Australia knows that it can trust a bank issue, an identity in the UK or Germany. So that's what we call control layers. Just put in slightly different words. And then the actual data transfer. So about, I don't know if it's still 18 months ago, it's now two years ago when it's all started and first game I think was announced at EAC as well. It was September though. September, yes. It was a different timing because of covid. So shortly after, that's probably almost two years ago, shortly after we ran a proof of concept on the data plane which is how do we actually transfer the data between different participants And we used open, ID connect for identity assurance and OP and open ID connect itself and that was the easiest part.
Speaker 16 02:47:22 So we, within three months we had multiple participants, multiple types of participants connecting to each other and transferring identity data. So that was the easy part. The next year almost we spend on different discussions around the control plane or another name for it is trust management. So this is how we establish the trust and establish the trust in a way. So we don't set up a centralized entity governing at all. So GAIN doesn't have a centralized entity, it is literally connecting the trusted networks together and making sure that each network has enough information to make a decision who it can trust. So there is a policy level aspect that is taken care of by oex. This is looking at the actual identity assurance levels, comparing them and giving enough information to participants to make those decisions. And we looked at different mechanism of establishing trust and we settled on Open ID federation and we've done a proof of concept in the last probably three to four months on that as well.
Speaker 16 02:48:28 Another thing that's worthwhile mentioned that this control plane or trust management is definitely a hot topic because there are multiple entities around the world and that's what we notice in different discussions are looking exactly at the same space. So there is UN development fund is looking at, they started off with the covid credentials sharing, but they're trying to take it further in the health space, especially there's AI does too that will have that problem where you need to establish a trust between different walls coming from different countries from different jurisdictions. How do you trust those systems that connecting and exchanging quite sensitive data sometimes and gain is another one that looking at the same space more from a gen general global level.
Speaker 16 02:49:12 Now what, what have we done? So this is a sort of one way to describe proof of concept that we've done on trust management. So we've established three federation islands. So if you, I dunno if you know open ID federation spec, open ID Federation spec allows you, allows parties to query trust metadata between different participants and understand and rely on the governance of each of the networks. So one of the ideas we had, we, we don't want to establish the central entity, we want each of the existing networks. So if you look at here, yes.com for example, it's an existing digital identity network here in Germany we don't, we definitely don't wanna prescribe how they transfer the data, how they do trust management. But we want to build the interfaces that allow other parties to understand. So they've built, they've got existing line parties, they've got existing IDPs, they build adapters to connect to other networks both inbound and outbound.
Speaker 16 02:50:18 And what we've done in, in a proof of concept, essentially connect to different reliant parties from different networks to different IDPs in different networks. So before that we created, I think someone coined minimum viable specification product where we looked at the specifications and tried to align across global scheme. This is a profile of open connect, this is a profile of an iConnect data assurance and this is a profile of federation, the minimum set of things you have to implement to enable that. So we've discovered certain things that need to be tightened up after this proof of concept. And that'll probably be our, one of our next few activities. We're probably not gonna go into demo, but we did have a really good demo of one of our participants K ddi, where they demonstrated a use case where a user was actually really, it is really quick, really simple, but it's really powerful to see a user lens, an airport, they see a QR code, they scan it like international airport in Japan they code and provision EIM on the fly so they can utilize local mobile networks and not to pay judges. And I keep saying every time I'm speaking about this that I'd love to have this here for example in Germany when I arrive. So that was a really good demo we can probably share separately. It's always tough to share the video in a presentation like this, but we'll probably share it somehow in the slides.
We learned that the hard way a couple weeks ago. Yep,
Speaker 16 02:51:48 That's right. Have I missed anything? Can I,
If I can emphasize what I think is so cool about this proof of concept is it's three completely different countries, Germany, Japan and Italy. Three completely different industry verticals of mobile networks, banking and a government stakeholder with a government network proving that they can interoperably move identity data between each other. That's awesome. That's really neat. So and that can be scaled to end number of entities participating in those networks, right? So that's putting in practice what the theory of gain was all about 18 months later it works. It's really neat. So good job by the proof of concept team.
Speaker 16 02:52:32 And another interesting point is those networks, because we, on the previous, one of the previous slides we had a technology agnostic as one of the goals. So in Alpha POC we had existing networks that are not open ID networks, they're just digital identity networks operating in their, their own way connecting. We also had wallet implementations connecting as a reliant parties as well. So we are not really prescribing, trying not to prescribe from gain perspective what technology you use internally. As long as you cover your external interfaces within the network of networks, you should be fine. And we're trying to keep them as simple as possible and build on existing standards. We haven't developed any of the new standards ourselves. We use existing standards.
Yeah, I think that that's also a huge point, right dma like if you have a decentralized model or a centralized model, like whatever that stack is that's happened within an island is okay, it's long as those interfaces work between them. So that's true for, in this case it's an identity network but in a wider sense of open data or open banking, that could be true for open banking integration across borders as well. It's a similar principle so it's a really big idea that's proven out
Speaker 16 02:53:44 And one of the hot topics right now in the working group is exactly trying to bring the bridge between the sort of federated and decentralized build. So we have quite a lot of contributions and everyone is welcome to join the working group to advance that further. It becomes even more topical for Europe with IDAs regulations coming in. I think that's all for me. Alright, don't talk.
Yes, there's more. I mean dma DMA sort of alluded to it a moment ago. The world is moving on, right? We've had a lot of new changes in the regulatory environment. I two has, you know the, the architectural reference framework is out. We've had development in the government, excuse me, the mobile driver's license landscape. We've had updates to verifiable credentials, we've had updates, all, all sorts of things have changed and are moving on. And so the proof of concept is taking stock right now and working with the experts that we have inside the working group to figure out how we create those bridges. And one of the things that we're doing at the moment is writing a white paper which will be available for public comment imminently soon, very, very, very soon. It's, I think it's almost ready. Dima left some pretty, pretty hard-hitting comments I have to say. So I gotta go work with those but I think probably 24 hours and it's ready. So we're trying to get this paper out for public comment just to say where we have been not just at the Open ID foundation but also at Nick Mother Shaw's working group at the O I X and the policy domain and some of the things that have changed at, at glyph in particular, but also just across the, the market. So look out for that paper and now you make clap.
Can, can you share a little bit more as co-chairs on a couple of points? So one is on the shift from it being a banking led paper to a wider industry paper. So over the original paper was indexed more around the opportunity cost for banks. You know, if they lost control of trust and trust moved away and identity moved away from them, they'd lose some of those payment rails and now it's a much wider concept. Yeah, I mean I would characterize the initial paper as sort of arguing that banks had a tremendous opportunity to catalyze this network. It wasn't targeted only at banks operating and running the network, but it was saying, hey you have an amazing opportunity to help make this thing happen for the world. And not only will it benefit you, but it'll benefit your customers and it will benefit relying parties and it's, it's very obvious, please do it. That said, with all of the developments in the market, there are a lot more opportunities for others to come in and invest and be the catalyst for this network. And so this next paper that we're writing right now really, really broadens the scope while, while still remaining open to the participation. And catalysis, I'm a biology major and I still can't say that word.
You know, being open to banks really, really playing a leading role if they, if they so choose alongside others.
Speaker 16 02:56:57 Yeah, I think the focus for us was always connecting existing islands of trust by no means we're setting up new islands of trust and were not forcing to set up a new infrastructure and the banks were natural first iteration because they already have K YC identities already ready to be shared. Yeah, but it's not exclusive government also in the same position.
Could you say a little bit more about government and particularly you've mentioned like the 18 0 13 dash five work, like what's happening in the eu, other jurisdictions like around how the, the proof of concept working group is think community group is thinking about bringing in government participation. So Italy is a start. Like any other efforts in that space bringing government in.
Speaker 16 02:57:44 One of the things that we're definitely trying to do looking forward is, so with the ADAS to looking at trust management, we're trying to see how this working group can become useful for yeah does two to help this to establish that trust management and different conversation, different activities in different forums. That's one. The other one is because we connect in existing islands of trust, my personal preference not necessarily a gain preference is always connect to the root, root of trust for each particular credential. So it's always helpful to, to connect to the the regional issue as opposed to sort of issue of the issue or filtered through the process. And a lot of times government is that regional issue for basic identity attributes. So any anything else there?
Well I know we're, we're speaking a lot to, I know, I know gala, you've, you've hosted many calls with treasury in the United States. We've had, we've had conversations with European regulators about these issues. I think the collaboration continues. I'm not sure if there's anything you'd like to add beyond that There's loads but let me first open it to the floor and see if there's any questions or comments on the work on gain.
Speaker 19 02:59:07 Yeah, thank you very much. You already mentioned the IDAs 20 framework network approaches, so you're collaborating already with them because the current version is a SAML based network that's not really scaling that.
Speaker 16 02:59:23 That's definitely looking at the next phase and I think GA probably can add more on collaboration with AI does.
Yeah, so big picture the speaker rep behind, sorry, disturbing the, we have entered into a liaison, it's kind of being inked you know as we speak and they've invited the open ID foundation to take part in a series, I think it's about five workshops that are coming up that the expert group is hosting to work on the next revision of the architectural reference framework. So we're kind of in on the conversation already cause they've selected some of the open ID foundation standards, particularly what some of you heard earlier is open ID for verifiable credential issuance, open ID for verifiable presentation and SIOP self issued open ID provider v2. So they have those in. But I think there's more nuance into how exactly those specifications are implemented in practice. One of the hypotheses was when the EU digital identity work goes into some future stage of certification and interoperability within the eu, can we help them in any way?
Right? We have freely available tests that we'll be developing. Can we con, you know, could they consume those tests as we think NS will probably collaborate in developing the tests so that the interoperability between within the EU and between other digital identity issuing authorities, that that interoperability is proven out And that means everyone's leaning into the same versions of the specifications like implementers rep two of open ID for verifiable presentation. Like that's one example where California said, we'll lean that way. Can we get the confirmation from the EU that they'll point that way? Can we do the same with New South Wales as they adopt and they're moving towards that direction. So we're trying to make sure everyone's nudging similarly into the same specifications. They're leaning into the same tests and using the same test frameworks that actually proving out the interoperability work through whatever forum. This is an example of a forum, the proof of concept work that that could be a space where interoperability tests are are done as and proven out as well. So we're just kind of trying to make sure we're talking to all the right thought leaders and intimately involved in the conversations around supporting them in their due process. Does that help answer the question?
Speaker 16 03:01:35 Yeah and the reality and interesting sort of interesting side of interesting part of this communities there, there are a lot of members of GAIN POC working group that are also members of different other forums in Europe and some of them on expert panel for rf. And so there are a lot of unofficial informal connections as well beyond the official connections that Gail mentioned. Yeah.
Any other questions? Otherwise this is a natural transition from this work. Thank you again Dima and Elizabeth and Mark for the overview and Joseph as well. And we're gonna rapidly transition to O I X's work, which dovetails beautifully with gain and a lot of what we've briefed you on this afternoon. So you have the clicker Nick, and then you'll be all powerful. Your mic on? He's got a mic.
Speaker 23 03:02:28 All
Right. Nick Shaw.
Speaker 23 03:02:29 Thank you. Hi everybody, I'm Nick.
Speaker 23 03:02:36 Hi everyone, I'm Nick Mother Shaw. I'm chief identity strategist at the Open Identity Exchange and we like O IDF are a members' organization. We're a kind of a sister organization to O I DF set up around the same time by the same people. We look at the rules whilst O IDF looks at the tools. So we're looking at more of the policy level of interoperability, which is tough because policies are different all over the globe. So what we've been doing as part of gain is looking at something that's starting to be called the open policy rules exchange framework work. And what this is enabling us to do is understand the different policy rules and exchange them between parties. And that started out as principally between frameworks. So from one framework to another. But as we expanded the work and explored it, we realized that the policy is a often initially expressed by the what was what's called the acceptor or the relying party subject to the framework they're working in.
Speaker 23 03:03:36 So we have different layers of policy. We have a framework that says, well these are my, these are my policies around proofing, assurance, privacy, data management, consent, security fraud complaints, management disputes, liability, I could go on and on about the different policy areas that exist. These are all actual mostly commercial and legal rules that a framework may set and an acceptor is subject to. So when I'm an acceptor and I'm expressing what I want to get from an identity, I can use the same language, I can use the same exchange framework. Then if I'm issuing some kind of credential, I can also use the same framework to express the policies that apply to the credential that I've issued. So how are they proofed? What kind of credential standard are they? Where might they be used? Are there any consent requirements for their use? Are there any areas where they cannot be used?
Speaker 23 03:04:31 So that same framework we've now realized can be used by all of these different parties to describe the policy requirements and that can be attached to individual credentials, to wallets as a whole. And the work we're doing is not just about wallets, it's not all about wallets. There are lots of normal, say normal IDs, traditional IDs, you note, I'm not using the word legacy, many IDs are government issued, they're centrally managed. That will not change. So we need to have a work in a world where we have a mixture of IDs from a one end centrally government issued wallets to private sector, sorry century government issued IDs to distribute it, private sector wallets. And again we're designing this framework to work across each of those ecosystems, recognizing also that federation doesn't go away. So I see so many presentations where I see this linear journey from centralized through federation to decentralized.
Speaker 23 03:05:35 But if we're going to have a world of multiple wallets, we still need the concept of federation where that selection of wallet is made, data is delivered in a standard way, there is a framework around that that means that it's done in a consistent and legal legally acceptable way. And we're working with the non frameworks around the globe on this analysis. We've already completed analysis on the UK framework, the EU latest version in both the regulation and the A and NSTA version four. We're currently working with Singapore and Canada and Sweden analyzing their frameworks. We're just about to start working with Thailand, I hope and MOIP as well, sorry, are also doing an analysis. So we will hope to have analyzed eight different frameworks from the three stroke four. I've kind of half done the Taiwan so far. We're finding that we're get, we've got a lot of commonality in the way they approach proofing.
Speaker 23 03:06:38 It's the same methodology but a lot of difference in the way they approach policy. And that's because policy is necessarily different but also it's evolving. So we expect to go through a normalization step there as we evolve the analysis and this framework is enabling us to answer these questions. The first question is can I trust the wallet or the ID itself? So that's a kind of fundamental question. The carrier of the identity, can I trust it? Who's it from? What policy rules does it work to? And these are where the most of the general policy rules fit. And then the, there's kind of three questions and which question you ask depends on what you're trying to do. So it might be, does an individual credential meet my requirements? So if I want to hire a car that could be a driving license, can the wallet derive some information I need?
Speaker 23 03:07:27 So is the person over 18? It could do that in a lot of different ways depending on the rules of how you derive a person is over 18 or can it derive a level of assurance that I need? And what we've realized is level of assurance are local and they reflect local available evidence and risk appetites. They're tiered usually. And where the tier break points are set and how the risks are formulated is different. So the concept of saying we're actually an IAL two from the US is going to be the same as a medium in the EU or substantial in the EU and a medium in the UK is a very difficult thing to do. It's easier to add up a set of credentials and formulate a new level of assurance. So that's what we expect to be doing as we un unveil the rec methodology.
Speaker 23 03:08:17 We've also been looking at data standards and we are calling for a protocol independent data standard. We're about to release a quite a large paper. Which conclusion is that there should be a single data standard regardless of the envelope. Whether it's been carried in a verifiable credential within an MDL or a digital travel credential through idc. The data is the data. Is the data the envelope you put it in, yes, is different and it's different security features for different delivery mechanisms. But the data where it's an equivalent name or an equivalent field should be the same. So we're going to be calling for that and we'd like to see that the O I D C verification object is used as a start point for that standard because there's no reason we can't drop that object in lots of other envelopes in terms of credentials, assessing whether an individual credential makes your requirements, we need to know quite a lot about it.
Speaker 23 03:09:12 Who's it from? That's well covered in most of the standards. What kind of policies apply to it that's new. That's the thing we're trying to unravel and enable to be communicated. What's the credential format? We have several emerging formats. Dccs, there's generic verifiable credentials, there's MDLs, how's it proofed? And this is an area we're doing a lot of work on. So how was this credential proofed and connected to the individual? How do we know it belongs to them? And bound into that literally is the question of authenticators. So what authenticators do I need to present the credential to make sure it is still me presenting it. So it's the genuine user presenting the credential. And I've already mentioned the data that goes with that. So we see that there are a number of new standards required here, standards around proofing. If you look at different proofing methodologies across different frameworks, you'll see them referencing the ISO standard here and there.
Speaker 23 03:10:11 But generally they're setting their own local standard for the process of proofing a document or using data. We need that to be standardized and transparent if we're going to achieve interoperability at the credential layer. And we think that's easier than trying to do it at the level of assurance layer. But this is work we're still exploring at the moment. And what we found, and apologies for the complexity of this picture, but there is a pretty common level of assurance methodology. It's about identifying a set permitted credentials or evidence, putting that through its invalidation and verification methods, combining those and this is the secret source. So I then combine the verification methods together usually into groups, sometimes singly. And then I then use a single or multiple pieces of evidence to derive a level of assurance and of the frameworks analyzed so far, they all follow the same process.
Speaker 23 03:11:10 We've been able to match map each of them into this process. Which means if we can get the credentials consistent and be able to communicate the trust in the credential, we can come up with a level of assurance and we could do that dynamically by land here in the, in the eu. Now with a UK wallet, the credentials in it can be read possibly by a local agent and a level of assurance in the EU context formulated. That's what we're trying to work out. Is that going to be possible in the future? So like my phone, like my bank card, my additional ID works all over the globe. It adapts to the local rules. So again, this is part of the analysis we're doing at the moment. I'll be talking a little bit more about all of this on Thursday morning. We've got a keynote then and we're doing a, a deeper dive on Friday, aren't we, Elizabeth, into, into the, into gain and what we're doing next there.
Speaker 23 03:12:02 So it gives you a little bit of an update of where we've got to so far. If you're interested then please gimme a shout, come and join our working group that's, that's looking at this. So we're, we're gonna heads down at the moment on those five other frameworks, but when we get all the information back, it's gonna be fascinating to see what we can determine around this commonality and can we come up with this exchange framework that will be a global, a global tool that frameworks can use and wallets can use around the globe. Okay, great. Thank you.
Wonderful. Before you run away, Nick obviously thank you for being here to share your, the work of the open ID identity exchange. This is exceptional work in my opinion to do this level of rigor. I mean clearly some of the partners you maybe glossed over or saw on the page there working with the Singaporean government with Diac on their trust framework with the US government, with you know, here in the eu you're trying to work with all of the key players to try and make this a reality, right? And in 18 months this has all kind of come together, you know, pretty fast. When are you thinking the white paper might be made available?
Speaker 23 03:13:04 So hoping to finish the analysis on their owning five in the next couple of months. They're all this all in, it's in train with all of them two to three months. So I'm hoping that we can bring that into white paper over the summer. We have our oh conference in September. So I want it, I want it out by then. So we can be talking about it at that point. What happens next though, cuz that that will be a paper on the analysis and what we found so far that will not be a complete methodology if that paper looks like it's going to be create a useful methodology. What we're saying to all the, the eight we're working on so far and some others we're also discussing this with is the next phase we've be kind of to do that for real, let's try and get each framework to properly describe all of their characteristics and processes in the methodology we've now defined at the moment we're doing it at O I X and we're making it clear to the partners we're working with.
Speaker 23 03:13:51 This is at the moment a piece of analysis. We don't to it dead, right? No one's gonna use the output other than for the paper. So we will move on to create a a, a full and, you know, production level framework if it's looks like it's gonna be a success, but I also want to bring it to life. So what I would like to do in Q4 is with our members and anyone else who wants to contribute is show a wallet moving from domain to domain, reading a new framework, such a policies and adapting as it goes. Cause I think if, unless you bring so
Possibly in the real world as early as q4,
Speaker 23 03:14:25 Yes, as an experiment, I don't, you know, I don't think it'll be like there's no reason why
For a real transaction or demonstrated like demonstration actually gained proof of concept. We're trying to
Speaker 23 03:14:33 Demonstration transaction. But yeah, I think we can move to that later this year. Wonderful.
Thank you. Thank you very much. Nick. Any questions from the group for Nick on the work of the open identity exchange? All right, not hearing any at the moment. Wonderful partnership working with you. Thank you so much Nick, for coming in to joining us, you know, for the continued collaboration. Please. Steiner,
Speaker 11 03:15:00 Quick question. Is it possible to, to see the stuff you've been working on or is it everything is sort of happening behind the curtains? Because the reason I ask is because I've, I've drawn a lot of inspiration from your work from for the trust framework guidance thing you've got on your website, so, oh,
Speaker 23 03:15:23 Thank you. Thanks. Well, I'm, I'm glad you're using that. It's, yeah, it's, and we, we continue to iterate and evolve that there'll be a new version late summer on that. Oh, more Wallace bracing and we're going to separate it out into more, more consumable chunks. It's all a bit of a long read at the moment. So we'll be reconstructing that it's, it's not published at the moment. We're working, one of the conditions of working with the kind of five frameworks, or sorry, eight frameworks that we've got. If we go back to that slide there, so this list is for, for many of them, they're not ready to share the analysis publicly. They're okay to share it within o So if, if you're part of the working group or NOx member, you can see what's going on. But we aren't able to publish it. When we do publish the paper, it will be taking selected examples, agreed with the frameworks to illustrate how it works and talking about, we will be publishing the whole characteristics though, but we won't be publishing who uses which characteristic other than by example. So yeah, un until we publish it, I'm afraid we, we can't share it unless you're, you're part of the confidentiality of the project and you're very welcome to join the project. So let's talk about that separately. Yeah.
Just become a member. Right. Join the working group.
Just one question on the previous slide, you had permitted documents, right? The orange slide, all the Yeah. The box one. Yeah.
Speaker 23 03:16:46 Yeah. It's always orange.
Yeah. Permitted credentials. Back in Japan, we have seen actually the, some of those quote unquote permitted credentials being weak in terms of the security feature or verification feature. And was, has been used as ave an attack vector there. So what kind of requirements are you talking about? The, the, the threat analysis or, you know, what, what the, the mitigation toward threat kind of things to be in the, the requirement for the permitted credentials.
Speaker 23 03:17:31 So to what, what we're seeing in the analysis now is that we've got that credential weight across the top arrow. So what people are doing is they'll have a list of credentials they accept and they'll use these score things like passports, very highly driving licenses nearly as highly as a passport, especially if it's chip readable. Bank accounts not quite as highly. And then other documents sit further down and data sources tend to sit a bit further down as well. And this is where the, where we're seeing these combinations come in. So we, we, on a validation method, we might say, you know, we'll give a higher score to a face-to-face check of a document or a scan of a document than we will data. And then we then combine those two things to come up with another score that then feeds into the overall model in the uk These are, these are actual scores. You see them, you know, go through the model and the analysis. We've done a missed in the eu, we, we end up codifying these things and codifying the combinations. The combinations have more higher implied weight when you apply them in the model. So yeah, you, you're absolutely right. The different pieces of evidence have different
Strengths, threat, threat based, you know, requirement might be,
Speaker 23 03:18:41 And that's
More compatible internationally.
Speaker 23 03:18:45 And what we're finding is what we are finding those data is very local. So this is why we focused in on the, the fi, the five golden credentials that we were, the passport, the driving license, telco account, bank account, and national ID card. Other things everybody seems to reference in some way people are starting to reference other people's digital id. So the UK does for instance, and it's probably gonna reference its own government ID as well, which has been given quite a high value. But yeah, it's difficult to explain it on this, on, on a single slide, but yeah, that, that's, that's in there. Yeah.
Speaker 11 03:19:22 So, so interesting. You mentioned the way you're waiting, the different sort of activities or processes or are you using something similar to vectors of trust or, or like to express this or how is that set up?
Speaker 23 03:19:39 You, the way we're expressing it at the moment is you end up with a, with a, with a, with a spreadsheet row over here that says we've got this combination plus this combination plus this combination equals, you know, a level of assurance. Yes, you could reduce that down into a kind of vectors of trust methodology I guess if you wished. We haven't gone as far as communication yet. We're trying to work out where the methodology is. But yeah,
So I can just add that we should be able to represent that pretty directly in the identity assurance spec as well. We have the ability to do verification methods and validation methods explicitly in that schema,
But you need the rules in order to automate it in a protocol.
I'm standing here thinking I need to get your analysis and convert it into some profiles for the identity assurance spec, don't I?
Speaker 23 03:20:35 Yeah, that would be good. Next time. Yeah. Okay,
Cool.
Excellent. Well thank you again, Nick.
All right. And with that we conclude our tour de force of a pretty decent sampling of what's happening in the Open ID Foundation right now. So based on kind of what you've collectively heard from, from the start of the conversation, some of the white papers, different efforts in the working groups and community groups and with our partner organizations. Any other questions from, from the floor, things you'd like to bring up? All right, well not hearing any, you'll see many of the members wandering around during the course of the next couple of days. Feel free to broach us, you know, have some creative conversations, such a privilege to be here in person to talk about new ideas right as they come up. And we're delighted to continue to work with you in terms of if specific ideas here resonate, I can click forward to our website, open id.net.
There we go. Open id.net. If you are intrigued, you're not already a member for the very low price of $50 as an individual contributor, you too can be a member of the Open ID Foundation. And of course for entities, we have a progressive scale to to have entity corporate membership as well. So we would really value your membership to help support the work of the foundation. It is, these are open standards. We derive our income from membership directed funds and certification, pretty straightforward. We try and keep certifications super low price. So we appreciate your membership to help deliver on our goals and our mission and our vision, but we also allow for contributions to the technical work or to the community groups at zero cost. There's no obligation even for membership to take part and contribute. So if you're not already involved, we warmly welcome your engagement as I'm sure Nick does, and the open identity exchange. So thank you for attending and joining today and we look forward to speaking more outside of these four walls. Thank you.
If you wish to help us with our promotional activities, we do have some stickers left. Come and see me or Gail.
