-
Notifications
You must be signed in to change notification settings - Fork 54
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: did:peer #120
feat: did:peer #120
Conversation
Things aren't nearly done here yet, but a couple key things I've realized in this process that I wanted to share:
I'll update this when I've made more progress. |
bf8d4d9
to
d5b529f
Compare
did/interface.go
Outdated
// Define the interface more clearly | ||
type DID interface { | ||
IsValid() bool | ||
Resolve() (*DIDDocument, error) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
hmm, not sure about this one.
some DIDs (like ION, and others) require network resolvers, which require hosted software. I'd like to avoid making recommendations of which resolvers to use here.
some DIDs (like peer, web, key) can be resolved more simply.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure. I'm not sure about this one either. I do think we need a DID interface though! I'm just not sure exactly what goes into it. IsValid() seems reasonable. What else is required in a DID?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
hmm...maybe some common methods to get keys? like getAuthenticationMethods
, getVerificationMethods
and so on?
would validation just be static, or should we eventually expand to determining whether the keys in the doc are themselves valid?
there also needs to be a more flexible way to determine validity across DID methods, as they each have a set of properties/processes that uniquely apply to each method
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think that's why each DID needs to implement an IsValid method no? That method would determine if the DID is valid or not.
It seems like that the biggest issue here is the network resolvers?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For resolution, here's what I ended up doing which works:
type Resolver interface {
Resolve(d DID) (*DIDDocument, error)
}
Some did's will have resolvers built in, and so will not. So network based resolvers we can ignore fine, it just won't be implementing the Resolver interface
looks great so far. I like where your head is at for (1)..left a comment |
thanks @decentralgabe ! yep. Got them. Thanks! |
6def758
to
6736f90
Compare
Right now there is simple encoding/decoding of method0 and method2 of did:peer. I'd prefer to get this into The scope of this already went a little out what it was supposed, with the introduction of some general utility stuff (such as errors and the util.go) and introducing some interfaces to the repo. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
small ones, should be good to go after this
@@ -67,4 +73,15 @@ func (d *DIDDocument) IsValid() error { | |||
return util.NewValidator().Struct(d) | |||
} | |||
|
|||
func NewDIDDocument() *DIDDocument { | |||
return &DIDDocument{ | |||
Authentication: make([]VerificationMethodSet, 0), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
would new()
work? may be easier to read
Co-authored-by: Gabe <gabe.l.cohen@gmail.com>
@decentralgabe updates made. One question for you and then maybe we are good to go? |
// offloading pairwise and n-wise relationships to peer DIDs. | ||
// | ||
// Currently only methods 0 and 2 are supported. | ||
// Method 1 will be supported in a future date |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
created #137
|
||
var availablePeerMethods = map[string]Resolver{ | ||
"0": PeerMethod0{}, | ||
"1": PeerMethod1{}, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should 1 be removed since it's not yet supported?
did/peer.go
Outdated
type DIDPeer string | ||
type PurposeType string |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
type DIDPeer string | |
type PurposeType string | |
type ( | |
DIDPeer string | |
PurposeType string | |
) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
gave you a more thorough review this time. really close 😄
@decentralgabe thanks a ton for going through the PR again. Super appreciate the second pair of eyes. Definitely missed a few things which you caught. Any other issues lmk. Again, thanks a ton for the review! |
One thing I'll implement in a future PR: We should make a future issue where Resolver is actually re-specified to DIDResolver. There's a chance we have non DIDResolvers down the road and we'd want to not run into confusion/conflict here. |
agreed |
Think we are good, as I've addressed all the comments, but feel free to bring up more critiques. Comments are welcome 👍 |
* origin/main: feat: did:peer (#120) # Conflicts: # did/key.go # did/model.go
This is an implementation of https://identity.foundation/peer-did-method-spec/ related to
#114.
Implemented:
Also included:
There's more to do here, but I will leave that for another PR unless it is necessary to add it to this one. Anything unimplemented I have returning an "unimplemented" error.