Resolution #1 on 2021-02-09: To exit the DID Core Candidate Recommendation phase, the DID WG will require two things: 1) for normative statements that are machine testable, at least two interoperable implementations per feature, where each feature is defined as one or more normative statement in the specification, and 2) for normative statements that are only human-testable, at least two demonstrations of implementation per feature, where each feature is defined as one or more normative statement in the specification.
Resolution #1 on 2021-02-02: The DagCBOR representation will be moved into its own specification and registered in the DID Spec Registries.
Resolution #2 on 2021-02-02: The CBOR representation will be kept in the DID Core specification as an at-risk representation.
Resolution #1 on 2021-01-05: The DID Working Group will maintain the DID Spec Registries until the end of its charter. The DID Working Group plans to request the management of W3C to submit a charter for a maintenance DID Working Group to the W3C Advisory Committee as a successor to this Working Group. Per the planned charter of that Working Group, that group would officially manage the registry, and would do that in cooperation with the W3C Credentials Community Group..
Resolution #1 on 2020-11-05: Add a test to the test suite that includes "@context": true when testing pure JSON implementations, which passes only if no error is thrown. The MIME type application/JSON corresponds to pure JSON processing.
Resolution #2 on 2020-11-05: change the text from "The value of the @context object member MUST be ignored as this is reserved for JSON-LD consumers." to "Note that the value of the @context object member will be ignored, if present."
Resolution #3 on 2020-11-05: Unknown properties are added to the Abstract Data Model by consumers using generic type processing rules per representation. Unknown properties are serialized by producers using generic type processing rules per representation.
Resolution #4 on 2020-11-05: The definition of "ignore a property during consumption" is to preserve the property in the Abstract Data Model using generic type processing rules per representation with no additional semantic processing performed.
Resolution #5 on 2020-11-05: 1) The DID Core spec Core Properties section shall define “representation-independent properties”; 2) each Representation MAY define its own “representation-specific syntax”, and 3) the ADM section should define how representation-specific syntax is handled if it appears in a representation other than the one in which the syntax is defined (“representation-foreign syntax”).
Resolution #6 on 2020-11-05: Processing of representation-specific syntax are defined by their representation and only processed when that representation is used, when another representation is used, the representation-specific syntax is ignored and preserved and passed through the ADM.
Resolution #1 on 2020-11-03: The DID Spec Registries MUST contain a section on Representations to enable future representations to be registered in an extensible manner. The DID Core specification MUST specify the requirements, such as invariants representations must preserve, on additional representations.
Resolution #1 on 2020-11-02: Adopt the language on slide 23 to add a section on "Avoiding Privacy-Violating Properties in Public DID Documents" to DID Core. See slide
Resolution #2 on 2020-11-02: Adopt the language on slide 34 as a starting point for a PR that establishes new language around Persistence. See slide
Resolution #1 on 2020-10-06: Document how dangerous specifying properties such as the "type" of a DID subject, that are not related to expressing cryptographic material/verification methods related to using the DID, in a VDR can be for entities such as people.
Resolution #1 on 2020-09-15: If all of these 5 steps are not done by the end of September, the CBOR representation will be removed from DID core and made its own note.
Resolution #2 on 2020-09-15: Language should be added to the DID Core specification that provides guidelines to Representation specification writers.
Resolution #1 on 2020-08-11: Define how fragment identifiers are dereferenced within the DID Core specification, anything else is defined elsewhere.
Resolution #2 on 2020-08-11: Define an DID Dereferencing abstract function with inputs and outputs in the specification.
Resolution #1 on 2020-07-01: The test suite will be containerized (using docker), will allow structured configuration input, and produce structured result outputs
Resolution #1 on 2020-06-09: The DID WG will publish a FPWD Note of the DID Specification Registries document, using the short name did-spec-registries, and use echidna to update the note as PRs are merged.
Resolution #1 on 2020-04-21: It is in scope for the DID WG to normatively define the parameters of a concrete set of processes that take a DID as input and provides a DID Document as output.
Resolution #2 on 2020-04-21: It is in scope to make these processes take in options and provide back a document along with different classes of metadata (e.g., document metadata and resolution metadata).
Resolution #3 on 2020-04-21: It is in scope to add tests to the test suite that exercise these processes to test the inputs (DIDs, DID URLs, and input metadata) as well as the outputs (DID Documents, resources, and output metadata).
Resolution #4 on 2020-04-21: It is out of scope to normatively define how any specific DID method implements method-specific details of DID resolution.
Resolution #5 on 2020-04-21: it is out of scope to define whether protocols are used for DID Method implementations or to define those protocols.
Resolution #6 on 2020-04-21: It is out of scope to test concrete DID Resolution protocols and data formats beyond the necessary process to demonstrate interoperability between the test suite and an implementation.
Resolution #1 on 2020-04-07: Use query parameter syntax for encoding DID Parameters, reserving matrix parameter characters for possible use in a future specification.
Resolution #3 on 2020-02-11: Merge PR #186 to implement structural changes to the specification as discussed during the recent DID WG F2F meeting, as soon as a note is added which informs readers that further changes are underway.
Resolution #1 on 2020-01-30: Proposal #1 above is agreed to by the Working Group. Further proposals may modify the baseline proposal above.
Resolution #1 on 2019-11-19: The DID WG will publish the current Use Cases and Requirements document as a FPWD of the Note, with a publication date of November 28, 2019. Subsequent WDs will be published automatically using Echidna as the editors see fit, following standard group discussion of any PRs.
Resolution #1 on 2019-10-29: Publish the DID Core specification as a FPWD with a short name of did-core within the month of November.
Resolution #1 on 2019-10-22: WG will let the editors start with a working mode they choose with team contact and chair approval and modify if necessary
Resolution #1 on 2019-09-17: The DID WG will use the existing CCG DID test suite as a starting point for the DID WG test suite.
Resolution #2 on 2019-09-17: The DID WG will move the existing CCG did spec test suite into the DID WG did spec test suite, preserving the commit history if possible.
Resolution #1 on 2019-09-16: The Working Group will adopt the CCG DID Use Cases document as the starting point for our group's DID Use Cases and Requirements document.
Resolution #2 on 2019-09-16: The Working Group will move the CCG DID Use case issues into our DID Use Cases and Requirements repository. This does not indicate support for any of the issues, and any issue can be closed at any time.
Resolution #3 on 2019-09-16: The Working Group will adopt the CCG "Decentralized Identifiers (DIDs) v0.13 Data Model and Syntaxes" Final Report as the first editors' draft of our Recommendation-track document.
Resolution #4 on 2019-09-16: The Working Group will move the open CCG DID Spec issues into our DID Spec repository.
Resolution #5 on 2019-09-16: The Working Group will keep all of the current CCG DID spec PRs that are actively in progress. Whether this occurs by copying, moving, or recreating is TBD.
Resolution #1 on 2021-02-16: The ADM is only used to represent a DID document or parts of a DID document (e.g. a verification method). For DID Resolution data structures, INFRA will be referenced normatively, as well as the JSON serialization rules for INFRA, to note that the data structure must be able to be serialized using INFRA->JSON rules.
Resolution #2 on 2021-02-16: If possible, and in order to increase interoperability, we should ensure that every normative MUST statement is machine-testable in the DID Resolution section. If it turns out to not be possible then further discussion will be necessary.
Resolution #1 on 2021-01-28: The DID Working Group will not define a canonical form for the Abstract Data Model.
Resolution #1 on 2021-01-14: Move resource=true from DID Core to the DID Spec Registries (as an extension)..
Resolution #1 on 2020-12-17: The DID Working Group will maintain the DID Spec Registries until the end of its charter. The DID Working Group plans to request the management of W3C to submit a charter for a maintenance DID Working Group to the W3C Advisory Committee as a successor to this Working Group. Per the planned charter of that Working Group, that group would officially manage the registry, and would do that in cooperation with the W3C Credentials Community Group.
Resolution #2 on 2020-12-17: The DID Spec Registries maintenance process will be documented in the DID Spec Registries document..
Resolution #3 on 2020-12-17: The Editors of the DID Spec Registries must consider copyright, trademark, legal, security, moral, and privacy concerns when reviewing additions to the registry and may reject registry entries if they deem the addition would cause undue harm. Considerations will be expressed as policies in the DID Spec Registries Process section. Entities registering items can challenge rejections first with the DID WG and then with the W3C Staff..
Resolution #4 on 2020-12-17: W3C Staff need not be consulted on changes to the DID Spec Registries, but do have the final say on registry contents. This is to ensure that W3C can adeqately respond to time sensitive legal, privacy, security, moral, or other pressing concerns without putting an undue operational burden on them..
Resolution #1 on 2020-11-19: sameAs/equivalentDIDs can only contain entries from the same did method as the the did document id.
Resolution #2 on 2020-11-19: The two properties we are defining for equivalence are: equivalentId and canonicalId.
Resolution #1 on 2020-09-29: A DID Method MUST NOT add, modify, or remove from the production or consumption rules for a representation.
Resolution #2 on 2020-09-29: A DID Method may process the abstract data model in pre-production or post-consumption to enforce DID Method-specific rules and transformations.
Resolution #3 on 2020-09-29: The Working Group supports a general "preserve by default" design goal for the abstract data model. This means that a general rule for the abstract data model is to preserve properties that are not registered or documented anywhere, such as "foo": "bar", as long as the property name and property value datatype can be cleanly and losslessly consumed from a representation into the abstract data model and produced from the abstract data model to a representation. The WG may specify exceptions to this general design goal.
Resolution #1 on 2020-09-24: The ability for a controller to optionally state at least one service endpoint in the DID Document increases their control and agency
Resolution #2 on 2020-09-24: Add concrete examples to the Privacy Considerations section to demonstrate how service endpoints might account for varying levels of privacy requirements.
Resolution #3 on 2020-09-24: Add privacy guidance that establishes that there is a privacy spectrum and publication strategies along that privacy spectrum of how service endpoints might be published.
Resolution #4 on 2020-09-24: Add privacy guidance that discourages services from being expressed in DID Documents that are published to Verifiable Data Registries unless a DID Method specification have given specific guidance about how privacy concerns are addressed.
Resolution #1 on 2020-08-27: Discuss in a non-normative appendix how one might model Service Endpoints that preserve privacy.
Resolution #2 on 2020-08-27: Define an abstract data model for serviceEndpoints in normative text, like we have done with verification methods.
Resolution #1 on 2020-08-18: Add the alsoKnownAs property to the DID Core specification which expresses a uni-directional alias relationship between the DID Subject and any other URI.
Resolution #1 on 2020-08-04: Add one issue in the Verification Methods section with a warning stating that there is an ongoing discussion around the naming of verification methods that may impact the final names used in the specification.
Resolution #2 on 2020-08-04: DID Core states clearly that private information of any type should not be included in did documents, including but not limited to verification relationships and services.
Resolution #3 on 2020-08-04: DID Core states that DID URI fragments in a DID Document SHOULD NOT contain private or sensitive information.
Resolution #4 on 2020-08-04: DID Core warns that all key representations in a DID Document SHOULD NOT contain information that isn't required to verify a proof.
Resolution #5 on 2020-08-04: DID Core warns that encryption SHOULD NOT be used to protect sensitive information in DID Document.
Resolution #6 on 2020-08-04: The values associated with publicKeyJwk property MUST be expressed as pure JSON. This is being done to align with the value space of RFC7517. The JSON-LD Context MUST align the value space of publicKeyJwk by specifying "@type": "@json".
Resolution #1 on 2020-07-21: did-core will restrict usage of prohibited algorithms and further restrictions can be set by did method authors
Resolution #2 on 2020-07-21: Producers that express cryptographic values in DID Documents MUST NOT include Parameter Information Classes that are private in nature. For example, JWK formats MUST NOT include JWK parameters that are listed as "Private" in the parameter information class.
Resolution #2 on 2020-05-12: Group items that are of the same kind together in the DID Specification Registries.
Resolution #3 on 2020-05-12: Eliminate the need for a JSON-LD Extensions "kitchen sink" context, DID Method implementers will pick and choose which properties they want to include in their DID Method-specific JSON-LD Context or a shared context between communities.
Resolution #1 on 2020-03-16: Any addition to the DID Core Registries MUST link, via at least a URL, preferably a content-integrity protected one, to the defining specification so that implementers can implement the property.
Resolution #1 on 2019-12-04: Pull in PRs 100, 101, 102, 109, and 110 (with editorial changes made by the end of Friday) after the next DID WG call.
Resolution #2 on 2019-12-04: We should use the same base-encoding format for secp256k1, secp256r1, ed25519, and curve25519 base-encoded public key values.