PP Auth: prove which platform is calling, and let the owner set terms

[coodos]

Description of change

An eVault cannot currently tell one platform from another. POST /platforms/certification mints a year-long token for any name a caller types in, and any registry-signed token bypasses access control outright — so "which platform is this?" has been answered by whoever asked.

PP Auth replaces that with a chain a caller has to hold the keys for. A deployment proves, on every handshake, which release it is running and what the association certified that release to do: it holds the deployment key, a named person's wallet authorised that key, the documents that person signed are unaltered, the version identifier derives from the platform and version, the author submitted that release, and the association certified it at a level for named domains. Six links, each failing closed, all six reported so a rejected handshake is debuggable.

The deployment presents its evidence rather than being looked up, so a verifier needs only public endpoints — never read access to the platform's eVault, which is the access it is trying to obtain.

The owner gets the other half. Certification says what a platform was found to be; an Access Policy says what the owner will deal with — the minimum level, whose reputation scores count and what score they must reach, and any domain refused outright. It is a signed statement, so it travels with the owner and anyone can check it. It can only narrow a certificate, never widen it: permitting finance does not let a social platform reach finance data, because the certificate gate runs first and independently.

A demonstrator at services/pp-auth-demo (port 4310, nothing else needs to be running). Chatterbox is social and L3; Ledgerly handles money and is L4. Point either at a domain it was not certified for and it is refused, with the reason. "Try to cheat" breaks one link at a time — paste your own public key, borrow the other platform's certificate — and the trace shows which link noticed.

The demonstrator's keys for the wallet, registry and association are generated in-process so it runs standalone. That is stated on the page and in the docs: the signatures and the verification are real, the roots are not. The minting facility is behind a separate entry point so it cannot be reached by accident from code that verifies real deployments.

Existing registry-minted platform tokens are untouched and keep working.

Issue Number

n/a

Type of change

New

How the change has been tested

• pnpm --filter @metastate-foundation/auth test — 33 passed. Each link refuses what it is there to refuse: a key the caller does not hold, evidence authorising a different environment, a version document swapped in from another release, an underivable version eName, a certificate for a different version, a certificate signed by an impostor, a refused release. Plus challenge replay, expiry and wrong-audience; the two authorisation gates; and policy signing, including a policy signed by someone other than the subject and one edited after signing.
• Exercised over HTTP against the running demonstrator: Chatterbox reaches social and is refused finance; Ledgerly the reverse. Each of the five tamper edits failed at exactly its intended link, and restoring returned the chain to green. Raising the owner's floor to L4 refused Chatterbox and kept Ledgerly; a reputation threshold of 50 did the reverse; denying communication refused it against a certificate that grants it.
• pnpm --filter pp-auth-demo check and build — 0 errors, 0 warnings. Docs site builds; the only broken anchors it reports are pre-existing in glossary and W3ID.
• pnpm --filter ppa test and check still pass — 20 tests, 0 errors.

Not done: the eVault does not yet enforce any of this. vault-access-guard still honours a registry token as a bypass. This PR is the library, the owner's terms and a demonstrator; changing the guard touches every platform at once and belongs in its own change.

Change checklist

• I have ensured that the CI Checks pass locally
• I have removed any unnecessary logic
• My code is well documented
• I have signed my commits
• My code follows the pattern of the application
• I have self reviewed my code

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on base/target branches other than the default branch.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: 71df237d-918c-4bb6-941c-5fc1a1298656

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[coodos]

Description of change

An eVault cannot currently tell one platform from another. POST /platforms/certification mints a year-long token for any name a caller types in, and any registry-signed token bypasses access control outright — so "which platform is this?" has been answered by whoever asked.

PP Auth replaces that with a chain a caller has to hold the keys for. A deployment proves, on every handshake, which release it is running and what the association certified that release to do: it holds the deployment key, a named person's wallet authorised that key, the documents that person signed are unaltered, the version identifier derives from the platform and version, the author submitted that release, and the association certified it at a level for named domains. Six links, each failing closed, all six reported so a rejected handshake is debuggable.

The deployment presents its evidence rather than being looked up, so a verifier needs only public endpoints — never read access to the platform's eVault, which is the access it is trying to obtain.

The owner gets the other half. Certification says what a platform was found to be; an Access Policy says what the owner will deal with — the minimum level, whose reputation scores count and what score they must reach, and any domain refused outright. It is a signed statement, so it travels with the owner and anyone can check it. It can only narrow a certificate, never widen it: permitting finance does not let a social platform reach finance data, because the certificate gate runs first and independently.

A demonstrator at services/pp-auth-demo (port 4310, nothing else needs to be running). Chatterbox is social and L3; Ledgerly handles money and is L4. Point either at a domain it was not certified for and it is refused, with the reason. "Try to cheat" breaks one link at a time — paste your own public key, borrow the other platform's certificate — and the trace shows which link noticed.

The demonstrator's keys for the wallet, registry and association are generated in-process so it runs standalone. That is stated on the page and in the docs: the signatures and the verification are real, the roots are not. The minting facility is behind a separate entry point so it cannot be reached by accident from code that verifies real deployments.

Existing registry-minted platform tokens are untouched and keep working.

Issue Number

n/a

Type of change

New

How the change has been tested

• pnpm --filter @metastate-foundation/auth test — 33 passed. Each link refuses what it is there to refuse: a key the caller does not hold, evidence authorising a different environment, a version document swapped in from another release, an underivable version eName, a certificate for a different version, a certificate signed by an impostor, a refused release. Plus challenge replay, expiry and wrong-audience; the two authorisation gates; and policy signing, including a policy signed by someone other than the subject and one edited after signing.
• Exercised over HTTP against the running demonstrator: Chatterbox reaches social and is refused finance; Ledgerly the reverse. Each of the five tamper edits failed at exactly its intended link, and restoring returned the chain to green. Raising the owner's floor to L4 refused Chatterbox and kept Ledgerly; a reputation threshold of 50 did the reverse; denying communication refused it against a certificate that grants it.
• pnpm --filter pp-auth-demo check and build — 0 errors, 0 warnings. Docs site builds; the only broken anchors it reports are pre-existing in glossary and W3ID.
• pnpm --filter ppa test and check still pass — 20 tests, 0 errors.

Not done: the eVault does not yet enforce any of this. vault-access-guard still honours a registry token as a bypass. This PR is the library, the owner's terms and a demonstrator; changing the guard touches every platform at once and belongs in its own change.

Change checklist

• I have ensured that the CI Checks pass locally
• I have removed any unnecessary logic
• My code is well documented
• I have signed my commits
• My code follows the pattern of the application
• I have self reviewed my code

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on base/target branches other than the default branch.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: 71df237d-918c-4bb6-941c-5fc1a1298656

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[coodos]

Description of change

An eVault cannot currently tell one platform from another. POST /platforms/certification mints a year-long token for any name a caller types in, and any registry-signed token bypasses access control outright — so "which platform is this?" has been answered by whoever asked.

PP Auth replaces that with a chain a caller has to hold the keys for. A deployment proves, on every handshake, which release it is running and what the association certified that release to do: it holds the deployment key, a named person's wallet authorised that key, the documents that person signed are unaltered, the version identifier derives from the platform and version, the author submitted that release, and the association certified it at a level for named domains. Six links, each failing closed, all six reported so a rejected handshake is debuggable.

The deployment presents its evidence rather than being looked up, so a verifier needs only public endpoints — never read access to the platform's eVault, which is the access it is trying to obtain.

The owner gets the other half. Certification says what a platform was found to be; an Access Policy says what the owner will deal with — the minimum level, whose reputation scores count and what score they must reach, and any domain refused outright. It is a signed statement, so it travels with the owner and anyone can check it. It can only narrow a certificate, never widen it: permitting finance does not let a social platform reach finance data, because the certificate gate runs first and independently.

A demonstrator at services/pp-auth-demo (port 4310, nothing else needs to be running). Chatterbox is social and L3; Ledgerly handles money and is L4. Point either at a domain it was not certified for and it is refused, with the reason. "Try to cheat" breaks one link at a time — paste your own public key, borrow the other platform's certificate — and the trace shows which link noticed.

The demonstrator's keys for the wallet, registry and association are generated in-process so it runs standalone. That is stated on the page and in the docs: the signatures and the verification are real, the roots are not. The minting facility is behind a separate entry point so it cannot be reached by accident from code that verifies real deployments.

Existing registry-minted platform tokens are untouched and keep working.

Issue Number

n/a

Type of change

New

How the change has been tested

• pnpm --filter @metastate-foundation/auth test — 33 passed. Each link refuses what it is there to refuse: a key the caller does not hold, evidence authorising a different environment, a version document swapped in from another release, an underivable version eName, a certificate for a different version, a certificate signed by an impostor, a refused release. Plus challenge replay, expiry and wrong-audience; the two authorisation gates; and policy signing, including a policy signed by someone other than the subject and one edited after signing.
• Exercised over HTTP against the running demonstrator: Chatterbox reaches social and is refused finance; Ledgerly the reverse. Each of the five tamper edits failed at exactly its intended link, and restoring returned the chain to green. Raising the owner's floor to L4 refused Chatterbox and kept Ledgerly; a reputation threshold of 50 did the reverse; denying communication refused it against a certificate that grants it.
• pnpm --filter pp-auth-demo check and build — 0 errors, 0 warnings. Docs site builds; the only broken anchors it reports are pre-existing in glossary and W3ID.
• pnpm --filter ppa test and check still pass — 20 tests, 0 errors.

Not done: the eVault does not yet enforce any of this. vault-access-guard still honours a registry token as a bypass. This PR is the library, the owner's terms and a demonstrator; changing the guard touches every platform at once and belongs in its own change.

Change checklist

• I have ensured that the CI Checks pass locally
• I have removed any unnecessary logic
• My code is well documented
• I have signed my commits
• My code follows the pattern of the application
• I have self reviewed my code

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on base/target branches other than the default branch.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: 71df237d-918c-4bb6-941c-5fc1a1298656

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[coodos]

Description of change

An eVault cannot currently tell one platform from another. POST /platforms/certification mints a year-long token for any name a caller types in, and any registry-signed token bypasses access control outright — so "which platform is this?" has been answered by whoever asked.

PP Auth replaces that with a chain a caller has to hold the keys for. A deployment proves, on every handshake, which release it is running and what the association certified that release to do: it holds the deployment key, a named person's wallet authorised that key, the documents that person signed are unaltered, the version identifier derives from the platform and version, the author submitted that release, and the association certified it at a level for named domains. Six links, each failing closed, all six reported so a rejected handshake is debuggable.

The deployment presents its evidence rather than being looked up, so a verifier needs only public endpoints — never read access to the platform's eVault, which is the access it is trying to obtain.

The owner gets the other half. Certification says what a platform was found to be; an Access Policy says what the owner will deal with — the minimum level, whose reputation scores count and what score they must reach, and any domain refused outright. It is a signed statement, so it travels with the owner and anyone can check it. It can only narrow a certificate, never widen it: permitting finance does not let a social platform reach finance data, because the certificate gate runs first and independently.

A demonstrator at services/pp-auth-demo (port 4310, nothing else needs to be running). Chatterbox is social and L3; Ledgerly handles money and is L4. Point either at a domain it was not certified for and it is refused, with the reason. "Try to cheat" breaks one link at a time — paste your own public key, borrow the other platform's certificate — and the trace shows which link noticed.

The demonstrator's keys for the wallet, registry and association are generated in-process so it runs standalone. That is stated on the page and in the docs: the signatures and the verification are real, the roots are not. The minting facility is behind a separate entry point so it cannot be reached by accident from code that verifies real deployments.

Existing registry-minted platform tokens are untouched and keep working.

Issue Number

n/a

Type of change

New

How the change has been tested

• pnpm --filter @metastate-foundation/auth test — 33 passed. Each link refuses what it is there to refuse: a key the caller does not hold, evidence authorising a different environment, a version document swapped in from another release, an underivable version eName, a certificate for a different version, a certificate signed by an impostor, a refused release. Plus challenge replay, expiry and wrong-audience; the two authorisation gates; and policy signing, including a policy signed by someone other than the subject and one edited after signing.
• Exercised over HTTP against the running demonstrator: Chatterbox reaches social and is refused finance; Ledgerly the reverse. Each of the five tamper edits failed at exactly its intended link, and restoring returned the chain to green. Raising the owner's floor to L4 refused Chatterbox and kept Ledgerly; a reputation threshold of 50 did the reverse; denying communication refused it against a certificate that grants it.
• pnpm --filter pp-auth-demo check and build — 0 errors, 0 warnings. Docs site builds; the only broken anchors it reports are pre-existing in glossary and W3ID.
• pnpm --filter ppa test and check still pass — 20 tests, 0 errors.

Not done: the eVault does not yet enforce any of this. vault-access-guard still honours a registry token as a bypass. This PR is the library, the owner's terms and a demonstrator; changing the guard touches every platform at once and belongs in its own change.

Change checklist

• I have ensured that the CI Checks pass locally
• I have removed any unnecessary logic
• My code is well documented
• I have signed my commits
• My code follows the pattern of the application
• I have self reviewed my code

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on base/target branches other than the default branch.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: 71df237d-918c-4bb6-941c-5fc1a1298656

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[coodos]

Description of change

An eVault cannot currently tell one platform from another. POST /platforms/certification mints a year-long token for any name a caller types in, and any registry-signed token bypasses access control outright — so "which platform is this?" has been answered by whoever asked.

PP Auth replaces that with a chain a caller has to hold the keys for. A deployment proves, on every handshake, which release it is running and what the association certified that release to do: it holds the deployment key, a named person's wallet authorised that key, the documents that person signed are unaltered, the version identifier derives from the platform and version, the author submitted that release, and the association certified it at a level for named domains. Six links, each failing closed, all six reported so a rejected handshake is debuggable.

The deployment presents its evidence rather than being looked up, so a verifier needs only public endpoints — never read access to the platform's eVault, which is the access it is trying to obtain.

The owner gets the other half. Certification says what a platform was found to be; an Access Policy says what the owner will deal with — the minimum level, whose reputation scores count and what score they must reach, and any domain refused outright. It is a signed statement, so it travels with the owner and anyone can check it. It can only narrow a certificate, never widen it: permitting finance does not let a social platform reach finance data, because the certificate gate runs first and independently.

A demonstrator at services/pp-auth-demo (port 4310, nothing else needs to be running). Chatterbox is social and L3; Ledgerly handles money and is L4. Point either at a domain it was not certified for and it is refused, with the reason. "Try to cheat" breaks one link at a time — paste your own public key, borrow the other platform's certificate — and the trace shows which link noticed.

The demonstrator's keys for the wallet, registry and association are generated in-process so it runs standalone. That is stated on the page and in the docs: the signatures and the verification are real, the roots are not. The minting facility is behind a separate entry point so it cannot be reached by accident from code that verifies real deployments.

Existing registry-minted platform tokens are untouched and keep working.

Issue Number

n/a

Type of change

New

How the change has been tested

• pnpm --filter @metastate-foundation/auth test — 33 passed. Each link refuses what it is there to refuse: a key the caller does not hold, evidence authorising a different environment, a version document swapped in from another release, an underivable version eName, a certificate for a different version, a certificate signed by an impostor, a refused release. Plus challenge replay, expiry and wrong-audience; the two authorisation gates; and policy signing, including a policy signed by someone other than the subject and one edited after signing.
• Exercised over HTTP against the running demonstrator: Chatterbox reaches social and is refused finance; Ledgerly the reverse. Each of the five tamper edits failed at exactly its intended link, and restoring returned the chain to green. Raising the owner's floor to L4 refused Chatterbox and kept Ledgerly; a reputation threshold of 50 did the reverse; denying communication refused it against a certificate that grants it.
• pnpm --filter pp-auth-demo check and build — 0 errors, 0 warnings. Docs site builds; the only broken anchors it reports are pre-existing in glossary and W3ID.
• pnpm --filter ppa test and check still pass — 20 tests, 0 errors.

Not done: the eVault does not yet enforce any of this. vault-access-guard still honours a registry token as a bypass. This PR is the library, the owner's terms and a demonstrator; changing the guard touches every platform at once and belongs in its own change.

Change checklist

• I have ensured that the CI Checks pass locally
• I have removed any unnecessary logic
• My code is well documented
• I have signed my commits
• My code follows the pattern of the application
• I have self reviewed my code

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on base/target branches other than the default branch.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: 71df237d-918c-4bb6-941c-5fc1a1298656

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[coodos]

Description of change

An eVault cannot currently tell one platform from another. POST /platforms/certification mints a year-long token for any name a caller types in, and any registry-signed token bypasses access control outright — so "which platform is this?" has been answered by whoever asked.

PP Auth replaces that with a chain a caller has to hold the keys for. A deployment proves, on every handshake, which release it is running and what the association certified that release to do: it holds the deployment key, a named person's wallet authorised that key, the documents that person signed are unaltered, the version identifier derives from the platform and version, the author submitted that release, and the association certified it at a level for named domains. Six links, each failing closed, all six reported so a rejected handshake is debuggable.

The deployment presents its evidence rather than being looked up, so a verifier needs only public endpoints — never read access to the platform's eVault, which is the access it is trying to obtain.

The owner gets the other half. Certification says what a platform was found to be; an Access Policy says what the owner will deal with — the minimum level, whose reputation scores count and what score they must reach, and any domain refused outright. It is a signed statement, so it travels with the owner and anyone can check it. It can only narrow a certificate, never widen it: permitting finance does not let a social platform reach finance data, because the certificate gate runs first and independently.

A demonstrator at services/pp-auth-demo (port 4310, nothing else needs to be running). Chatterbox is social and L3; Ledgerly handles money and is L4. Point either at a domain it was not certified for and it is refused, with the reason. "Try to cheat" breaks one link at a time — paste your own public key, borrow the other platform's certificate — and the trace shows which link noticed.

The demonstrator's keys for the wallet, registry and association are generated in-process so it runs standalone. That is stated on the page and in the docs: the signatures and the verification are real, the roots are not. The minting facility is behind a separate entry point so it cannot be reached by accident from code that verifies real deployments.

Existing registry-minted platform tokens are untouched and keep working.

Issue Number

n/a

Type of change

New

How the change has been tested

• pnpm --filter @metastate-foundation/auth test — 33 passed. Each link refuses what it is there to refuse: a key the caller does not hold, evidence authorising a different environment, a version document swapped in from another release, an underivable version eName, a certificate for a different version, a certificate signed by an impostor, a refused release. Plus challenge replay, expiry and wrong-audience; the two authorisation gates; and policy signing, including a policy signed by someone other than the subject and one edited after signing.
• Exercised over HTTP against the running demonstrator: Chatterbox reaches social and is refused finance; Ledgerly the reverse. Each of the five tamper edits failed at exactly its intended link, and restoring returned the chain to green. Raising the owner's floor to L4 refused Chatterbox and kept Ledgerly; a reputation threshold of 50 did the reverse; denying communication refused it against a certificate that grants it.
• pnpm --filter pp-auth-demo check and build — 0 errors, 0 warnings. Docs site builds; the only broken anchors it reports are pre-existing in glossary and W3ID.
• pnpm --filter ppa test and check still pass — 20 tests, 0 errors.

Not done: the eVault does not yet enforce any of this. vault-access-guard still honours a registry token as a bypass. This PR is the library, the owner's terms and a demonstrator; changing the guard touches every platform at once and belongs in its own change.

Change checklist

• I have ensured that the CI Checks pass locally
• I have removed any unnecessary logic
• My code is well documented
• I have signed my commits
• My code follows the pattern of the application
• I have self reviewed my code

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on base/target branches other than the default branch.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: 71df237d-918c-4bb6-941c-5fc1a1298656

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[coodos]

Description of change

An eVault cannot currently tell one platform from another. POST /platforms/certification mints a year-long token for any name a caller types in, and any registry-signed token bypasses access control outright — so "which platform is this?" has been answered by whoever asked.

PP Auth replaces that with a chain a caller has to hold the keys for. A deployment proves, on every handshake, which release it is running and what the association certified that release to do: it holds the deployment key, a named person's wallet authorised that key, the documents that person signed are unaltered, the version identifier derives from the platform and version, the author submitted that release, and the association certified it at a level for named domains. Six links, each failing closed, all six reported so a rejected handshake is debuggable.

The deployment presents its evidence rather than being looked up, so a verifier needs only public endpoints — never read access to the platform's eVault, which is the access it is trying to obtain.

The owner gets the other half. Certification says what a platform was found to be; an Access Policy says what the owner will deal with — the minimum level, whose reputation scores count and what score they must reach, and any domain refused outright. It is a signed statement, so it travels with the owner and anyone can check it. It can only narrow a certificate, never widen it: permitting finance does not let a social platform reach finance data, because the certificate gate runs first and independently.

A demonstrator at services/pp-auth-demo (port 4310, nothing else needs to be running). Chatterbox is social and L3; Ledgerly handles money and is L4. Point either at a domain it was not certified for and it is refused, with the reason. "Try to cheat" breaks one link at a time — paste your own public key, borrow the other platform's certificate — and the trace shows which link noticed.

The demonstrator's keys for the wallet, registry and association are generated in-process so it runs standalone. That is stated on the page and in the docs: the signatures and the verification are real, the roots are not. The minting facility is behind a separate entry point so it cannot be reached by accident from code that verifies real deployments.

Existing registry-minted platform tokens are untouched and keep working.

Issue Number

n/a

Type of change

New

How the change has been tested

• pnpm --filter @metastate-foundation/auth test — 33 passed. Each link refuses what it is there to refuse: a key the caller does not hold, evidence authorising a different environment, a version document swapped in from another release, an underivable version eName, a certificate for a different version, a certificate signed by an impostor, a refused release. Plus challenge replay, expiry and wrong-audience; the two authorisation gates; and policy signing, including a policy signed by someone other than the subject and one edited after signing.
• Exercised over HTTP against the running demonstrator: Chatterbox reaches social and is refused finance; Ledgerly the reverse. Each of the five tamper edits failed at exactly its intended link, and restoring returned the chain to green. Raising the owner's floor to L4 refused Chatterbox and kept Ledgerly; a reputation threshold of 50 did the reverse; denying communication refused it against a certificate that grants it.
• pnpm --filter pp-auth-demo check and build — 0 errors, 0 warnings. Docs site builds; the only broken anchors it reports are pre-existing in glossary and W3ID.
• pnpm --filter ppa test and check still pass — 20 tests, 0 errors.

Not done: the eVault does not yet enforce any of this. vault-access-guard still honours a registry token as a bypass. This PR is the library, the owner's terms and a demonstrator; changing the guard touches every platform at once and belongs in its own change.

Change checklist

• I have ensured that the CI Checks pass locally
• I have removed any unnecessary logic
• My code is well documented
• I have signed my commits
• My code follows the pattern of the application
• I have self reviewed my code

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on base/target branches other than the default branch.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: 71df237d-918c-4bb6-941c-5fc1a1298656

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[coodos]

Description of change

An eVault cannot currently tell one platform from another. POST /platforms/certification mints a year-long token for any name a caller types in, and any registry-signed token bypasses access control outright — so "which platform is this?" has been answered by whoever asked.

PP Auth replaces that with a chain a caller has to hold the keys for. A deployment proves, on every handshake, which release it is running and what the association certified that release to do: it holds the deployment key, a named person's wallet authorised that key, the documents that person signed are unaltered, the version identifier derives from the platform and version, the author submitted that release, and the association certified it at a level for named domains. Six links, each failing closed, all six reported so a rejected handshake is debuggable.

The deployment presents its evidence rather than being looked up, so a verifier needs only public endpoints — never read access to the platform's eVault, which is the access it is trying to obtain.

The owner gets the other half. Certification says what a platform was found to be; an Access Policy says what the owner will deal with — the minimum level, whose reputation scores count and what score they must reach, and any domain refused outright. It is a signed statement, so it travels with the owner and anyone can check it. It can only narrow a certificate, never widen it: permitting finance does not let a social platform reach finance data, because the certificate gate runs first and independently.

A demonstrator at services/pp-auth-demo (port 4310, nothing else needs to be running). Chatterbox is social and L3; Ledgerly handles money and is L4. Point either at a domain it was not certified for and it is refused, with the reason. "Try to cheat" breaks one link at a time — paste your own public key, borrow the other platform's certificate — and the trace shows which link noticed.

The demonstrator's keys for the wallet, registry and association are generated in-process so it runs standalone. That is stated on the page and in the docs: the signatures and the verification are real, the roots are not. The minting facility is behind a separate entry point so it cannot be reached by accident from code that verifies real deployments.

Existing registry-minted platform tokens are untouched and keep working.

Issue Number

n/a

Type of change

New

How the change has been tested

• pnpm --filter @metastate-foundation/auth test — 33 passed. Each link refuses what it is there to refuse: a key the caller does not hold, evidence authorising a different environment, a version document swapped in from another release, an underivable version eName, a certificate for a different version, a certificate signed by an impostor, a refused release. Plus challenge replay, expiry and wrong-audience; the two authorisation gates; and policy signing, including a policy signed by someone other than the subject and one edited after signing.
• Exercised over HTTP against the running demonstrator: Chatterbox reaches social and is refused finance; Ledgerly the reverse. Each of the five tamper edits failed at exactly its intended link, and restoring returned the chain to green. Raising the owner's floor to L4 refused Chatterbox and kept Ledgerly; a reputation threshold of 50 did the reverse; denying communication refused it against a certificate that grants it.
• pnpm --filter pp-auth-demo check and build — 0 errors, 0 warnings. Docs site builds; the only broken anchors it reports are pre-existing in glossary and W3ID.
• pnpm --filter ppa test and check still pass — 20 tests, 0 errors.

Not done: the eVault does not yet enforce any of this. vault-access-guard still honours a registry token as a bypass. This PR is the library, the owner's terms and a demonstrator; changing the guard touches every platform at once and belongs in its own change.

Change checklist

• I have ensured that the CI Checks pass locally
• I have removed any unnecessary logic
• My code is well documented
• I have signed my commits
• My code follows the pattern of the application
• I have self reviewed my code

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on base/target branches other than the default branch.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: 71df237d-918c-4bb6-941c-5fc1a1298656

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}