Why isn't it possible to add `services` at creation time?

[lemoustachiste]

The type does not define services as a valid option: https://github.com/decentralized-identity/didwebvh-ts/blob/main/src/interfaces.ts#L122, and I think when I dug a while back into the code it didn't do anything with it at creation time (code might have changed though).

So it means, to add a #whois service for instance, we need to first create the DID and then update it.

Is there a rationale behind this design choice?

Thanks

[lemoustachiste]

while this exists in the update method:

https://github.com/decentralized-identity/didwebvh-ts/blob/main/src/method_versions/method.v1.0.ts#L384

It does not for create

[swcurran]

A did:webvh implementation should have no opinion on the content of the DIDDoc, other than to make sure the id parameter exists at the root, and in the initial version of the DIDDoc it and any other place where the SCID exists is set to the literal placeholder"{SCID}". Once the SCID has been calculated, the placeholders are replaced in the DIDDoc with the SCID for the DID.

I suspect you are seeing the service handling in the resolver because a resolver inserts the "implicit services" into the DIDDoc if not already present. So an input DIDDoc should absolutely be able to have a /whois service in it.

If the implementation is impacting the DIDDoc in any other way, it is a bug. I'm troubled by the existance of the list of attributes of a DIDDoc that you point out (https://github.com/decentralized-identity/didwebvh-ts/blob/main/src/interfaces.ts#L122). It implies to me that there is a finite list of DIDDoc attributes that can be processed, which AFAIK is not correct, as there could be extensions being used that is (correctly) unknown to a did:webvh implementation.

It brings up the need for an addition to the test suite we are creating -- defining the contents of the DIDDoc in the test scripts to make sure that we can test that an implementation doesn't impact a DIDDoc.

[swcurran]

Thinking about this more and asking questions I have this response.

The TS library does not currently support the DID Controller simply providing a DIDDoc on creation (or, on update for that matter). I think it should at least allow it on creation. To do that, the DID Controller would have to construct the DIDDoc with spec defined SCID placeholders (the literal string "{SCID}") wherever the SCID is present in the DIDDoc. During creation, the SCID will be determined and those placeholders replaced with the expected value.

An alternative is to do exactly what this issue is requesting -- a way to add services to the DIDDoc created by the TS library itself. This could be in addition to doing what I propose above.