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

[Task] Expose iteration over verification relationship fields #989

Closed
7 tasks
cycraig opened this issue Sep 1, 2022 · 0 comments · Fixed by #1024
Closed
7 tasks

[Task] Expose iteration over verification relationship fields #989

cycraig opened this issue Sep 1, 2022 · 0 comments · Fixed by #1024
Assignees
Labels
Enhancement New feature or improvement to an existing feature
Milestone

Comments

@cycraig
Copy link
Contributor

cycraig commented Sep 1, 2022

Description

Add an optional scope parameter to the method getter on DID Document implementations to allow iterating over particular verification relationship fields.

E.g.

/// Returns an iterator over all [`<DID>VerificationMethods`] in the DID Document.
pub fn methods(&self, scope: Option<MethodScope>) -> impl Iterator<Item = &<DID>VerificationMethod> {
  ...
}

Edit: alternatively we could just delegate the individual authentication(), assertionMethod(), etc. functions.

Motivation

Currently, there is no way to list or iterate over the methods with a particular verification relationship (authentication, assertionMethod, keyAgreement, etc.) in IotaDocument and StardustDocument other than accessing the inner CoreDocument which has dedicated methods for each (authentication(), assertionMethod(), keyAgreement(), etc,).

It would be convenient to expose this functionality without bloating the API with methods for each field, similar to how resolve_method works now.

To-do list

  • Add optional scope parameter to methods().

Change checklist

Add an x to the boxes that are relevant to your changes, and delete any items that are not.

  • The feature or fix is implemented in Rust and across all bindings whereas possible.
  • The feature or fix has sufficient testing coverage
  • All tests and examples build and run locally as expected
  • Every piece of code has been document according to the documentation guidelines.
  • If conceptual documentation (mdbook) and examples highlighting the feature exist, they are properly updated.
  • If the feature is not currently documented, a documentation task Issue has been opened to address this.
@cycraig cycraig added the Enhancement New feature or improvement to an existing feature label Sep 1, 2022
@abdulmth abdulmth self-assigned this Sep 12, 2022
@abdulmth abdulmth linked a pull request Sep 16, 2022 that will close this issue
4 tasks
@eike-hass eike-hass added this to the v0.7 Features milestone Sep 19, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Enhancement New feature or improvement to an existing feature
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants