As a did controller, I should be able to update any property of my did document.

[OR13]

As a sidetree method implementer, I should not have to create a new schema for each new property type.

[csuwildcat]

Thank you for capturing all the floating bugs that allude to this more general desire. First, I want to ask if you are comfortable with slightly tweaking the title to center on the protocol change itself and the implication. Given just about anything is technically allowed in a DID Document via random inclusion or context extension, I feel this Issue title should read: "Allow arbitrary properties and values to be written in DID operations" - this captures the protocol/outcome reality, vs merely one of the high-level user story outcomes that it implies.

Here is my proposal for making this possible:

1. We maintain protocol-operative keys with a set of strict protocol handling rules and op action types. This means that we would not hinge our handling of protocol-sensitive keys on whatever flavor of the day a DID Doc assumes, which is a proper separation/abstraction from the presentation format.
2. We add a custom property that allows the implementer to open up their implementation to an arbitrary data value, which they can subsequently parse and handle however they please in the reducer portion of the protocol/code.
3. We create a process for codifying new op action types in the specification, for any new op action types we may want to add to the specification in the future.

This creates a flexible mechanism that allows an implementer to basically make their implementation a free-for-all if they choose, while allowing other implementers a mechanism to make additions in more statically defined ways.

[OR13]

I think my title is more descriptive of the actual impact to method implementers.

I agree with your proposed solution, let me rephrase it:

1. Sidetree protocol will maintain a list of allowed did operations (just like the did core spec).
2. Specific method implementations can choose to use a method specific operation type to enable users to control all properties of their did document, for methods that want to allow that (this is equivalent to defining what "update" means in different methods).
3. If you want to add new operation types to sidetree you will need to get the sidetree authors to approve your operation type... pretty much exactly they same as adding a property to an @context from an interop perspective.

I think this is a tractable solution, I do worry that we are perhapse trying to do the same things as the did core spec, by adding lots of definitions to the sidetree protocol... that won't lead to interoperability amongs anything other than sidetree based did methods.

[csuwildcat]

Let me provide some further details to clarify some fundamental assumptions/reasoning:

"I think my title is more descriptive of the actual impact to method implementers." - as a user story, it is fine, but what lies beneath are the dragons of systemic/economic viability implications. We will at least need to heavily warn about this implementer choice in the specification.

Responses to your numbered points:

1. "Sidetree protocol will maintain a list of allowed did operations (just like the did core spec)." I would say it this way: "The protocol spec will codify a list of required base operation types, which are exclusively intended to abstract protocol-sensitive functions away from the output data format, so that the integrity and logic inside the protocol code does not depend on a format that can change beneath it."

2. I would think of it in these terms: "Aside from protocol-operative keys, which MUST be abstracted from the presentation format and handled in a specified way, specific implementations can choose to leverage an open field that allows them to allow/include an arbitrary object/blob they operate on in whatever way they choose." - This is to cleanly separate the list of spec-required and spec-optional standard set of operation abstractions.

3. Operation type abstractions may be upleveled as standard op types if the community feels some aspect of the underlying DID Document is 1) stable enough to warrant it, and 2) is used by enough people that it should be more concretely codified.

"I do worry that we are perhapse trying to do the same things as the did core spec, by adding lots of definitions to the sidetree protocol" - we're not doing the same thing, we're allowing for a set of concrete abstractions for certain DID Document functionality as and when that functionality becomes stable/understood enough to do so. Even then, they are optional - the only required set is for protocol-operative keys, because that must be precise from implementation to implementation.

[OR13]

Even then, they are optional - the only required set is for protocol-operative keys, because that must be precise from implementation to implementation.

This is the key bit.

We need to do a better job of describing how we are handling interoperability in sidetree, because just describing public keys is not enough to get DID interoperability... and if that's not the objective, I think we should define the goal of sidetree better.

What layer enforces did core interoperability, sidetree protocol compliance, or did methods that use sidetree protocol?

If its the latter, than sidetree protocol can be used to create anything that is built on an authenticated CRDT, not just did methods.

Are we saying that its up to method implementers to ensure did core compliance, or do they get that by using sidetree correctly?

[OR13]

We are addressing this on https://github.com/decentralized-identity/sidetree/issues/368

closing.