Status: Draft architecture model
Date: 2026-09-01
Authority: Pancakes product architecture
This document defines identity as a shared Pancakes node capability.
Pancakes needs a stable way to represent a person across personal, household, guild, cooperative, institutional, hosted, virtual, and offline nodes. A person must be representable without first proving a legal name, address, citizenship, health-card number, banking relationship, or other institutionally recognized identity.
When a Pancakes node interacts with an external service, it may need to establish that a Pancakes person corresponds to an identity recognized by that service. That correspondence is an external identity binding. It does not replace the Pancakes identity or make the external authority the source of the person’s existence within Pancakes.
Each person known to Pancakes has a permanent, opaque Pancakes Person ID. The Person ID is the canonical subject identifier inside the Pancakes ecosystem.
External identifiers are connected to a Person ID through explicit, provenanced External Identity Bindings. A binding records the narrower claim that an external authority’s subject or account corresponds to a Pancakes person according to a stated method and level of assurance.
Identity is a capability layer implemented by Pancakes nodes. It is not a central Pancakes identity service and does not require a global registry of people.
Pancakes Person ID
├── node-local records
├── Ontario service binding
├── financial-service binding
├── social-service binding
└── school binding
A Pancakes Person ID may be created without external documentation. A person without a stable address, government identification, banking access, or health card remains fully representable within Pancakes.
Pancakes nodes do not need to verify a person’s legal or institutional identity merely to represent that person, relate records to them, or recognize them across Pancakes activities. External verification is introduced only where an external interaction requires it.
An Ontario account, bank customer record, social-service client number, or school account does not become the Pancakes primary key. Each remains an authority-specific identity connected to the Pancakes person through a binding.
A binding means:
According to this binding process, this external authority’s subject corresponds to this Pancakes person.
It does not assert that two identifiers are universally interchangeable. The binding retains who established it, how it was established, what the external system actually proved, and whether that conclusion remains current.
Most nodes need only a Person ID. They must not receive a person’s government, financial, school, or social-service identifiers merely because another node has established those bindings.
The canonical Person ID is an internal Pancakes identifier. External services should receive service-specific opaque identifiers where possible rather than the canonical Person ID. This prevents external authorities from correlating a person’s activity across unrelated services.
A personal, household, virtual, or offline node must be able to create and use Person IDs without a connection to a central service. Federation, synchronization, duplicate reconciliation, and external verification may occur later.
A permanent, opaque, non-semantic identifier for a person within Pancakes.
Example:
urn:pancakes:person:7b1998a6-4d20-4cca-9f7f-79a85f369384
The identifier must not encode a name, birth date, location, node, authority, or other personal attribute.
The portable representation of a Person ID used in node records and node-to-node messages. A Person Reference may carry routing or version metadata without changing the underlying Person ID.
An organization or service that maintains its own identity namespace, such as a government program, financial institution, school, employer, or social service.
The authority-specific account or subject identifier recognized by an external authority. It may represent an account, client, student, customer, or legally identified person. Its meaning is defined by the external authority.
A record connecting a Person ID to an External Subject, together with the method, provenance, assurance, lifecycle state, and evidence needed to interpret the connection.
Evidence that the present actor controls a credential, account, device, or Pancakes identity. Authentication does not necessarily establish legal identity.
A description of what a binding process established and how confidently a consumer may rely on it. Assurance is not a single universal score.
Identity is a layered capability. Nodes implement only the profiles required for their responsibilities.
| Profile | Responsibility | Expected adoption |
|---|---|---|
| Identity-aware | Store, accept, and exchange Person References | Required for nodes that represent people or person-related activity |
| Identity-resolving | Associate a local actor, session, or record with a Person ID | Expected for most interactive nodes |
| Identity-hosting | Create Person IDs and maintain canonical person records | Required only where people are enrolled or managed |
| Identity-authenticating | Establish that the current actor controls a Pancakes identity | Required where actions need authorization or accountability |
| Identity-binding | Establish and maintain External Identity Bindings | Required only for nodes that integrate with external identity systems |
| Identity-reconciling | Detect, review, merge, split, or supersede duplicate and conflicting person records | Required for federation and multi-node reconciliation |
A node that records household activity may be identity-aware and identity-resolving without becoming identity-binding. A school integration node may implement identity-binding while exposing only the resulting Person ID to other Pancakes nodes.
An identity-aware node needs operations equivalent to:
accept_person_ref(person_ref)
resolve_person(person_ref) -> local_person_view
associate_record(record_ref, person_ref)
describe_identity_context(person_ref) -> identity_context
An interactive node may also provide:
identify_actor(session_context) -> person_ref
authenticate_actor(authentication_request) -> authentication_result
An identity-binding node additionally needs operations equivalent to:
begin_binding(person_ref, external_authority)
complete_binding(binding_session) -> external_identity_binding
verify_binding(binding_ref) -> binding_status
refresh_binding(binding_ref) -> binding_status
revoke_binding(binding_ref, reason)
list_bindings(person_ref, requesting_context)
These are conceptual contracts rather than a commitment to a particular API, protocol, or programming language.
person_id: urn:pancakes:person:7b1998a6-4d20-4cca-9f7f-79a85f369384
status: active
created_at: 2026-09-01T12:00:00Z
The Person entity contains only Pancakes identity lifecycle information. Names, contact methods, addresses, household memberships, jobs, health information, and external identifiers belong in other records.
binding_id: urn:pancakes:identity-binding:0f05e568-0707-43a9-9204-d5eaf556eceb
person_id: urn:pancakes:person:7b1998a6-4d20-4cca-9f7f-79a85f369384
authority: ontario.ca
namespace: ontario-ca-login
external_subject: protected-authority-specific-value
binding_method: oidc-authentication
assurance:
kind: account-control
claims:
- controls_external_account
status: active
established_at: 2026-09-01T12:30:00Z
last_checked_at: 2026-09-01T12:30:00Z
expires_at: null
evidence_reference: protected:identity-evidence:example
The external subject and evidence reference are sensitive. They must not be included in ordinary node messages or logs.
Nodes relate domain records to a Person ID rather than copying external identity data.
household_member(person_id, household_id, membership_state)
worker(person_id, workplace_id, relationship_state)
student(person_id, learning_record_id)
care_event(person_id, event_id)
These relationships describe the node’s domain. They do not redefine the person’s identity.
Different external interactions establish different facts. A binding must record what was actually established rather than promoting every successful login to verified legal identity.
| Binding event | Permitted conclusion |
|---|---|
| Email login | The actor controls the authenticated email account |
| Ontario.ca Login | The actor controls the corresponding Ontario login |
| Social-service account connection | The external service associates the account with its client record |
| School portal connection | The school recognizes the external subject as a student or participant according to its rules |
| Bank or identity-verification result | The provider verified the returned attributes using its stated process |
| Manual identifier entry | The actor asserted an external identifier; no external verification has occurred |
The assurance record should use named conclusions and claims, not labels such
as high, medium, or low without definitions.
An External Identity Binding may pass through these states:
asserted
→ pending-verification
→ active
→ stale
→ revoked or superseded
Deletion of an external account does not delete the Pancakes person. Loss of a binding does not invalidate node-local records associated with the Person ID.
The model must permit:
Consequently, an External Identity Binding must not be represented as an
unqualified unique equality such as pancakes_id == external_id. It is a
lifecycle-managed association with provenance.
Merge and split operations are consequential identity actions. They require explicit authorization, retained history, affected-node review, and a reversible or compensating procedure.
Nodes should request only the external claims needed for the immediate service. If an external authority can return a verified conclusion, Pancakes should not retain identity-document images or the underlying evidence.
External identifiers and verification evidence remain at the binding-capable node or protected identity component. Other nodes receive a Person Reference and, where necessary, a narrowly scoped assurance result.
Where an external protocol allows it, each external relationship should use a different opaque subject identifier. The internal Person ID must not become a tracking identifier shared among external organizations.
Logs must not contain identity documents, authentication credentials, access tokens, complete external identifiers, or unnecessary personal attributes. Audit records should refer to protected binding records by Pancakes-controlled identifiers.
Possession of a Person ID is not authentication. Knowing a person’s GUID does not authorize an actor to view records, create bindings, or act for that person. Authentication and authorization controls are separate capabilities.
The first implementation may operate within one node, but the model must not assume a permanent central Pancakes service.
An offline or virtual node may create a Person ID and use it immediately. Later federation may discover that another node represents the same person. That discovery creates a reconciliation problem, not a reason to postpone identity creation.
Federated design must eventually define:
These questions remain open and do not block a single-node implementation.
The first implementation should prove the internal model without requiring an Ontario, banking, or other production integration.
Minimum scope:
asserted state.A later integration slice can replace a manual asserted binding with a sandbox OpenID Connect flow and an active, externally confirmed binding.
The identity layer identifies the person or actor to whom an action, permission, record, or relationship applies. It does not replace node governance, Pitchfork accounting, application-specific interpretation, or human-facing Pancakes interfaces.
Clients interpret.
Pitchfork accounts.
Nodes govern.
Identity authorizes.
Pancakes humanizes.
Within that architecture, this model supplies the stable person reference and the controlled boundary between Pancakes identity and external identity authorities.