-
Notifications
You must be signed in to change notification settings - Fork 16
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: add internal did:web resolution #190
feat: add internal did:web resolution #190
Conversation
use super::*; | ||
|
||
#[tokio::test] | ||
async fn resolution_success() { |
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.
Awesome work! Would we be able to add another test for resolving web dids with a port?
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.
Yep, I can certainly do that!
5357418
to
c76f6c6
Compare
crates/dids/src/document.rs
Outdated
#[serde(rename = "verificationMethod")] | ||
pub verification_method: Vec<VerificationMethod>, | ||
#[serde(rename = "verificationMethod", skip_serializing_if = "Option::is_none")] | ||
pub verification_method: Option<Vec<VerificationMethod>>, |
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.
How do you all feel about this change? 6a54d27 has some reasoning -- did-core and the web5 spec disagree so I'm not sure who's right. This example DID document on https://tbd.website/.well-known/did.json doesn't have a VerificationMethod
which is what sparked this change.
Maybe it's worth a separate PR for discussion aside from the did:web
resolution PR?
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.
web5-spec for reference
you're correct - per current web5-spec, verificationMethod list requires at least 1 VM in it. here is some discussion where we noted it would be a departure, but we didn't explicitly record the reasons why.
@decentralgabe would it make sense to add to our web5-spec the reasoning for this departure from did-core spec?
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.
yes, though I am wondering whether this guidance should still apply to the rust code.
originally it was to support a consistent feature set across languages that handled optional/polyglot type properties consistency
however, if rust is able to directly support the did core spec then maybe our guidance is superfluous
suffice to say - in this case I would be fine to follow DID core and ignore our spec - but open to counter points
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.
Okay cool this is a great matter to work through. I'm in favor of enabling support for the DID Core spec over our web5-spec
here in Rust. However, I propose we don't implement that change here, because there are more implications which need attending to. Primarily, the ones which come to mind are:
- did:jwk requires exactly one verification method, and so we should add error cases
- did:dht requires at least one verification method, and so we should add error cases
- we'll need to also account for this change in the APID and consider the downstream implications for Kotlin & Swift target languages
@enmand could we parse these changes out of this PR, and then I stubbed in #231 for subsequent work
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.
Sounds good! I've opened #233 with the changes to enable optional verification methods and rebased it out of this PR.
I see review has been requested, nice! This may sit for a bit as I'll be AFK for the next week, but others may get to it in the mean time. Nevertheless, we'll get this reviewed sooner or later! Thanks 🙌 |
Looks like this PR is out-of-date with the recent crate changes. I should have time later this week to rebase it. |
c76f6c6
to
4bc9f42
Compare
Rebased on the changes for the crate re-organization. Let me know if you want me to separate the |
Remove dependency on the Spruce crates for did:web resolution Resolves decentralized-identity#42 Adds a test related to decentralized-identity#39, but needs a trusted host for a real-resolution test for a path-based DID.
b7d8fc0
to
633df6b
Compare
// PORT_SEP is the : character that separates the domain from the port in a URI. | ||
const PORT_SEP: &str = "%3A"; | ||
|
||
const USER_AGENT: &str = concat!(env!("CARGO_PKG_NAME"), "/", env!("CARGO_PKG_VERSION")); |
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.
This is interesting, @enmand can you help me understand your reasoning for including setting the User-Agent
header? I can come up with a few reasons for and against, but I'm slightly skeptical and default to not implementing it unless absolutely necessary.
Also I wonder, do you know how this would impact browser environments given we were to run this in a browser via a WASM binding? It's not a huge deal in this moment because we're deprioritizing WASM in this moment, so no need to spend a bunch of time investigating, but again my skepticism would lead me to conclude we're better off leaving this out until we have clarity on the broad array of cross-platform implications.
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.
Mostly because it's a way for the did:web server to understand what versions/libraries it's dealing with, though given it's not a service-to-service environment and there are many callers maybe it's not as important. I'm not strong on keeping it or removing it -- I only added it because it was a natural thing for me to include, but also happy to not have it included.
Re. WASM environments -- that's a good questions. I'll implement it in a browser/WASM environment soon for the DWN project I'm working on, and if this is included I can report back (otherwise, I'll probably have other places where I make reqwest
requests in the DWN so I can try it there). One challenge with WASM in general is networking, but WASIX and other modern preview specs include some networking (including HTTP stubbed by fetch
, iirc)
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'm wrangling around code into the APID in this PR. I'm going to go ahead and merge this code and copy everything over into the temporary apid
module, but I'm going to remove this feature. It's probably something we want, but I want to approach these matters conservatively because of downstream impacts to cross-language binding. I appreciate the thought! And I suspect we'll add it back at some point once we fully comprehend the implications.
@@ -10,7 +10,7 @@ pub struct Document { | |||
pub controller: Option<Vec<String>>, | |||
#[serde(rename = "alsoKnownAs", skip_serializing_if = "Option::is_none")] | |||
pub also_known_as: Option<Vec<String>>, | |||
#[serde(rename = "verificationMethod")] | |||
#[serde(rename = "verificationMethod", default = "Vec::new")] |
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.
Clever. This may have implications but I'm fine with moving forward with it.
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 added it because the example did:web
(https://tbd.website/.well-known/did.json) was failing to Deserialize, complaining about verification_methods
being missing -- though maybe there's another way (aside from #233)?
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.
We should update that DID because it's not really adding any value. I'm not sure how it can be used in its current state.
Co-authored-by: Kendall Weihe <[email protected]>
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.
Really fantastic work ✅
Remove dependency on the Spruce crates for did:web resolution, and implement
did:web
resolution internally in thedids
crate.Adds a test related to #39, but needs a trusted host for a real-resolution test for a path-based DID (does TBD have one already?)
Resolves #42.
Note: e830f1d makes the
VerificationMessage
optional to match the current set of properties in DID-Core -- the web5-spec disagrees with this, and I'm not sure who's right -- but the example hosted DID (https://www.tbd.website/.well-known/did.json) doesn't include aVerificationMap
. The current implementation maps this to an emptyVec<VerificationMethod>
, this PR changes that to anOption<Vec<VerificationMap>>
.