RE: DID Use Case: Public Pointers to Private Data

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

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<mailto: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<mailto:anil.john@hq.dhs.gov>

Email Response Time – 24 Hours