- From: David Chadwick <D.W.Chadwick@kent.ac.uk>
- Date: Tue, 20 Feb 2018 11:21:52 +0000
- To: Adrian Gropper <agropper@healthurl.com>
- Cc: public-credentials@w3.org
Hi Adrian
I agree that 'trust negotiation' is the best way of selectively
releasing policies and credentials, but even then, in order to boot
strap the process, the server has to have a public policy that it is
willing to release to every client that contacts it, so that the first
matching credential can be sent. This could be as simple as 'prove that
you are a human (and not a bot)', and after the 'human' credential is
released, then progressively more restrictive policies can be released.
The client can also ask the server to release its credentials, such as
'prove you are the AS belonging to X'.
But assuming that trust negotiation does not take off anytime soon (and
it hasn't for the last 16 years [1]), then I think the first practical
implementation has to be the server sending its authz policy to the client.
regards
David
[1] Winsborough, W. H., Li, N. (2002), “Towards Practical Automated
Trust Negotiation”, 3rd IEEE International Workshop on Policies for
Distributed Systems and Networks, Monterey, CA, June, pp 92-103.
Winsborough W.H, Ninghui L., (2002)
On 20/02/2018 10:50, Adrian Gropper wrote:
> Hi David,
>
> It depends on your perspective on agency. From the perspective of the
> self-sovereign data subject, I want to maximize my agency and privacy by
> not sharing my policies with anyone, ever. I treat my policies just like
> my private keys, you can have a public manifestation of my policies in
> the form of a token but not the policies themselves. My personal
> self-sovereign AS gives me agency in the world and symmetry on the
> demands of my tech-enabled service providers.
>
> Also, the UMA spec does allow for minimization in the sense that you
> seek to the extent that a requesting party can negotiate claims
> escalation with the AS iteratively until it gets the token it wants.
>
> So, yes, there is a tension between the privacy of the two parties
> involved but in the healthcare use-case the service provider tends to be
> the regulated entity and her credentials tend to be public anyway. That
> said, both the requesting party and the resource owner deserve the
> benefit of a self-sovereign agent, the requesting party’s client and the
> resource owner’s AS respectively, and both can engage in a conversation
> that protects their privacy.
>
> Adrian
>
> On Tue, Feb 20, 2018 at 4:19 AM David Chadwick <D.W.Chadwick@kent.ac.uk
> <mailto:D.W.Chadwick@kent.ac.uk>> wrote:
>
> Hi Adrian
>
> On 20/02/2018 08:33, 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.
> >
> > 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.
>
> If a server does not publish its policies, then how is the client meant
> to know what credentials to send? This is not a recipe for least
> privileges, but rather, send me everything you have and I will decide if
> you are authorised or not, which strips the user of all privacy and is
> counter to the philosophy of the VC groups.
>
> Thus it is much better that the server does send its policy to the
> user('s client), so that the user can return just those credentials that
> match it.
>
> regards
>
> David
>
> > 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#>
> > 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/
>
> --
>
> 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 11:23:06 UTC