ARAP: core-first restructure with companion profiles

[mcguinness]

Restructures the AuthZEN Access Request and Approval Profile (ARAP) into a narrow-waist core with companion profiles, without changing the force of any requirement.

What changes

Core protocol first. The base document reads in flow order: requestable denial, submission, task, approval and re-evaluation. Message definitions stay in those sections; every processing rule has one normative home in PEP Processing, PDP Processing, or Access Request Service Processing. Trusted-state examples lead; binding artifacts follow in their own section.

Companion profiles. Four capabilities move out of the base, each hooking in through the extension points and registering its member names:

• authzen-access-request-catalog-profile-1_0.md: catalog-backed request input (informative reference)
• authzen-access-request-bulk-profile-1_0.md: multi-item submissions and the partial status
• authzen-access-request-callback-profile-1_0.md: completion notifications
• authzen-access-request-actor-profile-1_0.md: client.actor, client.source, and actor-chain verification

The core states that a normative reference to a companion is authoritative when its feature is used and does not require implementing it.

Explicit models. A Binding Model table (denial and approval boundaries, signed and lookup forms), seven Protocol Invariants, a Decision Context Members table giving each extension member's effect when recognized and its handling when not, and the profile's position among the AuthZEN continuation mechanisms (obligations, partial evaluation, Access Request, retry).

Security Considerations are threat statements that cite the rules mitigating them; they introduce no requirements.

What does not change

No requirement was added, removed, or changed in actor, condition, obligation, exceptions, or force. The base document's RFC 2119 keyword count fell from 409 to 314 entirely through listed duplicate folds, each paired with its surviving rule, and relocation to companions. Every stage was verified by script (build, anchor resolution, section-aware unit comparison, sentence diff) and independently audited before commit; the audits found no meaning change.

Open protocol questions

The restructure surfaced protocol questions it did not resolve, and adopts no answer to any of them. They are filed as eight issues, each stating the problem and recommending a solution:

• ARAP: signed approval state has no interoperable payload #659 signed approval state has no interoperable payload
• ARAP: the inline denial-binding form and the PEP's echo #660 the inline denial-binding form and the PEP's echo
• ARAP: issuer and audience identifiers and key discovery #661 issuer and audience identifiers and key discovery
• ARAP: binding rules do not name which identity they compare #662 binding rules do not name which identity they compare
• ARAP: the PEP's re-evaluation round trip is underspecified #663 the PEP's re-evaluation round trip is underspecified
• ARAP: submission processing order #664 submission processing order
• ARAP: the base Task Handle surface and extensibility #665 the base Task Handle surface and extensibility
• ARAP: should signed binding be a separately claimed conformance target? #666 should signed binding be a separately claimed conformance target?

Five independent reviews of this restructure converged on the same blockers, and all but one sit in the signed-binding layer. #659, #660, and #661 together define what a portable signed artifact contains and who vouches for the key that signs it. #666 asks who has to implement any of it: today every conforming Access Request Service and PDP must support JWS verification even when their deployment never exchanges a signed artifact, and that is the change that would most reduce what an implementer builds. #659, #660, #661, and #666 should be settled in the same cycle. #663 is the one a PEP implementer meets first. A longer write-up of the layering, with the move map and the capability-advertisement semantics, is in PROFILE-FAMILY-PROPOSAL.md on the arap-editorial branch.

Two further issues against the companion profiles, for callback acceptance semantics and an unsupported items member, are drafted and not yet filed.

Also

CI workflow, README, and Makefiles build and publish all five profiles.

[davidjbrossard]

Overall I think it reads well. I couldn't see any glaring issues and it breaks down the original doc into the subfiles you created.

• Re-evaluation Mode is never explicitly defined. Should we have a glossary of terms?

[mcguinness]

Good catch. ARAP already has a Terminology section, but the completion-mode concept was missing from it. I've added "Completion Mode" there, with reevaluate as the base mode, and replaced the undefined "Re-evaluation Mode" with "the reevaluate completion mode", which matches the OAuth profile's wording. No normative change.

[davidjbrossard]

Collectively approved on the WG call 10/01