Skip to main content
GET
cURL

Two layers, resolved in order

Connecting a platform to a provider is a two-layer resolution, and the layers are deliberately not the same trust surface:
  1. The OCSS Trust List decides whether you may connect. The SDK resolver fetches the root-verified /.well-known/ocss/trust-list and requires the target DID to be an active, unexpired entry. Absent, suspended, revoked, or expired — the resolver fails closed and this endpoint is never called.
  2. This endpoint (GET /providers/{did}/connect) says how to reach it. It returns the OAuth authorize_url / token_url / profiles_url / scopes a client uses to run the connect ceremony. It is a Phosra product-layer lookup, deliberately not part of the signed OCSS document — the standard stays vendor-neutral (trust, keys, accreditation); connection mechanics are Phosra’s concern as the OCSS implementor.
404 is returned (without distinguishing the cases) for an unknown DID, a revoked DID, or an accredited DID that has no connect config registered yet — no existence leak.
A 404 for every DID — including known-good ones like did:ocss:loopline — usually means the base URL is not an OCSS census (e.g. the control plane prodapi.phosra.com, which does not serve GET /providers/{did}/connect). Confirm censusBaseUrl points at an OCSS census host — the sandbox host or your assigned production census host (see Production Accreditation) — before assuming your DID or connect config is missing.

Registering your connect config

There is no self-serve write path for this endpoint yet. To get your platform’s connect config published: Interim (today): email developers@phosra.com with the four fields:
  • authorize_url — your OAuth 2.0 authorization endpoint (PKCE S256)
  • token_url — your OAuth 2.0 token endpoint
  • profiles_url — your child-profile listing endpoint (bearer access token; the token is discarded after the profile fetch)
  • scopes — the OAuth scopes the connect ceremony should request (e.g. child_profiles.read)
Phosra publishes the config to the connect registry once your DID is on the Trust List. Roadmapped: a self-serve, RFC-9421-signed PUT on this same path, so an accredited platform can register and rotate its own connect config without an email round-trip. Not yet built — no such endpoint exists today.

Finding the {did}

This lookup takes a provider {did} — you find one by browsing GET /api/v1/directory. Enumerate the directory, select an entry that advertises a sealed-classify enclave, and call this endpoint on its DID: a 200 means connectable, a 404 means it is on the Trust List but has no connect config yet.

Authorizations

Authorization
string
header
required

Bearer authentication header of the form Bearer <token>, where <token> is your auth token.

Path Parameters

did
string
required

The provider's OCSS DID, e.g. did:ocss:loopline. Colons are path-safe (RFC 3986) — send them literally, do not percent-encode.

Pattern: ^did:ocss:[a-z0-9-]+$

Response

The provider's OAuth connect config

authorize_url
string<uri>
required

The provider's OAuth 2.0 authorization endpoint (PKCE S256).

token_url
string<uri>
required

The provider's OAuth 2.0 token endpoint.

profiles_url
string<uri>
required

The provider's child-profile listing endpoint (bearer access token; the token is discarded after the profile fetch).

scopes
string[]

OAuth scopes the connect ceremony requests, e.g. child_profiles.read.