Re: DID Use Case: Public Pointers to Private Data

Hello Chris,

These are two good topics.

1. Yes a resolver should be "as close" to the target system (blockchain,
etc.) as possible, i.e. apps and services should use their own built-in
resolver that looks up DID documents directly. So even though resolvers
can be run as a service (see e.g. https://uniresolver.io/), such
intermediaries should be avoided except for dev/testing purposes.

Note however that at least one DID method I am aware of (Sovrin) allows
clients to validate the DID document even if it was retrieved via an
untrusted intermediary. This is done using a cryptographic "state proof"
that is included as metadata of the DID document, so even if a client
doesn't talk to the Sovrin ledger directly, it can still verify that a
DID document came indeed from the ledger. Of course even with this
feature, an intermediary DID resolver is still a weakness that should be
avoided if possible.

2. Your concern about which DID methods should be supported is also very
valid. We have discussed this a number a times. On one hand we want to
avoid a centralized governance mechanism that dictates "official" DID
methods; on the other hand we want interoperability. I think our answer
in these conversations so far has been that there will be a mix of
certain base requirements that DID methods must fulfill (e.g. have a
compliant spec and some test cases), and a loose community consensus
process to figure out which DID methods "everyone wants to support".

Hopefully we won't have 1000s of DID methods; at the same it can make
sense to have 2 or 3 DID methods even on the same target system
(blockchain, etc.). For example there are already several Ethereum-based
DID methods with different characteristics.

This W3C community group has a DID method registry, I think this is a
useful start:
https://w3c-ccg.github.io/did-method-registry/

I believe for special uses cases we will also see highly customized DID
resolvers that may only need to work with 1 or 2 DID methods, or use DID
methods that no one else uses. But I agree with you that for an open
interoperable ecosystem we will need some mechanism. A "social consensus
algorithm"? :)

We want to work on DID resolution in a separate document, I just created
an issue about this topic here:
https://github.com/w3c-ccg/did-resolution/issues/6

Markus

On 06/18/2018 10:26 PM, Chris Boscolo wrote:
> I think Anil has highlighted what may end up being the Achilles' heel for
> DID-based SSI adoption.
>
> For this SSI system to remain decentralized and free from censorship, the
> software that looks up the DID Documents for DIDs contained within Verified
> Credentials must be able to communicate directly with the distributed
> ledger that contains the DID Documents.
>
> This means the software that process Verified Credentials must support ALL
> DID methods it ever expects to encounter, OR it must rely on some
> yet-to-be-defined way to dynamically “load” support for newly encountered
> DID methods.  All other means to address this that I have read about
> re-introduce centralization.  It will be nearly impossible to introduce new
> DID methods into the ecosystem because it will require everyone that
> processes VCs to update the software to support the new DID method.
>
> Open-source efforts like the DIF universal resolver are important for
> interop testing of the DID Document lookup and processing but don't solve
> the "centralization" problem.
>
> Does anyone else in this community think this is a legitimate concern?  If
> so, perhaps we could discuss ways to bridge the gap between now and market
> adoption.
>
>    -chrisb
>
>
> On Wed, Jun 13, 2018 at 7:58 AM, =Drummond Reed <drummond.reed@evernym.com>
> wrote:
>
>> On Wed, Jun 13, 2018 at 6:59 AM, John, Anil <anil.john@hq.dhs.gov> wrote:
>>
>>> Thanks Drummond.
>>>
>>>
>>>
>>> So the magic thingy needed to make this work is a DID resolver and an
>>> existing product/system will need be upgraded in order to have this network
>>> discovery ability.
>>>
>> Yes.
>>
>>
>>>
>>> Who, if anyone, is building an open source, royalty free, and free to use
>>> SDK that contains this functionality that existing technology providers can
>>> then integrate with their tech stack?
>>>
>> The DIF universal resolver is being designed for this. And the Hyperledger
>> Indy SDK should also have this capability.
>>
>>
>>>
>>> If the intent is to provide this capability as a service offering, what
>>> would be the business model around that offering that is both long term
>>> sustainable and prevents platform lock-in?
>>>
>> Ironically I believe DID registration and resolution will rapidly become a
>> commodity similar to DNS registration except: a) decentralized, and b) at
>> dramatically lower cost (pennies or fractions of pennies instead of
>> dollars). So sustainability will be at the public or private blockchain
>> level, which has entirely different economics (and, of course, a much
>> stronger security and privacy model, since crypto is baked in at the very
>> core).
>>
>> Best,
>>
>> =Drummond
>>
>>
>>>
>>> Best Regards,
>>>
>>>
>>>
>>> -          Anil
>>>
>>>
>>>
>>> *From:* =Drummond Reed <drummond.reed@evernym.com>
>>> *Sent:* Wednesday, June 13, 2018 9:24 AM
>>>
>>> *To:* John, Anil <anil.john@hq.dhs.gov>
>>> *Cc:* W3C Credentials CG <public-credentials@w3.org>
>>> *Subject:* Re: DID Use Case: Public Pointers to Private Data
>>>
>>>
>>>
>>> On Wed, Jun 13, 2018 at 6:08 AM, John, Anil <anil.john@hq.dhs.gov> wrote:
>>>
>>>> I have always felt the line is quite clear: there is the DID layer of
>>> interoperability,
>>>
>>>
>>>
>>> Could you explain what interoperability at the DID layer means?
>>>
>>>
>>>
>>> Just that any peer can use a DID resolver to look up the DID document for
>>> any other peer. I often use the analogy (which is just an *analogy)* that
>>> it's the decentralized cryptographic equivalent of DNS.
>>>
>>>
>>>
>>>
>>>
>>>> and then the "decentralized P2P protocol" level of interop,
>>>> i.e., the protocol that any two DID-identified peers can use to talk.
>>>
>>>
>>> I assume that one is not tied to the other? i.e. After bootstrapping from
>>> what a DID provides, I can use existing protocols and data definition
>>> standards for two systems to talk w/ each other?
>>>
>>>
>>>
>>> Absolutely. That's the purpose of the service endpoint block in the DID
>>> document. Any peer can advertise the endpoint(s) and protocol(s) it
>>> supports in its DID document.
>>>
>>>
>>>
>>>
>>>
>>> In an Enterprise setting with existing technology and process investments
>>> that need to be leveraged, adding in a light-weight (DID) layer that serves
>>> as an introduction/matching/brokering capability between disparate
>>> systems would be of value if that is a core capability baked into the DID
>>> specification rather than outside of it.
>>>
>>>
>>>
>>> I think that's just what we have baked in. If you find anything missing,
>>> let us know and we'll fix it.
>>>
>>>
>>>
>>> Best,
>>>
>>>
>>>
>>> =Drummond
>>>
>>>
>>>
>>>
>>>
>>> Best Regards,
>>>
>>>
>>>
>>> -          Anil
>>>
>>>
>>>
>>> *From:* =Drummond Reed <drummond.reed@evernym.com>
>>> *Sent:* Wednesday, June 13, 2018 7:56 AM
>>>
>>>
>>> *To:* John, Anil <anil.john@hq.dhs.gov>
>>> *Cc:* W3C Credentials CG <public-credentials@w3.org>
>>> *Subject:* Re: DID Use Case: Public Pointers to Private Data
>>>
>>>
>>>
>>> On Wed, Jun 13, 2018 at 4:21 AM, John, Anil <anil.john@hq.dhs.gov> wrote:
>>>
>>> I had help to sanity check my intent : -)
>>>
>>>
>>>
>>> Your mention of the ‘sovrin protocol’ also brings to light one of my
>>> concerns in this area which is that there needs to be careful thought given
>>> to what is part and parcel of the base DID spec and what is spun out to be
>>> the responsibilities of DID enabled implementations like Sovrin or Veres
>>> One or others.
>>>
>>>
>>>
>>> I have always felt the line is quite clear: there is the DID layer of
>>> interoperability, and then the "decentralized P2P protocol" level of
>>> interop, i.e., the protocol that any two DID-identified peers can use to
>>> talk.
>>>
>>>
>>>
>>>
>>>
>>> I am concerned that this type of design choice conversation is not
>>> happening in public, and that the standard response seems to be (1) We are
>>> thinking about ANOTHER spec for THAT or (2) It is supported in the
>>> [implementation] protocol.
>>>
>>>
>>>
>>> The Sovrin protocol is being developed very publicly by the Sovrin
>>> Foundation <http://forum.sovrin.org/>, in part because W3C explicitly
>>> put protocol out-of-scope when it chartered the Verifiable Claims Working
>>> Group. There are of course other open standard P2P data exchange protocols
>>> that could be used, including UMA and OASIS XDI, but neither of those has
>>> been focused directly on the nuances of verifiable claims exchange, and in
>>> particular using zero-knowledge proofs for selective disclosure. That's the
>>> focus of the Sovrin protocol, the standard implementation of which is
>>> available as open source code in Hyperledger Indy
>>> <https://chat.hyperledger.org/channel/indy-agent>.
>>>
>>>
>>>
>>> Best,
>>>
>>>
>>>
>>> =Drummond
>>>
>>>
>>>
>>>
>>>
>>> Best Regards,
>>>
>>>
>>>
>>> -          Anil
>>>
>>>
>>>
>>> *From:* =Drummond Reed <drummond.reed@evernym.com>
>>> *Sent:* Wednesday, June 13, 2018 12:09 AM
>>> *To:* John, Anil <anil.john@hq.dhs.gov>
>>> *Cc:* W3C Credentials CG <public-credentials@w3.org>
>>> *Subject:* Re: DID Use Case: Public Pointers to Private Data
>>>
>>>
>>>
>>> Anil, this is beautifully stated. I'll note that within the Sovrin
>>> ecosystem, standardizing how access to a resource can obtained via a Sovrin
>>> agent endpoint listed in a DID document is one of the primary purposes of
>>> the Sovrin protocol <https://github.com/sovrin-foundation/protocol>. The
>>> authorization method is of course based on verifiable credentials. Much
>>> work is still to be done, but you have stated the need, the challenge, and
>>> the distinction of the work very well.
>>>
>>>
>>>
>>> =D
>>>
>>>
>>>
>>> On Tue, Jun 12, 2018 at 11:59 AM, John, Anil <anil.john@hq.dhs.gov>
>>> wrote:
>>>
>>> Name
>>>
>>> -------------------
>>>
>>> Public Pointers to Private Data
>>>
>>>
>>>
>>>
>>>
>>> Background
>>>
>>> -------------------
>>>
>>> When sharing information between multiple organizations, each participant
>>> typically segregates data that is publicly visible from data that is
>>> considered private. It is useful for organizations to provide the public
>>> information in a way that is cryptographically verifiable and includes the
>>> ability to point to data stores containing associated private information.
>>> This private information should only be accessible to authorized entities
>>> on an automated, case by case basis.
>>>
>>>
>>>
>>>
>>>
>>> Need
>>>
>>> --------------------
>>>
>>> A national customs and border authority facilitating and enforcing the
>>> movement of goods across its border is automating and streamlining the
>>> sharing of relevant documentation from trade organizations. The customs
>>> authority asks each trade organization to self-issue an identifier that
>>> enables them to create digital signatures for the purposes of signing
>>> documentation and authenticating themselves. When a trade organization
>>> ships goods across the border, it uses the identifier to digitally sign and
>>> share data that is visible to the customs authority and other trade
>>> members. When and what data was provided by the trade organization is
>>> auditable, including pointers to private, trade-sensitive, access
>>> controlled data. When the customs authority is performing an inspection,
>>> (a) it reads and verifies the public data and private pointers, (b)
>>> retrieves a cryptographic access token that only they can use to access the
>>> private data, and (c) accesses the private data using the cryptographic
>>> access token.
>>>
>>>
>>>
>>>
>>>
>>> Challenge
>>>
>>> -------------------
>>>
>>> While the public records are accessible to the customs authority and the
>>> trade organizations, the private records are only accessible to the customs
>>> authority or someone that they delegate the access token to. There are
>>> three protocols at play here: (1) accessing the public records, (2) using
>>> the access token for private access, and (3) the mechanism used to
>>> authenticate during the private access and the subsequent authorization to
>>> see the relevant private data.
>>>
>>>
>>>
>>>
>>>
>>> Distinction
>>>
>>> -------------------
>>>
>>> This use case identifies the notion that DIDs and DID Documents will
>>> enable architectural models and protocols that have a public and private
>>> component to them. The identification of each actor in the ecosystem and
>>> all three protocols in the challenge  are dependent on the authentication
>>> and authorization mechanisms supported/referenced by DIDs and DID Documents.
>>>
>>>
>>>
>>> This use case also suggests that naturally delegatable authentication and
>>> authorization mechanisms should be considered in order to reduce
>>> operational overhead and avoid privilege escalation problems when accessing
>>> these private systems.
>>>
>>>
>>>
>>>
>>>
>>> Best Regards,
>>>
>>>
>>>
>>> -          Anil
>>>
>>>
>>>
>>> Anil John
>>>
>>> Cyber Security R&D Program Manager
>>>
>>> Science and Technology Directorate
>>>
>>> US Department of Homeland Security
>>>
>>> Washington, DC, USA
>>>
>>> anil.john@hq.dhs.gov
>>>
>>>
>>>
>>> Email Response Time – 24 Hours
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>

Received on Tuesday, 19 June 2018 07:50:41 UTC