" ], "delegation": "" } ``` 1. Where a party's `requirements.level` is above `email`, its step MUST carry evidence satisfying every listed requirement. 2. The linkage proves to the envelope's parties that the step key belongs to `identityKey`, without revealing that to the public. A [BRC-94](/key-derivation/0094) or [BRC-97](/wallet/0097) proof SHOULD be attached, so that the linkage is verified rather than asserted. 3. Certificate fields not named in the requirement SHOULD NOT be revealed. 4. The object is stored encrypted to the parties per [BRC-78](/peer-to-peer/0078). Only `evidenceHash` is public. #### 6.7 Certificate types Three [BRC-52](/peer-to-peer/0052) certificate types are defined. A type id is `base64(H(utf8(name)))`, and no name carries a BRC number. | Name | Issued by | Fields | | ------------------------------ | ----------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------- | | `metanet email certificate v1` | A coordinator that verified control of the address by a one-time code or link | `email`, `verifiedAt` | | `consent envelope role v1` | An organisation's trust key, section 8 | `organisation`, `domain`, `role`, `limitAmount`, `limitCurrency`, `validFrom`, `validUntil` | | `consent envelope seal v1` | An organisation's trust key | `organisation`, `domain`, `purpose` | Revocation follows BRC-52's revocation outpoint. A verifier MUST evaluate it as of the block time of the step that used the certificate, not as of verification. ### 7. Control and Relay 1. **Funding.** The controller funds every step transaction. A party never needs coins. A coordinator funding many envelopes MAY draw on pre-funded outputs as in [BRC-227](/apps/0227). 2. **Relay.** A party's client sends the controller its step certificate without the anchor, its encrypted evidence and its encrypted field values. Any alteration breaks the signature over `stepDigest`, so the controller can forward or refuse, and nothing in between. 3. **Liveness.** A controller that refuses to advance a valid step leaves the party holding a signed step it can show it offered. Later steps cannot be produced without later parties' signatures. A controller can delay. It cannot forge, reorder or fork. 4. **Delegated control.** The sender MAY delegate the controller role to a coordinator with a [BRC-169](/peer-to-peer/0169) section 9 certificate whose scope is `consent-controller` and which names the origin. The token is then locked to the coordinator's derived key, and the certificate goes in the evidence bundle. A delegated controller can `FINALISE` and `EXPIRE`, and can `VOID` only with the sender's signed step (section 6.2). 5. **Changing coordinator.** The current controller MAY move the token to a new controller key with a `TRANSFER_CONTROL` step whose field values are `{ "controller": "<33-byte hex key>", "delegation": "" }`. A sender that keeps control itself can therefore switch coordinators at any point without touching the parties. 6. **A coordinator that disappears strands the envelope.** If control was delegated and the coordinator is gone, nobody can spend the token. Every step taken so far remains verifiable as a partial history, and the sender can open a new envelope whose definition names the stranded origin in a field. It cannot supersede it, because section 5.3 rule 2 needs the stranded token. A sender for whom this matters SHOULD keep control and delegate only funding and relay. ### 8. Organisation Trust Keys An organisation proves who it is by publishing a key at its own domain. Everything in this section is optional for an organisation and mandatory for a client that displays an organisation as verified. #### 8.1 The manifest 1. An organisation publishes its trust key per [BRC-68](/peer-to-peer/0068) at `https:///manifest.json` under `metanet.trust`. That key is the certifier for `domain:` in a definition, and the issuer of section 6.7's role and seal certificates. 2. An organisation that issues handles to its people also publishes `metanet.handles` per [BRC-169](/peer-to-peer/0169) section 5.1. Its `resolve` endpoint MAY be a host the organisation does not run, such as a coordinator, so a coordinator can answer handle resolution on the organisation's behalf while the organisation's key remains the certifier. 3. It MAY add a `metanet.signing` object, and MAY advertise its lookup host per [BRC-180](/overlays/0180): ```json { "metanet": { "trust": { "name": "Acme Example AG", "note": "Signing and handles for acme.example", "icon": "https://acme.example/icon.png", "publicKey": "0332430c198776f3fedac1ee3a6ea598d1a67e8fc83b6bc50b8d49a981025cee77" }, "signing": { "version": "1.0", "seal": null, "rotation": null }, "overlays": { "ls_consentenvelope": "https://signing.example/overlay" } } } ``` | Field | Requirement | Meaning | | ------------------ | ----------- | ------------------------------------------------------------------------- | | `signing.version` | MUST | `"1.0"` | | `signing.seal` | MAY | A seal public key, also bound by a `consent envelope seal v1` certificate | | `signing.rotation` | MAY | `"."` of the latest rotation record, section 8.4 | #### 8.2 A manifest hosted by somebody else 1. A domain MAY serve `/manifest.json` as an HTTPS redirect to a copy a coordinator hosts. A client MUST follow at most three redirects, all over HTTPS, and MUST treat the final content as the domain's own statement. 2. The coordinator then serves the key. An organisation that hosts its manifest this way SHOULD publish every key change as a rotation record (section 8.4), so that a substituted key is detectable even though it cannot be prevented. #### 8.3 The DNS fallback Where an organisation cannot change its website, it MAY publish a TXT record at `_metanet-trust.`: ``` v=metanet-trust1; k=<66 hex characters, compressed secp256k1 key>; n= ``` 1. A client MUST prefer a valid manifest. If both exist and name different keys, the client MUST treat the domain as unverified and say so. 2. A client SHOULD validate DNSSEC and MUST record whether it did (section 8.5). 3. A domain verified only by DNS MUST be labelled "verified by DNS". It offers no handle resolution, because BRC-169 resolution needs the manifest. #### 8.4 Rotation records A key change is an `OP_FALSE OP_RETURN` output whose pushes are, in order: ``` "domain key rotation" | u8(1) | domain | oldKey (33) | newKey (33) | u64be(effectiveAt) | sigOld | sigNew rotationDigest = H( lp("domain key rotation v1") || lp(domain) || oldKey || newKey || u64be(effectiveAt) ) ``` `sigOld` and `sigNew` are DER ECDSA signatures over `rotationDigest` by the old and new keys. A client SHOULD warn when a domain's published key changes without a matching record. #### 8.5 Domain observations Domains lapse and change hands, so a past signature must not depend on what the domain publishes at the moment somebody checks it. Whenever a step relies on a `domain:` certifier, the signer's client MUST fetch the domain's key at signing time and include an observation in its evidence: ```json { "version": "1.0", "domain": "acme.example", "method": "manifest", "dnssec": null, "trustPublicKey": "", "fetchedAt": "2027-03-02T10:11:12Z", "contentSha256": "", "finalUrl": "https://acme.example/manifest.json", "coObservations": [ { "observer": "", "signature": "" } ] } ``` 1. The observation is committed through `evidenceHash`, so it is anchored with the step. 2. An observation made by the signer alone is the signer's claim. The coordinator and any counterparty SHOULD fetch the same domain independently and add a co-observation. A verifier MUST report how many independent observers there were. 3. A verifier MUST report the result as "acme.example published this key on 2027-03-02, observed by N parties, anchored in block H". It MAY also fetch the domain now and report agreement or disagreement, which is informative and never decisive. ### 9. Email Addresses as Handles Every email address is also a handle, so that a sender never needs to know whether a recipient has a wallet. #### 9.1 Verified domains If a domain publishes `metanet.handles` (section 8.1), `local@domain` is resolved as `@local@domain` under [BRC-169](/peer-to-peer/0169) section 2.1 rule 7, and a plus-tag in the local part maps to a BRC-169 sub-handle tag. Nothing in this section changes BRC-169. #### 9.2 Other domains Where the domain publishes no handles, a coordinator MAY issue a hosted handle in its own namespace: 1. Lowercase the address. Split it at the last `@` into `local` and `domain`. Split any `+tag` off `local`. 2. Replace every character of `local` outside the BRC-169 handle grammar with `-`, append `_` and `domain`, and trim leading and trailing punctuation. 3. If the result exceeds 64 characters, use `e-` followed by the first 26 characters of the lowercase, unpadded base32 ([RFC 4648](https://www.rfc-editor.org/rfc/rfc4648)) encoding of `H(lowercased address)`. 4. The handle is `@[+tag]@`, bound to the person's identity key by a `metanet email certificate v1`. 5. A client MUST display the email address and the label "email verified by ". It MUST NOT display such a handle as verified by the email's domain. A recipient field MUST accept an email address and a handle interchangeably. #### 9.3 Linking an email address to a wallet 1. A person who signs by email and chooses to sign with a wallet proves control of both: the coordinator verifies the address, and the wallet signs a [BRC-138](/peer-to-peer/0138) proof addressed to the coordinator. 2. The coordinator then issues a `metanet email certificate v1` to the wallet's identity key. Requests later addressed to that email MAY be delivered to the wallet under section 10.3. 3. The person MUST be able to unlink, which revokes the certificate. ### 10. Confidentiality and Delivery #### 10.1 Encryption 1. The definition and each document are encrypted with AES-256-GCM under fresh random keys. Ciphertext MAY be stored anywhere and is addressed by its hash per [BRC-26](/overlays/0026). 2. Each object key is wrapped for each party that has an identity key with [BRC-2](/wallet/0002), `protocolID [2, "consent envelope document key"]`, `keyID -