definitions for private information
OR13 opened this issue · comments
@msporny if these terms are not going to be defined in this vocabulary, then we (universal wallet work item authors) will need to defined them in another vocabulary.
I'd prefer we use security vocab html to define them, but I would live with them not being in the same context....
For example:
https://w3id.org/security/v3 -> https://w3id.org/security#publicKeyJwk
https://w3id.org/security/v3-private -> https://w3id.org/security#privateKeyJwk
or
https://w3id.org/wallet/v1-> https://w3id.org/wallet#privateKeyJwk
We should close this issue when we have consensus documented in the html that private information will or will not be included here, and some guidance one how private information is or is not related to the vocabulary defined here.
@msporny @dlongley related: multiformats/multicodec#194
I would prefer that we go with this option:
https://w3id.org/security/v3 -> https://w3id.org/security#publicKeyJwk
https://w3id.org/security/v3-private -> https://w3id.org/security#privateKeyJwk
That gives us the option to merge -private into the public stuff if that's where the community goes -- I will most likely never be a +1 to that direction :) -- but I think this strikes the right balance.
To be clear, I'd rather we didn't define the terms at all so they're always dropped via JSON-LD expand/compact processing. We could provide guidance to folks: "use privateKeyJwk in your private JSON-LD documents, knowing that the declaration can't easily escape into another JSON-LD aware system... privateKeyJwk will be dropped if it hits a JSON-LD processor." It's not an entirely solid argument by itself and is not something you'd want to depend on in and of itself, but another layer of the security onion.
So the compromise is:
- Define
privateKeyJwkin the Security Vocabulary, marked with a BIG warning. - Place the term in a JSON-LD Context that is NOT the public one... name it
v3-private(or something equivalent).
I can live with that.
Have we considered putting it in a "Dangerous Security Vocabulary" document instead? So that people know that when they're dealing with it, it's dangerous stuff? Kind of how giant tractor trailers that are hauling hazardous materials have big warnings on them?
I like documentation all in one place, but I am fine with the context split, I proposed it and I think it has the security features developers expect.
Its also a loosing game not to define things, just opens the door for others to do so without providing a warning.
as they are clearly about to start doing with mulitcodec private keys : /
Addressed by PR w3c/vc-data-integrity#135 (which adds private/secret JWK key terms to the vocab)
I believe this can be closed when these PRs are merged: