メインコンテンツへスキップ

ARC 2.0.0-beta.28

Integrate identity

Treat verified caller context as the handoff into session views and provider policy, then add DID Connect only where the runtime already resolves credentials.

The integration point for identity is not a client widget. ARC resolves credentials into caller context at the runtime boundary, then uses that context when it constructs session data views and applies policy.

  1. Read Caller context so you know what CallerInfo contains and what fails closed.
  2. Read Session data and session views so you know which paths a caller can receive.
  3. Store durable per-user data through the session's /user (and only use /space when the runtime enables it for your blocklet scope).
  4. Keep authorization in provider and runtime policy. Use AUP or Web Device only for presentation and path binding.
  5. When you need the protocol or SDK itself, follow DID Connect in ARC for the runtime seam, then link out to DID Connect upstream materials for protocol details.

What “integration” means in ARC

LayerYour jobRuntime job
CredentialsDo not invent alternate auth headers in UI messagesResolve cookie / Bearer / access key into CallerInfo
Session viewBind UI and logic to /user, /tmp, and declared mountsBuild SessionUserAFS for the resolved caller only
MembershipDo not trust client-selected instance rolesOverlay membership only when server supplies instance context
StorageMount or use DID Space through supported AFS pathsEnforce role prefixes, isolation, and write gates

Practical rules

  • Prefer session paths over reconstructing spaces/<did>/blocklets/... in application code.
  • Prefer server-resolved caller fields over form fields that “look like” a DID.
  • Prefer local blocklet runs for UI acceptance; use isolated arc space --root-path for offline data inspection (Inspect local spaces).
  • Do not package historical DID Connect admin UIs as the ARC-stable extension surface for new work.

Not covered here

End-to-end passkey onboarding screens, OAuth provider configuration, remote multi-tenant provisioning, and membership administration APIs need their own versioned contracts and examples. This section stops at the verified handoff that current source implements.