Authorization: Delegation, ownership, and control

[trbouma]

I find the delegation model a bit complicated and have been reflecting on a more generic pattern.

I believe there is an implicit assumption that a DID "owner" is also the "controller" unless by exception by means of delegation. I don't think this is necessarily the case.

I think you can address the delegation aspect more generally by removing it and introducing the notion of "controller" along with "owner". You can prove "ownership" and/or "controllership"

In the majority of cases, owner and controller are the same subject, but in the case of delegation (guardian) the controller would be a different subject.

Further, by separating owner/controller it allows you to implement hybrid centralized/decentralized identifier/authentication schemes. For example, my email address "trbouma@gmail.com" is a centralized identifier, but I may wish to register and prove controllership in a decentralized context that is completely unrelated to Google.

Finally, you can have two independent lifecycles (or transitions) - one for ownership, and another for controllership. A good real-life example is the differentiation between the owner of a vehicle and the driver of the vehicle. Speeding tickets are attributed to the driver of the vehicle; parking tickets are attributed to the owner of the vehicle.

Anyway, these are suggestions to help simplify the spec.I may have missed some nuances in the model but happy to discuss further.

[msporny]

I find the delegation model a bit complicated and have been reflecting on a more generic pattern.

Yes, we agree and are currently working to simplify it via the Linked Data Object Capabilities work:

https://w3c-ccg.github.io/ld-ocap/

I think you can address the delegation aspect more generally by removing it and introducing the notion of "controller" along with "owner". You can prove "ownership" and/or "controllership"

Fundamentally, this is where the group is currently. We have yet to refine it into specification text. We're attempting to do so and have been deeply engaged in a large rev to the spec (preview available here):

https://pr-preview.s3.amazonaws.com/w3c-ccg/did-spec/pull/41.html

In the majority of cases, owner and controller are the same subject, but in the case of delegation (guardian) the controller would be a different subject.

Correct.

Further, by separating owner/controller it allows you to implement hybrid centralized/decentralized identifier/authentication schemes. For example, my email address "trbouma@gmail.com" is a centralized identifier, but I may wish to register and prove controllership in a decentralized context that is completely unrelated to Google.

Yes, correct.

Finally, you can have two independent lifecycles (or transitions) - one for ownership, and another for controllership. A good real-life example is the differentiation between the owner of a vehicle and the driver of the vehicle. Speeding tickets are attributed to the driver of the vehicle; parking tickets are attributed to the owner of the vehicle.

Correct.

Anyway, these are suggestions to help simplify the spec.I may have missed some nuances in the model but happy to discuss further.

I think we're aligned, we just need to convert it into spec text.

To summarize, the specification identifies (or is attempting to tease out the concepts of) "authentication" and "authorization". Authentication is how you prove that you are the entity associated with a particular DID. Authorization is how you specify who can do what on your behalf. Most of what you talk about above is "Authorization", where delegation is specified via authorization.

For example, in the event of a parent-child guardian relationship, in order to authorize a parent to modify the child's DID Document, you'd have a section in the child's DID Document that would say something to the effect of "An entity that can authenticate as DID X is allowed to update properties X, Y, and Z in my DID Document".

While the group agrees that conceptually this is a good model, Veres One will be the only DID Method to support this natively in the DID Document. Other ledgers have noted that they want the ability to specify these mechanisms themselves and thus they do not want the DID Specification to define the mechanism.

... which is why @cwebber and I are working on the Linked Data Object Capabilities work, to define a standard way of doing this in the hopes that other DID Methods will use it and it will eventually be standardized. Also note that the LD OCAP work will most likely be the delegation model that we use for Verifiable Credentials as well.

Is all of this aligned with your thinking on the matter? Are we missing something fundamental?

[trbouma]

I think we're aligned! We are going in the right direction. I am trying to boil things down to orthogonal self-evident primitives, namely,

1) Am I interacting with the right entity? (identifier) 2) Does the interaction originate from this entity (authentication) 3) Can I rely on the claim that relates to this entity (claim)

DIDs address 1) and 2) and VCs address 3)

The components of model can be implemented using different schemes (centralized, federated, decentralized) yet work together.

[msporny]

DIDs address 1) and 2) and VCs address 3) The components of model can be implemented using different schemes (centralized, federated, decentralized) yet work together.

Yes, exactly. That is the design intent of this particular standards stack:

Layer	Specification
Layer 3	Decentralized Identifier Management (e.g. DID-based Authn/Authz Protocols)
Layer 2	Verifiable Credentials / Verifiable Profiles
Layer 1	Decentralized Identifiers

While each layer emphasizes Decentralized schemes, the technology is spec'd such that you can mix-match centralized, federated, and decentralized at each layer (and between layers) to enable the multi-year/decade transition from centralized/federated to decentralized. In some cases, the transition may never happen because centralized is a better solution in that particular scenario (think high-security / dangerous materials use cases).

[trbouma]

Yep - we are on the same track. The only thing I need to ponder (being a minimalist) is where Authz lives. You might be able to push that into a Verifiable claim. As I mentioned earlier, there are three fundamental questions to be answered: 1) Ownership, 2) Control, 3) Truth (in the practical sense)

For sake of simplicity you might want to consider bumping out Authz and address Delegation (at root, it is a a control issue) as I described earlier.

[msporny]

@trbouma wrote:

For sake of simplicity you might want to consider bumping out Authz and address Delegation (at root, it is a a control issue) as I described earlier.

We have also identified various types of authorization. For example, authorization related to the DID Document, or authorization related to something else (like ability to rent a car or book a flight). The DID spec may want to address the former, where Verifiable Credentials would address the latter. It's still an active discussion in the group. We're currently testing out a few implementations to see how they work in various use cases. It'll most likely take a few months and some deployment experience for us to settle on a design pattern that works for everyone.

[msporny]

No spec changes have materialized as a result of this discussion. Closing in 7 days if there are no objections from @trbouma.