Question: Framework for PURL-DOI type DID Doc Long-term permanence [Re: Minutes for EDU/OCC...telecon]

Greetings,

Several people in the EDU/OCC telecon spoke of the need for 
self-assertions (Nate, Serge, Adrian, Cherie).

To me, this leads to a question of DID Document permanence. I.e., what 
will be the high-level steps required to:

   1. Make an assertion of identity (ie, by a DID identifier and DID Doc);

   2. Use a combination of PURL/DOI/URIs/URLs it so that this DID can 
continue to be accessible for, say, as long as a physical book lasts 
-- maybe 100 years.

Here is an example, from a real situation:

   A. Musician X writes Song S, and records it, and it is mixed to 
final .wav file Song_S.wav

   B. Musician X dies unexpectedly.

   C. Musician X had legally arranged to have the song published by 
Small Publisher Y (SP Y), but due to various factors (death of 
Musician X, changes in the music business), the recording of the song 
is not released.

   D. SP Y goes out of business, but realizes that Song S is good, 
will have an audience, and needs to be made available to the public 
somehow.

At this stage: Enter DID Documents.

Putting aside the question of payment for the song, and merely in 
terms of using a DID Document to permanently identify it and who made 
it, in the current Internet, would it be correct to:

  1. Set up a DID Doc to identify Musician X (even though deceased).

  2. Set up another DID Doc to identify the file of the recording 
itself, Song_S.wav.

  3. Host the two DID DOCs on servers so they each have a resolvable URL.

  4. Host the recording, Song_S.wav, on some other server, so it also 
has a resolvable URL.

  5. Create three PURLs (Persistent URLs), such as DOI or other 
permanent system, one pointing to each of these DID Docs and the third 
one pointing to the Song_S.wav file. (These PURL/DOIs systems are 
chosen so they will (hopefully) live for the target publishing life of 
100 years.)

  6. Make sure the DID Doc for Song S contains the PURL/DOI for 
Song_S.wav, so that the Song_S.wav can be found permanently from its 
DID Doc even if the hosting server changes (including to a distributed 
type of hosting).

  7. ?? In addition, make sure all three PURL/DOIs are contained 
inside each of the two DID Docs, so that any of the three PURL/DOIs 
(i.e. of the two DID Docs and Song_S.wav) can be used to negotiate 
with all three. I.e., So that the PURL/DOI link to Musician X will 
also lead to information about Song S and Song_S.wav, and the reverse 
as well. (The details of how that would happen inside the DID Docs are 
far beyond me, and perhaps this isn't possible).

And I may not be correct in #1-6 either, but this is as far as my 
brain can stretch at this time. :-)

Comments and corrections appreciated.

Steven








> Nate Otto: Serge has long suggested use cases requiring that the 
> issuer of an Assertion themselves only needs to hold a particular 
> badge. >Adrian Gropper: A need for individuals, not just
> institutions to be able to issue credentials
...
> Nate Otto: There is a very strong place for self-asserted claims in
> the future of Open Badges.
> Cherie: Dominode interested in
> self-asserted use case, Many types of achievements not recognized
> yet and we need to provide the on-ramp to use these standards for
> them. >Serge Ravet: An interesting document to justify the need for
> more open recognition: 
> https://digimusingsblog.wordpress.com/2018/03/15/incomplete-recognition-of-peoples-talents/

Received on Sunday, 25 March 2018 18:03:55 UTC