The identity federation gives every participant one account for the whole program: the identity service at id.oimlsmart.org is the single OpenID Provider, and every platform instance is a relying party that runs no login form and holds no account list of its own. Behind the account sits the organization registry with the OIML member taxonomy, so a sign-in resolves to a member state, a corresponding member, an issuing authority, a test laboratory, or a designated body.
What you can do today
- Sign in with what you already hold. GitHub and Google sign-in are linked today, passkeys and authenticator apps are first-class, and recovery codes cover the loss cases; SMS and voice one-time codes are a documented refusal, because SIM-swap and interception make them weak factors (the capture above).
- Request an account for your organization. The join flow offers the live OIML-CS participants register (the member states, corresponding members, issuing authorities, laboratories, and utilizers on the registry); approval comes from your own organization’s administrator, or the BIML secretariat when the organization is not listed yet.
- Read the machine contract. The discovery document publishes the endpoints, the algorithms, and the claims every relying party consumes: OIDC Core 1.0, authorization code with PKCE, ES256 ID tokens.
- Administer your own people. An organization administrator sets each member’s data cone (org-wide, assigned, read-only, or assigned and read-only together), and the token carries the posture so any service learns it without a callback.
- Give an instrument an identity. The device class issues each twin a per-device credential speaking the client-credentials grant only, bound to its organization and its instrument model; a re-key or a revocation is a console act with an audit trail.
- Run your own provider. The same software runs on a member’s own domain as a configuration act, with an executable proof in the repository’s end-to-end suite; the self-host runbook is public.
How it works
Each registered service declares a claims policy and receives the least claims it needs. The organization registry and its signing keys double as the program’s trust registry, which is the identity plane the dataspace work builds on. The service is developed in the open at oimlsmart/identity (the source is available; the open-source license is pending, and the repository says so plainly).
Today (SMART) and the vision (SMART+)
Today · SMART
- The provider is live in production: discovery, sign-in, the join flow against the live participants register, and the per-organization consoles. the contract ↗
- Every surface is a relying party: the demo, the studio, the vocab, the minisites hold no account lists of their own. the demo ↗
- GitHub and Google sign-in are linked; the participants register is populated (63 member states, 66 corresponding members, the IAs, the laboratory associations, the utilizers, the associates). the join flow ↗
The vision · SMART+
- Microsoft Entra and national or organizational providers join as configuration, not code; the member-state streaming update channel follows. roadmap ↗
- The device class at member scale: every deployed twin holding its own credential under its organization, re-keyed and revoked as console acts. roadmap ↗
Why it exists
A certification ecosystem that fragments accounts across services fragments the record of who did what, and legal metrology runs on attributed acts: who signed, for which organization, under which authorization. One provider makes attribution uniform, lets an organization administer its own people’s access, and lets an instrument hold a machine identity of the same shape as its owner’s.
Who may use it, and who may run it
Everyone gets an account on the services, and any member may run the identity software as its own provider; member states additionally receive the streaming update channel. The determinations, quoted from the program’s single entitlement source:
| Member State | Corresponding Member | Issuing Authority / Test Laboratory (of a Member State) | Utilizer / Associate | Applicant / public |
|---|---|---|---|---|
| ✅ | ✅ | ✅ | ✅ | ✅ join flow |
OIML SMART account (the identity service), quoted from the program's single entitlement source; the full matrix, all services by all member categories, lives atWho can run what.
| Member State | Corresponding Member | Issuing Authority / Test Laboratory (of a Member State) | Utilizer / Associate | Applicant / public |
|---|---|---|---|---|
| ✅ 🏠 🔄 | ✅ 🏠 | operates under its Member State | — | source available — license pending |
Identity service software, quoted from the program's single entitlement source; the full matrix, all services by all member categories, lives atWho can run what.
The honest questions
Does the program hold our member list hostage? No. The software is the same one the program runs, the self-host runbook is public with an executable proof in the end-to-end suite, and a member running its own provider on its own domain is a configuration act. The platform instances consume the same claims contract either way, so a deployment authenticates against the program provider or the member’s own without a code change.
Why no SMS codes? Because SIM-swap and interception attacks make SMS and voice one-time codes weak factors, and a certification ecosystem cannot afford weak attribution. Passkeys, authenticator apps, and recovery codes cover the same usability ground at a stronger posture; the refusal is documented in the repository.
What can a service learn about me? Only what its declared claims policy needs. Each relying party receives the least claims it needs; your organization’s administrator, not the program, sets your data cone, and the token carries the posture so services enforce it without a callback to the provider.
Try it, read it, talk to us
The demo federates through the same shape: the identity service holds the fictional cast as real accounts, assumed as personas through the account chooser, so the consoles show the attributed workflow without touching the production registry.
Request your organization's account against the live participants register; approval comes from your own administrator.
info@oimlsmart.org, the programme's front-door address. The first conversation about your organization's presence in the registry is the same address.