Skip to main content
GET
/
providers
/
{did}
/
connect
Get provider connect config
curl --request GET \
  --url https://prodapi.phosra.com/api/v1/providers/{did}/connect \
  --header 'Authorization: Bearer <token>'
{
  "authorize_url": "<string>",
  "token_url": "<string>",
  "profiles_url": "<string>",
  "scopes": [
    "<string>"
  ]
}

​
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.

​
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.

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.