W3C home > Mailing lists > Public > public-credentials@w3.org > June 2015

Re: Mitigating DDoS via Proof of Patience

From: Manu Sporny <msporny@digitalbazaar.com>
Date: Sun, 28 Jun 2015 23:26:36 -0400
Message-ID: <5590BAEC.7010508@digitalbazaar.com>
To: Credentials Community Group <public-credentials@w3.org>
On 06/28/2015 09:04 PM, Melvin Carvalho wrote:
> 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.

We've thought through this approach for the last 5+ years and the single
biggest obstacle is the enormous amount of code and machine reasoning
you have to write to do the "self-healing" part of it. We have tried
multiple times and failed, mostly because the security around an
owl:sameAs solution is very brittle. Implementers have to know an
enormous amount about the potential attack vectors, and frankly, most
developers just don't have the sort of security training that's required
to make this work. People would have to specify multiple providers for
their credentials as well, which would be confusing to most folks:
"Wait, my credentials are over at Google. Why do I have to keep them
over at Yahoo too? Which one is in charge of them?".

I've not seen a plausible proposal that doesn't pull owl:sameAs and the
whole Semantic Web reasoning stack into the picture, and at that point,
you've lost 99% of developers and 99.999% of most people and your
complexity has shot up into something that would take far more than a
weekend to put together (think months for a brittle implementation).

That said, happy to be proven wrong, but I don't think the whole
Semantic Web reasoning stack is the way to go at this problem. There are
simpler solutions.

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

The WebDHT protocol will be designed to run on top of HTTP, so there are
plenty of clients that have the basics necessary to implement the
protocol. How you hit WebDHT nodes across the Web still needs to be
designed and finalized, but the interaction will be an overlay network
on top of HTTP that looks like Telehash, Kademlia, and IPNS.

It is expected that there will be nodes that bypass the WebDHT protocol
entirely to provide convenience functions for organizations that don't
want to use the WebDHT protocol. For example, here's how you can lookup
a DID document today:

For this DID: did:8a55b33d-c169-4a50-9660-6d7894576329

go to this URL:

https://authorization.io/dids/did:8a55b33d-c169-4a50-9660-6d7894576329

We expect that many WebDHT nodes will provide those sorts of convenience
services just like almost every university provides DNS services as well
as Linux software package mirroring services for a variety of flavors of
Linux (RedHat, Ubuntu, Debian, etc).

So, it's easy to follow-your-nose using a DID - just use HTTP, and tack
the DID to the end of your favorite resolver service... just like we do
for DNS today (only far simpler).

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

ni:// is a solution for a different problem.

DIDs are not cryptographic hashes, they're identifiers. A DID doesn't
change when the content it's referring to changes (much like a URL).

While it is true that a cryptographic hash can be used to identify a
piece of content, with DIDs, we specifically don't want the identifier
to change when the contents of what the DID refers to changes.

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
Founder/CEO - Digital Bazaar, Inc.
blog: Web Payments: The Architect, the Sage, and the Moral Voice
https://manu.sporny.org/2015/payments-collaboration/
Received on Monday, 29 June 2015 03:27:05 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 11 July 2018 21:19:24 UTC