You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As with JWS's signature value, the format of the proof value is opaque to the application. The proof algorithm defines the format and any encoding is unique to that algorithm.
Of note, for proof algorithms that support proofs of knowledge or predicate proofs of the values in individual payload slots, each of those proofs uniquely generated during derivation must also be encoded/stored in the overall proof value.
These proof algorithms must also provide a programmable interface to applications such that they can request the generation and validation of a proof for each payload. These interfaces will be unique to the algorithm and its proofing capabilities and may vary significantly from one algorithm to another depending on the underlying cryptographic primitives.
Since some proof algorithms will require the predicate statement during derivation, applications must take care to limit or require consent on multiple derivations such that a hostile party cannot simply continue to refine the predicate request in order to gain more knowledge of the hidden value.
The format of any predicate requests are inherently algorithm and application/protocol context specific, these formats are out of scope of the JWP specification.
The text was updated successfully, but these errors were encountered:
Closing as this was a todo for initial publication. Currently defining a signature/proof format is out of scope. However, we may provide for commonality when wanting to structure proofs, e.g. an array of binary parts.
As with JWS's signature value, the format of the proof value is opaque to the application. The proof algorithm defines the format and any encoding is unique to that algorithm.
Of note, for proof algorithms that support proofs of knowledge or predicate proofs of the values in individual payload slots, each of those proofs uniquely generated during derivation must also be encoded/stored in the overall proof value.
These proof algorithms must also provide a programmable interface to applications such that they can request the generation and validation of a proof for each payload. These interfaces will be unique to the algorithm and its proofing capabilities and may vary significantly from one algorithm to another depending on the underlying cryptographic primitives.
Since some proof algorithms will require the predicate statement during derivation, applications must take care to limit or require consent on multiple derivations such that a hostile party cannot simply continue to refine the predicate request in order to gain more knowledge of the hidden value.
The format of any predicate requests are inherently algorithm and application/protocol context specific, these formats are out of scope of the JWP specification.
The text was updated successfully, but these errors were encountered: