Closed dhh1128 closed 1 year ago
Tagging @peacekeeper and @csuwildcat and @OR13 and @TelegramSam and @swcurran . This is my proposed update to peer DIDs that would make support for initial-state
official. My intention was to align as much as possible with how initial-state
is imagined to work in ION and so forth -- but the docs I could find about that seemed a bit stale. So I may have diverged slightly. Can you review?
Here is my documented signed-ietf-json-patch
... https://github.com/decentralized-identity/did-spec-extensions/blob/master/parameters/signed-ietf-json-patch.md
its got test vectors and a spec, and it lets you decide how you want to interpret a "mutation" to a did documents, represented as a URI...
initial-state
is of undefined type... and is therefore... pretty hard to document well...
@dhh1128 I suggest considering signed-ietf-json-patch
instead, or... using that spec, to generate a value for initial-state
... which would be legal, since initial state has not defined value.
@OR13 : Converting the deltas strategy of peer DIDs to use signed-ietf-json-patch
might be a good idea, but I think it is out of scope for this PR. Let's discuss that as a separate change.
@OR13 I have opened https://github.com/decentralized-identity/peer-did-method-spec/issues/24 to track your suggestion about using signed-ietf-json-patch
. Are you okay with the merge, given that we're tracking that now as a separate topic?
@dhh1128 this PR has been sitting for some time, are there any blockers to merging? It's referenced in the DIDComm v2 implementer's guide, and we're looking to use it as the mechanism to share peer DIDs over DIDComm v2 messages, so it would be good to know if this is/isn't the direction the spec will go.
Thank you for the ping, @Moopli . I thought this had been merged. There is no impediment to doing so, in my mind.
@dhh1128 @kdenhartog we're preparing to release a new version of afgo which uses peer DID initial-state for sharing peer DIDs in DIDComm V2; it looks like this fell through the cracks again, any chance it can be wrapped up and merged, if opinions on it remain the same?
I resolved the merge conflicts and can now merge this. However, the reason this languished so long is that @TelegramSam wrote a different algorithm for generating a numeric basis (numalgo=2
; see "Method 2" under https://identity.foundation/peer-did-method-spec/index.html#generation-method) that allows someone to specify an initial state (extra keys, endpoint) without using a query parameter. This makes the initial-state
stuff partly redundant. The new algorithm is in the implementation of peer DIDs on pypi and the one on Maven Central. So my question is: do we still need this? The feature it unlocks is only different from method 2 in that it can be used with dynamic peer DIDs -- and I'm wondering if anybody actually does that, given that KERI handles dynamism in a more generic way that provides the same guarantees.
I can't really comment if this is still needed considering the latest developments in did:peer and KERI, but wanted to mention that we switched to camelCase for DID parameters (including initialState
), see here:
Thanks for the reminder, @peacekeeper . I have updated the PR to use camelCase.
I closed this because it appears that we never got consensus, and it is now very old.
Signed-off-by: Daniel Hardman daniel.hardman@gmail.com