Re: DID Use Case: Public Pointers to Private Data

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