Re: Prioritizing Individual Sovereignty over Interoperability

Markus et al:

I think this is important thinking, and I endorse the sentiment.

The business guy in me says that we should think of ways to give it more
teeth than a simple statement of philosophy. I know there have been
discussions about defining the scope of DIDs in the spec in such a way that
this priority is honored--but I think such measures will be contentious and
probably not very effective anyway. So I'm asking myself two slightly
different questions:

   1. Is there an objective way to make misalignment transparent, so that
   even if an implementation of a DID method at odds with the ethos exists, it
   is obvious how much and in what way it's a bit of a misfit?
   2. Is there a way to make it hard/expensive/distasteful to implement a
   DID method for an ecosystem that is at odds with the
   autonomy/independence/philosophical mindset that has informed DIDs thus far?

Regarding #1, I have been promoting a notion of "Message Trust Contexts
<https://github.com/hyperledger/indy-hipe/blob/273cfdc55d9ce7cbf8716c5c3629398abc7b381e/text/message-trust-contexts/README.md>"
in DID Communication. These are explicit claims about how much trust can be
imputed to a given message based on the encryption that was used when it
was sent, whether the message is repudiable, whether perfect forward
secrecy is active, whether the sender was anonymous, whether the DID keys
used to secure the message are public and private, and so forth.

I wonder if a similar thing could be done with DID methods. Perhaps a "*DID
Trust Context*" could be associated with each DID method, answering
questions such as: is the DID captive to a proprietary technology; is it
free or cheap; is it published and thus correlatable; does its resolution
require a call to a centralizing system that could be observed; etc.
Although such trust contexts wouldn't in and of themselves prevent someone
from implementing a DID method that's misaligned with the ethos, at least
they would make the misalignment obvious, and handlers of DIDs could make
the choice to warn users about the consequences of interacting with such
DIDs. They could become one objective basis for DID reputation.

Regarding #2, I wonder about introducing the notion that DID methods must
support an independent audit capability that updates the DID Trust Context
of the audited method. This might give captive and surveillance-oriented
ecosystems pause, because the audit could be structured in such a way that
all dirty laundry gets aired.

--Daniel

On Fri, Apr 26, 2019 at 12:46 PM Markus Sabadello <markus@danubetech.com>
wrote:

> Hello list,
>
> In light of the discussions in the W3C CCG, DIF, and recent threads on
> GitHub concerning proposed changes to the W3C DID spec (related to
> "decentralization" and the "big tent" idea), Joachim Lohkamp (Jolocom),
> Kai Wagner (Jolocom), Eugeniu Rusu (Jolocom), Sean Baldwin-Stevenson
> (Jolocom) and myself (Danube Tech) have prepared an open statement and
> call to action for the community.
>
>
> https://stories.jolocom.com/prioritizing-individual-sovereignty-over-interoperability-95ec17a36c9b
>
> We invite you to read, share, and add your perspectives on that blog
> post with the aim of broadening the discussion and developing a more
> comprehensive and rigorous assessment of how to address the challenge of
> achieving interoperability without diminishing user sovereignty.
>
> Even though I won't be at IIW, I know sessions around this topic will be
> held, and I hope this statement will serve as useful input.
>
> Markus
>
>
>
>
>