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