When is a DID subject not a DID controller (if ever)? #122
Comments
|
I think there are cases for both scenarios, which could be covered by something like --
|
|
I think this is a great question for clarification, and I feel like I may have missed a large chunk of the historical conversation here so I'd like to offer up some ignorance in hopes that it be quickly put to rest. It really feels like the winds of DIDs are now pointing only to a certain class of enabled sentient sapiens. Once upon a time I thought it might be possible for my cats to have multiple DIDs - one for their medical records, one for their instragram accounts, and a separate one for Litter - like Tinder, but for cats. I also once had an idea that I'd tag all the books on the banana pancake trail with dids, so they could be tracked via QR codes (kinda as a playground for rugged wearing pepper-and-ink or scantrust kinda QR tech - SICPA has some tech in play too) Perhaps this is entirely dealt with by Guardianship and Ownership constructs - or that DIDs are now only about establishing communication with active software agents. Is the idea of having a DID for a book, where the control of that DID moves along with the controller while allowing the book to be referenced (via DID) sensible, or is that an abuse of DIDs in the current thinking? I'm noting that in the use-case-spec we write:
I'm asking as a point of clarification rather than advancing this specific question forward so that I can respond to the question itself with minimal lateral confusion. Looking at the use-cases tied to the charter, it does seem that the above are - more or less - "out of scope" and that only agency-capable entities should be the targets of DIDs.... but i would not mind some clarification. |
|
Responding to @rhiaro's opening:
Depending on your meaning, I would not say this is the default. It is the most common case that most of us care about, but one should not assume that the subject is the controller. In discussion (although not necessarily in the Use Cases & Requirements document yet), the most common cases where the subject is not the controller are devices and dependents, or more commonly for both: IoT and guardianship situations. However, the Subject of a DID should be assumed to be anything in particular. And, to my sensibility, the DID Document should not, itself, give any indication about what exactly that Subject is. The Subject of a DID is whatever that DID refers to. Any statements about that Subject, such as "who they are" in some other namespace, e.g., their legal name, or any claims about them like "he is the King of England" belong somewhere outside the DID Document, like in a Verifiable Credential. The authenticity and veracity of such a claim is a problem dealt with in that domain. The only thing the DID Document does is present the necessary information for secure interactions with the Subject. And yes, that Subject could be a company, a building, a car, or a cat. |
|
Sorry, I got distracted by @ewelton's comment. It is not possible to prove a null hypothesis within the system. You can't prove that I don't control a DID, you can only prove that I do. To @TallTed's response, I don't think that's accurate. If there is no controller property, you can't assume that the Subject actually controls the DID. Rather, if there is no controller property then you must look the DID method to see who the controller is. My understanding is that the controller property was added to allow another DID to control the DID under discussion. However, this is not a meaningful property for BTCR. The control resides on-chain and is completely independent of what might be in the DID Document. So, you could construct a BTCR DID Document with a controller value, it just wouldn't have any meaning wrt actual control of the DID. @kimdhamilton or @ChristopherA Could you verify if that is a correct wrt BTCR? |
|
@jandrieu My comment should not have been distracting, it was an honest request for clarification. I think you provided a bit of that, albeit coated in a bit of preliminary vitriolic ejaculation. My concern is that none of the use cases listed in the "focal use case" documents has the important properties we're now talking about - all of those cases are biased towards a certain class of subjects. The result is that important dimensions of "when wouldn't subject=controller" is hidden, as per the charter. |
|
@ewelton I meant that my answer to your question did not directly answer @rhiaro's closing question. The Use Cases and Requirements document is currently seeking additional use cases to fill out Section 2. The Focal Use Cases section is not intended to be comprehensive, but rather a deep dive on a limited set. If I still haven't addressed your question, @ewelton, please try again. Or, if it is more pertinent to the use cases document, consider adding an issue over there: https://github.com/w3c/did-use-cases/issues |
To be clear, I was answering "what wording would communicate @rhiaro's opening"? I don't think the governing normative language in the spec has been determined yet -- it could be your assertion here, or my earlier wording, or a combination of the two (e.g., "if there's no controller property, check the DID method; if the method doesn't specify, and there's no controller property, the subject is the only controller"). |
|
I think I see my disconnect with what @rhiaro was asking. I was reading DID Subject and Controller in the context of the roles in the architecture, not the DIDs that may be in the DID Document. In the way the question was asked:
I took this to literally mean the DID Subject, but I believe @rhiaro, you mean the DID of the current DID Document. In which case, I believe the answer is that the DID is always the de facto "controller" of its own document, whether or not it is listed explicitly in the controller property. The controller property may list one (or more?) DIDs whose Controllers should be afforded the privileges of controlling the current DID Document. I take this to mean that the DID of the current document is implicitly in the set of DIDs in the "controller" property. To my knowledge no one has proposed that the DID of the current document NOT be able to control its own document. Although, the more we discuss it, the less I feel this particular form of delegation / authorization is the right approach. |
What? DIDs identify entities, who may be designated as Controllers of other DIDs. You appear to be suggesting an indirect relationship, such that Controllers-of-other-DIDs may be designated as Controllers of this DID by listing the other DIDs that they control -- instead of listing the DIDs (or other identifying URIs) of those Controllers? That makes no sense to me. (And again I wonder whether using the DID abbreviation is causing more trouble than it solves by saving keystrokes; and just how much trouble could be solved by some pictorial illustrations of the things we're trying to talk about.) |
|
Thanks all for this discussion. Makes it evident that we do need to figure this out and make it explicit in the spec. I understood "DID Controller" to mean an entity which can change the DID document (for which there is an updated definition in an open PR here: 189e5bd). With that in mind, the DID itself - the identifier string - can't be a controller (re: "the DID is always the de facto "controller" of its own document") and I did indeed mean "The Subject of a DID is whatever that DID refers to" when I mentioned the DID subject being the/a DID controller for its own DID. In the case of DIDs for entities incapable of authenticating themselves, like a cat or a company, the DID subject (the cat or the company) cannot be the controller, so some other entity like a human (or a piece of software? right? or is this the realms of the robot uprising?) should be expressed with the top level If a DID and corresponding document is generated and there is no top level I still feel like I'm missing a part of the picture here though. |
|
@rhiaro I've taken this up w/ my cats.... but I think you are correct. The chances that we will come to decision before them is highly likely. |
|
A DID is an dereferencable identifier; it refers to a DID subject. If you dereference the DID, you get a DID Document that includes information about the DID subject. This information can only have been put there with the consent of a DID controller. It is safe to trust this information only got there with the consent of a DID controller provided that you trust the resolution process and the root of trust (as defined according to the DID method). So who/what is a DID controller? A DID controller for the DID
Exactly what a DID controller can do with a DID Document is up to a DID method to specify. Some DID methods may not allow updates to a DID Document; some may allow certain pieces of information to be written and prevent others pieces of information. Some DID methods may only allow DID controllers to directly make changes to a DID Document whereas others may employ technologies such as Authorization Capabilities to enable DID controllers to delegate authority to other parties to make changes. Systems using Authorization Capabilities are more likely to do most authority delegation through a chain of capabilities rather than by expressing multiple controllers. Some DID methods may require DID controllers to use cryptographic keys to make changes to a DID Document. In these systems, it may be the case that a DID controller cannot update a DID Document without also expressing verification methods (using an appropriate authorization relation such as |
|
@dlongley - I'd like to ask some follow on questions? What would be different about the DID-doc statements relative to limiting the doc to just support a conversation about VCs, and letting VCs or other elements bound through service_endpoints carry the load? As I have a tendency to derail otherwise focused conversations - is there a better issue w/in which to pursue this thread? The idea that did-controllers can update "statements" about a did-subject just smacks of an invitation to get into VC territory. Would we simplify the spec (and promote advancement and adoption) by simply equating the two and limiting the semantic for the DID-doc to Layer1 bootstrapping and let Layer2 carry all exchanges beyond cryptographic integrity? Equating DID-subject = DID-controller and fixing that relationship is a simplification that will reduce the burden and complexity of the spec, and as such, it will foster adoption. Perhaps limiting the problem space of DIDs is a win? |
This degree of limit would eliminate a vast (possibly the majority) segment of the expected universe of DIDs, and I would not be in favor of forcing this limitation. |
I second @ewelton 's proposal. TNO has been studying stuff related to representation, guardianship, delegation and mandates in a.o. the Sovrin Guardianship Taskforce. Each of those is complex and highly domain, jurisdiction and Verifier specific. It hence requires proper case-by-case modeling with verifiable credentials. It should not be modeled in a DID document. Cases of DID-subject != DID-controller should be treated as an impersonation security risk. Se also #4 |
|
Re-reading part of the core spec...
I do not have a clear answer to these questions... :-( |
|
I just realize that my question is also closely related to #4 (e.g., #4 (comment)) |
|
The reason controller != subject is because we can't guarantee that AND there are use cases where that is a useful thing, including IoT and guardianship. Perhaps most importantly, it avoids the security fallacy of arbitrarily believing that the entity currently controlling a DID Document is actually the subject. We can't identity-proof the controller as the subject within the context of DID technology and it is vital that we do what we can to minimize the expectation that proof-of-control is the same as proof-of-identity. DID Controller is a functional definition. Any entity that can actually control the DID Document is a controller. The point of crypto is to ensure strong authentication such that the control is reasonably restricted to parties who have access to a secret key--which is more easily protected than authentication mechanisms that rely on shared secrets. Proof mechanisms that don't use a secret key are also supported, which leaves DID Methods room to innovate. But thinking of proof-of-control of a secret key as the functional definition of controller is likely the most useful mental model. So, you can easily have multiple controllers of a DID Document, with or without the Document explicitly enumerating multiple proofs/keys, simply because multiple entities could have the ability to use the crypto that lets them change the DID Document. That said, I'll bear witness again to a point I'm in continuing disagreement with @dlongley about
I believe this is entirely the wrong framing. A DID Document, following the language of RFC3986:
Resolving a DID gives you a DID Document with the data need to dereference the DID as a URL. Functionally, what MUST be in a DID Document is the data required for dereferencing the DID as a URI that refers to the Subject. That is, a DID Document contains the information you need to securely interact with the Subject, either by dereferencing to a service endpoint or directly using cryptographic material in the DID Document for service-independent secure communications, such as encrypting a message or verifying a signature in a transport-agnostic manner. Anything that supports secure dereferencing is fair game for inclusion in a DID Document. Anything that does not directly support secure dereferencing is a privacy anti-pattern that should be avoided. If you want to say something about a DID Subject, you should use a VC, which is literally designed to do this, including the critical function that the author of such a statement is explicit, cryptographically verifiable, and the message is capable of status checks and automated refreshing in ways that may or may not be supported by any given DID method. In contrast, we are still debating whether or not a DID Document contains statements only asserted by the DID Controller or if it should include meta-data based on resolution--which may or may not be verifiable and may or may not have an explicit author. We could make the simplification that a DID Document MUST be a VC, signed by the controller, and explicitly separate the assertions of the controller from those of the resolver (and/or registry). This would be a clear separation of authority, including a nice delineation between the author/controller and the subject. However, this has not been the consensus to date. |
|
Wonderful points all - looking forward to Amsterdam I wanted to be very clear that I actually side w/ @TallTed 's comment that the S=C limitation is too strict, because I believe that only a small slice of the DID namespace will be capable of exercising agency, and of those, the "publicly resolvable" DIDs are going to have a set of "public credentials" which will form the basis of searchable open registries. When @jandrieu writes
I see the core of the problem in one word - with. I pretty much agree with all of the rest of @jandrieu 's comment except for that one word. I expect the vast majority of DIDs to point to elements with which it is impossible to exchange message - these are entities that we can talk about, but not with. We don't talk with them - we talk about them with their controllers, or perhaps we interact via controller designed endpoints. This is where S!=C, because the S is not necessarily capable of agency, whereas C's are. I think this bears out in IoT and software agents as well - does my wallet control my private crypto assets, or does it contain assets which I try to control? This appears to get tremendously difficult when we think in terms of Guardianship - but that is because we are making the mistake of trying to link DIDs with some form of 'real-world-identity' - and that linkage should be 100% in VCs. The only thing we know w/ DIDs is what the controllers want us to believe - there is no way to differentiate, in the land of DID-documents, the difference between S and C unless we build it into the core - which perhaps we do by saying S should never control a DID. Pulling apart delegates, subjects, and controllers (and service_endpoints, authentication protocols, etc.) seem to be the domain of VCs. So what about a hard and fast rule, S!=C - ever - S can be the target of VCs, but the DID-Document is only ever a minimal description of an S. Drop service_endpoints, authentication, and anything that is not about "managing a controller structure" (perhaps a list of KERI witnesses and supporting docs) Yet that seems quite overkill in cases where the simple "I done got me a DID and writ that private key on this here fancy wallet" It seems to me what is needed is a structured way to have some flexibility in the DID document, and thereby accommodate a wide range of use-cases in a strongly machine processable fashion. Ideally the absolute minimum could have a clear abstract data model - and perhaps, in that minimum, S and C are orthogonal - S is simply the registration of a key pair, C is the designation required to adjust S, and all else is handled by VCs. |
|
Indeed wonderful points!
I second that notion. From a technical perspective, C is the bunch of hardware+software that puts electronically signatures ("electronic agent"), whereas S is the party (legal or natural person) that the electronic signature is supposed to represent towards the Relying Party. The binding between S and C is "authentication". As highlighted in #151, bare DID-based signatures may be sufficient for "LOA1" authentication ("eIDAS Non-Existent"), but they are already insufficient for "LOA2" authentication ("eIDAS Low"). eIDAS Low requires "an authoritative source" that makes a claim about S. This translates in our context to VCs. Oskar |
|
@Oskar-van-Deventer my only concern about the phrasing - "S is the party (legal or natural person)" - I think that the majority of DIDs will not represent either. In some cases they will, but the identifier in that case should only serve to link the VCs, likely in the context of public registries. For cases where anonymity is valued, the binding between the public-S DIDs, VCs, and pairwise DIDs driving ZKP exchanges might be preferable. On the other hand, I totally agree with the recognition that we want to be able to use these DIDs to represent ourselves in transactions - but that is a special subset of DIDs where "S is a legal or natural person" is important. The sense that "C is hardware + software" is also somewhat troubling to me - but I'm waffling on that. Capturing the sense of C's as wallets and agents might be a clarifying step - but if we did that, then I'd say that for the set S_person \in DID*, ultimately relationships like Guardianship and Delegation would best be carried out by VCs linking those roles between elements of S (as in a Domain-Specific Trust Framework - which places the link-VCs in a documented governing - and thus enforcement - context) Thinking that C => bound to mechanics of keys, and that it is S's that manage C's, kinda does clarify things. S is never a C, a C's merely participate in an update policy brought into play when S's DID was minted. Perhaps it would be straightforward to map most of the Guardianship, Delegation, and related inter-S relationships into a combination of S->C bindings written as VCs. Reflecting on @rhiaro's init stmt:
In this setup, there is an implication that DIDs are minted by entities capable, at least in theory, of exhibiting agency and executing key-mgmt tradecraft. This setup is pretty important - when we talk about DIDs for my cats or cows though, it is a stretch - no matter how hard I try to explain DPKI to my bovine companions, they usually just stare at me and chew. Control is required to "take action regarding", but that is different from using a DID as the identifier for a passive actor. For maximum privacy preservation, it must be possible to be impossible to distinguish "President of the United States" from "Cow staring at a wall" - at the level of identifiers. The DID:S relationship is intentional - it is about, the DID:C relationship is mechanistic - but, as we are understanding the intentional component of the DID:S relationship must be carried by VCs. Maybe a clean separation - S!=C - is the answer..... or an equivalently clean S=C is the answer - and if we allow a more complicated relationship between S and some cabal of C, then we definitely need a mechanism for capturing the full-richness of this relationship in a complex structure of DID-documents. Seems to me that going one way or the other is easier than going both ways at once - or perhaps DIDs require Quantum computation ;) |
|
I like this discussion. Is it on the agenda for next-week's meeting in Amsterdam? Should it be? Or is it a "break-out" issue? |
|
This is a useful discussion. I would point out that controllers themselves are (typically) represented by DIDs and are thus themselves DID subjects. It is impossible to say I think everyone is on the same page regarding keeping private data out of DID Documents and in the domain of VCs to the greatest possible extent. However, some level of flexibility for stating minimal things (important "discoverable" things) about DID subjects should be in the data model (to support a number of use cases or practicality) even if it is often not used or permitted by systems employed in other use cases. The most obvious example of an important "discoverable" thing is "DID subject S has a service X where you can do Y with S (or find out Y about S)" or ... "DID subject S has a service X where you can find out all of the other services S has". |
|
That's a great point - and it is "as the spec is written", having grown from a context where S=C was fairly simple and then growing to encompass the subtle distinction between the two for use in cases where that made sense. And there was a wonderful extension mechanism, where you could "add attributes" to the DID-Document to address various "typical lookups" - S could talk about itself, perhaps leveraging the facilities of specific methods. If it was appropriate for S to be controlled, it could provide the relevant set of Controller attributes (and link those to a context), and if it was appropriate for S to advertise service_endpoints, it could do that as well. S was in control of the semantic of its self expression. I thought this handled the different sorts of S and rules of C (and other variants of referent) very cleanly. For S's that wished to participate and advertise "potential PII" - such as might be found in service_endpoints, they could do so - for those who wished not to, then the service_endpoint information could be moved to the time of DID introduction - and this gets more and more like pairwise DIDs and is related to the concept of "resolution" - publicly resolving a published DID to gather information about it and perhaps initiate communication is rather different than resolving a single use DID constrained to a single communication context. In the current climate of removing the possibility of S using the DID document to express anything except the cryptographic material required to bootstrap layer-2 communication, it seems that separating S and C, and replacing the C - not with a pointer to a DID, but with just the control material itself, is worth considering. S - the self-certifying identifier, can be used as the skeleton of the VCs which define all other behaviour, while C is the separate pool of cryptographic information required to update S - and, given the minimality of information in these restricted DID documents, the only update that makes sense is termination - all else is handled by VCs. How you get those VCs is out of scope for the DID-document, because it can potentially reveal PII. If we start cross-linking DID documents and establishing relationships between them we should look closely at tools that support that sort of data linking in a systematic fashion. If, on the other hand, we do not want to cross-link DID documents to form a DID-document web, then we should consider removing C as a DID itself and replace it with just the cryptographic material. The DID document thus contains 2 sets of cryptographic material - one about S, and the other about the rights to update the information about S, or C. In the case that S wishes to advertise itself as the sort of DID capable of agency, a simple rule of "if C-info is absent, use S" - that handles the S=C case cleanly, but allows separation when relevant - all while avoiding cross-document linking. In terms of the opening question then, sometimes a subject could use separate cryptographic material for each but be the same entity, and in some cases they could be different entities. The reason for "but S can not" is just to make it clear and simple. But why not just move "controller" to a VC? And we would want to see that all of this complexity is worth it - if the DID-document is only about S's cryptographic material, and everything else is moved out to VCs, then perhaps we can simply get rid of controller altogether - we should be able to look very closely through the use-cases to determine which ones that would break under the assumption that the DID-document had zero content beyond that required to manage keys. |
This semantic fuzzyness worries me. What is the nature of C and S? Until the DID spec explicitly addresses this issue, answer d) is the default answer. I do not like that answer, because it leads to all kinds of potential confusion (= interoperability issues) with implementors and users, not to mention the standards development by the DID-WG itself. |
|
@Oskar-van-Deventer Entities like these
Could be either S or C - they are capable of agency - they can act. Sometimes this involves a 'fiduciary' relationship. The detail of a,b,c to a governance framework should be carried by VCs. S, however - to the best of my knowledge - can include
So I see C as a subset of S - and S-C is underrepresented in the canonical use-cases. Let's look at DIDs then, and characterize them as:
if S=C is strict, then S-C = \empty - then S can only refer to agency-capable entities - so every S needs, minimally, some sort of software-agent. In that case we could completely remove any distinction, there is only the cryptographic material around S, and the "actual controller" of S impersonates S. What matters is only the management of the private-side of the crypto-material. Let's look in detail at a DID for my cat - and the desire to publish a service_endpoint in a global network of verifiable medical records - or even a ZKP provider that could prove that "S had a rabies vaccination" - the backing data might include the lot-number of the rabies vaccine, the date of administration, the DID of the administrator, etc. Maybe the VC issues a credential (perhaps with its own DID) that details S's rabies vaccination. In those cases I accept the agency by "impersonating my cat" - no one can tell the difference between any of the cases a-d above. Now consider the following case I have one particular cat - her name is "Khao Nieow Dahm" and she is a sweet and loving 3 year old calico. She has decided that she prefers spending her time with the widow who runs a small guesthouse a few doors down the road. KND likes spending time down the street and can't stand staying at home anymore because we have another, younger, newer cat "Bahn Haa" who routinely attacks her - any time BH sees KND, then BH attacks - it is BH's goal to "claim the house for her own", and KND has decided that P. Jeab's home is a much, much, friendlier environment. If want to transition KND's DID to P. Jeab, then I simply hand her the private key material and I promise that I will never, ever, use that private material again. I mean - trust me, I'm a trustable guy right? A better way to achieve the transfer might be simply me updating "the control of S" to point to the new controller, and then letting the new controller rotate S's keys. After that dance I can no longer impersonate S - as is required by the S=C condition. That's one possible argument for separating S and C - and not one that hinges on the legal bindings to agency-capable external entities. It is not yet clear to me, however, that strictly setting S=C doesn't have a solution that avoids the whole "transfer of impersonation" - perhaps P. Jeab generates new material, hands me the public-only part, and I update the DID-document with new public key information so that the impersonation ability transfers seamlessly. Perhaps that dance could be enshrined such that the simplification of S=C and the removal of C from the spec completely is a win. One thing that I do suspect is that enshrining a distinction between S & C in the firmament of the DID-Document itself requires one of two options - either There is a definite win if S=C is firm enough to drop the entirety of the controller construct - but if there is even one use case where S!=C is mandatory, then we're in the above territory and (b) seems like the only reasonable answer. |
|
@ewelton You confirm my worry of "answer d)", that is, we leave all of this to the implementers/market. A possible consequence is that much of this signing/authentication/delegation/representation stuff will be replicated both in DID and VC/VP, leaving the market confused and impeded about the non-interoperability of those. As for the cat example, I don't see why my cat should have private keys associated to it. My vet will put any cat to sleep, as long as the person bringing it in pays for it. There is no proof of ownership required, nor the consent of the cat. So the cat example feels like a red herring to me. Anyway, this discussion may be derailing. It will be good to continue the discussion in Amsterdam next week. Perhaps this should be a discussion for a joint meeting of DID-WG and CCG-WG? |
rhiaro
added
pr exists
|
A note has been merged saying:
I don't know if this reflects consensus (the PR didn't get review from most people in this thread) but if there are no objections to that this issue can be closed soon. |
rhiaro
added
pending close
I believe that has consensus... at least, that's how DID Methods today seem to be using (or not using) the |
I haven't had time to look into better language than this. But I do feel like it needs further tweaks, otherwise it's an interop failure. To me, it's like saying " "If Something like this creates a separation between expressing the semantics of subject/controller (which should be the same across all DID methods) and the mechanics for actually changing it, which are DID method specific. DID methods should not allow expressing a |
+1, that's a great way of phrasing it. |
|
@dlongley suggests
Unfortunately, this is not correct. The DID Subject is determined by the root of authority, NOT the other way around. This is a fairly fundamental to the authority architecture of DIDs themselves. A controller controls the DID Document and their intent about the Subject shapes the rest of any identity built around that identifier. The Subject may not even be involved in the DID Document, especially if the subject is inanimate or incapable (child, invalid, etc.). Ultimately, it is always the DID Method that determines the actual root authority (the ability to change the DID Document) and while we can require that the controller represent the root authority if present, I don't believe we can ascribe anything if the value is NOT present. If what you mean is "when the value of the controller property is not present, the controller value should be treated as the same as the "id" property of the DID Document", that I can support. But, that begs the question of what "controller" means when the DID Method is not required to represent the root authority in that manner. If the subject is a dependent (unable to exercise their own cryptographic authority), is the proposal that the controller value MUST be present and MUST be the same authority as recognized by the DID Method for changes to the DID Document? |
Yes, that. I'm happy for the language to reflect that.
Yes -- but I think there's room for a caveat where, if no verification methods are present, it is unnecessary to express a controller value. |
|
I'll make another PR to update the language |
|
@rhiaro Just a heads up that my proposed Appendix A is something you'll probably want to reference in your PR on this topic. I plan to submit it this week. But don't wait on that—we can always add a reference to it later. |
kdenhartog
added
ready for pr
rhiaro
added
pr exists
|
This will be closed when PR #371 is merged, which contains further discussion and is just about ready. |
rhiaro
added
pending close
|
No comments since marked pending close, closing. |
By default, the DID subject is a controller of its own DID (this is not stated in the spec but I think everyone agrees on this).
When there is explicitly a
controllerproperty at the top level of the DID document, pointing to a controller other than the DID subject, does this add to a list of controllers which still includes the DID subject, or does it override such that the DID subject is no longer considered a controller?If there is a case for both or the latter of these being an option, how could it ever be shown that the DID subject is not a controller of the DID?
The text was updated successfully, but these errors were encountered: