ORBIS.ID Open the walletWallet

Partners · Wallet

You are building the surface a person holds their credentials in.

The path built for this role — what ORBIS needs from you, what the platform will prove before you reach production, and the calls to run at each step.

Apply as wallet All profiles API reference

What ORBIS needs from you

You will need an ORBIS organization

Which is why this path starts with an application: an organization, its did:web identity and its vault-held key are created by an ORBIS operator through the provisioning ceremony. No public page can create one, including this one.

  • Which OID4VCI and OID4VP profiles you implement, and your holder key type.
  • How the device key is generated and protected on your platform — the account id IS the RFC 7638 thumbprint of that key.
  • Whether you intend to use the ORBIS wallet bridge or only the standards wire.

What ORBIS will never ask you for

A secret, a token, a private key, or a password — on this page or any other public one. There is no field for one anywhere in this pipeline. An operator token is revealed exactly once during provisioning and ORBIS keeps only its hash, so nobody at ORBIS can re-show it to you and nobody should ever ask you to send one back.

What the platform will prove before you go live

Not checkboxes — the real exercises, run against your integration, each recording the evidence it saw. This is what replaces weeks of email, and what stops anyone reaching production on a broken integration.

  • OID4VCI: /token then /credential completes with a valid proof-of-possession JWT.
  • OID4VP: a presentation completes end to end and verifies, bound to the verifier’s nonce and audience.
  • Holder binding: the key that holds the credential is the key that signs, and a mismatched account id is refused.
  • A replayed or stale holder JWS is refused.

Not built The engine that runs these is being built now. When it is wired, each check on your status page carries what it proves, what it saw, and — on a failure — the concrete fix.

The calls

Copy-pasteable, in order. Nothing here has been executed against the production origin and no value below is live data. Run everything against a demo- organization first.

Step 1 — the white-label configuration
curl -sS https://orbis.id/manifest
# → {"tenants":[{"id":"...","name":"...","did":"...","primaryColor":null,...}]}
Step 2 — the OID4VCI wire, exactly as the specification defines it
curl -sS https://orbis.id/t/<tenant>/token \
  -d 'grant_type=urn:ietf:params:oauth:grant-type:pre-authorized_code' \
  -d 'pre-authorized_code=<from the offer>'
# → {"access_token":"...","c_nonce":"...","expires_in":300}

curl -sS https://orbis.id/t/<tenant>/credential \
  -H 'authorization: Bearer <access_token>' \
  -H 'content-type: application/json' \
  -d '{"credential_configuration_id":"<type>",
       "proof":{"proof_type":"jwt","jwt":"<ES256 JWT, typ openid4vci-proof+jwt, aud=this issuer, nonce=c_nonce>"}}'
# → {"credentials":[{"credential":"<SD-JWT VC>"}]}
Step 3 — the holder plane. There is no shared secret on it.
# The account id IS the RFC 7638 thumbprint of the device key, and every
# call is a compact ES256 JWS signed by that key (typ orbis-holder+jwt,
# aud = this origin, iat inside a five-minute window, jti burns on first use).
# A path segment naming an account must match the signer, or it is refused
# with account_mismatch. Nothing an operator holds can forge it.
curl -sS https://orbis.id/member/me -H 'authorization: Holder <jws>'
curl -sS https://orbis.id/api/wallet/<thumbprint>/items
# → {"accountId":"...","fixtures":false,"items":[...]}
#   "fixtures": true means this deployment is serving demonstration data.

Operations used on this path: GET /manifest, POST /member/enroll, GET /member/me, GET /api/wallet/{accountId}/items. Their request and response shapes are in /openapi.json.

What happens next

  1. Applied ORBIS acts

    Your application exists and is in the review queue. Nothing has been provisioned.

    What moves it: An ORBIS reviewer picks it up. You do not need to do anything.

  2. Reviewing ORBIS acts

    A reviewer is reading it and may come back to you with questions.

    What moves it: The reviewer either asks you something or moves you to a sandbox.

  3. Sandbox you act

    You have a demonstration organization to build against. It is marked as a demo everywhere, permanently.

    What moves it: You build the integration, then ask for certification.

  4. Certifying you act

    The platform is running the real exercises against your integration and recording the evidence.

    What moves it: Every check on the readiness board passes. Each failure names the concrete fix.

  5. Live nobody waits

    You are a provisioned organization on the production rail.

    What moves it: Nothing — this is the destination. Your organization is now managed in Organizations, not here.

No duration is published for these stages because none has been measured — see the pipeline for why that is deliberate.

Apply Check an existing application

Already a partner? Sign in to the partner portal to see your status, issue and revoke your own API keys, and manage who else is on your account. To read your status without signing in, /partners/status takes your reference and contact email and nothing else.

The API reference lives at /developers and the machine-readable contract at /openapi.json. Nothing on this page restates them — they are the one source.