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

PROPOSAL: version tags for upgradeability #34

Open
theblockstalk opened this issue Jan 19, 2021 · 3 comments
Open

PROPOSAL: version tags for upgradeability #34

theblockstalk opened this issue Jan 19, 2021 · 3 comments
Labels
ready for PR Ready for Pull Request

Comments

@theblockstalk
Copy link

Sometimes system operators need to request that clients update encrypted document data and schemas due to

  • bugs
  • system upgrades requiring new data, linking or reprocessing of data

This requires that encrypted storage layers (servers, mobile devices) keep track of the version of schema and data they are using to an appropriate level. With this information, data schema and data upgrade functions can be requested applied only when relevant.

This proposal is to create version tags on data, specified by system operators:

  • plain text metadata stored beside the encrypted document and/or;
  • encrypt metadata stored beside encrypted document (not sure if/how this could work) and/or;
  • within the encrypted document (therefore can only be read by clients)

Additional feature: Version tags could be numeric, Datetimes or string labels, specified by system operators. Suggest starting with numeric.

@OR13
Copy link
Contributor

OR13 commented Jan 21, 2021

hmm, i think JOSE handles this for us automatically regarding the encryption envelope, but its possible to apply a plaintext version and an encrypted index version as well.

@dmitrizagidulin dmitrizagidulin transferred this issue from decentralized-identity/confidential-storage May 25, 2021
@msporny
Copy link
Contributor

msporny commented Jun 10, 2021

Having versions on each document might turn into a nightmare. Having a vault with multiple different document versions is problematic. So, -1 to that.

If we are going to put a version on something, it should be the vault config.

... but what might be better is feature discovery and a commitment to backwards compatibility.

@dmitrizagidulin
Copy link
Contributor

dmitrizagidulin commented Jun 10, 2021

Discussed on Jun 10, 2021 call.

  • @OR13 is right, no need to version the encrypted document format (since it's always JWEs).
  • Adding a version field to the Vault Config document might be useful though.
  • However, if spec changes are additive (and non-breaking - see HTML for example), versioning is not needed, and instead, you can do Feature Discovery. For example, OpenID Connect is a great example of this, it uses feature discovery flags in the config.

Next step: Add to the spec the notion that we're specifically not going after a numeric versioning, and will depend on feature discovery.

@msporny msporny added the ready for PR Ready for Pull Request label Jun 10, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
ready for PR Ready for Pull Request
Projects
None yet
Development

No branches or pull requests

4 participants