Remove "unauthorized" and add "deactivated" error code.

[peacekeeper]

Addresses #402.

---

Preview | Diff

[peacekeeper]

The question of resolution/dereferencing error codes started earlier this year when we added the DID Resolution section. Based on the discussions back then, and the comments in issue #402, the idea is that we include a minimal set of error codes in DID Core, and allow additional codes to be assigned via the DID Spec Registries in the future.

With this PR, we would have:

• For DID resolution: invalid-did, not-found, deactivated
• For DID URL dereferencing: invalid-did-url, not-found, deactivated

[kdenhartog]

I like adding the deactivated error, and I think it would remain beneficial to keep unauthorized as well. In the case of resolving dids from a public resolver connected to a private VDR (such as an intranet web server with did:web or a private hyperledger fabric network) I think it's beneficial to indicate the DID exists, but the resolver cannot return the DID Document without some form of authorization provided in the request. This bodes well for a zero trust architecture where the resolver service is acting as an authorization point for a resource (the DID Document).

With that in mind, this does open the question do we need to be able to provide authorization proof in the resolution options parameter?

[peacekeeper]

I feel pretty strongly that in the DID Core spec we should not talk about authorization of DID resolution and therefore remove the error code. This doesn't mean that such an error code and also some kind of authorization input metadata is not possible or not allowed, those things can be done and even added later to the DID Spec Registries. But if we want to address this now in DID Core, it would be a major new feature that we don't have time to discuss. As far as I remember, by default, we have always considered DID resolution to not require authorization.

If we want to specify this at some point, we could define the required metadata and error codes elsewhere, e.g. in DID Resolution, and then register those extensions in the DID Spec Registries.

[agropper]

+1 Markus. I think this is a complicated issue in terms of privacy. Happy to engage if the group thinks it’s important but we would need to develop some use cases to discuss further.

…

On Tue, Oct 20, 2020 at 3:08 AM Markus Sabadello ***@***.***> wrote: I feel pretty strongly that in the DID Core spec we should not talk about authorization of DID resolution and therefore remove the error code. This doesn't mean that such an error code and also some kind of authorization input metadata is not possible or not allowed, those things can be done and even added later to the DID Spec Registries. But if we want to address this now in DID Core, it would be a major new feature that we don't have time to discuss. As far as I remember, by default, we have always considered DID resolution to not require authorization. If we want to specify this at some point, we could define the required metadata and error codes elsewhere, e.g. in DID Resolution, and then register those extensions in the DID Spec Registries. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#440 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABB4YNTYQNVWXHAMUHS2T3SLUZNTANCNFSM4SWAHVOA> .

[peacekeeper]

Merge conflicts should be resolved now.

[msporny]

Normative, multiple positive reviews, no objections, merging.