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

ARC 2.0.0-beta.28

DID Connect in ARC

ARC embeds DID Connect service code to resolve trusted credentials into caller information and optional instance membership context.

The Node runtime imports the embedded @arcblock/did-connect-service and uses it at its authentication boundary. The resolver accepts trusted credentials, constructs caller information for AFS, and can add an instance membership role when the server supplies a trusted instance DID.

Runtime seam

PieceRole in ARC
createEmbeddedAuthServiceBoots connect-service against a local SQLite (or injected) auth database under the daemon home
HTTP handlerServes /.well-known/service/* for connect endpoints the host exposes
rpc.resolveIdentityTurns JWT / access-key inputs into a connect-service identity DTO
Shared resolveCallerFromCredentialsMaps that DTO to AFS CallerInfo for both Node and Cloudflare
@aigne/afs-membersOptional read-only AFS view of instance memberships for the fixed instance DID

Membership context is not client-selected. Only a server-resolved instance DID may enter membership resolution. A request cannot create a stronger relationship with an instance merely by naming one.

What to integrate against

Treat ARC's caller context as the handoff point for an AFS-aware Blocklet:

  1. Rely on the runtime to produce CallerInfo.
  2. Bind presentation to session facts if needed.
  3. Let provider and session policy authorize each operation after the handoff.

If you need DID Connect protocol, wallet flows, or SDK usage outside the ARC runtime seam, use DID Connect's own documentation and packages. Do not treat this page as a full DID Connect product manual.

What not to treat as the ARC product surface

MaterialHow to treat it
Historical DID Connect admin / management UIsLineage or optional host UI — not the stable ARC extension contract for new apps
Standalone historical product marketing pagesContinuity references only; not proof of a complete migration into ARC
arc did developer / provider / blocklet identity toolsSeparate CLI identity workflow for entity manifests; not end-user session login

arc did info and arc did check require an entity manifest in the current directory (blocklet.yaml, .aup/, and related layouts). Running them in an empty directory fails with:

text
ERROR: No entity manifest found in current directory (looked for blocklet.yaml, .aup/, index.html, index.{txt,md,ans}, package.json)

That failure is expected for session-auth work; those commands are for package/provider identity, not for inspecting a logged-in end user.