AAuth at aauth.sidecat.dev

These are public AAuth servers you can call, and conformance reports for the servers on this host. The Rust servers are aauth-rust 0.1.0-alpha.28. The Go servers are aauth-go ad34a9a. The suite is aauth-conformance f415f2f, in remote mode.

Get an exchange

With an agent key of your own, the exchange is the six calls below. The Person Server binds every accepted person to the subject directed-person-1 and grants only the scope read. A person token lasts 60 seconds. An auth token lasts 180 seconds. An agent token from the provider below lasts 3600 seconds.

1. Enroll the durable key at the Agent Provider.
2. Refresh it into an agent token. The token’s ps is https://ps.aauth.sidecat.dev.
3. POST https://ps.aauth.sidecat.dev/person, signed by that agent token, with {"resource":"https://rs.aauth.sidecat.dev"}. The answer is 200 and a person_token.
4. GET https://rs.aauth.sidecat.dev/records with the person token. The resource answers 401 and AAuth-Requirement: requirement=auth-token;resource-token="…".
5. POST https://ps.aauth.sidecat.dev/token, signed by the agent token, with {"resource_token":"…","presented_token":"…"}. presented_token is the person token from step 3, and resource_token is the value from step 4. The answer is 200 and an auth_token.
6. GET https://rs.aauth.sidecat.dev/records with that auth token. The answer is 200 {"sub":"directed-person-1"}.

Agent Provider

https://ap.aauth.sidecat.dev

Metadata is GET /.well-known/aauth-agent.json. Keys are GET /.well-known/jwks.json.

POST /bootstrap/enroll is signed with the HTTP signature label sig, scheme hwk, by the durable key (Ed25519 or ES256). Cover @method, @authority, @path and signature-key. The body is a JSON object, application/json; {} is enough. Cover content-type and content-digest as well. created has to be within 60 seconds of this server’s clock. A new key is answered 201 {"agent":"aauth:<local>@ap.aauth.sidecat.dev"}. The local part is the key’s thumbprint, so the same key gets the same identifier.

POST /bootstrap/refresh uses scheme jkt-jwt and is answered 200 {"agent_token":"…"}. This provider does not offer single-key refresh or sub-agent tokens.

Enrollments are kept in memory. After the provider restarts, enroll the key again. The signing key does not change across that restart, and the identifier does not change.

Person Server

https://ps.aauth.sidecat.dev is a direct Person Server. Metadata is /.well-known/aauth-person.json. POST /person issues the person token. POST /token issues the auth token. Any scope other than read is refused.

Resource

https://rs.aauth.sidecat.dev is a three-party resource. The protected route is GET /records. It trusts the Agent Provider and the Person Server on this page. A token from the four-party Access Server does not open it.

Servers

Rust reference roles, one process, plus the two public hosts above.

GET https://api.aauth.sidecat.dev/whoami answers 200 {"sub":"<agent identifier>"} for a verified agent. It trusts the bootstrap provider above and the suite’s fixture provider. It is not the resource in the exchange: a direct person-server token is for rs, and a four-party token is for records.

The Go servers are the same roles with go- in front of the host name: https://go-ps.aauth.sidecat.dev, https://go-as.aauth.sidecat.dev, https://go-fps.aauth.sidecat.dev, https://go-api.aauth.sidecat.dev/whoami, https://go-records.aauth.sidecat.dev/records, https://go-eap.aauth.sidecat.dev, https://go-events.aauth.sidecat.dev/events/subscribe, https://go-ss.aauth.sidecat.dev, https://go-sps.aauth.sidecat.dev, https://go-r3.aauth.sidecat.dev/authorize, https://go-r3-direct.aauth.sidecat.dev/authorize, https://go-r3-person.aauth.sidecat.dev, https://go-verifier.aauth.sidecat.dev/verify. Go also serves the four-party R3 issuer at https://go-r3-ps.aauth.sidecat.dev and https://go-r3-access.aauth.sidecat.dev. The Go servers do not trust the public bootstrap provider.

Suite host controls are not published. Names under conformance.test are not public DNS. They are how the suite on this host reaches its own fixture parties.

Run the suite against these servers

The grade is a remote-mode run of aauth-conformance. The reports are at /reports/. Each report has report.md, report.json, and this site renders the markdown.

A full run executes here. These servers send *.conformance.test to the suite process on this host, and the suite sends the role URLs to the servers on loopback. A suite on another machine can call the public URLs. Scenarios that never call a fixture party run that way. Scenarios that call back do not see the other suite.

To ask for a fresh grade of these servers, open an issue and say which roles.

Have this suite grade your servers

Open an issue on sidecat-dev/aauth-hosted. Give the base URLs and the roles. Runs are taken from that list. There is no URL that starts a run.

Your servers have to reach the suite’s fixture names for the scenarios that call back. That route is arranged for the run; it is not a public DNS name. The report is saved at https://aauth.sidecat.dev/reports/<id>/ and left there.

To grade a deployment yourself, use remote mode in the conformance README. The deployment file names the same fields the reports use: resource URL, person server, access server, agent provider, supervision server, agent identifier, and control URL where the role has one.

Source

The Caddy config, systemd units, this page, and the public server are in sidecat-dev/aauth-hosted. The README there is how to run a copy and how to operate this one.