BRP verification RFC

Status of this extract

This public technical summary faithfully describes the verification boundaries of the draft. It omits participant research, personal details and private source links. It is not the full RFC. The original research document is not published here.

This is a ScoutRail design proposal, not an IETF RFC, adopted industry standard, independent certification or a claim of complete implementation. The profile review process described on How verification works is available; an individual badge still needs actual completed checks and sharing permission. Private communication and HCP room disclosure are separately gated.

1. Keep different claims separate

Based on HCP sections H2 and H5.1 and the draft’s scope boundaries.

• Accepted by host: ScoutRail durably accepted an exact command and its result. This is not proof of delivery, reading, agreement or fulfilment.
• From signed-in account: the host bound that event to an authenticated account and checked its authority for the command. It does not establish who typed it or that its contents are true.
• Profile details supplied by participant: display names, photos, business descriptions and links are not verified merely because they were entered.
• ScoutRail profile checked: current evidence covers a named, versioned product policy. The original H5.1 draft requires real first name and surname, real photo, mobile and LinkedIn; Facebook is optional. This is not independent legal-identity proof.
• Identity, business role and authority: separate checks with their own issuer, method, scope and limitations. A profile badge does not grant authority to accept an offer.
• Content and reading: neither account provenance nor a profile badge establishes factual truth or that a human read a message.

Current product policy 0.2: mobile is now optional. Name, live portrait and LinkedIn control checks remain required for new live checks. Historical admin-attested records use a separately labelled policy and do not claim those live methods. The badge lists only completed checks and identifies its policy version. This is a deliberate change from the original H5.1 checklist, not a rewrite of the draft. HCP/0.1 remains pinned to its original four-check evidence contract and does not claim support for policy 0.2 evidence.

2. Bind a brief to an exact version

Based on the BRP need.publish and need.confirm commands, immutable references and HCP H6 provenance.

A published need has an immutable object reference: identifier, revision and digest. Its accepted event records the submitting actor, represented party, command and acceptance time. The content digest is based on canonical JSON and SHA-256 with a BRP domain prefix. A digest detects a content mismatch; it is not a signature or independent proof of who wrote it.

The other actor’s need.confirm command references the exact need and lists the requirement identifiers being confirmed, with that actor’s statement. The UI must show that scope. A new revision needs new confirmation. Confirmation must not silently become offer acceptance, payment, capacity reservation or completed service.

The host remains trusted. BRP/0.1 and HCP/0.1 do not provide portable issuer signatures, a public certificate, federation or independent non-repudiation. A future signature mechanism needs its own specified and tested profile.

3. Make evidence inspectable and current

Based on HCP H4–H6.

Each check identifies the subject, issuer, exact scope, method, explanatory limits, checked time, expiry and any revocation. Self-entered issuer names, screenshots, URLs or empty fields cannot stand in for a check that was never performed.

Current HCP snapshots are short-lived, at most 60 seconds, and cannot outlive any active check. An expired check is expired; revoked evidence is revoked; inaccessible or missing evidence is unavailable. A historical check at send time must not be presented as a current check.

Profile, photo and provenance reads require current permission for the exact room and recipient. Public badge sharing and room sharing are distinct. Private responses prohibit caching. Retrieval must not send a notification, mark a message read, share new fields or create a business command.

4. Present agreements as retained private documents

Product presentation clarification, updated 13 November 2026. This clarifies the draft’s existing offer acceptance, immutable-reference and access-control semantics. It does not change the pinned BRP/0.1 or HCP/0.1 wire contracts.

• Document Type and State MUST be shown separately, with visible text, icons and explanations accessible by hover, keyboard and touch. Type derives from the canonical record: need is Brief, offer is Offer, order is Agreement. A saved private brief is Draft; a shared brief is Shared, never Accepted.
• State MUST match the authorized current object identifier, type and revision. Offers distinguish awaiting acceptance, changes requested, accepted, withdrawn and expired. Agreements distinguish agreed, cancelled and closed. Missing or mismatched state is Unavailable. Conversation closure does not close an agreement; a cancelled agreement retains that fact after closure.
• MOU MUST NOT be inferred from an agreement, title or illustrated example. BRP/0.1 has no explicit MOU classification. A future optional classification requires explicit provenance and versioned compatibility; it cannot change existing canonical payloads, digests, permissions or exact assent.
• A brief, an unaccepted offer and a recorded agreement MUST have distinct labels. The paper-and-lock icon denotes an access-controlled record, not identity or legal certification.
• Offer acceptance binds the exact offer reference, terms digest and total. The host checks current authority, party, open state, expiry and current brief before recording the agreement. Accepted amendments and cancellations create a new agreement revision rather than overwriting the retained content. Cancellation receipts MUST be labelled separately from acceptance and must match the accepted cancellation reference.
• The UI MUST show the revision and provide inspectable content references and acceptance receipts. A positive acceptance stamp requires an event bound to this exact revision and source offer or amendment. Missing or mismatched evidence MUST remain unavailable.
• Account, represented party, authority reference, event and time describe recorded provenance. They MUST NOT be promoted into a claim of a handwritten or cryptographic signature, legal enforceability, independent verification of statements, delivery or payment.
• Attached terms remain separately retained files. The card MUST NOT imply that a downloadable PDF or portable certificate exists when none was generated.
• The lock MUST be explained as controlled access and a retained revision, subject to access, retirement and retention rules. It MUST NOT imply end-to-end encryption or that copies can be recalled.
• Illustrated walkthroughs MUST remain visibly identified as design previews. Their role marks and document receipts MUST NOT be mistaken for actual participant checks or transactions.

5. What implementation must prove

Exact actor, version, audience and authority binding; expiry and revocation handling; duplicate and uncertain-send recovery; private-data protection; accessible controls; and truthful distinctions between drafts, recorded events, partial confirmations and accepted agreements.

Schema and synthetic fixture tests establish only the cases they exercise. They do not perform real identity checks, guarantee safety, verify a payment or establish a completed transaction. Product release status must be verified separately.

Public technical foundations

• RFC 8785: JSON Canonicalization Scheme
• RFC 8259: JSON
• RFC 3339: timestamps
• RFC 8446: TLS 1.3

These standards provide technical building blocks. They do not endorse ScoutRail or standardise BRP’s business semantics.