This weekend we built and validated a trust-driven access control flow across our OpenID Federation demo stack.
Core outcome:
- If
app.idamaas.xyzis not an active trusted subordinate, API access is blocked. - If the required trust mark for
oidfapi.verifymy.idis revoked or missing, API access is blocked. - When either trust condition is restored, access is restored.
What We Developed
- Federation-aware app validation in
app.idamaas.xyz. - Trust-anchor-backed trust mark enforcement (no self-asserted shortcut).
- Admin trust mark lifecycle controls: issue, revoke, enable, cleanup.
- Diagnostics endpoints to explain trust decisions.
Demo Story 1: app.idamaas.xyz Enabled/Disabled
Enabled (expected success)
When app.idamaas.xyz is active as a subordinate:
- /demo/discover-and-call returns ok: true
- apiResult.ok is true
Disabled (expected block)
When app.idamaas.xyz is deactivated/deleted as subordinate:
- /demo/discover-and-call returns HTTP 403
- error is client_not_trusted
Demo Story 2: Trust Mark Enabled/Disabled
Trust mark enabled (expected success)
Required trust mark:
- issuer:
https://trust-anchor.zkp.au - id: urn:darkedges:trustmark:identity-verification
When active:
- trustMarkValidation.ok is true
- /demo/discover-and-call succeeds
Trust mark revoked (expected block)
When required trust mark is revoked:
- /demo/discover-and-call returns HTTP 403
- error is required_trust_mark_missing
Key Endpoints Used
- app demo flow:
GET /demo/discover-and-call - app diagnostics:
GET /demo/federation-details - trust mark list:
GET /federation_trust_mark_list - trust mark fetch:
GET /federation_trust_mark - subordinate admin:
/admin/subordinates - trust mark admin:
/admin/trust-marks
Operational Outcome
By the end of the weekend, trust state directly controlled access:
-
disable subordinate->blocked -
revoke trust mark->blocked -
re-enable either control->restored
This gives us a practical, explainable trust control model for federation demos and production hardening.







Top comments (0)