Re: did:key questions (was: DHS SVIP Blockchain/DLT/SSI Cohort - Multi-Product Phase 1 Interop Artifacts/ Scaffolding / Information)

On Fri, 12 Jun 2020 at 22:29, Dmitri Zagidulin <dzagidulin@gmail.com> wrote:

> Oh, I just meant, the fact that it _is_ a DID Document could be determined
> either because the URL starts with a 'did:', or that it has a 'this is a
> DID Document' mime type. (Which is one of the issues being debated - what
> to use for content-type for DID Docs).
>

Do you mean which mime type to use if a DID doc is served over HTTP?  Then
would it not be "application/ld+json" or do you mean some other mechanism
for serving a DID -- ie non-http -- are mime types even appropriate there?


> Similarly, there are no explicit type fields for DID Documents (the method
> is determined from the URL).
>
> On Fri, Jun 12, 2020 at 4:21 PM Melvin Carvalho <melvincarvalho@gmail.com>
> wrote:
>
>>
>>
>> On Fri, 12 Jun 2020 at 19:23, Dmitri Zagidulin <dzagidulin@gmail.com>
>> wrote:
>>
>>> Hi Melvin,
>>>
>>
>> Hi Dmitri, thanks for the response
>>
>>
>>> You bring up good questions!
>>>
>>> 1) Should the DID Document have a "type" field
>>>
>>> So this has been hotly debated, and so far, it's settled on "no".
>>> (Strong pushback against adding a type field, when it's been brought up in
>>> the issues.) So, yes, at the moment, the type is assumed by @context (and
>>> mime type!).
>>>
>>
>> When you say the type is assumed by the @context and the mime
>>
>> Assumed to be what?  Do you mean that the type is not explicit, but that
>> there is an implicit, implied using reasoning?
>>
>> I've looked in here, and nothing stood out:
>> https://w3c-ccg.github.io/did-spec/contexts/did-v1.jsonld
>>
>> I tried looking here: (didv "https://w3id.org/did#") but it doesnt seem
>> to lead to a context
>>
>> So I am just wondering what the type would be named.
>>
>> Regarding the mime type.  Would I be correct to say the did:key doesnt
>> have a mime type?
>>
>>
>>>
>>> 2) Can a did:key DID Document be embedded in a JSON "data island" in a
>>> web page
>>>
>>> Sure, why not. (Although the question does arise - why use an ephemeral
>>> did doc like did:key for those kind of use cases, why not go with a did:web
>>> or another longer-lived method).
>>>
>>> 3) How does one link entities (like Alice) and DIDs (including a did:key
>>> did), in the linked data sense?
>>>
>>> So, this is an /extremely/ hot and controversial topic :) Well, partly.
>>>
>>> 3a) Q: *Should* this be done in the first place?
>>>  A: Very carefully, and in a privacy-preserving way. But I can see some
>>> legitimate use cases for it.
>>>
>>> 3b) Q: How do you link from a DID Document to some other public profile
>>> endpoint (such as a WebID Profile)?
>>> A: (Again, you should _not_ do that in a ledger-based DID Document,
>>> since that is very much PII.) But if you need to, that's what the Service
>>> Endpoints mechanism is for. We do not yet have a proposed Service Endpoint
>>> for a WebID Profile link, incidentally, although I am planning to propose
>>> one over at https://github.com/solid/identity-panel/issues/1
>>>
>>> 3c) Q: How do you link from a public machine-readable document to a DID?
>>>
>>> A: (Assuming a legit public profile use case) Depends on what you're
>>> linking from.
>>> * To link a regular https URL or domain name, you can use the methods
>>> that did:web uses -
>>> https://w3c-ccg.github.io/did-method-web/#create-register,
>>>   which is basically the '.well-known' mechanism, or the DIDs in DNS
>>> spec https://tools.ietf.org/html/draft-mayrhofer-did-dns-01 .
>>> * To link from a Solid style WebID Profile - tbd. (again, I'm planning
>>> to bring it up in https://github.com/solid/identity-panel/issues/1
>>> thread).
>>> * To link from a linked data compatible social media profile like an
>>> ActivityPub profile used by Mastodon etc... I'm not sure. I think there's
>>> an experimental field for that?
>>>
>>> Hopefully this answers some of the questions.
>>>
>>>
>>>
>>> On Fri, Jun 12, 2020 at 11:30 AM Melvin Carvalho <
>>> melvincarvalho@gmail.com> wrote:
>>>
>>>>
>>>>
>>>> On Fri, 12 Jun 2020 at 17:06, Melvin Carvalho <melvincarvalho@gmail.com>
>>>> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Fri, 12 Jun 2020 at 15:10, Manu Sporny <msporny@digitalbazaar.com>
>>>>> wrote:
>>>>>
>>>>>> On 6/12/20 8:28 AM, Dan Bolser wrote:
>>>>>> > Just reading this:
>>>>>> > https://w3c-ccg.github.io/did-method-key/
>>>>>> >
>>>>>> > Which looks nice, but I don't understand how resolution from DID to
>>>>>> DID
>>>>>> > doc happens.
>>>>>> >
>>>>>> >     The creation of a DID Document is also performed by taking the
>>>>>> >     public key value and expanding it into DID Document
>>>>>>
>>>>>> Hi Dan, I'm one of the Editors for that specification. I'm going to
>>>>>> attempt to answer your questions below:
>>>>>>
>>>>>> > Ah... is the DID doc just a version of the key in a different
>>>>>> format?
>>>>>>
>>>>>> Yes, more or less. The DID Document is deterministically generated
>>>>>> from
>>>>>> the DID. The goal of did:key is to be THE simplest and easiest to
>>>>>> implement DID Method.
>>>>>>
>>>>>> > e.g. no other fields except those directly derived from the key are
>>>>>> allowed?
>>>>>>
>>>>>> Yes.
>>>>>>
>>>>>> > Sorry if that's obvious (sorry if this is a dumb question).
>>>>>>
>>>>>> No dumb questions... and this is a very good question and gets to the
>>>>>> heart of what did:key is about.
>>>>>>
>>>>>
>>>>> Hopefully this is neither a dumb question:
>>>>>
>>>>> Could a did:key Document be embedded in a regular JSON-LD document or
>>>>> "Data Island"
>>>>>
>>>>> For example could I say "Alice has a did:key:multihash document"
>>>>>
>>>>> What would be a way to link Alice and the did:key, if there is one?
>>>>>
>>>>> In Turtle:
>>>>>
>>>>> <#Alice> *???* <did:key:multihash> .
>>>>>
>>>>> In JSON-LD
>>>>>
>>>>> {
>>>>>   "@id": "#Alice",
>>>>>   "*???*":  [{ "@id" : "did:key:multihash" }]
>>>>> >
>>>>>
>>>>> What is the part labeled with 3 question marks?
>>>>>
>>>>
>>>> Hmmm, this also made me think:
>>>>
>>>>
>>>> https://w3c-ccg.github.io/did-method-key/#example-2-a-did-document-derived-from-a-did-key
>>>>
>>>> Perhaps the DID Document should have a type?  Something like
>>>>
>>>> "type": "DIDDocument"
>>>>
>>>> In Example 8, above.  Or is that assumed from the @context?
>>>>
>>>>
>>>>>
>>>>>>
>>>>>> > In this sense it's essentially a 'mock' or 'placeholder' DID
>>>>>> document?
>>>>>>
>>>>>> I wouldn't say it's a 'mock' or 'placeholder' DID document. It is a
>>>>>> bonafide DID Document that can be used in production systems that
>>>>>> don't
>>>>>> require key rotation. For example, very useful in test environments
>>>>>> and
>>>>>> systems that use short lived DIDs (throw-away pairwise relationships,
>>>>>> etc.).
>>>>>>
>>>>>> -- manu
>>>>>>
>>>>>> --
>>>>>> Manu Sporny - https://www.linkedin.com/in/manusporny/
>>>>>> Founder/CEO - Digital Bazaar, Inc.
>>>>>> blog: Veres One Decentralized Identifier Blockchain Launches
>>>>>> https://tinyurl.com/veres-one-launches
>>>>>>
>>>>>>