Re: Mitigating DDoS via Proof of Patience

On 29 June 2015 at 16:43, Dave Longley <dlongley@digitalbazaar.com> wrote:

> 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.
>

No, I totally agree, it's a hard problem.  What you need is to cache the
link from a time when the resource was there, or to get an out of band
link, got some other kind of meta credential showing that link.

The reason is the web was designed for stable URIs building a reputation
(e.g. pagerank) over time.


>
> >>
> >> 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.
>

Yep, it is definitely complex.  Maybe the old credential site could help
facilitate the move.  I think whatever the solution it involves caching of
the previous content, right?


>
> >
> >> 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.
>

OK, well let's acknowledge that it's a VERY hard problem to solve, with or
without web architecture.

I think perhaps two conversations are going on.

There's going to be a few ways to do it, all complex.  Independent on
working out a solution to the problem, we need to work out the cost benefit
here, if it's not an edge case, is it something in the critical path or
optional.

>
>
> > 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.
>

Yes, but also the chance of not delivering something increases with
complexity.  I'd be happy if there were options, and it was modular tools
to solve different cases.  Certainly I would not want to take the risk of
adopting did: URIs or even linking to them, unless I was confident they
were going to be around in a while.  Let's face it the chance of verisign
being around in 10 years is higher than the chance of did: URIs, right?

A clean modular way of doing this, means each person can take the solution
they prefer.  Perhaps this was what was in mind already, but it wasnt 100%
clear.  So sorry, if we're discussing two separate points at the same time.


>
> > 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.
>

OK, that sounds excellent, and mitigates a lot of what I've said above.
I'm concerned in general about how prominent this feature would be, wrt
increasing overall complexity vs utility.  That's just a subjective
viewpoint, totally respect your point of view -- just from experience
people starting new URI schemes tend to underestimate the challenge of
integration.


>
> >> 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.
>

OK, I hear you.  My replies have been quite "hand wavy", and in part,
that's because we seem to be at a new frontier.

My experience of this was in creating a web version of the bitcoin block
chain where each block is stored in /.well-known/ni/hash.  What I would
have liked to do is have a sameAs relation to many different servers
storing those hashes, creating a distributed database or block chain.  That
way blocks can be verified from a number of places, and new blocks added
(eg via HTTP PUT).  Longest chain wins ensures integrity.

I didnt get that much further with the implementation, due to the fact I
was the only node, so details are light.  My general feeling is that this
kind of thing will be emergent as implementations get out there.  I
appreciate more details are required to be constructive, so perhaps let me
spend a bit more time diving into the details of webDHT.


>
>
> >
> >> 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.
>

Totally agree.  My preference is to create implementations, as I think you
do too.  I think it's going to be helpful, in this case, to have a clear
idea of the problem statement, and how it fits into the bigger context.
Because there's a ton of applications for this technology and tons of
little bits that can be solved with existing stuff.

Really appreciate you taking the time to explain.

I think it's important to emphasize the importance of stable URIs for
credentials, at which point this problem goes away.  But it still remains a
problem, I'd be quite happy to help flesh out some ideas, maybe come up
with some implementation, because I dont think it's 100% clear the easiest
solution.


>
>
> --
> Dave Longley
> CTO
> Digital Bazaar, Inc.
>