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] Support relative references in CoreDocument #1072

Open
9 tasks
olivereanderson opened this issue Nov 9, 2022 · 1 comment
Open
9 tasks

[Task] Support relative references in CoreDocument #1072

olivereanderson opened this issue Nov 9, 2022 · 1 comment
Assignees
Labels
Request Request a feature
Milestone

Comments

@olivereanderson
Copy link
Contributor

Description

Add support for representing references to verification methods and services by fragment only in CoreDocument. In other words the following example from the DID core spec should deserialize to a valid CoreDocument.

Motivation

Section 3.2.2 of the DID Core spec states that relative references are often used to reference verification methods and services in DID documents.

Resources

Link to any resources relevant for the task such as issues, PRs, reference implementations, or specifications.

To-do list

Create a task-specific to-do list. Please link PRs that match the TODO list item behind the item after it has been submitted.

  • Item one
  • Item two
  • Item three

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.
@olivereanderson
Copy link
Contributor Author

olivereanderson commented Nov 15, 2022

Here is a list of possible solutions:

  1. Make deserialization expand such fragments to full DID URLs by prepending the document's id.
  2. Similar to 1. , but also make serialization ignore the DID part of a DID URL (as long as it is the same as the document's id).
  3. Expand the MethodRef type to also include a Fragment variant.

Question: Could approach 3. be problematic in the presence of custom JSON-LD @context ?

@eike-hass eike-hass removed this from the v1.0 Features milestone Dec 11, 2023
@eike-hass eike-hass moved this from Product Backlog to Sprint Backlog in IOTA Identity - Framework Developments Feb 5, 2024
@eike-hass eike-hass added this to the v1.2 milestone Feb 5, 2024
@eike-hass eike-hass moved this from Sprint Backlog to Product Backlog in IOTA Identity - Framework Developments Feb 16, 2024
@eike-hass eike-hass modified the milestones: v1.2, v2.0 Feb 16, 2024
@eike-hass eike-hass moved this from Product Backlog to Sprint Backlog in IOTA Identity - Framework Developments Mar 13, 2024
@eike-hass eike-hass assigned wulfraem and unassigned UMR1352 Mar 13, 2024
@wulfraem wulfraem moved this from Sprint Backlog to In Review in IOTA Identity - Framework Developments Mar 22, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Request Request a feature
Projects
Development

No branches or pull requests

4 participants