Skip to content
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

ION Reads and Writes #370

Merged
merged 24 commits into from
Apr 3, 2023
Merged

ION Reads and Writes #370

merged 24 commits into from
Apr 3, 2023

Conversation

decentralgabe
Copy link
Member

Overview

gabe added 5 commits March 29, 2023 17:24
* origin/main:
  [OSE-433] Add the OpenID4VC authorization endpoint (#338)
  Moarrr docs (#363)

# Conflicts:
#	go.mod
#	go.sum
@codecov-commenter
Copy link

codecov-commenter commented Apr 1, 2023

Codecov Report

Merging #370 (6cf039a) into main (e206a33) will increase coverage by 0.22%.
The diff coverage is 30.55%.

@@            Coverage Diff             @@
##             main     #370      +/-   ##
==========================================
+ Coverage   20.23%   20.46%   +0.22%     
==========================================
  Files          42       48       +6     
  Lines        4675     5454     +779     
==========================================
+ Hits          946     1116     +170     
- Misses       3597     4172     +575     
- Partials      132      166      +34     
Impacted Files Coverage Δ
config/config.go 16.14% <0.00%> (ø)
integration/common.go 0.00% <0.00%> (ø)
internal/util/util.go 0.00% <0.00%> (ø)
pkg/authorizationserver/oauth2.go 81.42% <ø> (ø)
pkg/server/router/did.go 4.84% <0.00%> (-1.71%) ⬇️
pkg/server/router/keystore.go 10.25% <ø> (ø)
pkg/service/did/handler.go 0.00% <ø> (ø)
pkg/service/did/key.go 0.00% <0.00%> (ø)
pkg/service/did/resolution/resolver.go 0.00% <0.00%> (ø)
pkg/service/did/service.go 0.00% <0.00%> (ø)
... and 7 more

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

@decentralgabe decentralgabe marked this pull request as ready for review April 1, 2023 05:44
@decentralgabe decentralgabe added this to the BTC Miami milestone Apr 1, 2023
@decentralgabe decentralgabe self-assigned this Apr 1, 2023
Copy link
Contributor

@nitro-neal nitro-neal left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great job! Just a few little things and some clarifying questions

Methods: []string{"key", "web"},
ResolutionMethods: []string{"key", "peer", "web", "pkh"},
BaseServiceConfig: &BaseServiceConfig{Name: "did"},
Methods: []string{"key", "web"},
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

do we want to add ion into the default method?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think so because it requires having a valid write node configured

universal_resolver_url = "http://uni-resolver-web:8080"
universal_resolver_methods = ["ion"]
ion_resolver_url = "https://tbdwebsiteonline.com"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

url doesn't resolve to anything right now, was this a placeholder or will this be the real url?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is in fact our ion node - you'll notice it works if you make a query like https://tbdwebsiteonline.com/identifiers/did:ion:EiBnKzBTMxW6wM5kIlVBHidpbvKHC9QrNqfYL-Rhpbt63Q

@@ -1,4 +1,6 @@
{
"keyType":"Ed25519",
"didWebId":"did:web:tbd.website"
"options": {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nice!

@@ -128,6 +133,56 @@ func (dr DIDRouter) CreateDIDByMethod(ctx context.Context, w http.ResponseWriter
return framework.Respond(ctx, w, resp, http.StatusCreated)
}

// toCreateDIDRequest converts CreateDIDByMethodRequest to did.CreateDIDRequest, parsing options according to method
func toCreateDIDRequest(m didsdk.Method, request CreateDIDByMethodRequest) (*did.CreateDIDRequest, error) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

pretty clever! Was this overkill though?

What was the reason to not have just string fields in the option{} req object?

*didKey -> option better not exist or return err

*didWeb -> option better be url or return err

*didIon -> option better not exist or return err

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

help me understand...the option object can accept anything - for ion need to accept an array of public keys or service endpoints

the object is a generic any but to extract the value you need to know the concrete type

if it can be simplified let's do it I couldn't figure out a simpler way

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

type CreateDIDByMethodRequest struct {

KeyType crypto.KeyType `json:"keyType" validate:"required"`

// Required when creating a DID with the `web`
DIDWebID string `json:"didWebId"`

// Required when creating a DID with the `ion`
DIDIonPublicKeys []string `json:"didIonPublicKeys"`
    DIDIonServiceEndpoints []string `json:"didIonServiceEndpoints"`

}

^ could be like this instead right?

I think I like your way more, but just wonder if it was overkill and could introduce some bugs or efficiency issue

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

oh yeah, this can work. the tradeoff is then having an "any" request vs a more generic method like I have and specific impls per type...with then the tradeoff of having some ugly mapping code.

I think the real solution is to get away from the generic -> specific funnel code we have now and instead register first-party handlers...I'm not entirely sure how this would work it would be a significant refactor but could be a more natural approach than forcing all DID methods to follow a similar structure.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it's related to Andres's points here #362 so I'll add a note with your comment and we can address in there

Type crypto.KeyType `json:"type,omitempty" validate:"required"`

// See https://www.w3.org/TR/did-core/#did-controller
Controller string `json:"controller,omitempty" validate:"required"`

// Base58 encoding of the bytes that result from marshalling the private key using golang's implementation.
PrivateKeyBase58 string `json:"base58PrivateKey,omitempty" validate:"required"`
PrivateKeyBase58 string `json:"base58PrivateKey,omitempty"`
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

remove validate:"required" was this intendend ?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can add this back until #371

ID: ionDID.ID(),
DID: didDoc,
SoftDeleted: false,
LongFormDID: ionDID.LongForm(),
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can these get really really really big? Maybe we need to revist the max size redis can store

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah I think this could end up being a few MB with updates. for now it should be fine

logrus.WithError(err).Warnf("error getting DID from storage: %s", id)

// if not, resolve it from the network
resolved, err := h.resolver.Resolve(ctx, id, nil)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

oh cool !

func (h *ionHandler) GetDID(ctx context.Context, request GetDIDRequest) (*GetDIDResponse, error) {
id := request.ID

// TODO(gabe) as we are fully custodying ION DIDs this is fine; as we move to a more decentralized model we will
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

maybe like we could at least have a log line / throw an error if the did in storage and the did that gets resolved are different?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

for now this is impossible since we only allow create and do not return the update key to the user. when we add updates and/or self-custody operations we will need to do this

return &GetDIDResponse{DID: resolved.Document}, nil
}

// GetDIDs returns all DIDs we have in storage for ION, it is not feasible to get all DIDs from the network
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

there is no Ion batch call functionality ?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

looking at the api - no - this is an improvement we can make

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

for _, didBytes := range gotDIDs {
var nextDID StoredDID
nextDID := reflect.New(reflect.TypeOf(outType).Elem()).Interface()
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this could be computationally really slow? (maybe not)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah, depending on how large the set of DIDs is this could be bad. this will mostly be fine with #349

@nitro-neal
Copy link
Contributor

🏆

@decentralgabe decentralgabe merged commit 35eb2e4 into main Apr 3, 2023
@decentralgabe decentralgabe deleted the 340-ion-reads-writes branch April 3, 2023 18:59
@decentralgabe decentralgabe mentioned this pull request Apr 3, 2023
2 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Generic "option" field that has unique meaning per DID method
3 participants