Manu Sporny: The discussion at W3C at the Web Payments IG is ongoing, on credentials and identity. The same people who said they are very interested in identity and credentials continue to say so. We distributed a poll so they could speak up for the Credentials CG/WG recruiting drive. Only a very small handful of them have done that. I'm going to have to pick up the phone and call them directly mainly because they are so busy and don't get to the poll. Even people in the Credentials CG haven't put anything on the poll so we need to get people to do it. It could be the holiday weekend that's partly responsible. I think people are busy or they are being nice and we have to get past that. ✪
Manu Sporny: The Web Payments IG has 75 people in it, hopefully we'll pick up a couple from there. ✪
Manu Sporny: From a recruiting standpoint, I got the full list of AC reps that were asked to fill out the poll that would probably be interested in credentials or supporting us at W3C. I got the list of people that haven't responded yet to Eric Korb and Richard Varn so hopefully you can have your recruiter people go after them. There's 100+ on there. I think 35 have responded. ✪
Manu Sporny: We have around 16 organizations so far, if you scan down the list, we're missing ETS, Badge Alliance, Concentric Sky. ✪
Manu Sporny: Sure, just keep in mind time is running out. We need the names by the end of July because getting them after that before TPAC is highly unlikely. ✪
Nate Otto: I talked to Wayne, C-Sky's president, he's positive can't put a "Yes" yet, but after today I'll be able to talk more clearly after some tech discussions. ✪
Manu Sporny: We've contacted CSC and Accenture ... I've made appeals to their reps, we've contacted two, I've got to wait on NRF and I haven't talked to ACT I'll talk to them this week. ✪
Manu Sporny: Does anyone else want to be actively involved in recruiting that's on the call? ✪
Manu Sporny: What's the status of Badge Alliance? ✪
Nate Otto: As far as who is footing the bill, won't be decided until later, but you can put them down as a strong maybe and get them signed up. ✪
Manu Sporny: Were there any other organizations that were missing from here that should be on here? ✪
Manu Sporny: Richard, my guess is that ETS is going to say yes to this? ✪
Richard Varn: Yes, I'm going to tell Mark to fill out the survey. ✪
Eric Korb: Rob Abel CEO of IMS Global offered to help recruit, though said that IMS doesn't join other standards bodies. [scribe assist by Nate Otto] ✪
Eric Korb: I have spoken to IMS, Rob Abel, and they said they don't typically join but they'd help recruit support for the project. I'll have to reach out to IMS myself and take them up on their offer. Their membership is definitely a target. Someone who is not on here is Blackboard. ✪
Eric Korb: You need a different group. We need someone on the Badge Alliance side. ✪
Nate Otto: I reached out to Mozilla Foundation and didn't get any answer on that. ✪
Sunny Lee: I think if we did get Mozilla support... as you know Mozilla operates as one big head and one smaller sized head, the Mozilla Foundation, and the Badge Alliance came out of there and sometimes they don't communicate. ✪
Nate Otto: I think we could get it to the point that they don't oppose the work, but I don't know if there's any particular engineer that's involved in the foundation side that could contribute. ✪
Manu Sporny: That would probably put Mozilla into a "no"/"not worth it" category. It's hard to get them to join efforts that aren't the main thing they are working on. ✪
Manu Sporny: Not a browser manufacturer, they've been a bit schizophrenic regarding identity, etc. I think browser manufacturers would be more disruptive going into this at the start. The browser reps at the F2F for Web Payments IG weren't too keen about identity and credentialing on the Web. ✪
Richard Varn: That's what you don't want, what do you want? ✪
Manu Sporny: If 75% of the ones that are blank to say yes we'd be good. ✪
Richard Varn: I just meant did you need a replacement for Mozilla. ✪
Manu Sporny: No, ... ideally we'd have all the big browser manufacturers at the table but it's been problematic. We'll probably give them a heads up that we're starting a group and we'll expect their help at some point. I can dig into that. The question is whether we dig into that now before we start proposing charters or after. ✪
Manu Sporny: Let's go ahead and put a stop on the recruiting discussion today, we have a lot of strong needs that we need to close out and get this to W3C management. ✪
Manu Sporny: Let's say we get 40; that's definitely enough for a very strong argument to do work at W3C. ✪
Eric Korb: Can you put a total on there? I can do it if you give me access. ✪
Manu Sporny: We have been working (Accreditrust and Digital Bazaar) to put together a site called "authorization.io". [scribe assist by Dave Longley] ✪
Manu Sporny: Authorization.io is a technology demonstration platform that will eventually become a polyfill for the browser APIs that we are proposing. ✪
Manu Sporny: This site represents the full round trip for the credentials lifecycle that we're covering in the CG use cases. ✪
Manu Sporny: It covers issuing, storing, and consuming a credential ✪
Manu Sporny: It ensures that these services can be provided by an arbitrary number (many) of third party services. ✪
Manu Sporny: Through the standard, these can all interoperate. authorization.io is the technical proof that we have built something that can interoperate. ✪
Manu Sporny: The data structures, and protocols should be finalized before we go into an official working group ✪
Manu Sporny: It's important to do that before starting a WG, so the WG doesn't get sidetracked by research. ✪
Manu Sporny: The web side is responsible for finding out who your id provider is and routing requests for credential issuing and consuming (transfer) ✪
Manu Sporny: Regardless of what device you're on; in all of those scenarios you are redirected to the proper identity provider. ✪
Manu Sporny: The same thing happens if you request a credential. You'll be sent to your id provider to get the credential which gets sent back to the consumer ✪
Manu Sporny: Much like the Mozilla backpack, but in a fully decentralized way. ✪
Manu Sporny: Also, if you decide that you have a bad experience with your id provider, you can move your credentials to another id provider without getting permission from that id provider. ✪
Manu Sporny: This is credential portability, which is akin to cell number portability, which we now have in the US. ✪
Manu Sporny: Eric is correct. If you want your work stuff to be stored at one idP and your home life stored separately, you can do that as well. ✪
Manu Sporny: Code is on github, you can read about how it work.s ✪
Nate Otto: What happens if the browser manufacturers don't want to implement this? [scribe assist by Dave Longley] ✪
Manu Sporny: Strategy is to plan for failure as far as the browser manufacturers are concerned. It's hard to get something into the browser. It may be years of convincing; we don't want the browser vendors to prevent us from building out this ecosystem. ✪
Manu Sporny: We continue using the polyfill. The strategy is to plan for them to fail to implement it. It may be years of convincing before they put the support in there. We don't want browser manufacturers to prevent us from building out this ecosystem. [scribe assist by Dave Longley] ✪
Manu Sporny: One of the stragegies is polyfill; the other route: if the browser vendors become very imterested and implement very soon, that will only take effect in new versions of these browsers, and polyfill will still be necessary for older versions. ✪
Nate Otto: As a polyfill is it required to be centralized? Will there only ever be one authorization.io that demonstrates this ability? [scribe assist by Dave Longley] ✪
Manu Sporny: It would be technically difficult to build multiple polyfill providers, but we would like to run authorization.io as a community effort, getting engineering resources from partner orgs. It becomes a critical piece of infrastructure and must be up 24/7. ✪
Manu Sporny: We expect there to be only one authorization.io, but many companies to be involved in providing data centers around the world to serve up authorization.io traffic. ✪
Manu Sporny: The reason there can only be one authorization.io right now is that the database that it's using needs to be synced across all data centers. The database contains things like mappings of your identifiers to you id provider. ✪
Manu Sporny: We've been talking about webDHT, but we don't have that built out yet, so until we have that built out, authorization.io needs to have a centralized database. ✪
Manu Sporny: Once we have webDHT, you might be able to have a second polyfill provider. dlongley: there would be some downsides, because your keys in-browser will be stored relative to one polyfill, and it would be hard to transfer them around. ✪
Manu Sporny: We expect it to be run for 7-10 years before we can end-of-life the site. ✪
Dave Longley: I expect we will be able to do this at some point after browsers implement API natively. ✪
Manu Sporny: For those familiar with the Mozilla Persona project, this is similar to what Persona did ✪
Manu Sporny: Though, we're saying that it should be a federation-run service, not just run by one organization. ✪
Dave Longley: If you want to be able to link credentials together, and assert that certain credentials are tied to a particular identity - all 7 of these credentials are tied to a particular identity - you need to tie them to an identifier of some kind. ✪
Dave Longley: The simplest way to do this as Linked Data, you say that your identifier is a URL. If you use a URL, you can link credentials together and everything will work just fine. ✪
Dave Longley: As a person that is using that URL, you have to make sure that the server continues to stay alive over time and you have ownership over that URL for a very very long time. If that URL disappears, so do all of your credentials. You have to get all credentials re-issued to you. That poses a big problem for some credentials - some take a long time to get. ✪
Dave Longley: That's one possible problem for using a URL. Another is if you decide to change Identity Providers - better features, current identity provider has been hacked a lot of times, whole variety of reasons you may want to change providers. ✪
Dave Longley: If you want to change identity providers, you can't rely on the URL being stable. Another problem with HTTP URLs is "vendor lock-in". ✪
Dave Longley: With these problems in mind, we introduced something called a decentralized identifier (DIDs). It's an identifier that isn't connected to domains. ✪
Dave Longley: We want to bury this as much as possible into the infrastructure. ✪
Manu Sporny: Keep in mind that this isn't just a problem with URLs, it's also a problem with email addresses. The core of the problem is DNS and domains (and who gets to own the domain). ✪
Dave Longley: One way to frame this problem is to say what we'd really like to have for these identifiers - we'd like to be able to create identifiers that are not connected to any particular piece of content - we don't want hashes of content. ✪
Dave Longley: We want a piece of text that refers to a particular individual, and people to claim them in a way that doesn't require them to understand the details. ✪
Dave Longley: There are a number of technologies that we looked at that don't quite match - for example, content-addressable identifiers - if information about your identity changes, your identifier changes - so that's a problem because you don't want your decentralized identifier to change. ✪
Dave Longley: We've looked at blockchain technologies - so, a public ledger is an ok technology to explore, the problem with the way a lot of blockchain technology is implemented, the addresses for people are based on a cryptographic keypair, then your bitcoin address is tied to that keypair. If you lose your key, that's a problem. Even with derived keys it's a problem. ✪
Dave Longley: When we're talking about your identity, you can't reissue credentials to a new key very easily - so, stored value in bitcoin blockchain has issues as well and we've thought deeply about that bit as well. ✪
Dave Longley: There are some issues that don't rule it out as a possible technology - what we want at the end of the day is something called "WebDHT" - we haven't invented it yet, but this is what we want: ✪
Dave Longley: You associate a piece of text with a piece of information, you ask the Web Decentralized Hashtable (WebDHT) - you ask it "find my data based on my email address and password hash" - it goes out, via HTTP, and finds the node that has your information. ✪
Dave Longley: Once you get your identity document back, that identity document contains your IdP and you can be redirected to it. ✪
Dave Longley: We're trying to find a system that works like this, doesn't lock you into a domain, trying to find a technology that matches the needs we outlined above. ✪
Nate Otto: I have a good handful of questions, but I'll defer to others if they've got them. ✪
Manu Sporny: Authorization.io is an implementation of the ideas dlongley just talked about. It has what we feel is a good implementation behind it, based on the ideas we've talked about over the last year. Secure, scalable, achieves all the requirements dlongley pointed out. [scribe assist by Nate Otto] ✪
Dave Longley: To clarify: it's an implementation that has the same functional properties of what I described, but we want to decentralize this in the future, let people spin up their own "webDHT" servers to do this work in the future. [scribe assist by Nate Otto] ✪
Dave Longley: Authorization.io is a system that has the same functional properties of what I've outlined, but we want to decentralize it even further. To be clear, authorization.io will only last 7-10 years, and over time, the WebDHT technology will live on a number of servers. ✪
Nate Otto: More like BitTorrent magnet links, perhaps. ✪
Dave Longley: It would work similar to Bitcoin, napster - you ask the network "I have this DID, give me the document" and you could get it back. ✪
Nate Otto: (Except that those are content-hash based) ✪
Dave Longley: There should be no costs for the general public to register and keep DIDs in this system. [scribe assist by Nate Otto] ✪
Nate Otto: What's a good capitalization of "did"? "dID", "DID"? ✪
Dave Longley: You would have ownership over it, there would be no costs associated with it, most folks don't buy domains... we want people to be able to grab identifiers and get into the system w/ decentralized identifiers w/o worry about vendor lockin, who their identity provider is, etc. ✪
Richard Varn: This is really a re-hash about telecom number portability. ✪
Richard Varn: If that metaphor is wrong, let me know. ✪
Nate Otto: Except unlike the phone industry, I hope that we don't let some random person who just knows your DID to actually get through to you during dinner. ✪
Dave Longley: No, good point and very good metaphor. The main difference has to do w/ cryptographic security over those things. ✪
Dave Longley: Because of the cryptographic mechanisms we want to build into this system, the individuals have control over that system. It's your decentralized identifier, you own it, you move it around as you see fit. ✪