Aegis ID
Vanguard Cloud Services

Get started guide

Launch the Aegis ID pilot with confidence.

A visual walkthrough in the order the product actually runs: choose a plan, create the account and the organization, set up the wallet, confirm the root wallets that can recover it, then issue a credential and prove it with a wallet challenge.

Start the walkthrough Review setup steps

Pilot path

Plan. Org. Root wallets. Credential.
WebPlan, account, organization
WalletWallet ID, then root wallets
AppsCredential, challenge, evidence

What this guide covers

One scrollable path from first visit to signed business action.

Use this visual guide as a practical onboarding path for administrators, wallet users, and relying-party application testers.

01Choose a plan 02Create account and second factor 03Create the organization 04Set up the wallet 05Confirm the first root wallet 06Get to three, and what that buys 07Issue and accept a credential 08Test a wallet challenge 09Use example apps 10Digitally sign a PDF 11Configure platform wizards 12Azure app, Key Vault, secrets
01

Plan first

Choose the plan before the account exists.

The order is deliberate: /plans, then checkout for a paid plan, then registration. Somebody who needs Enterprise finds that out on the pricing page rather than after filling in a form.

  • Open Plans and compare tiers, limits, and prices.
  • Pick a plan here, or on the registration form itself — both offer the whole catalogue.
  • A paid plan routes to hosted checkout; card details never reach Aegis.
  • A registration code from an administrator stands in for payment.
A form asks for a plan; it never grants one. The choice is validated against the catalogue and kept in the session, and every route passes the session's plan when the subscription is created. Posting a different plan on the form changes nothing.

Plans

Choose a plan.
TrialFree, time limited

Start trial
BasicPer month, per workspace

Choose Basic
EnterpriseTalk to us

Contact sales
A paid plan goes to checkout. Walking away from the card form still creates nothing you have not paid for.
02

Account registration

Create the account and finish a second factor.

Register with the work email the organization will use. A second factor completes the sign-in; which methods exist is configured per deployment rather than hardcoded.

  • Enter name, work email, phone, and password.
  • Complete the emailed or texted code, or a passkey.
  • Enter a registration code here if you were given one — it is checked now and spent at subscribe.
  • Land on the organization page, or on the invited organizations if the email matches a credential invite.
Codes and links are never shown in a response. Everything goes through the delivery service. On a hosted environment that means an administrator has to configure email or SMS first — until then, delivery fails closed rather than silently doing nothing.

Register

Create your Aegis ID account.
NameFrederick Pearson
Work emailfpearson@vanguardcs.ca
PlanBasic
Registration codeOptional
Create account
Use the work email so organization invitations match the wallet holder.
An invalid registration code re-renders this form rather than leaving a half-made account.
03

Organization identity

Create the organization, then prove who it is.

The workspace is created with a handle — globally unique, assigned once, never reused. The organization's name is only a label: two subscribers may both be "Cloudstrucc", and always will be able to.

  • Create the workspace and become its first administrator.
  • Note the handle. Its public page lives at /orgs/<handle>.
  • Optionally claim a domain and publish the TXT record at _aegis-challenge.<domain>.
  • Review people, claims, roles, branding, and the audit log.
DNS rather than a file upload. Publishing in the zone requires control of the zone; a file only proves control of one web server. Two organizations may both have a pending claim on a domain — only publishing decides it — but a domain already verified elsewhere is refused.

Organization identity

VCS-613
Handlevcs-613-a7f3
Public page/orgs/vcs-613-a7f3
Domainvanguardcs.ca
StatusVerified
RecordHostValueState
TXT_aegis-challengeaegis-verify=…Found
Unverified is not anonymous — the public page says plainly whether the domain is proven.
04

Wallet setup

Install the wallet and register a Wallet ID.

There are two wallets — iOS through TestFlight, Android through Play — and both do the same thing on first run. Setup is blocked until a Wallet ID exists, because a credential cannot bind without one.

  • Install the wallet for your platform on the device that will hold the credential.
  • Register with the same work email the organization knows.
  • Save the ten recovery codes. They are shown once and never again.
  • Share the Wallet ID from the app when an administrator asks for it.
The device key never leaves the device. Recovery rotates that key rather than restoring it, which is why nothing sensitive has to be backed up anywhere.
Wallet registrations are per environment. A wallet registered against dev genuinely does not exist on qa or prod. If an administrator is told "no wallet is registered with that ID", check which environment each side is on before checking the ID.

Your Wallet ID

AEG-4K7P-2M9X-QT3B

Email: fpearson@vanguardcs.ca
Recovery codes: 10 remaining
Device key: on this device only

Both platforms

iOS and Android are equals here.

Each build registers its own URL scheme — aegisid, aegisid-dev, aegisid-qa, aegisid-local — so all four environments can sit on one device, and a link opens the build it was meant for.

05

Root wallets

Nominate a root wallet, then have the holder confirm it.

Root wallets are the wallets that can recover administrative control of the organization. They exist because control otherwise rests on an email address and on the platform administrator — which means we could restore access to your organization, and so could anyone who took over your inbox.

  • Open Root wallets in the organization.
  • Paste the holder's Wallet ID and nominate it.
  • Show the QR to the holder. Their wallet scans it and confirms.
  • Watch the row move from Pending to Confirmed. Only confirmed wallets count.
Nominating is not confirming. A Wallet ID is an identifier, not a secret, so anyone who saw one could otherwise make that wallet responsible for an organization. The confirmation token travels only in the QR, is single-use, expires in 72 hours, and is discarded once spent. If the code is missed, withdraw the nomination and start again.

Root wallets

Nominate a wallet

WalletHeld byStatusAction
AEG-4K7P-2M9X-QT3BFrederick P.PendingShow QR
Pending means nominated and nothing more. It does not count towards the minimum.
Example root wallet confirmation QR code

aegisid://root-wallet-confirm?...

Scanned from the wallet, not a browser

Confirm root wallet

VCS-613 nominated this wallet to recover the organization.

Organization: VCS-613
This wallet: AEG-4K7P-2M9X-QT3B
Expires: 72 hours from nomination

Enforcement

No confirmed root wallet, no issuance.

On dev, qa and prod the policy is on: an organization with none cannot issue credentials at all. That is the point of the feature rather than a side effect of it.

06

Get to three

One is the bar to operate. Three is the bar to be safe.

Repeat the nominate-and-confirm step with two more wallets, held by different people. One root wallet means one lost device strands the organization; three means no single loss does.

  • Nominate a second and third Wallet ID. Existing root wallets do not need to approve.
  • Confirm each from its own device.
  • Ten is the ceiling — past a point another root wallet is another device that can recover the organization.
  • Withdrawing is allowed at any count, on purpose: a stolen device has to be removable at once.
What three unlocks. An administrator who loses their authenticator is recovered by two of these wallets approving from their own devices, at /auth/recover/approvals — with no platform administrator in it. At three confirmed wallets the weaker recovery-code-and-email path closes for this organization's administrators, because a route that is easier to attack is not an alternative.
Break-glass is the other case, not the same one. It covers losing every root wallet. The customer generates the code and keeps it, a root wallet authorises it in advance, and redeeming needs both the code and a platform administrator plus a ticket reference. No administrator here can reach your organization on their own — by construction, not by policy.

Root wallets

Three confirmed.
3 of 3 confirmed
WalletHeld byStatusAction
AEG-4K7P-2M9X-QT3BFrederick P.ConfirmedWithdraw
AEG-8FJE-B7RY-52R0Dana R.ConfirmedWithdraw
AEG-3YBP-17RT-HGD9Sam O.ConfirmedWithdraw
At one or two you can operate, but a danger banner says what you are exposed to.

Approve a recovery

An administrator of VCS-613 has asked to recover their access.

Requested by: fpearson@vanguardcs.ca
Approvals so far: 1 of 2
This link works only with your wallet

Why it is not just another email

The approval never reaches the person recovering.

Each approval link goes to its own root wallet holder's registered address. Somebody who has taken over the administrator's inbox reaches a status page and nothing they can act on.

07

Credential issuance

Issue a credential, and accept it in the wallet.

With root wallets confirmed, the organization can issue. Bind the invitation to a Wallet ID so only that wallet can accept it — the invite page also carries portal registration and sign-in links for the invited email.

  • Open People, choose the holder, and invite an organization credential.
  • Paste the holder's Wallet ID, or the whole aegisid://wallet?… link they shared.
  • Show the QR. The wallet scans it and accepts.
  • Check the ledger: the acceptance is on the evidence chain.
Binding to a Wallet ID is the high-assurance option. Without one the invite binds to the holder's registered email or phone instead, which is lower assurance. A wallet-bound invite is rejected on the device before it ever reaches the server if it names a different wallet.

People directory

Invite employee credential

NameEmailStatusAction
Frederickfpearson@cloudstrucc.comInvitedView QR
Open the invite modal to display the QR and deep link.
Example credential invite QR code

aegisid://credential-invite?...

Create portal account | Sign in

Credential invite

Vanguardcs invited this wallet to accept an organization credential.

Organization: Vanguardcs
Holder: fpearson@cloudstrucc.com
Status: Pending acceptance

Mobile wallet

Why this is not an Aries OOB link

The credential invite uses an Aegis deep link. Aries lab invitations still use an OOB payload with an oob parameter.

08

Wallet challenge

Prove a sign-in with a wallet challenge.

After OIDC sign-in succeeds, Aegis ID raises a wallet challenge from the issuing organization. Approving and declining are both real answers, and both land on the evidence chain.

  • Select the organization that issued the credential.
  • Start OIDC sign-in from the protected app.
  • Open the wallet and approve — or decline — the challenge.
  • Return to the app, then read the decision back in the ledger.
A product-path organization needs no ACA-Py. The wallet collects challenges by polling the organization it is connected to, so this works on any deployment whether or not the Aries lab is running.

OIDC challenge

Authentication succeeded. Wallet approval required.

OrganizationVanguardcs
Subjectfpearson@vanguardcs.ca
Send wallet challenge
Choose the issuing org before sending the wallet challenge.

Wallet challenge

Approve OIDC sign-in for Business Expenses.

Application: OIDC wallet challenge
Action: sign-in
Nonce: CH-2026-1048

Example applications

Show wallet decisions inside real business workflows.

The demo apps illustrate a relying-party pattern: the app handles its workflow, while Aegis ID supplies high-assurance proof, wallet approval, and ledger evidence.

Business Expenses

Approve or reject an expense.

After sign-in, the user opens an expense row and records a wallet-signed decision.

ExpenseAmountStatusAction
EXP-2026-1048$1,284.00PendingApprove
EXP-2026-1051$642.18PendingReject

Wallet ledger

Every decision becomes evidence.

The web app and mobile app both show the challenge payload, action, timestamp, subject, and result.

ActionResourceStatusTime
approveEXP-2026-1048Accepted10:42
sign-inOIDCAccepted10:40

Digital signature example

Upload a PDF, place a signature field, then send a wallet challenge.

The signature field can show the wallet-approved claim, timestamp, and ledger identifier after approval.

Template builder

Upload PDF and add fields.

TemplateContract Approval
Upload PDF Add signature field
Click the PDF to place the signature field.

Service Agreement

Agreement terms and approval routing details appear in the uploaded PDF.

Wallet signature field
Awaiting Aegis ID approval

Platform configuration wizards

Configure each assurance and federation path with guided steps.

Each platform path lists the values to collect, where to configure them, and which live test proves the connection is ready.

Microsoft Entra Verified ID

Production credential proof.

Use Entra admin center to configure the Verified ID authority, credential contract, claims, rules, and card design.
Open Azure setup section Microsoft Learn tenant setup Request Service API
  1. Sign in to entra.microsoft.com as a Global Administrator or an administrator allowed to configure Verified ID.
  2. Open Verified ID and complete tenant setup if it has not been configured yet: domain, authority, and Key Vault-backed signing keys.
  3. Create the credential contract, for example VerifiedEmployee, then define the claims, rules, and card style.
  4. Copy the authority DID exactly as shown in the issuance sample payload.
  5. Copy the manifest URL from the credential contract. Authenticator uses this URL to understand the credential display and issuance requirements.
  6. Record the credential type, for example VerifiedEmployee.
  7. Paste tenant ID, client ID, client secret, authority DID, manifest URL, credential type, and callback API key into the Aegis ID Verified ID wizard.
  8. Run the live test and scan the issuance QR code with Microsoft Authenticator.

YubiKey / FIDO2

Hardware-backed step-up.

Tap the YubiKey 5C NFC, use USB-C, or register a platform passkey for admin and approval step-up.

Laptop browser
Mobile app

Desktop and mobile supportedHardware-backed step-up can protect desktop sign-in, mobile approval flows, admin actions, and high-value application decisions.

Open wizard section Yubico setup Yubico FIDO2 guide
  1. Install Yubico Authenticator on macOS, Windows, Android, or iOS as appropriate for the test device.
  2. Insert the YubiKey over USB-C or use NFC where supported. Set a FIDO2 PIN if the key does not already have one.
  3. In Aegis ID, open the YubiKey/FIDO2 setup wizard and choose whether the policy applies to sign-in, admin actions, expense approvals, PDF signatures, or all high-value actions.
  4. Register the key as a security key or passkey when the browser prompts for WebAuthn.
  5. Test a protected action and confirm the browser asks for the key touch or PIN/user verification.
  6. If the key is reused from another pilot, do not factory reset unless you are intentionally removing all resident FIDO credentials from that key.

Keycloak

OIDC or SAML federation.

Use the Keycloak realm client configuration to set redirect URIs, client authentication, scopes, and claim mappers.
Open wizard section Keycloak admin guide Keycloak OIDC guide
  1. Choose the Keycloak realm that owns the users and roles for this organization.
  2. Create an OpenID Connect client for Aegis ID. Use confidential access when the server will store a client secret.
  3. Add the Aegis ID redirect URI exactly as shown in the wizard and set web origins to the trusted Aegis ID origin.
  4. Copy the client ID, client secret, realm issuer URL, and discovery URL.
  5. Add protocol mappers for email, name, preferred username, groups, roles, department, and any custom claims the organization needs.
  6. Paste those values into the Keycloak wizard, run the sign-in test, then send a wallet challenge from the accepted organization credential.

Generic OIDC / SAML

Any compatible identity provider.

Use the provider metadata page to collect issuer, endpoints, certificates, client credentials, and claim mappings.
Open wizard section OAuth permissions overview
  1. For OIDC, collect issuer, discovery URL, authorization endpoint, token endpoint, userinfo endpoint, JWKS URL, client ID, client secret, audience, and scopes.
  2. For SAML, collect entity ID, SSO URL, signing certificate, metadata XML URL or file, NameID format, and assertion attribute names.
  3. Configure redirect URI or ACS URL exactly as shown by the Aegis ID wizard.
  4. Map the provider claims to Aegis ID fields such as email, display name, object ID, groups, department, and assurance level.
  5. Store secrets in Key Vault or secure App Service settings, never in client-facing documentation.
  6. Run the wizard live test, then send a wallet challenge so the demo shows both federation and user-held credential assurance.

Azure foundation

Prepare the hosted environment before live Verified ID testing.

Use this section for administrator setup: app registration, secrets, app settings, and Key Vault hardening.

App registration

Microsoft identity platform app.

Use the app registration overview to copy tenant ID and client ID, then configure secrets and API permissions.
Open platform wizard section Register an app Verified ID Admin API Issuance API Presentation API
  1. Go to Microsoft Entra admin center, then Microsoft Entra ID, App registrations, New registration.
  2. Name the app, keep it single tenant for the pilot, and create it. A redirect URI is not required for client credentials.
  3. Copy Directory tenant ID and Application client ID from the app overview.
  4. Open Certificates and secrets, create a client secret, and copy the secret value immediately.
  5. Open API permissions, Add a permission, then search for the Verified ID Request Service or Verifiable Credentials service permission shown by the Microsoft Learn guide.
  6. Add the application permissions required by issuance and presentation calls, then grant admin consent. If the token has no roles, this step is incomplete or consent did not apply.
  7. Open Verified ID, create or select the credential contract, and copy the authority DID, manifest URL, and credential type from the issue credential sample.
  8. Generate a callback API key in Aegis ID or set a strong value in configuration so Verified ID callbacks can be authenticated.

Key Vault and App Service

Secrets and runtime settings.

Use Key Vault and App Service configuration to store production secrets and runtime environment values.
Open Azure setup section Verified ID advanced setup
  1. Create or reuse a Key Vault for production secrets such as AZURE_CLIENT_SECRET, SESSION_SECRET, VID_CALLBACK_API_KEY, and provider client secrets.
  2. Enable managed identity on the App Service if you want to use Key Vault references instead of plain App Service settings.
  3. Grant the App Service identity permission to read the required Key Vault secrets.
  4. Set App Service settings for VID_MODE, AZURE_TENANT_ID, AZURE_CLIENT_ID, AZURE_CLIENT_SECRET or Key Vault reference, VID_AUTHORITY_DID, VID_MANIFEST_URL, VID_CREDENTIAL_TYPE, VID_CALLBACK_API_KEY, and PUBLIC_BASE_URL.
  5. Restart the App Service after configuration changes so the running Node process reads the new values.
  6. Run the Verified ID live test. Issuance proves the credential can be created; presentation proves the credential can be requested and verified later.