# Optional author contact profile — Legible

This optional profile lets an author associate a chosen display name or
contact channel with their signing key and select it for an exchange or
publication. Its edition is `legible-author-contact/1`. It is separate from
Appoint, Trace, Nod, Response and Redaction records and adds no fields or
validity conditions to them. Draft participation needs neither a signing-key
identifier (DID) nor a contact profile.

An author MAY keep one current profile for each supported Ed25519 `did:key` at
`.legible/contacts/contact-<sha256-of-UTF8-DID>.json`. The directory SHOULD be
ignored by Git by default. A selected profile may accompany an exchange or a
static publication, but signature and storage do not authorize either action.
The filename is stable across updates and unique to the DID. The profile does
not establish a person's civil identity or prove control of an email account.

The JSON envelope has exactly `id`, `content`, and `security`. `content` has:

| Field | Meaning |
| --- | --- |
| `profile` | Exactly `legible-author-contact/1` |
| `author` | Supported Ed25519 `did:key` |
| `revision` | Positive JSON-safe integer (at most 9007199254740991), increasing for each replacement |
| `state` | `active` or `withdrawn` |
| `display_name` | Optional nonempty text, active profiles only |
| `channels` | Optional nonempty array of at most five `{kind,value}` pairs, active profiles only |

Supported channel kinds are `email` (address) and `https` (public HTTPS URL).
An active profile requires a name or a channel. A withdrawn profile contains
neither. Unknown and null fields are rejected. `id` is the lowercase SHA-256 of
RFC 8785 JCS bytes of `content`. `security` contains exactly `signature`, an
ASCII-armored plain Ed25519 SSHSIG over the UTF-8 bytes of the 64-character ID,
without a newline, in the distinct namespace **`legible-contact`**. The
public key must match `author`. Record signatures use namespace `legible` and
cannot be reused here. An author reviews the exact content and signs through
their trusted signing path. The profile carries no payment credential, mandate,
bank details, or evidence-access permission.

For example, unsigned content to review before signing:

```json
{"profile":"legible-author-contact/1","author":"did:key:<author-key>","revision":1,"state":"active","display_name":"Example author","channels":[{"kind":"https","value":"https://example.org/contact"}]}
```

`legible contact-id --in content.json` prints the exact ID to sign.
After a person signs it with OpenSSH using `-n legible-contact`, the command
`legible contact-seal --in content.json --sig id.sig --repo <directory>`
verifies and installs the current file. `contact-verify` checks a standalone
file; `contact-import` verifies and compares an incoming file. A repeat of the
same ID is a no-op. Lower revisions are rejected; differing content at the
same revision is a conflict. Higher revisions replace the local current file.
No historical email contents need be retained. A previously unseen profile's
revision does not prove it is the newest version anywhere on the network.

An author can sign a higher `withdrawn` revision. A publisher can also stop
publishing a profile under its own policy or in response to a relevant request,
even without that signature. The publisher must check its own pages, catalogs,
downloads, generated packages, backups and deployment when correcting or
removing information. Neither route recalls copies already distributed.

Public contact data can be personal data. Publishers assess the purpose, lawful
basis, access and correction or removal process for their own processing.
`visibility: public` on a record, a profile signature and a matching DID are
not consent to publish a contact channel, send it to a model or initiate a
payment. External AP2/x402 payment authorization and settlement remain distinct.

## Signature meaning

This auxiliary profile uses its own signing meaning and the `legible-contact`
namespace. Its signature does not adopt the NCO associated with Legible record
signatures in the `legible` namespace. A profile's declaration, verification and
publication permissions remain separate from those of any linked record.