Change how the authorized keys are published and used

[swcurran]

I've updated the spec. to include the changes we discussed last week with regards to authorized keys, SCID generation, and pre-rotation. While I generally followed what we discussed, I updated the SCID generation in a way I think makes the most sense, varying from what we discussed. Please review and let me know what you think.

updateKeys is a list of did:key DIDs in the parameters, as we discussed.

The existing SCID generation was based on just the DIDDoc with placeholders. I changed that to make it the Log Entry (minus the Data Integrity proof, of course), but including the parameters, the versionId, versionTime and "value": "<DIDDoc>" with placeholders (literal string {SCID}) wherever it is needed. It seemed easier to understand to use the entire entry vs. just a subset.

@andrewwhitehead - I also didn't do the SAID approach of using a ########... placeholder because I thought it would be a pain for the DIDDoc writer. It is much easier to just use the {SCID} placeholder, and to explain it, and really doesn't make any difference.

Pre-rotation becomes MUCH easier than what we had before. No more "detecting" key changes in the DIDDoc, and the hashing is just of the did:key DIDs, not the DIDDoc key reference entry data structure.

I really struggled over the description of what are the active authorized keys for the initial entry and subsequent entries. I'll probably try ChatGPT to see if I can make it better. Suggestions gratefully accepted...

[swcurran]

@brianorwhatever -- The comments you made were mostly tweaks to the wording. Does that mean you are more or less happy with the approach? Especially around the SCID generation?

[brianorwhatever]

I only briefly went through the scid generation and was pretty tired. I'm hopefully going to look at implementing it today so let's hold off on merging until after that

[swcurran]

Great. Definitely!

[brianorwhatever]

@swcurran I believe I implemented what is here in decentralized-identity/trustdidweb-ts#9 and it seemed to make sense. Take a look there and see if you agree I matched what's written here. Seemed like the SCID generation alg made sense. Interested in hearing @andrewwhitehead feedback

[swcurran]

Middle of the night thinking. I think the nextKeys array should not collect used/unused ones as I proposed. Rather, each instance becomes the current one, and the previously current set of hashes are dropped. I think a bad implementation could allow any nextKey to be reused, which would be a vulnerability.

The more general rule for (I think) any parameter is that the most recent value is the current one.

Reasonable?

[brianorwhatever]

I had just reached the same thought. Makes implementation easier as well 👌

[swcurran]

Good stuff. I'll update that. Makes the spec easier as well.

[brianorwhatever]

I think to differentiate we should use

updateKeys and nextKeyHashes

[swcurran]

I think to differentiate we should use

updateKeys and nextKeyHashes

Done.