Re: Mitigating DDoS via Proof of Patience

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