Trust Anchor
- IPNS ID
- Published
- Revision
This appliance
Set up this appliance
Enroll a public identity, then prove possession with a NOMOI mandate.
Bootstrap progress
- Operator TA IPNS ID
- Policy publication
- Published policy CID
- Administration scope
Progress refreshes while this screen is open. “Observed” means the publication is available. Successful operator sign-in permanently closes password setup.
Operator enrollment
Enrolled and published?
Back to appliance
Set up this appliance
This appliance
Sign in
Present a mandate, then sign a short-lived challenge — with a key in this browser, or in your own terminal. Your signing key stays on your computer.
- <scope prefix>.nomos.web.auth
- Signs in and shows the Trust Anchor's published policy.
- <scope prefix>.nomos.web
- Signs in with management access.
An enrolled operator, or a newly created TA's designated administrator, also gets management access with their own sign-in mandate.
Sign in
Back to appliance- 01 · Present mandate
- 02 · Sign challenge
or sign in your own terminal
A challenge lasts at most a minute. Keep your terminal ready before requesting one, or keep keys in this browser.
The terminal route issues the same 30-second challenge for nomos sign.
2. Sign the challenge
Challenge expires in s
Expired — request a new challenge.
or sign in your own terminal
Run in your own terminal
This mandate is unpublished. Save it as
nomos-login-mandate.pem next to where you run the command. Requires a CLI with --mandate-file support.This browser
Keys
This browser cannot run the key wallet. Use nomos id and nomos sign instead.
Signing keys, kept encrypted in this browser in the CLI’s own key-file format. Nothing here is sent to the appliance.
Signing keys
?
Keys are stored the way the CLI stores them: encrypted under your passphrase, in the same file format. Save each key file — clearing this site's data deletes the browser's copy. A saved key file works as ~/.config/nomos/ids/<name>, and CLI key files import here. Unlocked keys stay in memory only while this tab is open.
-
- No keys yet. Add one: create it here, or import a key file from the CLI.
This browser
Mandates
Mandates held here, by leaf CID, and the ones you issue. Nothing leaves this browser until you publish it.
This browser cannot run the key wallet. Use nomos issue and nomos verify instead.
Issue a mandate
reviewCheck this before you sign. It is decoded from the exact bytes that will be signed.
- Scope
- Subject
- Signed by
- Delegated from
- Index
- Valid
- Trust Anchor
- Issuer
- Algorithms
- Context
Mandate signed and kept in this browser. It is not published: hand the presentation to its subject, or publish it so verifiers can fetch it.
- CID
Publish this mandate and its chain to the appliance's IPFS node? Anyone can then fetch it by CID and see its scope, keys and validity; it cannot be withdrawn. Verifiers will no longer need its full chain shown to them.
Held in this browser
-
Publish this mandate and its chain to the appliance's IPFS node? Anyone can then fetch it by CID and see its scope, keys and validity; it cannot be withdrawn. Verifiers will no longer need its full chain shown to them.
Remove this mandate from the browser? It stays valid wherever else it is held.
- No mandates yet. Issue one, or add a presentation someone gave you.
This browser
Verifier
Verify a mandate held in this browser, or one on another device by exchanging three QR codes: mandate → challenge → response.
Verify a mandate
Check anyone's mandate with a Trust Anchor's verifier, then have its holder prove they hold the key it delegates to: in this browser when it holds that key, or on their own device by QR code. Nothing here signs anyone in.
Check a stamp or crew membership with a verifier, and have its holder prove they hold the identity it was given to, on their own device by QR code. Nothing here signs anyone in.
1. Choose the mandate
Mandate from this browser
Scanning checks it and challenges its holder straight away. Have them ready to scan back: the challenge lasts seconds, not minutes.
2. Prove possession of the key
Challenge expires in s
Expired — challenge the holder again.
Have the holder scan your challenge under Present my mandate, review and sign there, then scan their response. Your verifier checks it against the challenge retained here.
Have both devices ready before requesting a challenge: it lasts at most a minute.
Exchange files, text or a terminal command instead
Or the holder runs
Problems
Response detail
Present my mandate
You are the holder. Keep your key and passphrase on this device. The person verifying you scans and verifies on their separate device.
1. Show your mandate
No mandates for your keys are stored here. Add your mandate on Mandates first.
No stamps for your identities are stored here. Collect one under My passport first.
2. Scan their challenge
A signature proves possession of the mandate’s key. Confirm who is asking and what they intend to verify before signing; a live challenge can be relayed.
Receive a challenge file or text instead
Review before signing
This device signs for the mandate you chose, decoded here. The requesting verifier checks its authority.
- Scope
- Trust Anchor
- Mandate CID
- Signing key
The verifier’s screen counts down its challenge: sign before it runs out, or ask for a new one.
3. Show your response
Have the verifier scan this QR code on their device. They check it against their original challenge.
Return a signature file or text instead
Updating workspace…
You can read this Trust Anchor's published policy. Editing, publication history, and audit activity require administration or separate action grants.
Previously loaded information may be out of date.
your mandate
Overview
This Trust Anchor as a verifier resolves it now.
Recent changes
Full audit history →No audit events recorded for this TA.
Only reads recorded so far.
Needs you
Nothing needs you right now.
Publications
View activity →No publications recorded for this TA.
A publication is complete once its state is observed. The last five are shown.
Published policy
View policy →This session reads what the Trust Anchor publishes. Editing it takes an administration mandate.
your mandate
Hosted Trust Anchors
TA directory
No Trust Anchors yet
Create one under New TA. Its namespace, state and provisioning progress appear here.
New TA progress
Nothing provisioning
Create a TA to follow its provisioning here.
your mandate
Inspector
Choose a TA
On this appliance
or anywhere
Read from IPFS, not from this appliance:
Trust Anchor
operatorSuspended: its verifier is stopped and queued publications wait. Resume or delete it from the TA directory.
Published policy
- Published CID
Root authorities
- None.
Trusted namespaces
- None.
Revocations
- None.
Published mandates
- None.
Inspected policy details
Saved drafts
?
Open a saved draft or delete its editable copy. Deletion also closes it if open, discarding unsaved edits. Publishing a draft removes it too; its publication keeps the snapshot. Published policy and publication snapshots are retained.
-
older policyDelete this saved draft and discard its open edits?
- No saved drafts.
No draft open
New drafts start from the published policy. Change roots, trusted namespaces and revocations, save, then publish one immutable revision.
You prepare it with your operator session. Saved drafts are available to this TA’s administrators by ID, and changes are recorded in both audit logs.
Operators
The root identities its published policy names, marked where one is registered as an operator on this appliance, then registered operators it does not name as roots.
No root identities or operators.
-
rootoperatornot registered as operatorRemove this operator registration? Published root authority stays unchanged.
The bin removes an operator registration from this TA immediately after confirmation, including initial administrators and keys listed as roots. Published roots, saved drafts, queued publications and the self session remain independent. Use “Remove root from draft”, then save and publish, to withdraw root authority separately.
Known identities
No known identities.
Known identities are kept on the appliance that manages a TA, and this one does not manage it. They are not published.
-
rootForget this identity for this TA?
These are this TA's known identities: its administrators see them under Policy and issue mandates to them from Keys. A known identity grants nothing, so keeping the list grants nothing either. Both this TA's audit log and the operator's record each change.
Publication jobs
No publications.
Publication jobs are run by the appliance that manages a TA, and this one does not manage it. What it published is under History.
Audit log
Include readsNo events to show.
The audit log is kept by the appliance that manages a TA, and this one does not manage it. What it published is under History.
-
Actor
Load more to reach the latest events.
Published history
Follows each state's previous CID back, as nomos ta audit does: from the TA's current state, resolved afresh, or from the state CID it was given.
-
State contents
- None
your mandate
Published policy
- IPNS ID
- Published CID
Root authorities
- None.
Trusted namespaces
- None.
Revocations
- None.
Published mandates
- None.
Policy details
Publication may take time; a job is complete only when its state is observed.
Verifier directory
Listed on the sign-in page
Listing only offers it for choosing. Anyone who knows this TA’s IPNS ID can still verify against it through the API.
Saved drafts
?
Open a saved draft or delete its editable copy. Deletion also closes it if open, discarding unsaved edits. Publishing a draft removes it too; its publication keeps the snapshot. Published policy and publication snapshots are retained.
-
older policyDelete this saved draft and discard its open edits?
- No saved drafts.
No draft open
New drafts start from the published policy. Change roots, trusted namespaces and revocations, save, then publish one immutable revision.
You prepare it with your operator session. Saved drafts are available to this TA’s administrators by ID, and changes are recorded in both audit logs.
Operators
?
An operator is a key this TA may name as a root. Registering one grants no authority until it is a root of a published policy. Removing a registration leaves published roots, saved drafts, queued publications and bootstrap enrollment unchanged. To withdraw root authority, edit and publish a policy draft.
The root identities the published policy names, marked where one is registered as an operator on this appliance, then registered operators it does not name as roots.
No root identities or operators yet.
-
rootoperatornot registered as operatorin draftRemove this operator?
Known identities
?
A known identity names a public key for this TA, so that any of its administrators can issue a mandate to it without pasting the key. It grants nothing and cannot be a policy root — register it under Operators for that. The pencil beside one renames it, as does adding its key again; removing one does not revoke mandates already issued to it.
No known identities yet. Add the people and services you issue mandates to.
-
rootForget this identity?
Publications
If sign-in or publication was interrupted, open it here to load its status and any saved draft. Unsaved edits stay in this browser tab during sign-in; reloading discards them.
Save your edits before opening another draft or publication.
Publication job
- Job
- Accepted
- Draft
- Published CID
Retrying.
Raw job
Published history
Resolves this TA's IPNS name afresh and follows each state's previous CID back, as nomos ta audit does. It reads the published states themselves, so publications from the CLI appear too.
-
State contents
- None
your mandate
Verification result
Response detail
Rechecks the login mandate with its TA verifier. A rejected chain and an unavailable verifier remain distinct; neither grants access.
Publications
No publications yet
Policy updates and their delivery status appear here.
Audit history
Include reads
A record of every action
Who changed what, with which mandate, and the result.
-
Actor
No loaded events match the filter.
Load more to reach the latest events.