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

Add details about sequence #27

Open
tplooker opened this issue Mar 22, 2021 · 1 comment
Open

Add details about sequence #27

tplooker opened this issue Mar 22, 2021 · 1 comment
Assignees
Labels
ready for PR Ready for Pull Request

Comments

@tplooker
Copy link
Member

Currently in both the definition of DataVaultConfiguration and EncryptedDocument the term sequence is defined with the following definition

A unique counter for the data vault in order to ensure that clients are properly synchronized to the data vault. The value is required and MUST be an unsigned 64-bit number.

What is presently un-clear is how this value is incremented and how things like validation occurs.

It is my assumption that sequence represents the value of monotonically incrementing counter that is enforced by the EDV server and is incremented each time a change (a document is created, updated or deleted) occurs on the target EDV, is this assumption correct?

If so I'm happy to file a PR with a clarification in the definition offered under DataVaultConfiguration.

My second question is how the value sequence relates in EncryptedDocument. Is this the value of the counter when the document in question was last updated? If so there is the potential to use this value to do primitive conflict resolution, for example a server being able to reject a document update if the request made features an out of date sequence number.

@tplooker
Copy link
Member Author

tplooker commented Apr 1, 2021

Discussed on the April 1st call, updated the language above to reflect the current behaviour of the sequence value to be "represents the value of monotonically incrementing counter that is enforced by the EDV server and is incremented each time a change" occurs on the target EDV, thanks @dlongley for clarifying.

@dmitrizagidulin dmitrizagidulin transferred this issue from decentralized-identity/confidential-storage May 25, 2021
@tplooker tplooker added the ready for PR Ready for Pull Request label Jun 24, 2021
@tplooker tplooker self-assigned this Jun 24, 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

1 participant