Skip to content

spec: define 'align' for publisher authority binding (§4.5.1) #98

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
sachinsharma3191 wants to merge 1 commit into
base: main
Choose a base branch
from
+2 −2
Open

spec: define 'align' for publisher authority binding (§4.5.1) #98

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 2 additions & 2 deletions spec/ard.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -174,7 +174,7 @@ Identity binding, compliance attestations, provenance, and cryptographic signatu

#### 4.5.1 Publisher Authority Binding

The cryptographic trust domain asserted in `trustManifest.identity` MUST align with the `<publisher>` domain embedded in the entry's discovery identifier (Appendix C). This is ARD's defense against namespace squatting: an entry claiming `urn:air:google.com:...` is rejected by a verifying registry unless it can produce a verifiable attestation issued by `google.com`. The discovery identifier and the security principal are otherwise decoupled — the former is a stable searchable handle, the latter a dynamic cryptographic credential.
The cryptographic trust domain asserted in `trustManifest.identity` MUST align with the `<publisher>` domain embedded in the entry's discovery identifier (Appendix C). The trust domain aligns with the publisher when it equals the publisher domain, or is a subdomain of it, after case folding, and the publisher domain is not a public suffix. Domains are compared as A-labels, so an internationalised domain name is converted before the comparison. For example, with the identifier `urn:air:acme.com:server:weather`, the identity `spiffe://prod.acme.com/ns/prod/sa/weather` aligns, while `spiffe://acme.com.evil.example/...` does not; an entry claiming `urn:air:co.uk:...` cannot align with any identity, because `co.uk` is a public suffix. This is ARD's defense against namespace squatting: an entry claiming `urn:air:google.com:...` is rejected by a verifying registry unless it can produce a verifiable attestation issued by `google.com`. The discovery identifier and the security principal are otherwise decoupled — the former is a stable searchable handle, the latter a dynamic cryptographic credential.

@mindpower mindpower Oct 11, 2026

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for putting this together, @sachinsharma3191

One concern with allowing any subdomain to match by default: in many deployments, subdomains (dev.acme.com, staging.acme.com, vendor-hosted subdomains, or multi-tenant hosts) are operated at a lower trust level than the apex domain. If spiffe://dev.acme.com/... or did:web:dev.acme.com automatically aligns with urn:air:acme.com:..., a lower-trust subdomain can mint entries under the root acme.com namespace without acme.com's authorization.

It would be safer (and simpler) to require an exact domain match between the trust domain and (both as lowercase ASCII A-labels, since §4.2 already requires to be lowercase. If prod.acme.com is its own trust domain, it can either publish as urn:air:prod.acme.com:... or be explicitly delegated by acme.com at the key/DID/bundle layer. That also avoids needing verifiers to bundle and maintain a Public Suffix List just to guard subdomain matching.


#### 4.5.2 Verification

Expand Down Expand Up @@ -539,7 +539,7 @@ npx ajv-cli validate -s spec/schemas/ard-entry.schema.json -d path/to/entry.json
Beyond structural validity, conformance checks the following:

* `representativeQueries` is present and contains 2–5 examples (§4.2) — **warning**, not error: an entry that omits it or supplies a different count still validates structurally, but is flagged, since it will not be found by search.
* The URN publisher domain MUST align with `trustManifest.identity` (§4.5.1).
* The URN publisher domain MUST align with `trustManifest.identity`, as defined in §4.5.1 (equal to, or a subdomain of, the publisher domain; the publisher is not a public suffix).
* `capabilities` are treated as structured filter tokens (§5.3.1).

### D.3 The Registry REST API Specification (OpenAPI)
Expand Down