How is the initial identifier for an object created?

[swcurran]

In defining did:webvh (formerly did:tdw), we included the definition of a "self-certifying identifier" (SCID) as part of the inception event for the log. The SCID serves as a stable identifier for the log, so that if the actual DID changes because the web location of the DID has to change, the SCID remains the same, and the log can still be verified.

I wonder if this spec. could benefit from this same concept.

[msporny]

I wonder if this spec. could benefit from this same concept.

The spec is agnostic to how the state machine works and defers that behavior to the application specs. We do use the concept of a SCID in this application spec:

https://digitalbazaar.github.io/cel-spec/#example-example-of-a-did-document-that-has-added-a-verification-method

Note that the DID Document id value is did:example: in the create operation, but then is magically did:example:zQmQoeG7u6XBtdXoek5p3aPoTjaSRemHAKrMcY2Hcjpe3jv in the update operation. You could just replace did:example with {SCID} and you'd have feature parity with that part of did:webvh.

All that said, we left SCIDs to the application layer that would build on top of the CEL spec. The CEL spec is agnostic to how the state machine processes the events and operations in the log, among two other things:

https://digitalbazaar.github.io/cel-spec/#application-specifications

[brianorwhatever]

I could see a world where you call the first proof hash the identifier for an inception event. I guess how would you know which proof is the first. Does it hurt to have multiple identifiers?

I guess what I'm saying is proofs are essentially identifiers to the documents they secure.

[msporny]

I could see a world where you call the first proof hash the identifier for an inception event. I guess how would you know which proof is the first.

My intuition is that if we try to pick one way to generate the "initial" identifier, spec writers for applications will complain. For example, I expect various DID Methods to vary how they generate that initial hash, or more importantly, rebel if we tell them how to do it. :)

This is why the spec delegates how the state machine is built to the application. Some people will use a series of full blown JSON objects in their events. Others will use JSON objects + JSON patches. Others will use a list of PDF files... others images, sound, video, MIDI files, etc. Pushing the semantics at the log / event layer, down into the state machine is probably the wrong thing to do, architecturally. It feels like a layer violation that makes it difficult for the application authors to make independent decisions.

Does it hurt to have multiple identifiers?

Probably. :)

I guess what I'm saying is proofs are essentially identifiers to the documents they secure.

There's more nuance there, IMHO. A proof secures /something/, usually an input hash... but that input hash might not be the only thing the proof is securing. For example, in Data Integrity, the proof also secures the input parameters to the proof itself. In the ecdsa-xi-2023 cryptosuite, it secures two input hashes. So, what hash is being secured matters and you have to make sure that the way you do that doesn't accidentally create a post-quantum issue. Cryptographic hashes are post-quantum resistant... elliptic curve signatures are not. How you mix the two matters, so we can't just say "Just use the proof".

[swcurran]

My intuition is that if we try to pick one way to generate the "initial" identifier, spec writers for applications will complain.

It depends on how much you are willing to put into spec about what the event MUST have. Right now, you just define operation and previousEvent, but requiring a SCID in the first entry, defining how it is generated that is agnostic to the rest of the event content (much as previousEvent is defined, BTW), and “encouraging” (requiring?) it to be used in the ID of the log itself (e.g. in the URL, etc.) would be valuable — especially if you make the log portable.

The SCID is the true/pure identifier for the log. The URL published/passed to consumers is a combination of the identifier (SCID) plus how you find the log. The nice thing is that allows you to move the log location (how to find it) while retaining its verifiable identifier (the SCID) and verifiable end-to-end history.

[relves]

A standardized independently verifiable tamper-evident log that doesn't rely on blockchain is sorely needed and I'm excited to have come across this effort.

IMHO, with a prescribed SCID style solution, these logs could have a reliable, unique, stable, and cryptographically bound identifier that would be very useful for referencing and making public commitments to the log itself. Would including this in the spec preclude applications from layering their own identification schemes over top if desired?

[bumblefudge]

I like @swcurran 's point about infrastructure (or domain apex, in a more server-bound implementation) being pluggable/portable/swappable if the longer-lived SCID part is primary and everything else can be a verifiably mutable property... seems a strong argument for making SCID-identifier a CEL requirement rather than an optional extension?