Login

The doors

This application serves two doors, and both accept the same account. The product door is ommisa.org, which opens the application directly, and the institutional door is ai.oimlsmart.org, which forwards to the product door. A session minted at one door is a cookie that lives on that door’s hostname, so the doors do not share a sign-in state; signing in at either door again is a single silent hop when the account’s session at the identity service, id.oimlsmart.org, is still live.

The tiers

The anonymous tier serves every visitor a daily allowance of questions over the public OIML corpus, and the allowance is counted by network address. The member tier, which an OIML SMART account unlocks, raises the daily allowance to 300 questions, adds the member corpora, the memory files, the synchronized conversations and the projects, and carries each member’s own quota. The command-line interface authenticates with the Device Authorization Grant (RFC 8628), which issues a personal access token scoped by the <service>:<read|write|admin> grammar, and a token issued for one door serves the other.

Signing in at the terminal

ommisa login
ommisa login --read-only
ommisa whoami
ommisa logout

The device flow presents a short code for approval in the browser and stores credentials under ~/.config/ommisa/credentials.json with mode 0600. The default scope grants read and write access, and the --read-only option drops the write scope, under which storing conversations and memory files is refused.

What a sign-in carries

The application is a relying party of the estate’s identity service, which means it receives an identity assertion and mints its own session; it never receives a password. Revoking access at the account console takes effect at the next request, because the service confirms every session through token introspection (RFC 7662). The command line’s local log of questions never leaves the machine it runs on.