search

w3c-ccg / security-vocab

The Linked Data Security Vocabulary
https://w3id.org/security
Other
21 stars 21 forks source link

definitions for private information #62

Open OR13 opened 4 years ago

OR13 commented 4 years ago

https://github.com/w3c-ccg/universal-wallet-interop-spec/pull/25/files#diff-9c6d9b71546e84d84bee622bc124592cR43

@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

OR13 commented 4 years ago

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.

OR13 commented 4 years ago

@msporny @dlongley related: https://github.com/multiformats/multicodec/pull/194

msporny commented 4 years ago

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:

  1. Define privateKeyJwk in the Security Vocabulary, marked with a BIG warning.
  2. 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?

OR13 commented 4 years ago

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 : /

dmitrizagidulin commented 1 year ago

Addressed by PR https://github.com/w3c/vc-data-integrity/pull/135 (which adds private/secret JWK key terms to the vocab)

OR13 commented 1 year ago

I believe this can be closed when these PRs are merged: