-
Notifications
You must be signed in to change notification settings - Fork 11
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 spec for proofs #89
Changes from 1 commit
ae6cb3d
c5e173b
e0b62bc
1c4f105
71e0c5b
f67e687
c97b7ff
c583207
2b314cb
521b459
a3331d9
53abb81
e2fc0c3
486a3eb
333f579
23c2995
a8053cf
1e952c2
aea2dc3
12d0bd4
09bf877
7bce59f
4326429
3d64512
bfc1a28
fa244ff
088b8aa
4a069a1
9ae4a15
c0d15ed
72bff56
865c9d4
fee322c
14fed5e
428dd5b
01a9054
051eb9b
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -39,6 +39,11 @@ request = COSE_Sign<{ | |
; Attributes. An optional list of request attributes defined in the spec. See | ||
; the list of all attributes in this repo. | ||
? 8 => [ * attribute ], | ||
|
||
; Flag. When set, a proof of what was requested will be given, if possible. | ||
; Otherwise, an error will be returned. When not set, a response will be given | ||
; without an associated proof and without error. | ||
? 9 => bool | ||
}> | ||
; end::request[] | ||
|
||
|
@@ -85,6 +90,12 @@ response = COSE_Sign<{ | |
; Attributes. An optional list of response attributes defined in the spec. See | ||
; the list of all attributes in this repo. | ||
? 8 => [ * attribute ], | ||
|
||
; Proof. If requested, this is the set of steps constituting a proof of existence | ||
; of what was requested in the state of the Merkle tree. | ||
; See https://github.com/liftedinit/merk/blob/develop/docs/algorithms.md#binary-format for | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'd like to put the thoughts of this document into a separate specification document and not rely on implementation specific documentation. Note that using specific implementations is not something the spec should recommend or even mention. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. OK, I can put the binary structure into a separate adoc |
||
; reference. | ||
? 9 => [ + ( node-hash / key-value-hash / key-value-pair / parent / child ) ] | ||
}> | ||
; end::response[] | ||
|
||
|
@@ -159,3 +170,44 @@ attribute-id-custom = nint | |
|
||
; An attribute contains an ID and arguments. | ||
attribute = attribute-id / [attribute-id, * attribute-arg] | ||
|
||
; Represents a parent operation in a proof | ||
parent = h'10' | ||
|
||
; Represents a child operation in a proof | ||
child = h'11' | ||
|
||
; The hash of a key-value pair | ||
key-value-hash = bstr | ||
|
||
; The hash of a node in a proof, containing, in order, the hash | ||
; of the key-value pair, the hash of the left child, and the hash of | ||
; the right child | ||
node-hash = bstr | ||
|
||
; A node key of a proof is a collection of bytes together with its length | ||
node-key = { | ||
; The length of the key | ||
0 => uint, | ||
|
||
; The value of the key | ||
1 => bstr, | ||
} | ||
|
||
; A node value of a proof is a collection of bytes together with its length | ||
node-value = { | ||
; The length of the value | ||
0 => uint, | ||
|
||
; The value itself | ||
1 => bstr | ||
} | ||
|
||
; The key-value pair of a proof | ||
key-value-pair = { | ||
; The key | ||
0 => node-key, | ||
|
||
; The value | ||
1 => node-value | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think an attribute here would be better, as:
So I'd rather have a system similar to
async
support; a request attribute, a response attribute and a server attribute that indicates support for those. This way servers can advertise they support proofs, clients can ignore proofs, and if proof is requested the server should bail out as it cannot provide it, and client can then re-request without the attribute if it chooses so.[1] there is an argument that HTTP headers are different as they are optional while attributes require handling or fail, but in this specific case it is actually beneficial.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Acknowledged . . . will refactor this into a proof attribute