Re: DID Method requirements (revocability)

Hello Chris,

In my mind, DID resolution is an abstract function that takes a DID as
an input parameter and returns a DID document.

This process can be invoked in several ways:

1. By integrating a DID resolver library into an app or service, i.e.
DID resolution happens through a library call similar to calling a DNS
library.
2. Using a command line tool such as did-client
<https://github.com/digitalbazaar/did-client>.
3. Using a web service such as Universal Resolver <http://uniresolver.io/>.

If DID resolution is called for a DID that doesn't exist, then no DID
document is returned.

I don't think the options you mention (empty JSON doc or empty string)
are good ones; instead the result of the DID resolution function should
explicitly be "no DID document".

1. A library may return a null value or throw an exception.
2. A command line tool may print an error or simply print nothing.
3. A web service may return 404.

Separate from that, we can discuss whether a "DID that does not exist
because it has never been created" and a "DID that has been revoked"
should be considered equivalent from a DID resolution perspective, or if
those are two different cases.

I believe there could be some value in distinguishing between these
cases, but then again some DID methods may not be able to support this
distinction (just like some DID methods may not support versioning).

This is a good topic for a DID resolution spec that should standardize
some of this, I just created an issue:
https://github.com/w3c-ccg/did-resolution/issues/5

The Universal Resolver does not support revocation yet, it's highly
experimental.

Markus

On 06/13/2018 06:29 AM, Chris Boscolo wrote:
> Thanks for the clarification, Drummond.
>
> With an eye toward interoperability, I have one clarifying question.
>
> If I query a DID what response indicates that it is revoked? (I could not
> find the answer in https://w3c-ccg.github.io/did-spec/)
>
>  1) The call returns an empty JSON doc like: {}
>  2) The call returns an empty doc such as: ""
>  3) Or something else?
>
> Thanks!
>
>   -chrisb
>
>
> On Tue, Jun 12, 2018 at 8:40 PM, =Drummond Reed <drummond.reed@evernym.com>
> wrote:
>
>> On Tue, Jun 12, 2018 at 5:18 PM, Chris Boscolo <chris@boscolo.net> wrote:
>>
>>> During the W3C call this morning, one issue that was highlighted was
>>> whether or not a DID needs to support the ability to be revoked in order to
>>> claim compliance with the standard.
>>>
>> Good question, Chris. I can't check right at the moment but I believe we
>> said it was optional for a DID method to support revocation. So a DID
>> method specification simply needs to say:
>>
>>    1. Is revocation supported?
>>    2. If so, how?
>>
>> We recommended that any DID method capable of supporting revocation do it
>> by nulling out the DID document.
>>
>>
>>> This prompted a question for me.  Does anyone know how many of the DID
>>> methods supported via https://uniresolver.io/ do the revocation check as
>>> part of the read/verify step?
>>>
>> I don't offhand but maybe Markus does?
>>
>>
>>> Also, in re-reading the DID spec, I notice it does not specifically
>>> mention doing this check during the Read/Verify step.  Would it be worth
>>> adding some language clarifying that implementors should do this?
>>>
>> If the recommended method of revocation is to null out the DID document,
>> then no additional work is necessary: if the return is a null DID document,
>> the DID is revoked.
>>
>> So the revocation check is only necessary if the DID method has a
>> different way of doing revocation. In which case I would agree that it
>> should be recommended to check it on resolution.
>>
>> =Drummond
>>