Re: Mitigating DDoS via Proof of Patience

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

> On 06/28/2015 09:04 PM, Melvin Carvalho wrote:
> >
> >>
> >> On 29 June 2015 at 01:56, Dave Longley <dlongley@digitalbazaar.com
> >> <mailto: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?
> >
> > 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.
>
> 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.


>
> You can't just put an assertion out there and have everything be just
> fine in the world of credentials. The original question primarily had to
> do with dealing with adversaries. How do you deal with them in this
> "anyone can assert anything" world with "owl:sameAs"? What other
> complexities do you have to build into the system to preserve trust?
>

> >
> > 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.
>
> Your argument holds for devices and any software that needs to use a new
> protocol -- it may take time to adopt it. However, regarding people,
> most of them either don't use URLs as identifiers now or are unaware of
> the fact that they do. That wouldn't change with `dids`, it would remain
> the same. However, if people need to start understanding and managing
> their identity URLs (eg: "owl:sameAs"), I see that as a much greater
> barrier to adoption.
>
> Whatever choices we make to enable identifier portability, I believe
> people must come first. At a minimum, their experience needs to be no
> significantly worse than it is today. I think a `did` scheme (or some
> even deeper infrastructure-based mechanism in DNS or similar) is the
> most likely to achieve that because it's layers away from the typical
> person's experience. I suspect "owl:sameAs" approaches would be more
> likely to bubble to the surface cause aggravation.
>
> >>
> >> 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.
>
> I'm not quite sure I understand this. This seems to be orthogonal to the
> question at hand; the current credentials work already allows credential
> documents to be portable in that sense. The credential documents
> themselves can live anywhere, the problem is with what they assert. Do
> they assert "https://superprovider.com/#melvin" is the recipient of the
> credential or someone else?
>

Got it.  So we're talking about the portability of the subject of the
credential.  Not the portability of the credential itself, which can be
solved with signatures, which is a good thing.  Agree with all of the above
in that case.


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


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


>
> >
> > What about ni:// type URIs with a .well-known lookup area.
>
> How do you propose that 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.


>
> >
> > The above was something of a brain dump.  I hope no opinion there
> > comes across as a strong view or inflexible.
>
> Nope. :)
>
> 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.  I can see this being a plus, tho, and im
very interested in webDHT in general.


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