- From: Dave Longley <dlongley@digitalbazaar.com>
- Date: Mon, 29 Jun 2015 10:43:05 -0400
- To: Melvin Carvalho <melvincarvalho@gmail.com>
- CC: Credentials Community Group <public-credentials@w3.org>
On 06/29/2015 09:16 AM, Melvin Carvalho wrote: > >> On 29 June 2015 at 05:01, Dave Longley <dlongley@digitalbazaar.com >> <mailto:dlongley@digitalbazaar.com>> wrote: >> >> Suppose I, your adversary, assert "https://iamaliar.com/#adversary" >> is "owl:sameAs" "https://superprovider.com/#melvin". In this case, >> we do *not* want any software looking at a bunch of triples to >> conceivably deduce that the credential belonged to this new entity. >> How do we avoid this? > > Ideally you'd need a two way link. I may be misunderstanding you, but, by definition of the problem, that's not possible. The original identifier URL is gone. So what's the alternative? This is the hard question I'm asking. It's not an unsolvable problem, but I do suspect the solution is messier than what you're proposing. >> >> How would you have a credential associated with it unless you had >> it reissued? Of course, if you can reissue credentials at any time >> there is no problem. You can't do that with many credentials. The >> problem that needs solving is this: >> >> If a credential has been issued to your identifier and your >> identifier changes, how do you keep using that credential without >> having it reissued? >> >> Simply saying "make an `owl:sameAs` assertion" doesn't fully solve >> the problem. What if an adversary makes such an assertion? What >> are the details for thwarting such an adversary? > > This should be solved with two way links. Also there's one more layer > of protection. The signer might not give a credential to an > adversary. Where would the two way links be? Remember, by the definition of the problem: 1. You can't have one of those links at the original URL; it's gone. 2. The signer can't reissue the credential, so "the signer might not give a credential to an adversary" is irrelevant. Trying to solve this with "owl:sameAs" requires more complexity than you've offered thus far. > >> Sure, they can happen together, and a `did` is just a new type of >> URL (they are locators and contain the scheme for retrieving them, >> eg: `did:abcd-1234-5678-1234`). In the current credentials work, >> an identifier for the recipient of a credential is just a URL. > > OK great. So it seems did: is trying to solve an edge case or > moving HTTP identifiers. Yes, it is solving the case where people may want or need to change identity providers throughout their lives without losing their credentials. I don't consider that an edge case, however. > Typically this isnt a problem I like to solve in v1.0 of a spec > because it really goes against the grain of COOL URIs cant change. I agree with the premise: for typical, small scale problems, it's not worth trying to solve this sort of thing in a v1.0 spec. However, I think Identity and Credentials aren't just neat features that you may want to add to a piece of software, they are integral to people's lives. So, I don't think the premise applies in this case. > It would be good to put into a context of the bigger picture how big > a deal it is. As a side project this is fine, and exciting. But as a > dependency I'd be very wary of the cost and time of gaining > adoption. As stated above, I do think it's a really big deal. But, I've also said it's not a deal breaker, as we've engineered the solution to work with any URL. It's just going to cause a *lot* of headaches if we don't solve this problem upfront. >> How do you propose [ni:// type URIs] would work? > > Something like > > .well-known/did .well-known/ni .well-known/genid .well-known/uuid > > Some of these exist already. Then you can also have owl : sameAs > between a number of sites that serve the IDs. I don't understand the details of this system. Can you provide some examples of how it would work? Can you go through the flow of issuing a credential to an identifier and then explain what happens when the person loses control over that identifier? My understanding is that "ni:// type URIs" typically refer to content-addressable identifiers. What happens when the content of my identity document changes? Do I lose my credentials? I'm not seeing any details here. Again, I can't emphasize enough that these problems are hard -- and if you don't have the details down, everything falls apart. > >> I just think there are a lot of details to consider to make a >> system like this both function and establish trust. > > Totally agree. It would be good to be clearer how essential this > system is to the overall stack. To my mind things can function quite > well (at least as well as webmail) without it. My main concern is that you're saying things can function quite well without this approach, but you haven't yet presented the details for how it would. It's fine to have an intuitive feeling that it would work simply, but if you want to actually explore an alternative approach then you've got to put a lot more effort into understanding the details. That's where it becomes clear whether or not your intuition is off. -- Dave Longley CTO Digital Bazaar, Inc.
Received on Monday, 29 June 2015 14:43:31 UTC