gistfile1.txt

PROPOSAL: Existing documentation in the DID Core specification should be refined to point out that Verification Relationships are arcs in a graph of information and Verification Methods are nodes in a graph of information. That is, they provide different types of information. The first (Verification Relationship) is the expression of a relationship between a DID Subject and cryptographic information used for the purposes of verifying a proof. The second (Verification Method) is the expression of cryptographic material. An image should be provided depicting the explanation.

PROPOSAL: Mark all verification methods 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.

PROPOSAL: The DID WG urges the W3C CCG to write documentation in the Linked Data Security specifications that clarifies how public / private key terminology has been used in the past, why it is vague and leads to security issues (like key reuse attacks in RSA), and why the LDS specs strongly advise specification authors to be more specific about key type and usage when naming key types.

PROPOSAL: 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".

PROPOSAL: JsonWebKey2020 should be renamed to imply that only public key material is meant to be expressed in it (e.g., JwkPublicKey2020).

Orie's proposals:

PROPOSAL: Documentation will be written in the DID core specification describing a required naming convention for verification method types.

PROPOSAL: DID Core states clearly that no private information of any type is to be included in did documents, including but not limited to verification relationships and services.

PROPOSAL: DID Core states that fragments SHOULD NOT contain private or sensitive information.

PROPOSAL: DID Core warns that all key representation SHOULD NOT contain private or sensitive information.

PROPOSAL: DID Core warns that encryption SHOULD NOT be used to protect sensitive information (counter to the JOSE spec guidance).