Authorization Evidence and Audit Trail for OAuth 2.0 Access Tokens

1.1. Relationship to the Bounded Work Framework

OAuth 2.0 Bounded Work Authorization [I-D.liu-mcguinness-oauth-bounded-work] sets out a framework for work a user has approved. It describes three objects: a bounded work proposal, the governing authorization that an approval decision establishes for it, and approval evidence. It states the invariants that relate them and lists eight requirements, R1 through R8, that a realization of the framework has to meet. It specifies no wire formats.¶

This specification is a realization of the framework's third object. It defines the evidence record itself, how that record is projected into credentials, and the mechanism through which the approver can end the authorization the record describes. Its terminology (Section 2) uses "governing authorization", "approval record", "approver", and "subject" with the meanings the framework gives them.¶

Against the framework's requirements, this specification is the realization of R2, of R5, and of the part of R7 that runs from a credential to the approval behind it. It also carries the distinctness that R1 asks of the identifier: the disclosure object names the governing authorization by an identifier that is not the client identifier, not a token issued under the authorization, and not a refresh token family (Table 3), and the Authorization Server assigns one where the authorization has none of its own.¶

The remaining requirements belong to other work. Comparing each requested operation against the approved bounds, and refusing where the comparison cannot decide (R3), is the work of whatever framework supplies the bounds, for example domain-specific authorization schemas ([I-D.liu-oauth-authorization-schemas]). Refusing every issuance path once the authorization has ended (R4), and bounding the time within which already issued credentials stop being accepted (R6), are properties of the token layer; Section 6 states what an ending requires of the Authorization Server, but it neither covers every issuance path nor sets an acceptance window. Answering a query about the authorization from a party that holds no credential (R8) is not defined here either: Section 8 conveys lifecycle state as part of a response about a token.¶

1.2. Relationship to Domain-Specific Authorization Schemas

Domain-specific authorization schemas [I-D.liu-oauth-authorization-schemas] define the behavioral boundaries of a governing authorization and their runtime enforcement: a schema instance requested in authorization_details, once approved, is bound to the issued access token, verified by Resource Servers against each behavior, and given a lifecycle (active/ended, with ending reasons completed, withdrawn, terminated, and expired).¶

The two compose in a single access token. The schema instance states what is permitted, the bounds. The authorization evidence states why it is permitted, the approval decision and the disclosure it was based on. The authority_hash member of Table 1 binds the second to the first, so that a party holding the evidence record apart from the token can tell whether the schema instance it later obtains is the one the approval was witnessed against (Section 9.3).¶

4.5. Signature

The as_signature member is a signature by the Authorization Server over the approval record. It proves that the AS witnessed the decision, it makes the record tamper-evident, and it is what a relying party examines in a dispute. Its guarantee is bounded by trust in the AS, as discussed in Section 9.4.¶

The signature covers the evidence object in full, with two exceptions. The as_signature member is excluded because a signature cannot cover itself. The content_hash member is excluded because it is the digest of the signing input and is therefore derived from it. Every other member is covered, including id, approval together with the disclosure object inside it, authority_hash, evidence_ref, proposal_ref, and the OPTIONAL withdrawal_handle member defined in Section 6.2.¶

The signing input is a JSON object containing exactly the covered members, canonicalized with JCS [RFC8785]. Because withdrawal_handle is covered, an AS that includes the member MUST have associated the handle with the authorization record before it signs, and cannot add or change the member afterwards without invalidating the signature. The fields that carry the lifecycle state of the authorization are maintained on the AS and are not members of the evidence object, so signing the object does not fix any value that later changes.¶

Members of the evidence object other than those defined by this specification MAY be present, for example an attestation of the rendering step of the kind discussed in Section 9.5. Any such member is part of the signed field set and is therefore covered by the as_signature without further provision. A verifier that does not understand an extension member MUST still include it when reconstructing the signing input, and MUST NOT reject the record solely because a member is present and unrecognized.¶

The signature format MUST be a detached JWS [RFC7515] in Compact Serialization, using the AS's signing key. In detached Compact Serialization (see Appendix F of [RFC7515]), the payload portion is omitted, resulting in the form header..signature.¶

The JWS header MUST contain a typ header parameter with the value evidence+jws, and a verifier MUST reject a JWS whose typ is absent or carries any other value. The parameter separates this JWS from the others the AS produces under the same key, in particular from the signature over an access token. Without it, an as_signature could be presented where a token signature is expected, and a signature made for another purpose could be accepted as one, because the two would be indistinguishable byte strings over the same key. The value is not registered in the IANA "Media Types" registry; [RFC7515] permits an application to define its own.¶

Implementations MUST support ES256 [RFC7518] for both signing and verification, so that a conformant AS and a conformant verifier interoperate without prior arrangement. Other asymmetric algorithms registered in the IANA "JSON Web Signature and Encryption Algorithms" registry MAY be used where both parties support them. The steps that produce the JCS input, the content_hash, and the as_signature are specified as a single algorithm in Section 5.3.¶

To verify an as_signature, the verifier reconstructs the signing input from the received evidence object by removing the as_signature and content_hash members and canonicalizing the remainder with JCS, then verifies the detached JWS using the AS's public key. The content_hash can be checked in the same pass: the verifier recomputes the digest over the reconstructed JCS output and compares it with the received content_hash. That comparison requires no key material and detects corruption or truncation of the record. It does not detect adversarial modification, because an attacker who alters a record can recompute its digest, and it is therefore not a substitute for signature verification. Section 9.2 states what the digest does provide.¶

A verifier MUST NOT select the verification algorithm from the alg header parameter of the JWS it is verifying. It MUST have an explicit allowlist of acceptable asymmetric algorithms, MUST reject a JWS whose alg value is not in that allowlist, and MUST reject a JWS whose alg value is none. It MUST reject a JWS whose alg value does not match the type of the key used to verify it. When the JWS header contains a crit member, the verifier MUST reject the JWS if any header parameter named in crit is absent from the header, or is present but not one the verifier understands and has processed. These header parameters are defined in [RFC7515].¶

In the examples in this document the as_signature value is abbreviated for readability. Actual values use the detached JWS Compact Serialization form described above. Appendix B gives a complete worked example, including the canonical signing input, the digest, and a signature that verifies.¶

The key used to sign the evidence record MAY be the same key the AS uses to sign access tokens, provided the typ requirement above is met, or it MAY be a separate dedicated key. Whichever key is used, implementations MUST ensure that it is associated with the AS through a verifiable mechanism, for example by publishing it in the AS's JWKS endpoint as defined in [RFC7517]. A dedicated evidence signing key allows key rotation on a schedule independent of token validation.¶

4.6. Embedded and Reference Projections

The evidence object defined in the preceding sections can be conveyed to Resource Servers in two forms:¶

Embedded projection:

The full evidence object is carried in the authorization_details of the access token, as shown in the preceding examples. This is the default form.¶

Reference projection:

The token carries a pointer to the record rather than the record itself. The evidence object contains exactly two members, id and content_hash, and no others. It contains no as_signature, because there is nothing in the token for such a signature to cover. The Resource Server retrieves the complete evidence object, including its as_signature, via token introspection (Section 8).¶

A non-normative example of the authorization details object as it appears in a token using the reference projection:¶

{
  "authorization_details": [
    {
      "type": "authorization_evidence",
      "evidence": {
        "id": "urn:uuid:e73517f6-d8eb-4017-9602-2e251c7ffc7c",
        "content_hash": "LTfvHZqdAF4BzvfUZkUccL2mudBr3Re81CLkIEFIZjg"
      }
    }
  ]
}

This two-member pointer is the same shape the OPTIONAL evidence_ref member of Table 1 uses to name a related record. A deployment that needs a pointer to an evidence record uses this shape whichever way it is being carried.¶

The requirement levels in Table 1 and Table 2 describe the complete evidence record, as the AS produces it and as the embedded projection carries it. The reference projection is a pointer to that record, not a fragment of it that is expected to satisfy the same requirements, and the introspection response returns the complete record.¶

The AS selects the projection per deployment. The reference projection reduces token size and limits the exposure of the disclosure object in signed tokens that are visible to multiple Resource Servers (see the privacy discussion in Section 10).¶

When a Resource Server receives a reference projection, it MUST retrieve the complete evidence object via token introspection, MUST verify its as_signature as described in Section 7, and MUST verify that the id and content_hash of the retrieved record match the reference carried in the token. On mismatch, or when the introspection endpoint is unreachable, the Resource Server MUST treat the evidence as unavailable and apply its policy for a missing evidence record rather than relying on the unsigned reference alone.¶

5.1. Approval-to-Evidence Pattern

The evidence object records the outcome of an approval interaction. Before the AS can generate a signed evidence record, it first presents a consent interface to the approver and captures the decision. Regardless of the grant type, that interaction follows a common pattern:¶

1. The AS receives an authorization request from a client, which may be acting on behalf of an AI agent.¶

2. The AS determines that an approval decision is required and presents a consent interface to the approver. The consent interface renders the structured disclosure of the requested authorization (the disclosure object, Section 4.4.2).¶

3. The approver reviews the disclosure and performs a decision action, e.g., clicking an "Allow" or "Deny" button, providing biometric input, or entering a PIN.¶

4. The AS captures the interaction details (the disclosure, the decision, the action the approver took, and when) and constructs the evidence object as defined in Section 4.¶

5. For an approved or narrowed decision, the AS signs the evidence record and includes it in the issued access token. For a declined decision, no credential is issued and no authorization record is created, because the decision establishes no governing authorization. The AS MAY retain the evidence record for audit and dispute resolution, but a record retained this way is bound to no credential and is not reachable through token introspection (Section 8).¶

Client/Agent          Authorization Server           Approver
    |                         |                          |
    |-- authorization req --->|                          |
    |                         |                          |
    |                         |--- consent UI ---------->|
    |                         |    (disclosure)          |
    |                         |                          |
    |                         |<-- decision action ------|
    |                         |    (button_click, etc.)  |
    |                         |                          |
    |                         |  [capture evidence]      |
    |                         |  [sign with as_signature]|
    |                         |                          |
    |<-- access token --------|                          |
    |    (with evidence)      |                          |
    |                         |                          |

5.2. Applicability to Other Flows

The pattern above applies to any OAuth flow in which an approver is presented with a disclosure. In the Authorization Code Grant the AS presents a consent screen during the /authorize redirect. In CIBA the AS delivers a consent request to the approver's authentication device, e.g., a push notification, and the evidence captures the approver's out-of-band decision action. Flows that capture approval decisions asynchronously follow the same pattern, for example the JWT authorization grant with interaction response ([I-D.parecki-oauth-jwt-grant-interaction-response]) and the deferred token response ([I-D.ietf-oauth-deferred-token-response]).¶

Flows that involve no approver interaction, e.g., the Client Credentials Grant without user context, cannot produce evidence records. There is no approval decision to record, and this specification defines no substitute.¶

5.3. Evidence Generation and Signing

When issuing an access token carrying evidence, the AS executes the following algorithm. These steps answer the question that Section 7.1 of [RFC9396] leaves to the definition of the authorization details type: what the AS puts in the enriched object, and how that content is protected.¶

1. Record the structured disclosure presented to the approver, including its summary, the identifier of the governing authorization the approval establishes, and any notices or material risks, as the disclosure object.¶

2. Capture the decision, the confirming action, and the timestamp of the decision in the approval object.¶

3. Generate the id of the evidence record, a URI unique across the records the AS issues.¶

4. Where the token carries the approved bounds in an authorization details object identified by disclosure.authority_ref, canonicalize that object with JCS [RFC8785], compute its SHA-256 digest, and store the base64url encoding in authority_hash. The digest is taken over the object as the AS will place it in the token response, so that a verifier recomputing it from the object it receives obtains the same bytes.¶

5. Where the deployment conveys a withdrawal handle in the token response, associate the handle with the authorization record and populate withdrawal_handle, and populate evidence_ref and proposal_ref where they apply. Every member of the evidence object other than content_hash and as_signature MUST be final before signing, because every one of them is covered by the signature.¶

6. Create a JSON object containing every member of the evidence object except content_hash and as_signature.¶

7. Apply JCS [RFC8785] to the object from the previous step, producing a deterministic byte string.¶

8. Compute the SHA-256 digest of the JCS output, encode it in base64url, and store the result in the content_hash member of the evidence object.¶

9. Compute a detached JWS in Compact Serialization over the JCS output from step 7, with a JWS header carrying the typ value required by Section 4.5, using the AS's private signing key, and store the resulting header..signature value in the as_signature member of the evidence object.¶

10. Include the authorization_evidence authorization details object in the token response and bind it to the issued access token, in the embedded or the reference projection (Section 4.6).¶

Token refresh is a renewal operation, not a new approval. When the AS issues a new access token from a refresh token while the governing authorization is still active, it re-projects the same evidence record, with unchanged id, content_hash, and as_signature, into the new token. A refresh request MUST NOT mint new evidence for the authorization. The condition under which the AS may issue a token carrying evidence at all is stated in Section 6.2.¶

6.1. Authorization Records and Withdrawal Handles

The authorization record defined in Section 2 is distinct from its projection into a credential. The record lives on the AS, is created at the moment of the approval decision, and carries the lifecycle state of the governing authorization. The signed evidence object of Section 4 is what a Resource Server sees. Withdrawal operates on the record, not on the projection, and therefore remains possible after every credential carrying the evidence has expired.¶

Because the authorization record is created at approval time, withdrawal is possible during the window after the approver has approved an authorization but before the resulting credential has been issued.¶

https://as.example.com/revoke/urn:uuid:181c3a47-7ae7-4109-8290-d69cd3ca6896

The requirement is a privacy control and not an authorization control: it limits what a third party can learn about the governing authorizations an approver has established, and it does not make possession of the handle sufficient to act on one. The handle is a lookup key, not a credential: possession of the URI does not by itself authorize withdrawal.¶

The AS SHOULD present the withdrawal handle to the approver over the front channel at or shortly after the approval interaction, for example on the consent confirmation page or in an authorization management view. This is the primary delivery channel and the only one that reaches the approver directly. The OPTIONAL withdrawal_handle member defined in Section 6.2 additionally conveys the handle in the token response; that copy reaches the client rather than the approver, and MAY support client-provided authorization management interfaces or agent-initiated self-withdrawal.¶

When a withdrawal handle is delivered through a token response (in addition to, or instead of, the front channel), clients MUST treat it as sensitive data and MUST NOT expose it in URLs, logs, or user agents beyond what is necessary to present the withdrawal option to the approver.¶

When a governing authorization ends, the AS SHOULD update the authorization record with ended_at, the timestamp of the ending, and ending_reason, indicating how the authorization ended. Implementations SHOULD use values from the following set for ending_reason: withdrawn (the approver ended the authorization through the mechanism defined in this section), completed (the authorized work finished), terminated (ended by a party other than the approver, such as the client or an administrator of the AS), or expired (lapsed without any party acting). Where accountability requires distinguishing who initiated a withdrawal, implementations MAY additionally record the initiator (for example, principal, client, or administrator). These fields are maintained on the AS and are not included in access tokens. They support audit and dispute resolution, including the question of whether a contested operation occurred before or after the authorization ended.¶

6.2. The withdrawal_handle Member and Withdrawal Semantics

The OPTIONAL withdrawal_handle member of the evidence object carries the withdrawal handle for the governing authorization established by the approval recorded in the evidence (Section 6.1, Paragraph 3). Its value is the handle URI itself:¶

{
  "withdrawal_handle": "https://as.example.com/revoke/urn:uuid:181c3a47-7ae7-4109-8290-d69cd3ca6896"
}

The member carries the handle and nothing else. The current state of the governing authorization is deliberately not part of the evidence record. The record is an immutable account of the approval, and a member whose value changes while the record is in force could not be signed. A Resource Server that needs the current state obtains it through token introspection (Section 8), and a party that needs to act on an ending follows the handle.¶

The withdrawal_handle member is inside the signed field set of Section 4.5. An AS that includes the member MUST therefore fix the handle before it signs the evidence record and MUST NOT alter the member afterwards. A deployment that needs to replace the handle of an issued record MUST issue new evidence rather than modify the existing record.¶

The AS MUST NOT issue an access token carrying evidence for a governing authorization that has ended at issuance time. Where issuance and withdrawal can race, the AS MUST evaluate the authorization record state atomically with credential issuance.¶

The effect of an ending depends on the lifecycle phase of the governing authorization:¶

Before the approval decision:

There is no authorization to withdraw. If the approver refuses the request through the consent interface presented during the authorization flow, the AS records a declined decision (Table 2) and no authorization is established.¶

After the approval decision, before credential issuance:

The AS invalidates the pending authorization by applying the cancellation semantics defined by the host protocol. For example, a deferred issuance flow may invalidate its deferral code so that subsequent polling requests return access_denied ([I-D.ietf-oauth-deferred-token-response]).¶

After credential issuance:

The AS revokes the issued tokens as appropriate per [RFC7009], SHOULD reflect the ending in a status mechanism such as a token status list [I-D.ietf-oauth-status-list], and MAY propagate the ending event to downstream subscribers using a shared signals mechanism such as CAEP [I-D.ietf-secevent-caep].¶

This specification defines the withdrawal trigger and the authorization record state. It does not redefine the cancellation or token revocation semantics of any host protocol; those semantics are applied as defined by the respective protocol. The other three endings, completed, terminated, and expired, are defined by the authorization framework in use and carry the same protocol consequences for credentials issued under the ended authorization.¶

9.2. Content Hash

The content_hash is a digest of data its holder already has, and it is worth being precise about what it establishes. A party holding a record can recompute the digest, so the member detects corruption and truncation in storage or in transit. It does not detect an adversary: anyone able to modify a record can recompute its digest, and a verifier comparing the two learns only that they are consistent with each other. Integrity against modification comes from the as_signature and never from the digest.¶

The digest becomes adversarially meaningful only when it reaches a verifier by a different path from the record it describes. That is the case in the reference projection of Section 4.6, where the id and content_hash travel inside a signed token while the full record arrives from an introspection endpoint. Comparing the two establishes that the record the AS returned is the record the token pointed at. The same reasoning is why evidence_ref in Table 1 carries a digest of the record it names.¶

Because identical records yield identical digests, the content_hash also allows deduplication in audit stores and lets two parties confirm that they hold the same record without disclosing it. Since the digest is deterministic, a record whose content can be enumerated yields a digest that can be computed in advance and used as a correlation handle. Records in this specification carry a unique id and a decision timestamp, which makes enumeration impractical, but implementations publishing digests to shared or public stores SHOULD assess whether correlation of digests across stores raises privacy concerns for their deployment.¶

9.3. Binding the Decision to the Approved Bounds

The as_signature covers the evidence object, but the enforceable bounds are not members of that object. A separate authorization details object in the same token carries them, and the evidence names it through approval.disclosure.authority_ref. The signature therefore commits the AS to the decision and to what the approver was shown, but not to the bounds. A party holding the record apart from the token cannot tell whether a bounds object it obtains later is the one the AS approved.¶

The authority_hash member closes that gap. It commits the signed record to a digest of the bounds object, in the same way content_hash commits a reference to the record it names. It detects a bounds object presented alongside a genuine record that is not the one the record approves, whether the substitution happens in an audit store, in a retrieval from the AS, or in a Resource Server's own assembly of the two. This matters most in the reference projection (Section 4.6) and after the credential expires, where the record and the bounds travel separately.¶

Two limits are worth stating. Where the access token is itself a signed JWT, its signature already covers the bounds object, so authority_hash adds nothing against an outside attacker; its value is in the uses of the record that leave the token behind. And it does not remove the trust in the AS described in Section 9.4: the AS holds the signing key and can sign a digest of bounds it never intended to enforce. Against the AS the digest buys consistency, not honesty. An AS that commits to one set of bounds at approval and enforces another is detectable by any party holding both.¶

Where no authorization details object carries the bounds, for example in a deployment that expresses authority only through scope, the member is absent and no such binding exists. This is a property of the deployment, not a defect in the record. A relying party that requires the binding MUST treat the absence of authority_hash as a reason not to rely on the record for bounds it cannot otherwise establish.¶

9.4. Evidence Tampering and Trust in the AS

The trust boundary of the mechanism is narrow. The as_signature provides cryptographic proof that the AS recorded an approval decision. It does not independently prove that the approver actually approved. The AS controls both the approval interaction and the signing key, so a compromised or malicious AS could fabricate evidence records. Trust in the evidence record therefore depends on trust in the AS and its operational security. Deployments requiring stronger non-repudiation guarantees SHOULD supplement this mechanism with approver-side signatures or independent approval auditing.¶

9.5. Attestation of the Rendering Step

The as_signature is an assertion by the AS about what the AS presented and recorded. It is not an assertion by the approver's device about what that device displayed. Where the AS serves the consent interface directly to the approver's user agent, the two coincide closely enough that the distinction rarely matters. Where a party other than the AS renders the disclosure, for example an agent or client that presents the structured disclosure object in its own interface, they do not: the AS records what it supplied for presentation and has no visibility into what was actually shown, in what form, or for how long.¶

This specification provides no attestation of the rendering step. Attestation backed by device hardware, such as a secure element or a trusted execution environment, can establish that a genuine application on a genuine device presented a given data structure and that a genuine approver gesture followed. On a general-purpose operating system it cannot establish that what reached the display matched that data structure, because the rendering path lies outside the attested boundary. A Resource Server MUST NOT read the absence of such an attestation from an evidence record as a defect in that record, since this specification neither defines nor requires one.¶

A deployment that does use an attestation of the rendering step MUST carry it inside the evidence object, so that it is covered by the as_signature of Section 4.5, and MUST bind it to the same id. An attestation carried outside the signed record, or bound only to a device or a session, proves that some consent interaction once occurred on that device. It proves nothing about the approval this evidence record describes, and it can be replayed across approvals. The format of such an attestation, the trust anchors against which it is verified, and its privacy consequences are outside the scope of this specification.¶

9.6. Replay of Genuine Evidence

A verified evidence record does not become invalid when the authorization it describes ends. The as_signature carries no expiry and the record is deliberately immutable, so a genuine record taken from an expired or revoked token continues to verify indefinitely. That the same record reappears in successive tokens issued for one governing authorization is intended behavior and not an attack; see Section 5.3.¶

The exposure is a party presenting such a record as though the authorization were still in force. That cannot be answered cryptographically, because nothing about the record changes when the authorization ends. It is answered by the credential and by authorization state: the record is usable only through a credential the AS issued to carry it, and a Resource Server that needs to know whether the governing authorization is still active consults the mechanisms of Section 9.9 rather than the evidence record. Presenting a genuine record in a context the AS did not issue it for is addressed by Section 9.7.¶

9.7. Token-Evidence Binding

When the evidence object is embedded in a signed JWT access token ([RFC9068]), the token signature and the as_signature cover the same bytes. The value of having both is not that they protect different fields but that they answer different questions and have different reach. The token signature binds the evidence to this particular token, with its subject, audience, and expiry. The as_signature binds the evidence to the approval record the AS created, and it continues to verify after the evidence has left the token entirely. Together they mean:¶

• An evidence record cannot be moved from one token to another without detection, because the receiving token's signature would not cover it;¶
• An evidence record cannot be altered, whether it is still inside a valid token or has been taken out of it, because the as_signature is invalidated either way;¶
• An evidence record that has been extracted from its token remains verifiable on its own, which the token signature cannot provide because the token is no longer present.¶

The third point is what makes the reference projection of Section 4.6 workable. A Resource Server holding only an id and a content_hash can retrieve the record and establish that the AS produced it, with no reliance on the token that pointed at it. It is also what makes the record usable as audit evidence after the credential has expired.¶

Implementations MUST NOT copy an evidence object from one access token into another without re-validating the as_signature and confirming that approval.timestamp is consistent with the new token's issuance time.¶

With an opaque (reference) token there is no token signature over the evidence at all. The evidence object is not embedded in the token and MUST be retrieved by the Resource Server via token introspection ([RFC7662]) or a dedicated evidence retrieval endpoint, so the as_signature is the only integrity protection the record has. Implementations MUST protect the transport between the Resource Server and that endpoint with TLS.¶

9.8. Cross-Domain Evidence Verification

When the RS is in a different trust domain from the AS, the RS still has to obtain the AS's public key to verify the as_signature. Implementations SHOULD:¶

• Publish the AS's evidence signing keys at a well-known JWKS endpoint ([RFC7517]) accessible to the RS;¶
• Include a kid (Key ID) in the JWS header of the as_signature to enable key selection;¶
• Support key caching at the RS with appropriate cache invalidation to balance performance and key freshness.¶

When the AS and RS belong to different administrative domains, trust establishment for the evidence signing key MAY be facilitated through a trust framework, federation agreement, or explicit key distribution mechanism.¶

A second cross-domain case is not resolved here. Where the same work reaches more than one Authorization Server, as when an agent obtains a token for that work at a second Authorization Server through an identity assertion grant ([I-D.ietf-oauth-identity-assertion-authz-grant]), each Authorization Server decides under its own policy and signs its own evidence record. This specification does not say whether the second verifies and relies on the record the first signed, whether it produces a record of its own that refers to the first, or how an auditor is meant to join the two. The authority_ref of the second record MAY carry the identifier the first assigned, which is what would join them, but nothing here requires that or defines what a verifier concludes when it is present. How the records of two Authorization Servers for one piece of work relate is left for further work.¶

9.9. Withdrawal Enforcement Boundary

Withdrawal under this specification is enforced by the AS and by downstream token revocation and status mechanisms; it is not purely cryptographic. A token issued before the governing authorization ended remains cryptographically valid until it expires, is revoked via the token revocation mechanisms of the host protocol (e.g., [RFC7009]), or is rejected based on status information such as token status lists ([I-D.ietf-oauth-status-list]) or shared signals ([I-D.ietf-secevent-caep]). Deployments with short-lived tokens reduce the window during which an ended authorization is not yet enforced; deployments requiring timely propagation of endings SHOULD combine token revocation with status lists or event-based propagation.¶

This specification does not require resource servers to consult authorization state. Whether an RS enforces the ending of a governing authorization directly, or relies on the AS to revoke the associated tokens, is a deployment decision.¶