Re: Mitigating DDoS via Proof of Patience

On 29 June 2015 at 05:26, Manu Sporny <msporny@digitalbazaar.com> wrote:

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

Regarding adoption new URI schemes typically take years or decades to gain
adoption.  It's not just to dereference them, they act as primary keys
across the whole web, people link to them, tie stuff to them etc.  I dont
count you out, as you have a stellar track record here.  But even for you,
to say that we'll all be using did: URIs in 10 years seems unlikely.  We'll
be using http: mailo: tel: and perhaps a few more -- did: could become one
of them, but it will take years to emerge.  It shouldnt be a dependency to
the spec.  If it gains traction I think it can go into future versions.

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