update namestring generation

[kdenhartog]

@dhh1128 @Oskar-van-Deventer if we believe that peer did's are derived from the origin key, I think it would be good to eliminate the possibility of generating with another UUID methodology in this method spec as well.

What's your thoughts on this?

[Oskar-van-Deventer]

Hi Kyle, How about the following versions? * did:peer:1:…… : this one has the NSI derived exclusively from the initial verification key (“origin key”) * did:peer:2:…… : this one has the NSI derived from the whole initial DID Document, which includes the origin key * did:peer:3:…… : this one has the NSI derived from the origin key, combined with yet other useful stuff like a group secret All of these (some still hypothetical/future) Peer DID are derived from at least the origin key. I interpret your question that the origin key should always be included in any version/variation of Peer DID. Is that what you meant? Note that anyone could specify a forked “Pear DID” (did:pear :…) that does not have such limitation. So I do not see any serious harm in explicitly adding the limitation to Peer DID, that the NSI derivation should include at least the origin key. Oskar

[dhh1128]

I have written up a potential update to the spec that changes the generation method from simple pubkey derivation to hashing the full did doc. I didn't raise it as a PR because I'm waiting for Christian Lundkvist (who first proposed the idea) to give feedback. But you could have a look, if you want to: dhh1128/peer-did-method-spec@c807027#diff-eacf331f0ffc35d4b482f1d15a887d3b This particular revision (which I might throw away; it's just raw thinking) does not do the thing that Oskar suggested, which is to allow different derivation schemes distinguished by the prefix letter. I don't think lots of derivation schemes is generally a benefit--I'm intuiting that it's flexibility without a deep purpose (https://codecraft.co/2012/10/17/flexibility-is-no-virtue/)--but there may be important reasons to preserve at least an option for more than one scheme. I'd be curious to hear your thoughts.

[dhh1128]

@kdenhartog and @Oskar-van-Deventer I commented on this issue via email before I realized where it was. The comment stream is about the peer did method spec, but this is an issue in the sovrin repo, where the did:sov method lives. Should we move the issue and the comments over to the peer did method spec (https://github.com/openssi/peer-did-method-spec)?

[kdenhartog]

Yeah, I think it's best for us to figure out what we want there first and see if some of the decisions we make for that will have an impact on the sov method. That was the main reason for opening this issue.

[Oskar-van-Deventer]

@dhh1228 Daniel, a question is whether we should keep the current semantics of did:peer:1:... at this stage. Also, the removal of forward compatibility (i.e. removing the keyfmtchar) is risky, as the then any update to the genesis-generating method would require a new spec, e.g. Peer2 DID with did:peer2:... I don't like that. Hence I'd like to keep the keyfmtchar.