search

dhuseby / did-git-spec

Proposed specification for the did:git: method
Apache License 2.0
15 stars 5 forks source link

Can committer id be replaced with alias? #3

Closed kimdhamilton closed 5 years ago

kimdhamilton commented 5 years ago

The current selection of filename seems to be introducing a lot of complexity. From the DID Dir Spec:

The name of each DIDDoc is arbitrary but a best practice is to name each file with the public key identifier (PkId) associated with the identity in the DID document.

Naming the files after aliases would remove some challenges this is causing e.g. discussed here, and remove the need for alias mapping.

dhuseby commented 5 years ago

@kimdhamilton The DID Dir spec I wrote a year ago when I needed a solution for storing DID documents on disk and using that like a "keyring" for a signing tool. It reflects my thinking of a year ago when I was still groping around in the dark for the answers. I knew something needed to be done, but what needed to be done wasn't fully formed yet.

The aliases feature was mostly added for convenience to users of BetterSign. I didn't want users to have to specify the key hash ID or some other hard-to-remember string when specifying which DID document they were talking about. I envisioned users being able to do bs --verify mom < email_from_mom.sig. I wanted the aliases to be free-formed so that users could choose whatever they wanted and could have multiple aliases for the same identity.

In the context of the git repo, aliases can be useful for assigning nicknames to identities that serve auxiliary functions in the governance of the repo. The Firefox and Linux Kernel projects like using a tree structure of "module ownership" for different sections of the code. They have different systems for figuring out who should be asked for review. Aliases could be used to better automate the process. Imagine an alias owner_foo that maps to the identity of the owner of the foo part of the code.

At this point, I want to drive the did-git-spec forward and then adapt the did-dir-spec to match, not the other way around. Ultimately I want the did-dir-spec to be useful in other contexts other than managing identities in a repo and having aliases helps with that I think.

dhuseby commented 5 years ago

@kimdhamilton I just read your post to the mailing list. I was thinking that we'd name the DID documents the same as the in the did:git string format: did:git:<repo ID>:<committer ID> purely for simplifying the code that maps did:git strings to the correct DID document. There's no technical reason why the can't be an alias but by making it the hash of the public key in the DID document, we're sidestepping naming collisions and confusion in the heads of the humans involved. Since this relies as much on meat-space protocols as it does cryptography, anything that reduces potential confusion is probably better.

As I said above the aliases were for command line shortcuts and make sense for specifying, on the command line, the identity a person wants to sign a commit with but I don't think the aliases should land in the did:git strings in the git commit records. That's why I think we should still go with the being the hash of the public key and then allow free-form aliases.

kimdhamilton commented 5 years ago

This makes sense to me; closing the issue