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

Re: Mitigating DDoS via Proof of Patience

From: Dave Longley <dlongley@digitalbazaar.com>
Date: Sun, 28 Jun 2015 19:56:02 -0400
Message-ID: <55908992.7020608@digitalbazaar.com>
To: Melvin Carvalho <melvincarvalho@gmail.com>
CC: Credentials Community Group <public-credentials@w3.org>
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:


Then, superprovider.com goes out of business (or is about to). You get a
new identifier here:


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

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

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.

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.

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

Dave Longley
Digital Bazaar, Inc.
Received on Sunday, 28 June 2015 23:56:27 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:17:46 UTC