fix(psp-1): removing ambiguous uses of the word "profile"

Author: CMCDragonkai

docs/reference/specifications/psp-1.mdx

@@ -37,7 +37,7 @@ sets), delegation/attenuation semantics, revocation checks, and CEP verification
 behavior. Transport/envelope bindings and sigchain framing are defined in PSP-3;
 receipt formats and proof traces are defined in PSP-2; enforcement
 placement/modes are defined in the CEP/BA specification; acceptance and
-governance live in TAP/RAM and related profiles.
+governance live in TAP/RAM.
 
 ## 2. Terminology and Requirements Language
 
@@ -160,8 +160,7 @@ convention. Scheme names (e.g., `vault:`, `k8s:`) and content identifiers (e.g.,
 
 These canonical names appear in the textual specification and in the
 non-normative JSON projections. PSP-3 defines the on-wire field names and
-encodings; profiles MAY map the canonical names to alternative encodings but
-MUST provide a bijection between the PSP-1 names and the on-wire representation.
+encodings.
 
 ## 3. Overview and Goals
 
@@ -206,8 +205,8 @@ What PSP-1 defines:
 - Receipt schemas: All receipt formats (PoAR/VOR/View) are specified in PSP-2.
 - Transport/envelope and sigchain framing (JOSE/COSE/DSSE, canonical bytes):
   specified in PSP-3.
-- Channel-binding mechanisms: Concrete binding profiles (e.g., TLS exporter,
-  DPoP) are profiled elsewhere; PSP-1 only requires a verified binding.
+- Channel-binding profiles: Concrete channel-binding mechanisms (e.g., TLS
+  exporter, DPoP) are defined elsewhere; PSP-1 only requires a verified binding.
 - Global time/ordering: PSP-1 does not require a global clock or total order.
   Acceptance (TAP) specifies clock sources and tolerances.
 - Secret issuance/derivation/aggregation crypto and interactive evaluation
@@ -307,14 +306,14 @@ Deterministic Evaluation and PSP-4).
   signature, and tightening rule are defined in the Builtins registry (PSP-4).
   The exact set in use is pinned by `builtinsId` in the Grant.
 - Channel comparisons (e.g., `channelGeq`) consult the pinned
-  `channelLatticeId`, which defines the set of recognized channel profile
-  identifiers and their partial order. Unknown profiles or an unknown lattice
-  MUST cause deny.
+  `channelLatticeId`, which defines the set of recognized channel-binding
+  profile identifiers and their partial order. Unknown identifiers or an unknown
+  lattice MUST cause deny.
 - Resource subset checks in declaration-aware builtins (e.g., inPairSet) consult
   the scheme comparator selected by the resource's scheme name.
 - If a builtin, lattice, or comparator required by the Program is unknown or
   unavailable, evaluation MUST fail closed.
-- Programs may constrain the live session's profile using
+- Programs may constrain the live session's channel-binding profile using
   `channelGeq(channel, "...")` as defined by the pinned channel lattice.
   Programs may also assert runtime or provenance context via equality over
   environment facts (e.g., `ctxEq("k","v")`). How those environment facts are
@@ -371,7 +370,7 @@ evaluate Programs deterministically and emit minimal proof traces (which check,
 which query, which literals). This keeps receipts auditable without a general
 Datalog engine. If richer inference is required in a domain, issuers or
 attestors SHOULD precompute finite sets (content-addressed) and reference them
-from the Program; alternative profiles that carry ruleful logic MUST remain
+from the Program; alternative extensions that carry ruleful logic MUST remain
 TAP-gated and provide either a compiled CPL/0 guard or an approved CEP runtime.
 
 ### 4.5 Evaluation Environment
@@ -386,7 +385,7 @@ reference these facts by name.
   - iat: Int - NumericDate (Unix seconds) carried by the Presentation.
   - presenter: Str - DID of the presenting Subject.
   - enforcer: Str - DID/identifier of the enforcing CEP (audience).
-  - channel: Str - profile representing the live session's binding.
+  - channel: Str - the live session's channel-binding profile identifier.
   - ctx: `Map<Str, Term>` - runtime context (e.g.,
     `{"ns":"prod","pod":"runner-42"}`).
 - Optional environment facts (TAP-gated)
@@ -433,9 +432,9 @@ PairSet/ActionSet.
 - data:export
 - model:infer
 
-Actions are plain strings compared for equality. Any domain governance over
-action names (allowlists, required constraints) is outside PSP-1 and MAY be
-enforced by TAP or profiles by requiring corresponding Program literals.
+Actions are plain strings compared for equality. Governance over action names
+(e.g., allow-lists, required prefixes/constraints) is out of scope for PSP-1 and
+is defined by TAP policy.
 
 ### 5.2 Resources
 
@@ -589,8 +588,8 @@ identifier references an immutable snapshot in a registry (see PSP-4):
   one scheme is referenced.
 - **`channelLatticeId`** - **REQUIRED only if** the Program uses the
   `channelGeq` builtin. It is a content-addressed snapshot of the channel
-  lattice used to interpret `>=` between channel profile labels. It MUST be
-  omitted if the Program does not call `channelGeq`.
+  lattice used to interpret `>=` between channel-binding profile identifiers. It
+  MUST be omitted if the Program does not call `channelGeq`.
 
 A Grant does **not** pin any action registry; actions are plain strings compared
 for equality. Governance over action names lives in TAP and MAY be enforced by
@@ -606,11 +605,11 @@ rulebooks when evaluating Programs.
   builtin operators. Each operator entry defines the operator's identifier,
   argument types, semantics, tightening rules for attenuation, and resource
   bounds (time/memory). Unknown operators MUST cause denial at verification.
-- **Channel lattice snapshot** - Contains a unique ID, a set of channel profile
-  labels, and a partial order over those labels. The partial order defines the
-  result of `channelGeq(channel, floor)`. The precise meaning of each label
-  (e.g., `mtls:v1`, `tlsExporter:v1`, `dpop:v1`, `bearer:v1`) is defined outside
-  this spec in the registry; only the ordering matters here.
+- **Channel lattice snapshot** - Contains a unique ID, a set of channel-binding
+  profile identifiers, and a partial order over those identifiers. The partial
+  order defines the result of `channelGeq(channel, floor)`. The precise meaning
+  of each label (e.g., `mtls:v1`, `tls-exporter:v1`, `dpop:v1`, `bearer:v1`) is
+  defined outside this spec in the registry; only the ordering matters here.
 - **Schemes manifest (`schemesSnapshotId`)** - Contains a unique ID and a map
   from scheme names to comparator snapshot IDs. Each comparator snapshot defines
   normalization and subset decision rules for one scheme (e.g., vault, k8s,
@@ -650,17 +649,17 @@ A CEP MUST deny if any of the following holds:
 
 ### 6.6 Interpreting `channelGeq`
 
-The literal `channelGeq(channel, floor)` compares the verified channel profile
-(from the Presentation's channel binding) against the floor value under the
-pinned channel lattice. Common channel binding profiles include:
+The literal `channelGeq(channel, floor)` compares the verified channel-binding
+profile identifier (from the Presentation's channel binding) against the floor
+value under the pinned channel lattice. Common channel-binding profiles include:
 
 - **`mtls:v1`** - Mutually authenticated TLS 1.3 (see RFC 8446).
-- **`tlsExporter:v1`** - TLS exporter-based channel binding (see RFC 9266).
+- **`tls-exporter:v1`** - TLS exporter-based channel binding (see RFC 9266).
 - **`dpop:v1`** - Demonstrating Proof-of-Possession (DPoP) (see RFC 9449).
 - **`bearer:v1`** - No sender-constraining (Bearer tokens).
 
 The pinned lattice defines the partial order between these labels (for example:
-`mtls:v1 >= tlsExporter:v1 >= dpop:v1 >= bearer:v1`). This subsection is
+`mtls:v1 >= tls-exporter:v1 >= dpop:v1 >= bearer:v1`). This subsection is
 informative; the authoritative ordering and the set of recognized profiles are
 defined by the snapshot referenced by `channelLatticeId`.
 
@@ -999,9 +998,9 @@ Grants and transient proof-of-use.
     - syntactic attenuation (checks/literals tightening and declarations
       subset).
   - How parent Grants are made available is TAP-governed (e.g., local cache,
-    pre-enforcement resolver, or a profile-defined stapled chain receipt / zk
-    chain proof). At enforcement, if required parent Grants are not locally
-    available, the CEP MUST deny.
+    pre-enforcement resolver, or a TAP required stapled chain proof / zk chain
+    proof). At enforcement, if required parent Grants are not locally available,
+    the CEP MUST deny.
   - Any failure in the above MUST cause deny.
 - Storage
   - Presentations MUST NOT be recorded on sigchains.
@@ -1050,9 +1049,9 @@ alternative encodings but MUST preserve the semantics.
     step outside CPL/0 evaluation. At enforcement, if required parent Grants are
     not locally available, the CEP MUST deny.
   - A TAP policy (with PSP-3 bindings) MAY define alternate, bounded chain
-    attestation artifacts (e.g., a stapled chain receipt or a zero-knowledge
-    chain proof). PSP-1 core does not define or require such artifacts and
-    forbids embedding raw Grant bodies in Presentations.
+    attestation artifacts (e.g., a stapled chain proof or a zero-knowledge chain
+    proof). PSP-1 core does not define or require such artifacts and forbids
+    embedding raw Grant bodies in Presentations.
 
 **Example:** The following JSON projection illustrates one possible mapping of
 the conceptual fields. Names and encodings are illustrative only; the normative
@@ -1081,9 +1080,9 @@ specification of on-wire fields is defined in PSP-3.
   channel binding verification, custody/attenuation verification, and Program
   evaluation under the pinned semantics and bundled declarations.
 - Per-use narrowing is achieved by the Program's literals (e.g., ctxEq, ttlOk)
-  evaluated against Presentation-supplied ctx and iat/exp. A future TAP-gated
-  profile MAY introduce presentation overlays with strict attenuation and
-  receipt requirements.
+  evaluated against Presentation-supplied ctx and iat/exp. TAP policy MAY
+  introduce presentation overlays with strict attenuation and receipt
+  requirements.
 
 ## 11. Delegation and Attenuation
 
@@ -1215,8 +1214,8 @@ hop-by-hop. Children MAY only narrow or preserve authority.
 - No network I/O in evaluation:
   - Program evaluation and attenuation checks MUST NOT perform network I/O.
     Required parent Grants MUST be locally available at enforcement (e.g., via
-    cache, pre-enforcement resolver permitted by TAP, or a profile-defined
-    stapled artifact). If not locally available, the CEP MUST deny.
+    cache, pre-enforcement resolver permitted by TAP, or a TAP-defined stapled
+    artifact). If not locally available, the CEP MUST deny.
 
 ### 11.7 Fail-Closed Conditions
 
@@ -1858,7 +1857,7 @@ CEP evaluation outline
   Principal-side (as shown).
 - Presentations remain small; do not embed Grant bodies in PSP-1 core. If
   parents aren't local at enforcement, deny (TAP defines pre-enforcement
-  hydration or profile-level stapling).
+  hydration or stapling chain proof).
 - Receipts: PoAR should capture enough to audit the decision (`programId`,
   declaration CIDs, pins, minimal trace), plus derivation metadata (tokenRef),
   but never the token itself.
@@ -2065,7 +2064,7 @@ invocations.
 | --------------- | ------------------------------------------ | ------- | ----------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------- | ----------------------------------------------------------- |
 | `withinTime`    | `(now:Int, nbf:Int, exp:Int)`              | Bool    | `nbf <= now < exp`                                                                                          | `[nbf_child >= nbf_parent $\land$ exp_child <= exp_parent]` | ill-typed => deny; else boolean result                      |
 | `ttlOk`         | `(iat:Int, now:Int, ttlMax:Int)`           | Bool    | `now < iat + ttlMax`                                                                                        | `ttlMax_child <= ttlMax_parent`                             | ill-typed => deny; else boolean result                      |
-| `channelGeq`    | `(channel:Str, floor:Str)`                 | Bool    | channel >= floor in the pinned lattice                                                                      | floor_child >= floor_parent                                 | unknown lattice or profile => deny                          |
+| `channelGeq`    | `(channel:Str, floor:Str)`                 | Bool    | channel >= floor in the pinned lattice                                                                      | floor_child >= floor_parent                                 | unknown lattice or channel-binding profile => deny          |
 | `inPairSet`     | `(action:Str, resource:Str, pairsCid:Str)` | Bool    | `(action, resource) $\in$ PairSet(pairsCid)` (resource normalized via comparator)                           | PairSet_child $\subseteq$ PairSet_parent                    | missing/malformed declaration or comparator failure => deny |
 | `inActionSet`   | `(action:Str, actionsCid:Str)`             | Bool    | `action $\in$ ActionSet(actionsCid)`                                                                        | ActionSet_child $\subseteq$ ActionSet_parent                | missing/malformed declaration => deny                       |
 | `inResourceSet` | `(resource:Str, resourcesCid:Str)`         | Bool    | $\exists$ selector $\in$ ResourceSet(resourcesCid) such that resource $\subseteq$ selector under comparator | ResourceSet_child $\subseteq$ ResourceSet_parent            | comparator or normalization failure => deny                 |