- From: <msporny@digitalbazaar.com>
- Date: Wed, 07 May 2014 13:14:39 -0400
- To: Web Payments CG <public-webpayments@w3.org>
Thanks to Dave Longley for scribing this week! The minutes for this week's Web Payments telecon are now available: https://web-payments.org/minutes/2014-05-07/ Full text of the discussion follows for W3C archival purposes. Audio from the meeting is available as well (link provided below). ---------------------------------------------------------------- Web Payments Community Group Telecon Minutes for 2014-05-07 Agenda: http://lists.w3.org/Archives/Public/public-webpayments/2014May/0016.html Topics: 1. Decentralized Identifiers 2. Decentralized Database or Purely Protocol? 3. The Decentralized Identity URL 4. Registering a New Decentralized ID 5. Data Portability 6. Decentralized ID Decisions Chair: Manu Sporny Scribe: Dave Longley Present: Dave Longley, Manu Sporny, David I. Lehn Audio: https://web-payments.org/minutes/2014-05-07/audio.ogg Dave Longley is scribing. Manu Sporny: Tim holborn, Pindar, and Brent will be unavailable today, so we can't do any resolutions w/o a quorum, but what we can do is talk about decentralized identity Manu Sporny: And try to get the use cases into a form that makes it easier to get through them next week Topic: Decentralized Identifiers Manu Sporny: So let's talk about decentralized identifiers Manu Sporny: http://manu.sporny.org/2014/credential-based-login/ Manu Sporny: So, using credential-based login, we can go from bob@example.com - resolve via telehash and get to - https://foobar.com/identities/bob Manu Sporny: Going off of what we have for credential-based login, we had this concept that when you put in an email address, you would resolve that via telehash to some kind of identifier, like https://foobar.com/identities/bob Manu Sporny: So you could resolve an email address to a URL using telehash [w/some privacy protection implementation details in there] Manu Sporny: Ideally, what we would like is to go from bob@example.com - resolve via telehash - and get id:xyz:bob.bobman Manu Sporny: Decentralized identifier is id:xyz:bob.bobman Manu Sporny: You could instead resolve the email address to some kind of decentralized identifier Topic: Decentralized Database or Purely Protocol? Manu Sporny: There are two ways we could implement the decentralized identity part -- we could use a decentralized database, like a bitcoin/ripplename like mechanism that stores this information in a truly decentralized database, the info is replicated between nodes, etc. -- the question is how exactly that's done; the other way this could be done is a decentralized network where the peers answer the request, so "id:xyz:bob.bobman" could be stored by an identity provider and when a request is sent to the network than the IdP would respond back with the information requested Manu Sporny: One is a decentralized database, the other is a query+response protocol Manu Sporny: The latter is easier to implement because you don't have to specify the storage mechanism, just the query+response mechanism Dave Longley: I agree that it would be easier to specify the protocol and leave the storage mechanism up to the implementers. [scribe assist by Manu Sporny] Dave Longley: Everyone just follows the protocol, it should work out. It doesn't preclude using a decentralized database. We specify the protocol, we don't have to specify the protocol itself. [scribe assist by Manu Sporny] Dave Longley: We still have all these privacy concerns, any requests that are made must be aligned w/ privacy concerns. [scribe assist by Manu Sporny] Dave Longley: If you go w/ a decentralized database, you don't know who is responding w/ the information, you just get the information back. [scribe assist by Manu Sporny] Dave Longley: Just to be clear, the information you get back from the service is encrypted? [scribe assist by Manu Sporny] Manu Sporny: Yes, we can't store passport credentials if we don't do that. [scribe assist by Manu Sporny] Dave Longley: So, you send the query out - get back a decrypted blob from somewhere. In the other case, can we get information out of who is responding? [scribe assist by Manu Sporny] Topic: The Decentralized Identity URL Manu Sporny: So i want to dial the complexity back a bit, the key thing we want to be able to do ... when a third party asserts a credential on an identity, we want them to be able to assert that credential on a decentralized ID, meaning that it shouldn't be https://somedomain.com/i/bob, instead it should be attached to a decentralized ID Manu Sporny: So, we want to assign credentials to id:xyz:bob.bobman, not https://foobar.com/identities/bob [scribe assist by Manu Sporny] Dave Longley: We may need some kind of blockchain type mechanism to claim a name - should identities end up being a public key hash? Why are we trying to come up with these URL schemes for them. [scribe assist by Manu Sporny] Dave Longley: It could just be urn:PUBLIC_KEY_HASH - whenever you sign some piece of information, if you want to write credentials to a particular key, you would somehow set yourself up w/ an id provider that can listen to the network. [scribe assist by Manu Sporny] Dave Longley: Then your identity provider must grab the message and sign it, that's how it gets into your list of credentials. [scribe assist by Manu Sporny] Dave Longley: Essentially, anyone can write credentials to the network about any public key ID. Then the id provider can just pick that up. [scribe assist by Manu Sporny] Dave Longley: Anyoen can write to decentralized network, anyone can join when they want, they just set their key. You either create a new identity or write to your existing identity w/ the new key. [scribe assist by Manu Sporny] Topic: Registering a New Decentralized ID Manu Sporny: So the steps are ... step 1 is you go to any identity provider and login and create an account with them (username + password), the first thing they are going to ask you to do, they will do one of two things Manu Sporny: Let's talk about the secure way to do this Manu Sporny: IdP will say, you need to create a special account and we can't see the password for that account Manu Sporny: IdP will redirect you to that piece of software that lets you create a private+public key pair that's attached to the telehash network Manu Sporny: They will send a special network saying "a new account is being created" Manu Sporny: On that other website, we are going to ask them for a passphrase, and that is going to be their decentralized ID and we're going to send that ID back to the identity provider Manu Sporny: The IdP at that point, has a decentralized ID for that person Manu Sporny: And at that point... then your identity provider we need to register ourselves as your identity provider Manu Sporny: So they'll do a write to the network Manu Sporny: IdP will say "we need you to authorize us as your identity provider" Manu Sporny: It will send you back to that centralized website, password-based key generation website Manu Sporny: That website will digitally sign the decentralized ID with the identity provider, saying this decentralized ID's provider is this URL (this is the mapping to the Web) and that is digitally signed and is posted to the network Manu Sporny: Ok, decentralized ID and IdP are now linked together Dave Longley: You could delegate trust to your identity provider - allow their key to make changes to your identity. [scribe assist by Manu Sporny] Dave Longley: "These are the parties that are allowed to make changes to the credentials." [scribe assist by Manu Sporny] Dave Longley: That's difficult because it's hard to say who can make changes to the credentials. [scribe assist by Manu Sporny] Dave Longley: So, if you lose that key, or it's compromised, the person w/ the key can make changes. So, for multi-sig, you need an initial write to say "these are the rules for writing to the identity". [scribe assist by Manu Sporny] Dave Longley: So, it's getting complicated, but if you were afraid of losing your identity forever, you could do "Multi-sig w/ 2 out of 3 keys". One of them is yours, the other is your identity provider, another is a family member/relative. [scribe assist by Manu Sporny] Dave Longley: So, to generate IDs, it just needs to be a UUID or public key hash - something that's going to be globally unique that doesn't have any actual meaning. [scribe assist by Manu Sporny] Dave Longley: Once you put meaning into the identifiers, people are going to try and claim the same thing. [scribe assist by Manu Sporny] Dave Longley: These decentralized IDs should be entirely opaque. [scribe assist by Manu Sporny] Manu Sporny: There are concerns with recovering the id later if we make them opaque Manu Sporny: Then we could have id:dave.longley:af746cd Dave Longley: The information is going to be a part of the document associated with that identity. You could put identifying information into the ID itself, then tack on some GUID to it. [scribe assist by Manu Sporny] Manu Sporny: I'm concerned about how you re-generate the same GUID, but maybe those concerns are unfounded. Dave Longley: It may be worse to not make this identifier opaque. [scribe assist by Manu Sporny] Dave Longley: We can allow the identifier to be customized in some way. [scribe assist by Manu Sporny] Manu Sporny: The thing that ends up storing this information is going to be the IdP, and it will be stored internally somehow Dave Longley: To be clear - the polyfill login site is going to host your key, they'd sign information and transmit to the IdP. [scribe assist by Manu Sporny] Dave Longley: This still can work w/ a decentralized database, but that's not an integral part of the standard. You could use an IdP that uses a decentralized database. [scribe assist by Manu Sporny] Dave Longley: You chose the IdP that works that way. An IdP doesn't have to work that way. [scribe assist by Manu Sporny] Manu Sporny: So the first problem is solved, how you associate credentials with a decentralized ID Topic: Data Portability Manu Sporny: The other question is how to get the info from one IdP to the other Dave Longley: So, one way to do it - redirect to centralized polyfill to do write operation, you sign the data you want to write, then you can send it somewhere. [scribe assist by Manu Sporny] Dave Longley: You have your entire identity document, request your entire IdP document, instead of sending it to another website, you send it to your other IdP. [scribe assist by Manu Sporny] Dave Longley: There's nothing much that needs to change. When you're not switching IdPs, you request the document from your IdP, then that goes to polyfill site, you write new credential, then you write to your IdP. Then your IdP stores it. [scribe assist by Manu Sporny] Dave Longley: You write what you want to change, instead of sending to old IdP, you send it to new one. [scribe assist by Manu Sporny] Dave Longley: Write to your old IdP w/ your new IdP information, close out your account. [scribe assist by Manu Sporny] David I. Lehn: What happens when you have multiple IdPs? [scribe assist by Manu Sporny] Dave Longley: You can write to one or more of them. Preferred IdP, and others. [scribe assist by Manu Sporny] Dave Longley: Conformant credential writer just picks one IdP, but others can write to other ones. Write to other identity providers is an extension/option. [scribe assist by Manu Sporny] Dave Longley: These don't have to be identity providers - they're just information storage places. They just need a web storage location. You just say "I trust this place". [scribe assist by Manu Sporny] Dave Longley: All of the credential writers just need to understand properties of a document, IdP stuff is written on top of that. IdP is primary place of storage - they can have username/password to allow you to access things. [scribe assist by Manu Sporny] Manu Sporny: You should be able to login to your IdP using your IdP (Credential-based login) [scribe assist by Manu Sporny] Dave Longley: Some piece of software that knows how to store keys for you. [scribe assist by Manu Sporny] Dave Longley: IdPs can be storage locations, they can use usernames/passwords, can provide you w/ insurance for backing up your identity, etc. [scribe assist by Manu Sporny] Dave Longley: We can make it easier for people to use - but main thing is this credential writer that has access to keys. They can send credentials to some storage location. [scribe assist by Manu Sporny] Dave Longley: Ultimately, we want that to be the browser. In the meantime, there can be polyfills to do that. [scribe assist by Manu Sporny] Topic: Decentralized ID Decisions Manu Sporny: Ok, so we made a few decisions on the call today: Manu Sporny: 1. Credentials need to be associated with a decentralized identifier if they are going to be portable. Manu Sporny: 2. A polyfill management site (which will be replaced by browser code in the future) is responsible for creating the decentralized identifier. Manu Sporny: 3. The polyfill management site will associate a public key with the decentralized identifier. Manu Sporny: 4. When you register with an identity provider, that identity provider will provide a storage URL that will be sent to the polyfill site to specify the storage location for the identity credentials. Dave Longley: The polyfill management site is also responsible for writing to your identity and sending the result to the storage URL. [scribe assist by Manu Sporny]
Received on Wednesday, 7 May 2014 17:15:02 UTC