Use cases

One identity: Atlantis ID with a passkey (2 min)

1. Atlantis ID → Sign in → Continue with a passkey.
2. Account page: name, date of birth, Atlantis ID number, SIGNED IN · PASSKEY · TDIF IP1 / CL2.
3. Dashboard: the Auth0 lane shows the sign-in; the Atlantis ID lane shows the ID token verified with auth_methods: passkey.

Point at the sign-in page: it's Auth0 Universal Login, branded as Atlantis ID on its own domain login.id-atlantis.xyz. The dashboard's Auth0 lane shows Auth0's own log of the sign-in.

Say: "Atlantis ID runs on Auth0, which does the hard part: passwords, passkeys, resets. This passkey is phishing-resistant MFA: it's bound to this site, unlocked with Face ID or Touch ID, and there's no secret to steal. In TDIF terms that's credential level 2; a password alone is level 1."

Agency A through the exchange (4 min)

1. Agency A → Sign in. The exchange asks "Who should confirm it's you?" → Atlantis ID. Auth0 remembers you from step 1.
2. Exchange consent screen: "Agency A wants: profile, email" → Yes.
3. Agency A: "Do you already have an Agency A account?" → No, open a new account.
4. Account page: records, the assurance level, the exchange audit ID, and "Sign-in 1" with a pairwise identifier.
5. Dashboard: the request object was signed and encrypted; the exchange checked consent, issued a pairwise identifier, and deleted your name and email straight after (exchange.attributes_purged).

Point at "Who should confirm it's you?": that page is the identity exchange, Keycloak with an Atlantis theme. The dashboard's Exchange (Keycloak) lane shows Keycloak's own events.

Say: "Agency A doesn't talk to Auth0 at all. It talks to the identity exchange, which runs on Keycloak. The exchange is double-blind: Agency A authenticated with a private key, sent an encrypted, signed request, and got an identifier only Agency A can use. It never learned it was Atlantis ID, and the exchange kept nothing about you once Agency A had its tokens."

Agency C: the same person, a different identifier (2 min)

1. Agency C tab → Sign in → the exchange asks which provider again → Atlantis ID (Auth0 remembers you, no passkey prompt). Consent: this is a different agency, so it asks again → Yes.
2. Agency C doesn't recognise you → No, open a new account (C-00001).
3. Put the Agency A and Agency C account pages side by side. The pairwise identifier under "Sign-ins linked to this account" is different at each.

Say: "Same person, same provider, two agencies. Each gets an identifier that's useless anywhere else, so they can't join their records behind your back."

Step-up for a sensitive action (3 min)

1. Back on the Agency A tab → Change payment details → Confirm it's you.
2. The exchange offers only the provider you used. Auth0 asks you to sign in again → passkey.
3. Agency A opens the change form: "Confirmed with TDIF IP1 / CL2".
4. Dashboard: step_up.started, acr.essential_met, step_up.completed.

Say: "Agency A asked for level two as an essential requirement. Had I used a password, or Poseidon ID, the exchange would have refused rather than pass on a weaker sign-in." (Extra E3 shows the refusal.)

Credential to the wallet, sign-in at Agency B (4 min)

1. Atlantis ID account page → Add Atlantis ID to wallet → QR + 4-digit code.
2. Phone: Atlantis Wallet → Scan the Atlantis ID QR code → enter the code → Add to wallet. Show the card.
3. Agency B → Sign in with Atlantis ID wallet → QR.
4. Phone: Scan a sign-in QR code → consent sheet: four fields shared, birthdate and email not shared → Approve and share.
5. Laptop signs in by itself: "Welcome, [your given name] … Not shared: date of birth and email."
6. Dashboard: did.resolved, presentation.verified, account.created. No Auth0 or exchange events.

Say: "Atlantis ID, the identity provider, issued that credential. Agency B trusts it because it checks the signature against the key Atlantis ID publishes at did:web:id-atlantis.xyz, and it checks the credential is bound to this phone. It signed me in and got only the four details it asked for. No exchange and no identity provider at sign-in time."

Close (30 seconds), the four messages: "Real products: Auth0 for the identity provider, Keycloak for the exchange. Double-blind: two agencies, two identifiers, no way to link them. Phishing-resistant MFA with passkeys, enforced where it matters. And a verifiable credential an agency can trust without calling anyone. All of it follows the technical profile of TDIF, now the AGDIS Data Standards: alignment, not accreditation."

A second provider and account linking (4 min)

1. Agency A → Sign out. Sign in → Poseidon ID → Register (any email, e.g. demo+<date>@example.test, password at least 8 characters).
2. Consent at the exchange → Yes.
3. Agency A: "Do you already have an account?" → Yes, link this sign-in. Enter the account number (A-00001) and a wrong reference first → refused. Then a real one from the account page (e.g. VR-1234) → linked.
4. The account page now lists two sign-ins, with different pairwise identifiers and levels (CL2 passkey, CL1 Poseidon password).

Say: "Two providers, two identifiers, one citizen. The agency can't correlate them itself; it asks the citizen to prove record ownership."

The standards view (2 min)

Dashboard → tick TDIF profile only. Each remaining event carries the AGDIS Data Standards 2024 clause it demonstrates. The header shows Audit chain ✓. docs/TDIF_GAP_LIST.md has the full table: every row met, apart from two Auth0 plan limits (signed request objects to Auth0, Auth0's own sub).

Step-up refused (2 min, after E1)

Signed in to Agency A with Poseidon ID → Change payment details → Confirm it's you → Poseidon password. The exchange refuses: "This needs a stronger sign-in". Dashboard: acr.essential_unmet.

Agency A passkey (2 min)

Agency A account page → Add a passkey → saves a passkey for agency-a-atlantis.xyz. Sign out, then Sign in with an Agency A passkey. The dashboard shows passkey.authenticated and no exchange or Auth0 events. Step-up still goes through the exchange.

Consent and logout at the exchange (2 min)

Agency A account page → Manage consent at the exchange → expand Agency A → Remove access. Then sign out at the exchange: Agency A is signed out too (front-channel logout), and the next sign-in asks for consent again.

Trust failure (2 min, after step 5)

Atlantis ID account → Demo: trust failure → Get an untrusted test credential → add it to the wallet → Agency B sign-in. Agency B refuses: "not on the trusted issuer list". Afterwards, add the real credential again from Add Atlantis ID to wallet, because the wallet keeps the last one.

Say: "The signature is perfectly valid. What fails is trust: Agency B only accepts credentials from issuers it has chosen to trust."

User management at Atlantis ID (1 min)

Atlantis ID → User management → search, block, send reset, remove passkey. These are Management API calls; the dashboard shows them as ADMIN events.

Prove who you are with your passport: IP1 Plus, then IP2 (5 min)

Before: on the Atlantis ID account page, Identity verification shows IP1. If it doesn't, press Remove identity verification.

1. Agency C (signed in with the Atlantis ID passkey) → Open your full health record → Confirm it's you → passkey. The exchange refuses: "needs TDIF IP2 / CL2; the sign-in achieved TDIF IP1 / CL2". Dashboard: acr.essential_unmet.
2. Atlantis ID account → Verify with your passport → QR code.
3. Phone: Atlantis Wallet → Scan → the passport sheet → passport number, date of birth and expiry from the photo page → Hold passport to iPhone. Hold the top of the phone flat on the photo page until it says it's done (5 to 15 seconds).
4. The wallet shows each check: hashes match, signed by the Document Signer, chains to DFAT's CSCA, not revoked, MRZ valid. The laptop page turns to "Your passport is verified" and the account says IP1 Plus. Dashboard: passport.chip_read, passport.passive_auth_verified (with the CSCA serial and DFAT's CRL date), idv.level_raised.
5. Account → Verify Medicare card (the demo number is filled in; it's a simulated source verification) → IP2.
6. Back to Agency C → Open your full health record → Confirm it's you → passkey → the record opens: "Confirmed with TDIF IP2 / CL2". Dashboard: acr.essential_met, step_up.completed.

Say: "The chip proves the passport is genuine: DFAT signed those exact details, and the signer isn't revoked. That's the technical verification the Accreditation Rules ask for. A passport on its own is IP1 Plus; IP2 adds a second document. The wallet never read my photo. And IP2 only exists with a passkey: a password sign-in to the same account is asserted as IP1 Plus."

Afterwards: Remove identity verification puts back the earlier name and date of birth.