- From: Steven Rowat <steven_rowat@sunshine.net>
- Date: Tue, 20 Feb 2018 10:43:09 -0800
- To: Adrian Gropper <agropper@healthurl.com>
- Cc: =Drummond Reed <drummond.reed@evernym.com>, Credentials Community Group <public-credentials@w3.org>
On 2018-02-20 10:20 AM, Adrian Gropper wrote: > > 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. Thank you, that settles it for me, for now, because it seems: a) A SANC / DID system as I envisaged it can exist; and b) Before knowing how to proceed I need to know more about the relations between UMAs, blockchains, and privacy. I'll begin nosing around in that (including trying to find out if somebody else is doing it, which may be the easiest way to achieve my goal. :-) ) Thank you again for the comments. Steven > > > 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> > <mailto: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# > <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> > <mailto: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/ > <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:43:35 UTC