- From: Adrian Gropper <agropper@healthurl.com>
- Date: Tue, 12 Jun 2018 22:31:10 -0400
- To: Christopher Allen <ChristopherA@lifewithalacrity.com>
- Cc: "John, Anil" <anil.john@hq.dhs.gov>, W3C Credentials CG <public-credentials@w3.org>
- Message-ID: <CANYRo8hnJMMFOFeGEu7CK-9ThmoLTXSGkfH6k=CyStGSVDfBWw@mail.gmail.com>
This is very similar, if not the same, as the HIE of One self-sovereign technology stack which combines DID and UMA. The public pointer to private data is a service endpoint in the DID document that can also include public credentials. UMA resolves the public pointer to an Authorization Server (AS) that inspects the credentials of the requesting party prior to issuing an ocap-style authorization token to the requesting party's client that is used to access the private data. I believe no new standards are needed for this to work. The correlation issue comes up if multiple DIDs use the same AS endpoint. Various techniques can be used to make correlation more difficult but It's not clear to me what is preferred. Some of these issues are being discussed in the DIF but I have not seen a good reference of the current state. Can someone on this list that is more familiar with the DIF progress point us to the relevant doc(s)? I don't understand Christopher's "consent proof" point in this context. Adrian On Tue, Jun 12, 2018 at 6:43 PM, Christopher Allen < ChristopherA@lifewithalacrity.com> wrote: > Concept ACK > > I particularly like the idea of public credentials that can be used to > authorize (ocap?) access to private information. I might add that there > could be four levels — public open, public non-correlatable, private > non-correlatable, private correlatable with consent proof. > > — Christopher Allen [via iPhone] > > On Tue, Jun 12, 2018 at 12:01 PM 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 >> >> >> > -- Adrian Gropper MD PROTECT YOUR FUTURE - RESTORE Health Privacy! HELP us fight for the right to control personal health data. DONATE: https://patientprivacyrights.org/donate-3/
Received on Wednesday, 13 June 2018 02:31:36 UTC