transfer of controllership and it's intersection with the subject of an identifier

[kdenhartog]

We've got language like this in section 5.1.4

That is, a DID is bound exclusively and permanently to its one and only subject

But I've also seen it mentioned in issue #233 (comment) that the controller gets to decide who the subject of the DID is. However, it's legitimate that a DID could have multiple controllers. What happens in the case where the controllers don't agree on the subject?

Additionally, what happens if control of the DID is transferred and the new controller chooses to use the same DID to identify a new subject? Do we need to consider these concerns in the spec and represent some way for the controller to indicate these things or are they really features not bugs?

[jandrieu]

That statement, unfortunately, is a legacy of a misinterpretation of the original 4 motivations behind this work. It simply isn't true. Never was. There can be no guarantees about what a DID refers to. All you can do is accumulate statements asserting what a DID refers to, e.g., VCs with that DID as the DID subject.

Those assertions can be

• accepted without critical evaluation,
• accepted based on the reputation of the issuer, and/or
• vetted by third parties

But you still only have the word of certain parties as to what a DID actually refers to.

Language like that in Section 5.14 should be replaced with something more accurately representing what DIDs can and cannot do.

[kdenhartog]

I think that makes sense. Follow up question, would that mean that I could receive VCs, the subject of the DID changes without me knowing, and then later I notice something off so I ask for a VC again? Seems to fit the real world quite well in the idea that "people change". Seems like it would be useful to update the spec to make the langauge follow in that direction. If I took a pass at attempting that could I get you to review it because you've been one of the more vocal people on the nuances of controllership?

[jandrieu]

I'd love to get to a PR that is clearer.

One relating item we don't make crystal clear in the spec is the notion of proof-of-control as the fundamental form of authentication. I've spoken with implementers and to them its obvious that you perform proof-of-control BEFORE issuing a credential, in order for the Issuer to verify the ID used for the subject is in fact under the recipient's control. Then, you do it again every time it is presented so the ultimate Verifiers can know that the current presenter is--to some notion--the same person it was issued to initially.

I use the phrase "to some notion" because, of course, the keys could be under anybody's control. So, you don't have anything as rigorous (or as invasive) as a DNA test or biometric scan, BUT modern secure systems often rely on the security of those control mechanisms: "Not your keys, not your bitcoin." If we are comfortable believing that private keys can legitimately be used as an authentication mechanism (and for most use cases that's entirely appropriate), then proof-of-control is a form of assurance about the identity of the subject (and it's WAY better than username/password but not perfect). This two-steps of proof of control are what you, as a Verifier, are depending on for judging legitimacy of a VC.

Of course, the current spec doesn't guarantee that the Issuer in fact did a proof-of-control before issuing, but that is how the magic works.

So I can see two adjustments to the spec from this thread.

1. Clarify this proof-of-control as a form of identity assurance.
2. Add some normative properties for how an issuer might include the proof-of-control in the original credential, enabling a verifier to check that, in fact, there is a proof-of-control (as a proof) that shows the DID subject definitively signing a challenge & domain for this VC.

#1 is more editorial and an easy errata.
#2 is, IMO, a huge missing link, but would take some effort to build consensus around it.

I'd like to help with both.

Neither of these address the idea of the subject "changing", e.g., someone selling their keys (or selling the capability to sign with those keys), but your intuition is spot on. If you have reason to doubt the legitimacy of key control for a given identifier, by all means, ask for refreshed credentials. Some of those might be impossible to get updated, but if it matters, it's worth checking.

[kdenhartog]

Point 1: +1

While I agree with point 2, I'm not certain it should be done at this spec. It seems to fit within the scope of a VC issuance protocol spec (which we both know is out of scope). My reason for thinking this is because it talks explicitly about the combination of VCs and DIDs and what issuers should do while issuing. I do think we could generalize it to fit within this spec and put it as a security considerations point.

What's your thoughts on that approach?

[jandrieu]

Turns out the only requirement for point 2 is the ability to prove control, which you can do with several protocols, including email and http(s). This was a rather interesting realization that opened a whole world of alternative mechanisms.

While DIDs were developed hand-in-hand to work with VCs, there are a few alternatives that can provide the same sense of identity-proofing, i.e., proof-of-control, without the particular overhead of DIDs themselves.

[kdenhartog]

I think I'm lost then on what are the normative properties we would include then from point 2. Could you provide a few examples with VCs and non-VCs alike and how they would change the did spec?

[jandrieu]

Re #1, explaining proof-of-control better would be a good PR.

Re #2, properties that would be added would be additions to the VC spec to have a standard way for an issuer to present evidence of the proof-of-control for the subject performed before issuing the credential. Nothing would change in the DID spec. Sorry that was unclear.

More controversially, I would ALSO advocate in the DID spec trying to shift from focusing on what the subject of a DID is. I think that's been a big red herring.

The vital thing a DID does is enable autonomous authentication. The "subject" framing interprets DIDs with an outdated mental model. All we ever know is that at any given time, the party in a session either can or cannot prove control. The fact that someone can prove control makes them a controller. The ceremony of proving control establishes a fact about the person who proved control, but we have no similar ability to discern anything about a subject. We only have evidence of control.

Rather, the architecture lets one use proof of control to achieve a specific level of identity assurance regarding an identifier. That proof can then be used to secure verifiable credentials of various attestations with that identifier as a subject. Together, we can interpret those statements by specific issuers to develop a notion of the subject of that identifier. In earlier terms, we can gather claims from various authorities to establish who someone is, which in our model is shared under the authority of the holder, who is usually the subject.

The trick is understanding that we never really know who someone is in exactly the same way we never know who (or what) the subject of a DID is. We can gather evidence. But evidence can be incorrect or out of date. This is a fundamental epistemological issue.

So we can convince ourselves who the subject of a DID is, but that will never be definitive. IMO, the privacy impact of that shift in perspective should be clarified.

[jandrieu]

@kdenhartog Any more comments? The group would like to know how to move this towards closure.

[kdenhartog]

At best I think we may be able to add a non-normative section about the intersection of controllers and subjects. As you pointed out though, getting consensus on this topic would likely be very difficult to achieve at this point, so I'm satisfied with leaving that part as a note that people can dig through the issues to find.

As for point 1, I think we can add a small detail to proving control of a did document which states the following:

Through the use of digital signatures a controller can assert proof of control which can be used in a variety of different contexts. By asserting proof of control of the identifier, the controller is asserting proof of ownership of the public key which may not be the same as the subject of the DID. However, it's up to the verifier to determine if the static or dynamic usage of digital signatures is adequate to meet their assurance guarantees. In the case where it's not, it's up to the verifier to establish their own levels of assurance to identify if they believe the controller is the subject or is authorized to speak on behalf of the subject of the identifier.

I've opened a PR for this, but not sure if this is the right place for it to go. Let's discuss the details of this in the PR and then we can close this issue once it's merged.

[kdenhartog]

The PR exists for this issue, but I'm in favor of closing it and the PR #352 once the appendix work being discussed in #373 ends up in the spec or as an additional side document. Either would satisfy my question for this issue.

[kdenhartog]

This issue is going to be closed and the discussion will become part of the work that's done for #373