Re: Mitigating DDoS via Proof of Patience

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

> On 06/28/2015 11:41 AM, Melvin Carvalho wrote:
> >
> > Why not have a credentials footprint that spans many sites connected
> > together with owl : sameAs, and you can have a preferredURI.
>
> Suppose we went with "owl:sameAs". What mechanism would you suggest that
> we would use to establish "owl:sameAs" relationships as authentic?
>
> For example, suppose I issue you a credential to your identifier:
>
> https://superprovider.com/#melvin
>
> Then, superprovider.com goes out of business (or is about to). You get a
> new identifier here:
>
> https://ultraprovider.com/#melvin.
>
> How do you go about ensuring you don't lose the credential without
> having it reissued to your new identifier? Where is the "owl:sameAs"
> assertion made and how do you give consumers of your credential
> assurance that you're the actual owner, ie: How do they distinguish you
> from someone else who makes an "owl:sameAs" assertion for your old
> identifier?
>

Thanks for getting back.  Great example!

So the principle here is that names (ie URLs) on the web are sticky.  The
reason for this, is that you can have a huge number of inbound links
without even knowing it.

Changing domains is hard.  If amazon wanted to change its name, tons of
stuff would break.  But that's not a reason for them not to buy amazon.com
in the first place as their web presence.

So, we need to accept that the baseline for choosing names is that any
change is going to be problematic.  There's no real way to avoid this, if
you want to use http, just damage limitation.

Consider changing your name in real life, how does that affect your
university degree?  Well, either you get a new copy of the certificate, or
you create some kind of trail to show that the new name is the same as the
old one.

So if you have a two way owl : sameAs and one of them goes down.  Any
software that had that information, could look in the other place for the
information and slowly self heal.

So any software looking at a bunch of triples could conceivably deduce that
the credential belonged to the new entity.

>
>
> >
> > To be clear, I dont want to say did: is a bad idea, certainly there are
> > advantages, just to understand the pros and cons and motivations a bit
> > better.
>
> We should certainly document the pros and cons. The above exercise will
> also help in the endeavor to provide understanding.
>

Yes


>
> One of the pros of the `did` approach is that a credential is portable
> even when the only thing in it that ties it to you is your identifier. I
> suspect it will be difficult to accomplish that (whilst providing the
> same assurances) with another scheme.
>

Yes


>
> In order to support portable credentials, some complexity is going to
> have to be added somewhere. With the `did` scheme, we push most of that
> complexity into the software responsible for storing and looking up
> `dids`. "Infrastructure software", if you will. This keeps the problem
> isolated away from most people, away from the common users of the system.
>

Portable identifiers have been proposed many times.  The main con is that
you have to persuade lots of people and devices to use them.  This can
typically take a decade.  The main disadvantage of HTTP is that URLs are
sticky.


>
> An alternative to this approach is to push the problem to the surface.
> Make people take care of linking up their various identifiers and, I
> suspect, managing a more complex set of keys. You can probably try to
> hide this behind software as well, but, firstly, it's going to touch
> many more parts of the system, and second, people are going to be more
> aware of it (and less satisfied with the system as a result).
>

Yes

Another way to do it is to have the signature make the document portable,
so that it can live on *any* HTTP doc.  What can then happen is discovery
via inverse functional properties to get the data structure.  e.g. search
for email address user@host (that becomes the hard part) and then see who
has signed credentials associated with it.

In short, both systems are going to pose hard problems.  HTTP URIs being
sticky, but with some ways to limit damage (I think this is the path to
explore), but with huge adoption.  Then did: URIs as portable but much
harder to find via follow your nose, search, or well known lookups, and the
battle to get the libraries well supported.

No reason why both cant happen together.  But with did: I think it will
have to be a "wait and see" to see if it starts to gain wide enough
adoption to be a realistic alternative to HTTP.

What about ni:// type URIs with a .well-known lookup area.

The above was something of a brain dump.  I hope no opinion there comes
across as a strong view or inflexible.  Really open to hearing solutions
based on pros and cons.


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