decentralized-identity / peer-did-method-spec

A rich DID method that has no blockchain dependencies. The verifiable data registry is a synchronization protocol between peers.
https://decentralized-identity.github.io/peer-did-method-spec/index.html
Apache License 2.0
27 stars 17 forks source link

Add support for initial-state #23

Closed dhh1128 closed 1 year ago

dhh1128 commented 4 years ago

Signed-off-by: Daniel Hardman daniel.hardman@gmail.com

dhh1128 commented 4 years 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?

OR13 commented 4 years ago

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.

dhh1128 commented 4 years ago

@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.

dhh1128 commented 4 years ago

@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?

Moopli commented 2 years ago

@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.

dhh1128 commented 2 years ago

Thank you for the ping, @Moopli . I thought this had been merged. There is no impediment to doing so, in my mind.

Moopli commented 2 years ago

@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?

dhh1128 commented 2 years ago

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.

peacekeeper commented 2 years ago

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:

dhh1128 commented 2 years ago

Thanks for the reminder, @peacekeeper . I have updated the PR to use camelCase.

dhh1128 commented 1 year ago

I closed this because it appears that we never got consensus, and it is now very old.