Profiles
The core of ATEP answers who sent an envelope, whether it was altered, what attestations the sender holds and whether they are revoked. A profile is a separate document that answers a different question: what does a payload mean, and what must a receiver do about it, for one domain. Anything of the second kind belongs in a profile and not in the core.
Status. The profiles are working documents of the project, part of the working Draft 10 of the specification, which is not published. They have not been reviewed by anyone outside the project. Draft 09 is still the current published draft, and it still contains the robotics profile as its section 17. ATEP is an experimental alpha and has not been independently audited.
| Profile | Code | Draft | State |
|---|---|---|---|
| ATEP-R, robotics | R | Draft 00 | The text of section 17 of Draft 09, moved to its own document without being rewritten. Stewarded by AIRAD LABS for now. |
| ATEP-C, chain of custody | C | none | A slot only, not started. Whether to build it is a decision that has not been made, and it needs review by people who build evidence systems and who know the privacy law that applies before it becomes a draft. |
What a profile may and may not do
A profile may define payload types, claim types, header values and the rules for what a receiver does with the result of core verification, including failing closed. It may not change how the core verifies an envelope, change an envelope byte or an error code of the core, require a chain, a token, a registry or a log, or define a claim about a person, a score, or a way to list an agent’s interactions. These are the design commitments of governance.
A verifier that implements only the core verifies every envelope correctly. It does not interpret what the payload means. An envelope can name the profile its sender applied in an optional protected header, profile, which a core verifier reports and does not interpret; a verifier that does not implement the named profile still verifies the envelope in full. The header is specified in the working Draft 10 and implemented in the code in the repository. No release carries it yet.
What has not moved yet
The profile documents exist, but the core still carries what ATEP-R uses: the command-class header, a policy setting and three step 1 errors. Moving them out is later work, and renaming claim types by profile would change signed data and the test vectors, so it is not planned unless it is decided. The specification says exactly this in its section 17.
Registering a profile
There is no registry and none is planned. A profile is listed in the repository by a change that follows the contribution rules, and being listed says only that the project has a copy of it. Anyone may write a profile for another domain and publish it elsewhere. The rules and the eight sections of a profile document are in the profiles README.