IdentityMapper

IdentityMapper is the reference implementation of the IdentityMapper Protocol.

IdentityMapper Protocol defines a canonical identity exchange between heterogeneous identity systems. It does not replace authentication or trust. It standardizes how verified identity is represented, projected, and resolved across different identity worlds.

It is not an LDAP wrapper, OAuth wrapper, or authentication server.

It defines a shared boundary between identity worlds:

Source Provider
    |
    v
canonical Identity
    |
    v
Target Identity Mapper

Identity is the canonical representation shared by all source providers and target identity mappers.

Project Status

IdentityMapper is a protocol draft and reference implementation under active development.

The core architecture has been validated against multiple identity models.

The reference implementation verifies:

14 source providers x 14 target identity mappers = 196 projections

The IdentityMapper Rule

Implementations are never mapped to each other.

Every implementation maps only to the domain invariant.

The Mapper Rule

Mappers never contain business logic.

Their only responsibility is translating implementation models into domain models.

A mapper does not validate, authenticate, authorize, persist, or decide.

A mapper is deterministic. The same input always produces the same domain model.

IdentityMapper defines the identity domain model, the capability contracts, and the source-to-target identity protocol. It does not perform authentication as a service by itself.

Core Idea

External systems, protocols, products, and APIs have their own implementation models. A mapper translates one implementation model into a stable domain model. Business logic works with the domain invariant, not with the implementation.

Source providers reduce proof or assertions into the canonical Identity model. Target mappers project that Identity into a target world. Source and target implementations never communicate directly.

The Invariant Mapping Pattern is:

Implementation
       |
       v
Mapper
       |
       v
Domain Invariant
       |
       v
Capabilities

The pattern can be summarized as:

1. Find the domain invariant.
2. Define the minimal domain contract.
3. Map every implementation to the invariant.
4. Business logic depends only on the invariant.
5. Capabilities extend the invariant.
6. Implementations never communicate directly.

Quick Example

Identification
--------------
identifier

Credential
----------
credential

        |
        v

Authenticate
    |
    +-- ResolveIdentity
    |
    +-- VerifyCredential

        |
        v

Identity

Identification is not Identity. Identification selects a candidate. Credential verifies the candidate. Only successful authentication produces an Identity.

Documentation

The implementation details are intentionally kept out of this README.

• Documentation index
• RFC 0001: IdentityMapper Protocol
• RFC 0002: IdentityMapper Compliance Suite
• RFC 0003: IdentityMapper Protocol Versioning
• Architecture
• Architecture verification
• Capability protocol
• IdentityMapper protocol
• Implementer's guide
• External implementation experiment
• Compliance badge
• Compatibility matrix
• Host
• Host service
• MapIdentity
• Reduction matrix
• Reduction template
• Provider footprint
• Domain concepts
• Capabilities
• Provider notes
• Changelog

Repository Structure

src/identity_mapper/
  domain.py
  capabilities.py
  capability_protocol.py
  mapper.py
  matrix.py
  providers/
    basic/
      matrix.json
    ldap/
      matrix.json
    oauth/
      matrix.json
    ...

src/identity_mapper_service/
  app.py
  registry.py
  responses.py
  schemas.py
  service.py

compliance/
  test_protocol_compliance.py

config/
  config.json

docs/
  rfcs/
  architecture.md
  compatibility-matrix.md
  identitymapper-protocol.md
  provider-footprint.md
  host.md
  host-service.md
  reduction-matrix.md
  reduction-template.md
  architecture-verification.md
  domain/
  capabilities/
  providers/