- From: Adrian Gropper <agropper@healthurl.com>
- Date: Tue, 20 Feb 2018 13:20:39 -0500
- To: Steven Rowat <steven_rowat@sunshine.net>
- Cc: "=Drummond Reed" <drummond.reed@evernym.com>, Credentials Community Group <public-credentials@w3.org>
- Message-ID: <CANYRo8iC6awvA9Ps+WJq9WGMbBJOfPpPxyBekHRrjHHOjhPeLw@mail.gmail.com>
inline... On Tue, Feb 20, 2018 at 12:44 PM, Steven Rowat <steven_rowat@sunshine.net> wrote: > On 2018-02-20 12:33 AM, Adrian Gropper wrote: > >> Steven, >> >> The common denominator is one “owner” for the SANCs. Each SANC can be >> described as a single resource or resource endpoint such as a URI or IPFS >> address. Each SANC does not really need its own DID although, as Drummond >> notes, it could. The author / owner operates an UMA standard authorization >> server. Would-be users of any particular SANC would be pointed to the >> authorization server for a license and present their requesting party DID >> and associated credentials to the authorization server, maybe payment. >> > > Thank you, that clarifies several more things for me; including the UMA > standard, which I wasn't aware of. > > But, given blockchains, I am prompted to ask: > Is such a (UMA-type) centralized access server to the SANCs absolutely > necessary? > UMA authorization servers don't have to be centralized or federated. They can be as self-sovereign as a blockchain wallet is, the difference being that the blockchain wallet is not addressable, whereas the UMA AS is addressable via a service endpoint in the DID Document. > > In other words, does it seem possible that the SANC / DID system could be > built on a blockchain ledger system, so that allowing access to the SANCs > would be essentially built-in and decentralized? (Even if some of the > credentials asked for by the SANC / DID system might need to have been > issued to would-be users from centralized servers originally?) > It depends. If everything about the SANCs and access to them is public, then UMA may not be needed. Public blockchain ledgers and their smart contracts are ill-suited to private information, be it business or personal. Adrian > > Steven > > >> That leaves open the issue of how a SANC and the author’s DID are >> discovered. Having a DID and DID Document for each SANC doesn’t really >> address this issue. It has to be dealt with by the author at the time of >> SANC publication either way. >> >> The benefit of using an authorization server is privacy for the resource >> owner. They don’t have to publish their policies, just execute them and >> issue an access token or not. This works nicely when the SANC is a portion >> of a health record and our HIE of One project is a reference implementation >> of the standards for both DID and UMA AS as applied to healthcare. >> >> Adrian >> >> On Tue, Feb 20, 2018 at 2:46 AM =Drummond Reed <drummond.reed@evernym.com >> <mailto:drummond.reed@evernym.com>> wrote: >> >> Steven, I caught this just before bed, so a few quick thoughts: >> >> 1. Using DIDs to identified works produced by an author (what you >> call SANCs) is indeed a classic example of what DIDs are >> designed for. >> 2. It can work exactly as you describe, with every SANC getting >> its own DID and DID document. >> 3. However given the closely related nature of some of the SANCs >> you describe, many of them that are logically related >> *could* also be described with DID service URL (see the DID >> Spec Completion Proposals >> <https://docs.google.com/document/d/1aR8V_JUJdq1Sbi47wCV5aa- >> dEY0e-V2RqwPNP5ci1bg/edit#> >> for details). This is basically a path rooted on a DID. The >> only real difference is that all the SANCs you described don't >> necessarily need their own DIDs and DID documents. But they do >> need to be rooted on a DID that the author controls. >> >> It's just an optimization, but it could help with efficiency. >> >> =Drummond >> >> On Mon, Feb 19, 2018 at 8:18 PM, Steven Rowat >> <steven_rowat@sunshine.net <mailto:steven_rowat@sunshine.net>> wrote: >> >> >> Greetings, >> >> (Please excuse the long post; I’ve shortened it several times >> but it’s >> a relatively complex proposal, so I don’t think I can present >> it well >> any shorter.) >> >> I’m mulling an idea that a DID method might allow a nested >> publishing >> system that links all designated stand-alone works by a single >> author. >> I’ve been calling such works SANCs (“stand-alone nested chunks”). >> “Nested” because they include smaller chunks inside a larger work, >> like stand-alone chapters from a book, special-use paragraphs >> inside a >> chapter, sample excerpts from a piece of music, or >> self-explanatory >> Figures from a scientist’s data set. >> >> I post here a first description of the idea, to ask if such a SANC >> publishing system seems technically feasible with DIDs. My >> hunch is >> that it’s an inevitable development when DIDs and linked data >> exist, >> and possibly people are already working on it elsewhere, though I >> don’t know of any at present. >> >> I give a slightly longer summary and two examples below, and some >> rationale at the end for why this might be a valuable use of >> the DID >> system. >> >> Any feedback appreciated. >> >> Summary: >> In the proposed Stand-Alone Nested Chunk (SANC) system, a >> “stand-alone” work is any discrete work by an author that the >> author >> believes will have its own audience or use. Taking text as an >> example, >> a SANC could be as small as a single sentence, paragraph, or >> graphic >> deemed noteworthy; or as large as a series of books. Every >> SANC gets a >> DID Document. Every DID Document contains meta-data (and/or >> links) to >> facilitate end-user access to the parent section of a SANC; >> laterally >> to other SANCs at the same level; and to other larger works or >> groups >> of works, all of which are also SANCs. Depending on the >> implementation, portions of this linked access might use a >> permissions >> language like ODRL, including for payments, sample excerpts, >> and usage >> rights. >> >> Example 1, Scientist: >> >> Scientist M issues a report, “String Theory Today”, with Abstract, >> Purpose, Method, Graphs, Data (containing Figures), Discussion and >> Conclusions. Scientist M has published many different reports over >> his/her career. Five earlier reports were directly related to >> String >> Theory. From the current report, Scientist M believes that the >> Abstract, Data, Conclusions, and two of the Figures from Data, >> and the >> last paragraph of the Conclusions, would each be useful in various >> collaborations, including as stand-alone statements in news and >> science-preview sites. >> >> Scientist M therefore, to get up to speed in the SANC / DID >> system, >> issues (or authorizes the issuing of) DID Documents for each >> SANC that >> is designated as a meaningful unit: >> —Scientist M him/herself; (1 DID Doc) >> —M’s full list of past reports; (a DID Doc for each report) >> —M’s group of String Theory reports; (1 DID Doc for the group) >> —M’s New report, “String Theory Today”; (1 DID Doc) >> —Abstract, Data, and Conclusions of the new report (3 DID Docs); >> —2 Figures from the Data; (2 DID Docs) >> —A paragraph from the Conclusions (1 DID Doc). >> Every DID Document contains a way to access all other works >> (SANCs) by >> the same author, including getting meta-data about the author and >> his/her works. >> >> Example 2, Musician/lyricist/poet: >> >> For each of the following: >> —“A thing of beauty is a joy forever”. >> —“No eternal reward will forgive us now for wasting the dawn”. >> —“This is the way the world ends / not with a bang but a whimper”. >> Who wrote it? What larger work is it part of? What else did they >> write? Can we read their other work now? Do we have to ask >> permission >> or pay someone in order to get access to their work? >> >> The proposed SANC / DID system could answer all these >> questions on the >> basis of the user encountering a single work by the author, of >> any size. >> >> Discussion: >> The questions posed in Example 2 could equally apply to >> Example 1; and >> to any other examples that can be envisioned for other types >> of works. >> And an argument might be made that all these questions can be >> answered >> by searching the Internet, but I see at least two strong >> reasons why a >> SANC / DID system would be an improvement: >> >> 1. Author control: >> Currently, Google, Wikipedia, and various advertisers and >> plagiarizing >> sites constitute an industry feeding on the data that is created >> and/or enabled by authors. In the SANC / DID system, an author >> has the >> right to arrange and benefit from both the meta-data linking >> the SANCs >> and from the SANCs themselves. >> >> 2. More Effective Distribution: >> Young authors, or authors of any age who are just starting >> out, will >> often not be easy for an end-user to track down, even if their >> works >> have real value to the society. If an end-user can answer all the >> above questions easily, via a single work (SANC) they >> encounter by the >> author, it will increase the dissemination speed of that author’s >> works through the society, with much less middleman overhead. >> >> Final note: I think there are a large number of people who >> might make >> use of a SANC / DID Document system to publish their work: >> novelists, >> journalists, filmmakers, bloggers, and so forth. And it isn’t >> limited >> to single persons: groups—any legal entity—could make use of it; >> including governments who have complex layered material they must >> supply; corporations with internal documents or user-manuals to >> manage; and educational institutions with intricately >> inter-related >> course materials. >> >> >> All feedback appreciated, especially detailed warnings. ☺ >> >> Steven Rowat >> >> >> -- >> >> 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/ >> > -- 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 Tuesday, 20 February 2018 18:21:07 UTC