> For the complete documentation index, see [llms.txt](https://docs.lpp-minduniverse.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.lpp-minduniverse.org/lingua-pactum-protocol-lpp-documentation/12.-interoperability-and-standards/12.4-identity-and-credential-mapping.md).

# 12.4 Identity & Credential Mapping

LPP requires identifiable principals and issuers.

It does not require one universal identity system.

The architectural model is:

```
External Identity System
        ↓
Identity Evidence
        ↓
LPP Principal / Issuer Mapping
        ↓
Authority Evaluation
```

#### Identity Is an Input to Authority

Identity answers:

> **Who is this principal or issuer?**

LPP still asks:

> **What legitimate authority does this identified principal possess for this action?**

Therefore:

```
Valid Identity
⇏
Valid Authority
```

#### External Identity Frameworks

An implementation may rely on external identity systems for:

* human identity,
* workload identity,
* service identity,
* agent identity,
* organizational identity,
* or cryptographic identity.

LPP need not replace these systems.

Instead, an Authority Object may reference the identity representation recognized by the deployment.

#### Credential Mapping

External credentials may carry claims about:

* identity,
* organizational role,
* issuer,
* qualification,
* authorization,
* or other governance-relevant facts.

LPP may use those claims as evidence.

But a credential should not be treated as equivalent to an Authority Object unless it actually expresses the authority semantics required by the applicable LPP profile.

Thus:

```
Credential
≠
Automatically an Authority Object
```

#### Verifiable Credentials

The Authority Objects research identifies W3C Verifiable Credentials as a relevant adjacent mechanism.

The conceptual relationship is:

```
Verifiable Credential
        ↓
may represent verifiable claims

Authority Object
        ↓
represents the legitimacy basis
for a specific class of AI-triggered action
```

A deployment could potentially encode or reference LPP-relevant authority claims using a verifiable credential framework.

However, GitBook v2.0 does not claim that a finalized normative LPP-to-VC schema has already been standardized.

#### Identity Portability

Cross-system interoperability requires the receiving system to understand or map the identity associated with an Authority Object.

The important invariant is not that every system use the same identity namespace.

It is that:

```
issuer
subject
principal
responsibility
```

remain unambiguously resolvable under the relevant trust relationship.

#### Identity Mapping Does Not Weaken Authority

An identity bridge must not silently transform:

```
Identity A
```

into:

```
Broader Authority A+
```

Mapping establishes identity equivalence or recognition.

It does not create new legitimate scope.

***