Relying-Party Desk
What it is
The Relying-Party Desk is how one organization (the relying party, for example a prime contractor or an insurer) asks another (the supplier) for signed proof receipts, and how the supplier answers on its own terms.
- The relying party picks a request template, addresses it to the supplier's e-mail address, and CMDash sends a single-use invitation link.
- The supplier opens the link, signs in to (or creates) its own CMDash workspace, and accepts. Accepting creates a grant in the supplier's workspace. Nothing is shared until that happens, and the grant is the supplier's act, not the relying party's.
- From then on, every receipt the supplier issues for a granted claim is delivered under the grant, and the relying party reads it in place. Nothing is copied into the relying party's workspace, so a revoked or expired grant stops the very next read.
The relying party sees only the signed receipts for the claims that were granted: the statement, the numbers the receipt signs, the dates and the basis. It never sees the supplier's evidence, evidence salt, or anything else in the supplier's workspace.
When to use it
Use it when someone you do business with must prove a security claim to you, or when you are the one being asked. The receipts are checkable without CMDash (see Verifying a proof receipt), so the relying party does not have to take the supplier's word, or CMDash's.
Before you start
- Tier: no tier gate. The desk is under the
PROOF_RECEIPTSentitlement, which every tier holds, Free and up. A relying party and a supplier can both be on Free. - Role: sending, re-sending, accepting and declining are OWNER or ADMIN. Reading requests, grants and deliveries is open to any member.
- To send a request: the sender's e-mail address must be verified.
- To answer a request (supplier): one of three levels, recorded on the grant and shown to the relying party as Supplier identity: DNS-verified (a verified address in the request's domain, in a workspace that proved the domain by DNS TXT record), E-mail-verified (the workspace confirmed the domain with a link mailed to a role mailbox), or Mailbox-verified (you are signed in with the exact address the request was sent to). Below DNS-verified only self-assessed and self-attested lines are shared; measured lines show as not shared. Details and limits: Prove a domain. The link alone is never enough: a forwarded link must not let some other organization answer with its own proof.
- The supplier has something to share only once it has issued receipts. Receipts are issued
from
/proofwith Refresh now (Proof receipts).
How to
Ask a supplier for proof (relying party)
- Open Supplier requests (
/proof/requests). - Choose a template (see Request templates below), enter the supplier's e-mail address, and send.
- CMDash e-mails a single-use link that lapses after 14 days. The page tells you whether the e-mail was delivered; if the deployment cannot send e-mail, or the provider refused the message, the page says so and shows the link so you can pass it on yourself. It never reports a message as sent on a guess.
- To send an open request again, use Send again. The new link replaces the old one, so an earlier e-mail stops working, and the 14-day clock restarts. The address on a request cannot be changed: to ask someone else, send a new request.
The page shows each request as Waiting for the supplier, Answered, Declined or Expired.
Limits. An organization can create 20 requests an hour and 50 a day. Invitation e-mails (first sends and re-sends together) are capped at 100 a day per organization, and any one request can be re-sent 3 times a day. The address must be a business address on a public domain: a request to an internal or reserved name is refused, because no supplier could ever prove it.
Request templates
A template is a named list of claims, each stating how it is established. The request page shows the basis next to every line so a self-attestation is never read as a measurement.
<!-- templates:begin -->| Template | Lines | Basis |
|---|---|---|
CMMC SPRS score and five-point practices (cmmc-sprs-5pt) | SPRS score | Self-assessed. Computed from the supplier’s own practice assessments; it is a self-assessment. |
| Five-point practices (44) | Self-attested. The status a member of the supplier last recorded for each practice. Self-attested; nothing was measured. | |
| POA&M summary | Self-assessed. Open and closed items counted from the supplier’s own plan of action; a self-assessment. | |
Cyber-insurance core controls (insurance-core) | Multi-factor authentication | Measured. Enrolment counted over identities reconciled from the supplier’s connected identity providers; an identity whose state is unknown is not counted as enrolled. |
| Endpoint-detection coverage | Measured. Hosts running an endpoint-detection agent, counted over the supplier’s connected integrations; an unknown host is not counted as covered. | |
| Backups | Measured. Read from the supplier’s connected AWS accounts through AWS Backup: an account counts only when a backup plan that selects resources exists and every resource enrolled in AWS Backup has a recovery point from the last seven days. No plan, an empty plan, a stale backup, or a read that failed is not counted as met. Data outside connected AWS accounts is not measured; resources not enrolled in AWS Backup are not counted. Where no AWS account is connected, nothing is measured and no backup claim is issued. | |
| E-mail authentication (SPF, DKIM, DMARC) | Measured. Read from public DNS for each domain the supplier has verified: a domain counts only when SPF, DMARC at quarantine or reject, and a strong DKIM key were all observed. A missing or weak DMARC policy, or a record that could not be read, is not counted as met. | |
CMMC Level 2 core proof (cmmc-l2-core) | Every CMMC Level 2 claim CMDash issues: SPRS score, five-point practices, MFA enrolment, malicious-code protection, POA&M summary and evidence freshness | Per claim, as above. |
Two things follow from this. A line that states CMDash does not measure it is listed so you can see what CMDash cannot prove, and a request never asks a supplier for it. And a self-assessed or self-attested line is exactly that: the supplier's own words about its own records, signed as such.
Answer a request (supplier)
- Open the link from the e-mail (
/proof-invite). The page shows who is asking and which template, before you have a session. - No account yet: choose Create your free workspace. The Free tier is enough to answer; see Free tier. Already have one: sign in; you return to the same page.
- The page shows the identity level you would answer at. If it asks you to prove the domain, it sends you to Proof → Prove a domain (Prove a domain). The invitation is remembered in this browser for 24 hours so you can come back and finish.
- Choose Accept and share. The grant is created in the workspace you are signed in to, never in one chosen by the link, and each granted claim's current receipt your level allows is delivered at once.
An invitation that is expired, used, withdrawn or unknown always reads the same, so a token cannot be probed. Accepting from the page shares every statement the template lists.
Some supplier actions exist on the API only, with no screen yet: choosing a subset of the claims when accepting, choosing a shorter grant life (the default and maximum are 365 days), declining a request, listing the grants you made, and revoking a grant. See the developer reference.
Read what a supplier shared (relying party)
Use Supplier assurance (/assurance): one card per supplier, one row
per claim, with freshness, drift and a Verify link on every receipt.
Withdraw a grant (supplier)
A supplier can revoke a grant at any time (API only today). The relying party reads nothing more under it from the next request on. Receipts already delivered stay verifiable, because they are signed documents; revoking stops future delivery and in-place reads. A grant also ends on its own when it expires, and when the relying party's organization is closing.
Common questions
Can the relying party see my other receipts or my evidence? No. It reads receipts only for the claims in the grant, only while the grant is active, and never the evidence salt or items.
Is the free workspace a trial? No. See Free tier for what it includes and its lifecycle. An idle Free workspace that has an active grant is not treated as dormant.
Is the Free-tier limit on shares enforced for grants? Not today. The plan sets a limit of three for relying-party sharing, but no route enforces it; see Free tier.
What did the requester learn when I declined? The request shows as Declined. Nothing else about your workspace is revealed.
Does CMDash guarantee the supplier's answer is true? No. A receipt proves what the supplier signed and that it has not been altered since; it does not prove the source system told the truth or that the control is effective. The verifier lists exactly what it does and does not establish.