When is a DID subject not a DID controller (if ever)?

[rhiaro]

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 controller property 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?

[TallTed]

I think there are cases for both scenarios, which could be covered by something like --

• When controller property is not present, the DID subject is the only controller of the DID.
• When controller property is present, its value identifies all controllers of the DID. If the DID subject is not included therein, the DID subject is not a controller of the DID.

[ewelton]

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:

The Subject is the entity referred to by the DID, which can be literally anything: a person, an organization, a device, a location, even a concept. Typically, the Subject is also the Controller, but in cases of guardianship, agents (human or software), and inanimate Subjects, this is not possible. As such, the Subject has no functional role. When the Subject is, in fact, the Controller, we consider the action to be taken by the Controller on their own behalf as the Subject. When the Subject is not the Controller, the Controller is said to be taking action on behalf of the Subject, such as when an employee manages a DID on behalf of their employer or a parent uses a DID on behalf of their child.

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.

[jandrieu]

Responding to @rhiaro's opening:

By default, the DID subject is a controller of its own DID

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.

[jandrieu]

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?

[ewelton]

@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.

[jandrieu]

@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

[TallTed]

@jandrieu

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.

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").

[jandrieu]

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:

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?

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.

[TallTed]

The controller property may list one (or more?) DIDs whose Controllers should be afforded the privileges of controlling the current DID Document.

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.)

[rhiaro]

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: https://github.com/w3c/did-core/pull/123/commits/189e5bd8aab97eadd801ea9a2e401a7573eaf527). 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 controller property.

If a DID and corresponding document is generated and there is no top level controller property, and the DID subject happens to be a cat, we would have to assume that document will never change, because there is no authorized entity capable of changing it.

I still feel like I'm missing a part of the picture here though.

[ewelton]

@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.

[dlongley]

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 foo is any entity that is specified, implicitly or explicitly, as having root authority to express information in the DID Document associated with foo. So how is a DID controller specified?

1. A DID Document that has no controller property has an implicit DID controller that is identified by the DID, i.e., the same entity as the DID subject.

2. A DID Document that has a controller property has one or more explicit DID controllers, identified by DIDs, expressed in the value of that property. If the DID subject is intended to be only one a DID controller amongst several, it must be specified using this property just like any other DID controller. If the DID subject is not specified but other entities are, then the DID subject is not its own DID controller.

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 capabilityInvocation) in its own DID Document. Note that these systems may allow DID Documents to be created that are immutable because they contain no appropriate verification methods and they do not specify a controller that references another DID subject with appropriate verification methods.

[ewelton]

@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?

[TallTed]

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.

[Oskar-van-Deventer]

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?

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

[iherman]

Re-reading part of the core spec...

• The controller key appears to be defined in §6.5 Authorization and delegation. Getting back to @rhiaro's question, it certainly needs further explanation. For example, it is not clear from the definition whether there can be only one controller or several...
• The same key also appears in §6.3 Public Keys. What does that exactly mean in the context of keys? Is the same notion or something else? Is it singular or plural? How is it related to a document level controller if one is defined?

I do not have a clear answer to these questions... :-(

[iherman]

I just realize that my question is also closely related to https://github.com/w3c/did-core/issues/4 (e.g., https://github.com/w3c/did-core/issues/4#issuecomment-544637669)

[jandrieu]

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

If you dereference the DID, you get a DID Document that includes information about the DID subject.

I believe this is entirely the wrong framing. A DID Document, following the language of RFC3986:

URI "resolution" is the process of determining an access mechanism and the appropriate parameters necessary to dereference a URI; this resolution may require several iterations.

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.

[ewelton]

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

That is, a DID Document contains the information you need to securely interact with the Subject,

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.

[Oskar-van-Deventer]

Indeed wonderful points!

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.

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

[ewelton]

@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:

When there is explicitly a controller property 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?

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 ;)

[Oskar-van-Deventer]

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? One of the things that we need to understand, is what the impact of any conclusion to discussion, or absence thereof, would be on the did-core document and its associated terminology.

[dlongley]

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 S never equals C (as this eventually ends in a contradiction through infinite recursion) and, as noted, it is insufficient for the use cases to say that S always equals C.

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".

[ewelton]

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, if the C information is present, then C can update the document, but S can not if the C information is absent, then S can update the document

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.

[Oskar-van-Deventer]

In terms of the opening question then, if the C information is present, then C can update the document, but S can not if the C information is absent, then S can update the document

This semantic fuzzyness worries me. What is the nature of C and S? a) pieces of hardware and software that performs the actual operation of putting electronic signatures; b) flesh-and-blood human beings that operate a); c) natural and legal entries that may either equate b) or are represented by b); d) any or all of the above

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.

[ewelton]

@Oskar-van-Deventer I probably have this all wrong, but this is my current understanding:

Entities like these

a) pieces of hardware and software that performs the actual operation of putting electronic signatures; b) flesh-and-blood human beings that operate a); c) natural and legal entries that may either equate b) or are represented by b); d) any or all of the above

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

• inanimate objects which are uniquely identified, about which VCs & ZKPs can provide information
• animate objects that are "sentience-challenged" - cats, plants, the occasional president
• abstract objects, such as concepts and roles

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:

• A DID Is effectively a sequence of integer pairs <S,doc_n> where doc_n+1 = update(doc_n), for n>=0 up to some final n, such that doc_n = null for all n > M
• The crypto-material about S is used to do things in the ballpark of
  • correlate public VCs
  • authenticate
  • engage ZKPs
• Update to the DID-doc itself is "executable" only by C - and this is guarded by the crypto-material associated with C

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 a) completely defining all possible S/C relationships completely, a-priori, in the specification, and modeling them explicitly in an abstract data model b) pushing the S/C binding into a "mechanism of systematic extension/flexibility" whereby different terms-and-conditions of S/C relationships could be managed - as in "this DID-document includes Controller tech"

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.

[Oskar-van-Deventer]

@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?

[dlongley]

@ewelton,

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.

This has been considered in the past and rejected on the basis that an indirection is much more powerful and avoids potentially nasty economics. For example, a controller of 1000 different DIDs that needs to do key rotation will pay for one update when using the indirection approach (DID as a controller) and it will pay for 1000 updates when not using that approach (key material directly as a controller).

Regarding what someone may or may not put into a DID Document: I think it's also important to remember that the DID core spec is a data model spec and that it is not a legally binding document. This means we can only talk about what the things mean that are in the spec and what to do with any things that show up that are not understood (i.e., you should ignore them). We can't prevent people from adding things in their systems that we may prefer that they would not. It also means that there are protocol level considerations that are simply out of scope.

All we can do here is say "This is our model, these are the things we agree on, what they mean, and how to represent them; if you use any of these things that we talk about, this will be the expectation." Further restrictions on how to resolve a DID to an authoritative DID Document (including whether or not you can do so publicly vs. requiring some form of authorization, etc.), any shared rules for resolution, and so on -- are in the domain of either DID resolution or DID methods. We should also do our best to remember that economics will be the real driver behind how the spec is used and that we won't think of every possible interesting innovation... we should just make room for them to occur.

[jandrieu]

@dlongley It's not clear to me that the group has endorsed an extensibility model, which to my mind is at the core of the JSON/JSON-LD question.

If we allow extensibility, then, yes, we can't keep people from putting odd things in a DID Document, but we could restrict it in any number of ways. For example, we could require that any additions are in a specific property. Or just that one can't overwrite existing standard properties.

We could also choose that extensibility beyond the standards process is inappropriate.

In any case, the specification DOES specify what makes a conformant document. That's the whole point of a standard. So, the idea that it "isn't a legally binding document" is a strawman. It's not legally binding, but it does define conformance.

[dlongley]

@jandrieu,

It's not clear to me that the group has endorsed an extensibility model, which to my mind is at the core of the JSON/JSON-LD question.

It seems to me that people in both camps still want extensibility. Regardless, humans can and will extend whether or not we say how it should best be done in the spec. If we don't say how it will be done in the spec, it will just be much more likely to be done in a way that does not promote interoperability. Again, this cuts to my point that we, as spec authors, do not control the behavior of the community, we merely provide advice for how to best achieve interop. We don't get to "allow" or "disallow" extensibility no matter how much we shout it into the wind. Yes, we get to define conformance, but if what we put out there doesn't provide for what people need it to do, people just won't conform and the spec won't get uptake.

[cboscolo]

wrt to extensibility @jandrieu wrote:

For example, we could require that any additions are in a specific property.

Assuming the community decides not to require JSON-LD for extensibility (my vote), I strongly urge us to take this approach as documented in this issue: https://github.com/w3c/did-core/issues/143

I would prefer that the "controller" property be removed from the DID-core spec because I think it will create more confusion and interop problems than it solves. But we decide to keep it, then I also support @talltree's suggestion to make the controller field optional. (https://github.com/w3c/did-core/issues/122#issuecomment-558342991)

[jandrieu]

@dlongley No one is saying that a spec controls anything. What we are saying is that the spec defines what is or isn't acceptable in a conformant document.

Throwing up your hands and saying "we, as spec authors, do not control the behavior of the community" is a non-sequitur. Nobody said that we could.

If you don't want a standard, then we can move on. But since we are here to define a standard, we absolutely DO control what is and is not conformant. That's what we are talking about here.

The more salient point of conformance is that if conformance is too much of a burden, implementers will simply use non-conformant documents and those non-conformant documents may or may not be accepted by others in the ecosystem. That's an argument for making conformance as simple and straightforward as possible. It is NOT an argument for pretending that defining what does or doesn't go in a DID Document is a futile effort.

How we do extensibility is at the heart of this debate. If everyone wants it, great. The JSON-LD camp has a specific method for doing that. I have not heard any proposals from the JSON-only camp about how to do extensibility.

What I'm looking for is a proposal from those who favor pure JSON is two things.

(1) Do you want extensibility at all? Or are you advocating that extensions to the data model MUST go through a future standardization process? (2) If you do want extensibility, how do you propose that will work? How does one add a property to a DID Document in a way that doesn't break interop?

[ewelton]

@Oskar-van-Deventer I still think this is on point and I think I what we are stuck on is central to the concept of Subject - see #4 . Also consider the text in the introduction section of the current editors draft of the DID-core spec

In a decentralized identity system, entities (that is, discrete identifiable units such as, but not limited to, people, organizations, and things) are free to use any shared root of trust.

the case I hoped to highlight was "discrete identifiable units" which includes all manner of "things" - and specifically things that lack even pseudo-agency. Such things might be the subject of a Verifiable Credential - which, from the latest editors version of that spec includes this note

NOTE As of this publication, DIDs are a new type of identifier that are not necessary for verifiable credentials to be useful. Specifically, verifiable credentials do not depend on DIDs and DIDs do not depend on verifiable credentials. However, it is expected that many verifiable credentials will use DIDs and that software libraries implementing this specification will probably need to resolve DIDs. DID-based URLs are used for expressing identifiers associated with subjects, issuers, holders, credential status lists, cryptographic keys, and other machine-readable information associated with a verifiable credential.

The case of using Verifiable Credentials to assert medical or insurance information about, for example, a cat, would - by your model, require a New Form of Identifier to use as the subject - specifically because of thre limitation you are imposing on the "kinds of allowable subjects of DIDs". It is worth noting that there would be no way to enforce the rule that "A DID Subject must have a reasonable need for cryptographic material and the capability to process and manage it"

What I am focused on, here, is the difference between S & C in the context where

• I am using Verifiable Credentials to manage information about a Subject
• I want to identify the Subject using a DID
• The Subject is fundamentally incapable of controlling the DID

This brings us to @dlongley 's point above - namely that it is a really useful structure to have the controller simply point to a DID. If I have 9 cats, each with a DID, and 9 VCs which identify those cats as their Subject, then it makes sense to have a 10th DID which is the controller of the other 9 DID documents.

Furthermore, each of the 9 cats might identify a service_endpoint - perhaps one that points to the chip-registry for the identification chip with which they are implanted (this is a well established industry). One of my cats is chipped in Portland, OR - and they have extensive medical records there. One has flown around the world - cleared customs in multiple countries - and has extensive customs-and-border documentation. Saying that she should not have access to DIDs for use as a Subject of Verifiable Credentials seems pretty severe - and consider a DID embedded in one of the many blockchain-based supply chain solutions out there. I personally know bags of rice that have DIDs. I want to live in a world where I can use a QR code on my Starbucks coffee to trace the entire supply chain - where everything along the way has been tagged with DIDs.

In these cases the S probably does not need any cryptographic assets - that is optional. And the use case for that DID-Document is not establishing layer-2 communication with an agent that digitally represents the cat or the individual bag of rice - both of which may still advertise service_endpoints.

At the center of this discussion is the ability of the DID-document to reflect a wide range of use-cases - this is similar to, but not the same as extensibility. Right now, the one-sized-fits-all-use-cases model for DID-Documents only has one knob to fiddle with in terms of adaptability, and that is making fields optional. The "nature of the DID-document" can be roughly approximated by looking at what fields are present and using that to make an educated guess about how to process the document.

One optional field that provides some true extensibility (rather than just knock-out) is the method-specific data @cboscolo mentions (issue #143). While I believe that we definitely need method-specific data, doing so requires each method to provide a data-model for the method specific data.

I believe this is on-topic, because we are addressing "when is S != C" - and above are several descriptions of cases where S != C. In highlighting these cases we have drawn on use-cases which also highlight a drawback of the "one-sized-fits-all" DID-model resulting from an over-focus on the "Layer-2 bootstrap problem" - that problem is critical, and we have some really fantastic solutions for it - but the space of DID subjects is larger than "governmentally authorized legal entities" and includes S's which do not have the Layer-2 bootstrap problem.

And I really like @jandrieu 's comment here:

How we do extensibility is at the heart of this debate. If everyone wants it, great. The JSON-LD camp has a specific method for doing that. I have not heard any proposals from the JSON-only camp about how to do extensibility.

What I'm looking for is a proposal from those who favor pure JSON is two things.

(1) Do you want extensibility at all? Or are you advocating that extensions to the data model MUST go through a future standardization process? (2) If you do want extensibility, how do you propose that will work? How does one add a property to a DID Document in a way that doesn't break interop?

The S=C vs. S!=C issue, highlights a deficit in the one-size-fits-all data-model approach, and our responsibility as specification creators, is to make sure that our solution is coherent, consistent, and implementable.

The solution I would prefer - and this is purely personal preference and bias - would look like this

• just stick w/ JSON-LD and leverage
  • the fact that @context is an array
  • we have computers, which are helpful at making all sorts of format transformations
  • contexts do not need to be fetched 'from the web'
• use @context to allow the DID-Document to announce its semantic (I Am Gumby Dangit!)
• create multiple contexts for different 'capabilities' of DID-Documents - for example
  • controlled passive object (requires controller->DID, has limited identifying crypto)
  • endpoint bootstrap (Advertises service_endpoints, etc.)
  • uses KERI for key mgmt
  • authentication viable (supporting DID auth)
  • simple proxy (a DID which is kept for residual purposes, pointing to another)

At RWoT 9 in Prague I was very excited because I felt we were on the verge of the above - and I thought "wow, DID's are almost done - fully featured, extensible, safely processable, semantically clear" - and I am somewhat saddened by the shrinkage in the scope and viability of DIDs because we want to support Forth, Pascal, and punch-cards.

So while I am very open to other solutions - I see value in the concerns of interoperability with other ecosystems - like JOSE - and I think there is value in exploring that and building the right data model specification that can capture these variations and provide alternative implementations.

I am less open to building a solution restricted such that:

• S must ONLY represent legal entities (how could you enforce this?)
• DID-documents can ONLY be used to bootstrap communication with agents
• DIDs are ONLY controlled by S (so guardianship and delegation require impersonation)

My goal in exploring S=C as an option was because it opens the door to a much simpler DID-document data model - and we could get rid of method-specific variation as well. I want to point out that while forcing S=C enables vast simplifications to the model - those simplifications are not free, they cost us in terms of the scope of DIDs.

I think, in terms of this issue, we have addressed @rhiaro 's opening question:

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 controller property 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?

We have

• discussed cases where S!=C
• discussed cases where S may not have cryptographic information
• identified the value of C being a reference
• established the need to build a "web of linked DID-Documents"

And I have proposed that we can address the question of "what happens when you have S + crypto & C" through using "multiple contexts" to break the DID-Document into a set of features, each of which is semantically modeled by a JSON-LD context which, when taken as an array of values in a DID-Document allow the DID-Document Controller to assert what the DID-Document is saying to the world.

[jandrieu]

@rhiaro Could you clarify your original question? We aren't sure if we addressed it or if we all got distracted by side-issues.

[rhiaro]

The text around the definition of controller still needs clarifying, but having re-read through the thread and I think there might not be complete agreement on which direction to clarify things. Here are some multiple choice questions to try to figure that out.

1. The controller property is optional. When there is no controller property:

   • a) the implicit controller is the DID subject. If the DID subject is an entity not capable of exerting control, so be it.
   • b) there is no controller. Operations that could be carried out by the DID controller according to the DID's method will never be able to happen.
   • c) read the appropriate DID method spec to determine what the value of controller can be implied to be.

2. The DID subject MAY be the DID controller (for the same DID). When the controller property is present, the DID subject is known to be the DID controller:

   • a) only if the DID of the subject is the value of, or included in a list of values of, the controller property.
   • b) always, in addition to any explicit value(s) of the controller property.
   • c) In cases determined by the appropriate DID method spec.

Please choose a/b/c if you have an opinion, and I'll write a PR to cover the broadest agreement, and we can move focussed debate there.

@dlongley's response was a clear answer to the question, though I don't know if the specifics have consensus. Per the questions above, this is equivalent to 1a) and 2a), as is @TallTed's first response.

1. A DID Document that has no controller property has an implicit DID controller that is identified by the DID, i.e., the same entity as the DID subject.

2. A DID Document that has a controller property has one or more explicit DID controllers, identified by DIDs, expressed in the value of that property. If the DID subject is intended to be only one a DID controller amongst several, it must be specified using this property just like any other DID controller. If the DID subject is not specified but other entities are, then the DID subject is not its own DID controller.

[iherman]

I would expect that very few DID document will be authored by humans directly; most of them will be authored by specialized tools. If so, then what really counts for me is spec and implementation simplicity. This motivates my choice:

1.b When there is no controller property then there is no controller. Operations that could be carried out by the DID controller according to the DID's method will never be able to happen. 2.a When the controller property is present, the DID subject is known to be the DID controller only if the DID of the subject is the value of, or included in a list of values of, the controller property.

[jandrieu]

This property is horribly named.

The DID Controller is not the entity specified by the controller property.

ALL DIDs have Controllers. Not all DID Documents have a controller property.

When the property is absent, it does NOT mean that the controller==subject, because that is not a provable proposition.

The point of the controller property was to delegate control of a DID to another entity via a different DID.

All DID methods provide a means to perform CRUD operations--those actions "that could be carried out by the DID controller". The means of control may or may not be represented in the DID Document. We have never proposed, for example, that a DID Method must respect the value of Controller in the DID Document. Which means the answer to 1 must be (c).

None of the answers to 2 address the commonly understood situation when the document is controlled by someone other than the subject. All you can get is that the entity that actually controls the DID wants to assert that the subject is the controller. But you can have a subject that is inert, which means that the subject is not the controller, regardless of how much the controller wants to assert it. For example, the subject of did:example:xyz is the Moon. The controller is the party that actually controls the crypto that can update the DID (and presumably used to create it). However, even if the controller property lists the Subject DID as controller DOES NOT make the Moon the controller. There remains some entity--who is NOT the Moon--who is in fact the controller.

I suggest we use a different name for this property. The name itself is confusing. With a more finely scoped name it might be easier to distill exactly what it means without confusing it with the role name of the same lexical value, "Controller".

[ChristopherA]

@jandrieu wrote:

This property is horribly named.

Not only that, it has all gone the wrong way and we've lost something important.

In the early drafts of DIDs, we had two kinds of keys, control keys, and ownership keys. We knew both of these words were inaccurate, and in fact swapped them at least once. But the ideas was that we had some keys that you could do a "proof-of-control of the private key", which was needed for signatures, which was separate from the "the ultimate owner key" which could be used to change the list private keys that you could do a "proof-of-control" of.

This distinction still exists in the BTCR method, the revealed-in-the-blockchain transaction public key is used in signing as it shows "proof-of-control" of the private key associated with it. This is what is in the DID document.

However, there is a key that is not revealed until it is needed, that is the ownership key. On the blockchain it is not public — it exists solely as hash of the public key. You can somewhat prove that you have the public key associated with that by revealing the actual private key, but it doesn't mean a lot as once you do so the recipient can do the same. I would argue now (I didn't back then) that this hash, or it's public key, shouldn't even be in the DID document. Only the blockchain can actually accept it, and once the transaction is confirmed, there is a new a new "proof-of-control" key.

I definitely don't want to return to those terms (controller/owner), but I do worry that we are making public by putting what was once the owner key into the DID document, which is unnecessary except in some rare non-blockchain cases like did:peer. I worry that we are conflating these two uses, which the BTCR team carefully keep apart. Bitcoin architectures in general avoids key reuse and too early reveal of signatures and even public keys, as this can allow for censorship and privacy leaks.

-- Christopher Allen

[ewelton]

In the reference above I noted that https://github.com/w3c/did-core/issues/122#issuecomment-599525786 appears mandatory in order to allow DIDs to refer to passive, persistent objects, incapable of change.

[dlongley]

Is this issue actionable in any way? Do we need to keep this issue open, is there an action someone wants to see happen to close it out (such as proposing specific concrete text based on responses here in the thread)? If not, we should close this issue.

[kdenhartog]

I'd think we could probably use a bit more non-normative language (either through adding details through definitions or a paragraph to address the topic) on did subject vs did controllers. This seems to be one of the areas where we have quite a bit of tribal knowledge built up.

[rhiaro]

I agree, the language in the spec does not make clear what is argued for in any of the comments in this issue. I'll make a PR. I might get it wrong, but then we can work on it in the PR.

[rhiaro]

A note has been merged saying:

If the controller property is not present, the DID controller can be determined by consulting the respective DID method specification. It cannot be assumed that the DID subject is also the controller of its own DID, nor can it be assumed that only entities identified by DIDs present in the value of controller are capable of exerting control over the DID in question. Similarly, DID methods are not obliged to respect the value of controller and can specify means for updating the DID document that are unrelated to the controller property.

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.

[msporny]

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.

I believe that has consensus... at least, that's how DID Methods today seem to be using (or not using) the controller property.

[dlongley]

If the controller property is not present, the DID controller can be determined by consulting the respective DID method specification. It cannot be assumed that the DID subject is also the controller of its own DID, nor can it be assumed that only entities identified by DIDs present in the value of controller are capable of exerting control over the DID in question. Similarly, DID methods are not obliged to respect the value of controller and can specify means for updating the DID document that are unrelated to the controller property.

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 "controller is scoped to the DID method and meaningless on its own". I don't think that's good and I don't think that even reflects reality with most DID methods. I would prefer to see something more like:

"If controller is present, it expresses the root of authority for information expressed in the DID Document. If controller is not present, then the DID subject represents the root of authority. To determine how the DID Document can be changed, you must consult the DID method. It is possible that the DID method will indicate that the DID Document can no longer be changed beyond whatever its present value is."

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 controller in a DID Document unless it is intended to convey an alternative root of authority over what is expressed in the DID Document.

[dmitrizagidulin]

@dlongley

"If controller is present, it expresses the root of authority for information expressed in the DID Document. If controller is not present, then the DID subject represents the root of authority. To determine how the DID Document can be changed, you must consult the DID method. It is possible that the DID method will indicate that the DID Document can no longer be changed beyond whatever its present value is."

+1, that's a great way of phrasing it.

[jandrieu]

@dlongley suggests

the DID subject represents the root of authority

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?

[dlongley]

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.

Yes, that. I'm happy for the language to reflect that.

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 -- but I think there's room for a caveat where, if no verification methods are present, it is unnecessary to express a controller value.

[rhiaro]

I'll make another PR to update the language

[talltree]

@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.