Re: [Long] Request Opinion on DID Documents and “SANC” (proposed nested publishing system)

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?

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

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/

Received on Tuesday, 20 February 2018 17:55:21 UTC