Issuer-side back-link check (credentials)

Credentials verify with a similar mutual-back-link pattern, but the shape is asymmetric. The entity names the credential by ID; the issuer names the subject by network ID.

The two halves

Subject side

The entity's olpn.json lists the credential in credentials[]. Each entry has a credential ID in @user@domain[/path] form:

{
  "network_id": "§:entity:jane.law",
  "credentials": [
    {
      "id": "@[email protected]/attorneys",
      "title": "Attorney",
      "type": "Employment"
    }
  ]
}

Issuer side

The issuer publishes a credential document at https://{domain}/{user}/olpn-credential.json with an olpn_entity_id naming the subject:

{
  "olpn_entity_id": "§:entity:jane.law",
  "olpn_credential": {
    "id": "@[email protected]/attorneys",
    "title": "Attorney",
    "type": "Employment",
    "property": { ... },
    "dataset": { ... }
  }
}

The check

1. Resolver parses the credential ID by finding the second @. Splits into username and domain (with optional /path on the domain side).
2. Fetches https://{domain}/{username}/olpn-credential.json, or the HTML embed fallback.
3. Parses. Must have olpn_entity_id.
4. Case-insensitive compare of olpn_entity_id against the entity being verified.
5. If equal, the credential verifies, with verified: true and a timestamp. Otherwise, dropped.

Asymmetry with property verification

Property verification has the entity naming the property in properties[] by ID, and the property naming the entity in ownership[] by network_id. Both sides reference each other by opaque identifiers.

Credential verification has the entity naming the credential ID, and the issuer naming the subject's network_id directly in olpn_entity_id. The credential document does not re-name the credential ID back at the entity. This is because the URL path is the credential ID — by fetching {domain}/{user}/olpn-credential.json the resolver is implicitly asserting the ID structure.

Datasets do not change verification

A credential ID can encode a dataset path (@[email protected]/attorneys), but the resolver does not verify datasets. The dataset field inside the credential document is metadata for display. Verification only checks the olpn_entity_id.

Failure modes

• Malformed credential ID. Must start with @ and contain a second @. Otherwise the resolver can't parse it and drops it.
• Credential document missing. Issuer has not published it, or 404.
• olpn_entity_id missing. The document exists but the back-link isn't populated.
• olpn_entity_id mismatch. The issuer issued to someone else. The resolver will not verify this for the current entity.
• Malformed JSON or wrong content-type. Parse failure.

Revocation

To revoke a credential, the issuer removes the credential document from its domain, or sets olpn_entity_id to a different (or empty) value. The next time a resolver re-fetches, the credential will no longer verify. There is no revocation list; revocation is implicit in the fact that the issuer controls the document.

An implication: a subject cannot keep a credential valid against a revoking issuer. The protocol sides with the issuer on credential status, which is the right default. Issuers who revoke irresponsibly damage their own credibility.