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

OK, how about this for a solution.

Alice has a credential at

https://superprovider.example/.well-known/ni/sha-256/8a55b33dc1694a509660-6d7894576329

The hash is a hash of a bunch of stuff, say Name or Name+email or Passport
ID ... this is contained in the document via meta data, and so can be
verified.

superprovider goes out of business so alice switches to acmeprovider

The urls is now:

https://acmeprovider.example/.well-known/ni/sha-256/8a55b33dc1694a509660-6d7894576329

Where possible the providers link to each other.  But where they cant at
least the hash can be verified still.

The subject of the document could be a ni:/// URI or perhaps <#this> for
those that prefer HTTP URIs

So we tend not to care too much where the domain is, but rather, what the
content is.


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