Re: [EXTERNAL] Re: The DID service endpoint privacy challenge

>
> >>> When we say mediator, do we mean any party that is given an encrypted
> payload without the ability to decrypt the secret portion of the payload?
> Is this term meant to include a remote personal datastore instance host?
>

I was trying to use the word not as a carefully defined label for a crisp
concept (a term), but in its general dictionary sense -- something that
sits between. I'm not sure whether, under that usage, a remote personal
datastore instance qualifies. If it is just serving data without passing
messages along to the recipient, then no (there's nothing on the other side
of it that's being mediated). But if it is actually forwarding messages,
then yes.

There are multiple ways that "mediator" is formally defined as a term. One
of them is in the DIDComm spec being worked on at DIF. There, the usage of
the term coincides with this loose definition, but adds some extra nuances.
I didn't want to get into those here.

>
>
> >>> This all sounds like it could be true, save the encrypted data they
> would retain if they were acting as the host of the user’s remote personal
> datastore instance
>

Retention is an orthogonal concern. A mediator might retain copies of
messages, or it might not -- in the same way a mail server might retain
messages it has relayed to a remote client, or it might delete them. I
assume clients would set up policies about that. A mediator that retains
such data is obviously able to address some use cases that require
statefulness (useful, but introduces cybersecurity trove issues [mitigated
by the encryption]).

>
>    - If Alice chooses to change her mediator, links will fail for some
>    Requesting Parties (Bob) and they will need to discover Alice's new
>    mediator one way or another
>
> >>> Why would links fail if Alice can rotate in new endpoints to her DID
> Doc? She should be able to add/change service endpoints and have resolving
> parties auto-detect this.
>

I agree with Daniel B here, but I'm realizing it surfaces an assumption
that might not be shared: a mediator has to be declared in a DID doc. A
mediator is a combination of an endpoint and a key to use for outer
envelope encryption of any messages dropped at that endpoint. If Alice is
using mediator 1, her DID doc says so. Then, if she changes to mediator 2,
her DID doc starts saying that, instead. If the persisted links that Adrian
is talking about are cached URIs after DID resolution, they will break. But
if they include an unresolved DID, they won't, because they'll be resolved
the new way when they're used. This is analogous to the difference between
caching a pre-DNS-resolved URI ("when I want to talk to party x, I go to
http://123.45.67.89/hello") and caching a non-DNS-resolved URI ("when I
want to talk to party x, I go to http://hostname_that_needs_resolution/hello
")

>
>
> >>> I agree with the best practice of having only one type of service
> endpoint, but from a different angle: if we don’t all agree on one
> universal standard for personal datastores, we won’t be hardly as
> successful at creating a solid, ubiquitous foundation for decentralized
> apps and services.
>

My view diverges on this. I don't believe data is now, should be, or will
be the heart of SSI interactions; the self-sovereign identity subject must
be the heart instead, with data being legs and feet. Thus, personal
datastores (which certainly need to exist and are vital; don't get me
wrong) feel like the wrong foundational abstraction; people themselves are
better. First you deal with them; then you can deal with their data, if
they let you, as long as they continue to let you. You may have a
relationship to their data, but it is always secondary to the relationship
with them. They never fully disintermediate themselves, and they remain The
Fact you can't get around. Every attempt to access data is an opportunity
for them to express their sovereignty. This is a pretty radical departure
from today's information economy, which runs on the assumption that info is
an independent, inert resource to harvest, and it's published and held
somewhere in trust for an identity subject.

It is true that a heavy identity subject in the middle of every interaction
could create inefficiency; thus, automating the authorization and intent of
the data subject with respect to the data is crucial. Done right, I think
it's invisible in UX and nearly invisible in terms of cost -- unless/until
the identity subject wants otherwise. I don't think this is actually the
sort of distinction that makes architectures impossible to reconcile, so
I'm not trying to incite a new debate on this thread. I still agree with
what we jointly published about rhythm and melody between hubs and agents
making beautiful music. I'm just noting that I have a different take on how
to balance the two and which is primary.

But here, that's a subtlety. No matter whether you like my balance or
Daniel B's, the fact remains that data interop is hugely valuable and we
need to solve it.

>