This document defines the SADAR authentication scope namespace — the OIDC scope claim values used when SAI or any conformant component authenticates to an agent, tool, resource, or registry. It covers the namespace pattern, the six initial scopes, the token TTL bounds, the lazy refresh rule, and the target-as-issuer principle. The full normative specification lives in 7. searchAndInvoke Telemetry andAuthentication companion document Part III, with the umbrella requirement in 2.Scope §5.1.8.5.
Audience: implementers building SADAR-conformant components that authenticate to other SADAR entities, and security architects designing the deployment's OIDC and access-control infrastructure.
The most important thing to understand about SADAR scopes is who issues the tokens that carry them. When SAI invokes an agent, tool, or resource, it authenticates to the target's authentication endpoint — declared in the target's registry manifest. The target's authentication endpoint issues the access token. The registry is not the token issuer.
This separation is foundational. The registry holds manifests, validates them, and runs the bilateral match algorithm at discovery time. It does not hold credentials, mint tokens, or sit in the runtime authentication path. After discovery completes, all authentication flows directly between the requester and the target — the registry is no longer involved.
Federation does not introduce a separate token system. In a federated topology, a registry has its own manifest in the Registry of Registries declaring its own authentication endpoint, NFRs, and operational details. When SAI or another registry needs to interact with a federated registry, the calling party authenticates to that registry's authentication endpoint per the same authentication baseline as any other agent or service. There is no SADAR-defined federation broker, no inter-registry trust framework above the per-target authentication.
All SADAR-defined OIDC scopes follow the pattern urn:sadar:scope:v1:{category}:{operation},where {category} groups related operations and {operation} names the specific authorized action. The pattern parallels other SADAR vocabularies — urn:sadar:nfr:v1:{category}:{attribute}for non-functional requirement identifiers and urn:sadar:error:v1:{category}:{code} for error codes.
Custom scopes outside the SADAR-defined set are allowed but SHALL NOT use the urn:sadar: prefix. Implementations and ecosystem participants extend in their own organization-controlled namespaces. Targets receiving tokens with unrecognized custom scopes SHOULD ignore them rather than reject the token, unless the target's policy explicitly requires a recognized scope.
The following scopes are normatively defined for v1. Future versions may add scopes; such additions are MINOR-version increments under the SADAR vocabulary versioning policy.
Two operational principles govern how these scopes are used:
• Scope minimization. SAI SHOULD request only the scopes required for the immediate operation. A token authorizing invocation does NOT implicitly authorize repatriation; both are obtained as needed.
• Scope multiplicity. A single token MAY carry multiple scopes per OIDC convention. SAI may request multiple scopes in a single token request when the same target authentication endpoint will issue tokens covering related operations.
Token lifetimes are bounded between an operational floor and a security ceiling. The recommended default sits inside the bounds and balances re-authentication cost against revocation latency.
Per-scope variation is allowed and expected. Higher-risk scopes — repatriation, invocation against persistence-write targets, anything with cross-trust-boundary effect — SHOULD use shorter TTLs. Lower-risk scopes — registry:health,registry:list_registries — MAY use longer TTLs up to the maximum.
The TTL travels in the token itself as the standard OIDC expclaim. SAI determines expiration from the token, not from local-clock tracking against issuance time. This avoids clock-drift hazards and lets the issuer change TTLs without coordination with consumers.
SADAR mandates lazy refresh: tokens are refreshed on next use after expiry, not proactively. The rule has a specific rationale grounded in how SADAR authentication actually works.
Token refresh in SADAR requires re-authenticating to the target's authentication endpoint — there is no cheaper "refresh" path. Every fresh token requires a fresh authentication. The cost of refreshing ahead of expiration is therefore the same as the cost of acquiring at expiration; lazy refresh is preferred because it minimizes total round trips. Proactive refresh would burn extra round trips on tokens that may never be used again.
For long-running SAI invocations or processes that may pause for extended periods, tokens may expire between operations. Implementations SHOULD handle expired-token rejections from targets by re-authenticating and retrying once. Repeated failures after re-authentication indicate a real authorization problem and are reported as errors, not retried indefinitely. The retry-on-401 behavior is implementation defensiveness; the spec does not normatively mandate it.
Tokens carrying SADAR scopes are JWTs per OIDC convention. The scope claim in the JWT is a space-separated list of scope values per RFC 8693 and OIDC Core. The token is signed by the target's authentication endpoint using key material declared in the target's manifest per §5.1.8.
SAI verifies tokens it presents and tokens it receives using the target's registry-published JWKS. Verification follows the same path as for any other §5.1.8 JWT — there is no SADAR-specific verification step layered on top. The cryptographic primitives, signature verification, and key handling are exactly those defined by the authentication baseline.
The scope mechanism layers OIDC scope claim values onto the SADAR authentication baseline. Several adjacent concerns are out of scope here and live in dedicated sibling pages or companion documents:
• Security Overview — orientation to the security layers and how they compose.
• Authentication Baseline — OIDC Client Credentials over mTLS, JWKS endpoints, key rotation. The authentication mechanism beneath the scope vocabulary.
• SADAR Context Token — the separate authorization-context token that travels with each invocation.
• Trust Models — how an originator's identity propagates through a multi-agent flow.
• Registry Security — registry isolation, manifest signing, and why the registry is not in the runtime authentication path.
• Helper API and Repatriation — Observability pages that complement the telemetry:repatriate scope.
• 7. searchAndInvoke Telemetry and Authentication, Part III — the full normative specification of the scope namespace, the six initial scopes, TTL bounds, and lazy refresh.
• 2. Scope §5.1.8.5 — the umbrella authentication scopes requirement.
• 2. Scope §5.1.8.1 — the authentication baseline beneath the scopes.