1
0
mirror of https://codeberg.org/fediverse/fep.git synced 2026-08-08 13:35:51 +00:00

FEP-8b32: Better test vectors (#871)

- Added intermediate outputs to feature file.
- Improved formatting and fixed a typo.

Reviewed-on: https://codeberg.org/fediverse/fep/pulls/871
This commit is contained in:
silverpill
2026-06-27 19:36:20 +02:00
committed by silverpill
parent 6da1856717
commit 90444d8d5e
2 changed files with 18 additions and 7 deletions
+14 -5
View File
@@ -1,7 +1,7 @@
Feature: FEP-8b32: Object Integrity Proofs
@fep-8b32
Scenario: Signing document
Scenario: Signing a document
Given document
"""
{
@@ -27,8 +27,17 @@ Feature: FEP-8b32: Object Integrity Proofs
"""
And Ed25519 secret key "z3u2en7t5LR2WtQH5PfFqMqwVHBeXouLzo6haApm8XHqvjxq"
And current time "2023-02-24T23:36:38Z"
When Signing the document for key "https://server.example/users/alice#ed25519-key"
Then The signed document is
When signing the document for key "https://server.example/users/alice#ed25519-key"
Then the canonicalized document is
"""
{"@context":["https://www.w3.org/ns/activitystreams","https://w3id.org/security/data-integrity/v2"],"actor":"https://server.example/users/alice","id":"https://server.example/activities/1","object":{"attributedTo":"https://server.example/users/alice","content":"Hello world","id":"https://server.example/objects/1","location":{"latitude":25.273962,"longitude":-71.184902,"type":"Place"},"type":"Note"},"type":"Create"}
"""
Then the canonicalized proof configuration is
"""
{"@context":["https://www.w3.org/ns/activitystreams","https://w3id.org/security/data-integrity/v2"],"created":"2023-02-24T23:36:38Z","cryptosuite":"eddsa-jcs-2022","proofPurpose":"assertionMethod","type":"DataIntegrityProof","verificationMethod":"https://server.example/users/alice#ed25519-key"}
"""
Then the combined hash is "cf63e2308ce7d1137667192c5c5e751ba7b1c6e3d5e746a7b717d309654ad1980793e8d97e2de4b989b2b2d7a5fae8cf941f102a03c0ecab00f03eaa2330c650"
Then the signed document is
"""
{
"@context": [
@@ -66,7 +75,7 @@ Feature: FEP-8b32: Object Integrity Proofs
@fep-8b32
Scenario: Verifying a signature
Given The signed document is
Given the signed document is
"""
{
"@context": [
@@ -101,7 +110,7 @@ Feature: FEP-8b32: Object Integrity Proofs
}
}
"""
And The actor
And the actor
"""
{
"@context": [
+4 -2
View File
@@ -53,7 +53,9 @@ Objects SHOULD NOT contain more than one integrity proof.
### Proof verification
Recipients of an object SHOULD perform proof verification if it contains integrity proofs. Verification process MUST follow the *Data Integrity* specification, section [4.4 Verify Proof][DI-VerifyProof]. It starts with the removal of the `proof` value from the JSON object. Then verification method is retrieved from the controlled identifier document as described in *Controlled Identifiers* specification, section [3.3 Retrieve Verification Method][CI-RetrieveMethod]. Then the object is canonicalized, hashed and signature verification is performed according to the parameters specified in the proof.
Recipients of an object SHOULD perform proof verification if it contains integrity proofs.
Verification process MUST follow the *Data Integrity* specification, section [4.4 Verify Proof][DI-VerifyProof]. It starts with the removal of the `proof` value from the JSON object. Then verification method is retrieved from the controlled identifier document as described in *Controlled Identifiers* specification, section [3.3 Retrieve Verification Method][CI-RetrieveMethod]. Then the object is canonicalized, hashed and signature verification is performed according to the parameters specified in the proof.
The subject of the controlled identifier document where the verification method is expressed MUST be the [owner][FEP-fe34-Owner] of the signed object, or a [DID][DIDs] that is provably associated with that actor (e.g. using a mechanism described in [FEP-c390] or [FEP-ef61]).
@@ -75,7 +77,7 @@ Implementers are expected to pursue broad interoperability when choosing algorit
Integrity proofs and linked data signatures can be used together, as they rely on different properties (`proof` and `signature`, respectively).
If compatiblity with legacy systems is desired, the integrity proof MUST be created and inserted before the generation of the linked data signature.
If compatibility with legacy systems is desired, the integrity proof MUST be created and inserted before the generation of the linked data signature.
If both `proof` and `signature` are present in a received object, the linked data signature MUST be removed before the verification of the integrity proof.