The identity the frontend shows: who the caller is, their roles, and application-specific details.

Authentication establishes an Arc.Principal; identity enrichment turns it into what the UI needs. The two are separate on purpose: identity is presentation data and never an authorization decision. Commands and queries are protected by authorize, not by what this module returns.

The frontend reads it from GET /.cratis/me; LiveView reads it with Arc.LiveView.assign_identity/2. Both call resolve/2, so they cannot disagree.

Providing details

Implement Arc.Identity.Provider and Arc discovers it:

defmodule MyApp.IdentityDetails do
  use Arc.Identity.Provider, details: MyApp.Identity.Details

  @impl true
  def details(%Arc.Identity.Context{id: id}) do
    {:ok, %MyApp.Identity.Details{display_name: MyApp.Accounts.display_name(id)}}
  end
end

details: names an Arc.Schema module. It is what /.cratis/identity-details/schema describes and what proxy generation turns into a typed TypeScript class for useIdentity.

The three outcomes

• not authenticated - GET /.cratis/me answers 401
• authenticated but the provider returned {:unauthorized, details} - 403
• otherwise - 200 with {id, name, isAuthenticated, isAuthorized, roles, details}