description: Integrate a relying party with TrustNet over standard OpenID Connect: registration, consent, PPIDs and claims.
Integrate with TrustNet
TrustNet is an Identity Orchestration Layer over standard OpenID Connect.
For your application — the relying party (RP) — it behaves like any OIDC
provider: your users sign in through TrustNet, and your application receives an
ID token whose sub is a pairwise pseudonymous identifier (PPID) plus only
the claims the user approved. You do not store passwords, you do not build a
consent UI, and you never receive the user's internal TrustNet identifiers.
Your role as an RP
You integrate like any OIDC client:
- Register your application in the TrustNet portal and prove the domain of your production redirect URIs.
- Send users to the authorization endpoint with an authorization-code + PKCE request, and state which claims you are asking for.
- Handle the callback, exchange the code for tokens, and validate the ID token.
- Read the approved claims from the ID token or from UserInfo.
- Optionally refresh tokens for ongoing access, and implement logout and the required back-channel logout endpoint.
What "zero code changes" means
TrustNet does not require an SDK or a TrustNet-specific login widget. It is a standard OIDC provider, so an application that already speaks OIDC needs configuration, not a new integration layer.
It does not mean "no work":
- you must register the RP and prove your redirect hosts;
- you must declare the claims you may request, each with a reason shown to the user at consent;
- your OIDC client must request those claims and handle the standard token and logout flows.
What you receive
| Value | Meaning |
|---|---|
sub |
The PPID. Stable for your RP and a given persona; never an account or persona identifier. |
| approved claims | Only the claims the user approved, from the persona they chose. |
sid |
A session identifier in the ID token, used to match back-channel logout tokens. |
| tokens | Opaque access token, ID token, and — when you request offline_access — a refresh token. |
The access token is opaque. Do not parse it or assume it is a JWT; use UserInfo or the RP machine plane to read the consented claims. TrustNet's own token introspection is internal and is not an RP-facing surface.
Endpoints
Production endpoints (the issuer is permanent):
| Surface | URL |
|---|---|
| Issuer / discovery | https://id.trustnet.app (/.well-known/openid-configuration) |
| Authorization | https://id.trustnet.app/oauth2/auth |
| Token | https://id.trustnet.app/oauth2/token |
| UserInfo | https://id.trustnet.app/userinfo |
| JWKS | https://id.trustnet.app/.well-known/jwks.json |
| Revocation | https://id.trustnet.app/oauth2/revoke |
| RP-initiated logout | https://id.trustnet.app/oauth2/sessions/logout |
| RP portal | https://me.trustnet.app |
| RP machine plane | https://rp.trustnet.app/api/rp/v1 |
For local staging, substitute the staging hosts:
id.stg.trustnet.test, me.stg.trustnet.test, rp.stg.trustnet.test.
Staging uses a private CA; trust it before running the examples (see the local
staging README in the repository).
Start here
- Quickstart — register an RP and complete a first login.
- Concepts — accounts, personas, PPIDs, consent, claims and the tenant/sector model.
- How-to guides — token validation, UserInfo, refresh, logout, secret rotation, domain proof, errors, deletion and export.