OAuth RAR requested terms and returned grant
Can an OAuth RAR client treat its requested payment amount and recipient as the granted authority?
RFC 9396 requires the authorization details granted to the access token to be returned. They can differ from the request: consent can reduce permissions, a type can permit enrichment, and the server can omit values. Interpret the returned grant using that type before relying on the requested transaction terms. This does not establish payment execution.
Documentation reviewed 2026-10-25. Primary source.
Boundaries
- Compare the actual token grant with the intended transaction using the applicable RAR type. The server may omit values; the fictitious payment example is not a universal payment schema or settlement proof.
- Buyer implementation, live runtime enforcement, settled payment, physical outcome, certification or permission to act are not established.
- No expanded capabilities or licences for existing INDEX executables.
Complete record JSON · Exact free preview JSON · Source review
OAuth RAR permission combinations
Does one OAuth RAR object pair each action with just one listed resource location?
RFC 9396 applies the common actions, locations and datatypes of one authorization-details object as a cross-product. Arrays do not implicitly pair their positions. Separate authorization-details objects can express distinct combinations. A client must inspect the type-specific semantics and the complete combinations before treating a request as narrowly scoped.
Documentation reviewed 2026-10-25. Primary source.
Boundaries
- Limit the rule to the RFC common fields as used by the applicable type; do not invent semantics for arbitrary extension fields. A request is not an issued grant.
- Buyer implementation, live runtime enforcement, settled payment, physical outcome, certification or permission to act are not established.
- No expanded capabilities or licences for existing INDEX executables.
Complete record JSON · Exact free preview JSON · Source review
OAuth RAR semantic downscoping
Does a JSON subset comparison establish that revised OAuth RAR details reduce authority?
RFC 9396 permits authorization_details on a token request to reduce the permissions of the issued token. The server must use type-specific semantics to decide whether the requested permissions are a subset; structural JSON comparison alone is insufficient. Issuing the reduced token does not change the underlying authorization grant.
Documentation reviewed 2026-10-25. Primary source.
Boundaries
- Do not prescribe a universal comparator, assume all permissions are additive, or infer that narrowing one token revokes the original grant.
- Buyer implementation, live runtime enforcement, settled payment, physical outcome, certification or permission to act are not established.
- No expanded capabilities or licences for existing INDEX executables.
Complete record JSON · Exact free preview JSON · Source review
OAuth scope and RAR combined consent
Can an agent ignore OAuth scope when authorization_details is present in the same request?
RFC 9396 allows scope and authorization_details in the same request. Their permissions are combined according to the applicable API semantics, and the authorization server must present the combined authorization requirements to the user. Neither field should be assumed to cancel or supersede the other without the relevant definition.
Documentation reviewed 2026-10-25. Primary source.
Boundaries
- The combination algorithm is API-specific, not a universal union or intersection. Keep AS obligations separate from client policy and actual consent evidence.
- Buyer implementation, live runtime enforcement, settled payment, physical outcome, certification or permission to act are not established.
- No expanded capabilities or licences for existing INDEX executables.
Complete record JSON · Exact free preview JSON · Source review
OAuth resource parameter does not filter RAR
Does an OAuth resource parameter automatically narrow authorization_details to that server?
RFC 9396 states that the resource parameter does not change how an authorization server processes authorization_details. A resource value is therefore not a filter that silently removes other detailed permissions. The RAR type, its locations and the actual granted details need separate review before relying on a restricted target.
Documentation reviewed 2026-10-25. Primary source.
Boundaries
- Do not claim that resource is ignored for scope or that authorization_details can bypass audience validation.
- Buyer implementation, live runtime enforcement, settled payment, physical outcome, certification or permission to act are not established.
- No expanded capabilities or licences for existing INDEX executables.
Complete record JSON · Exact free preview JSON · Source review
OAuth RAR invalid authorization details
May an OAuth RAR server silently ignore unknown fields in a known authorization-details type?
RFC 9396 requires rejection with invalid_authorization_details for unknown types, invalid fields or values, and missing required fields. A type definition can expressly permit extension fields, so not every unfamiliar field is automatically invalid. Validation must use the supported type definition rather than silently accepting malformed authority terms.
Documentation reviewed 2026-10-25. Primary source.
Boundaries
- The applicable type definition determines which fields are known. Do not reject legitimate type-defined extensions merely because they are not common RFC fields, or claim deployed enforcement was tested.
- Buyer implementation, live runtime enforcement, settled payment, physical outcome, certification or permission to act are not established.
- No expanded capabilities or licences for existing INDEX executables.
Complete record JSON · Exact free preview JSON · Source review
OAuth RAR front-channel integrity
Does sending payment authorization_details through a browser protect them from replacement?
RFC 9396 warns that authorization details sent through the front channel can be tampered with or swapped. It recommends integrity protection such as signed request objects or pushed authorization requests. Protecting those request terms does not establish that the server granted them, that the client may execute them, or that a payment settled.
Documentation reviewed 2026-10-25. Primary source.
Boundaries
- Preserve the source conditional: when parameter integrity is a concern it MUST be protected. Signing or pushing the request does not prove user approval, transaction execution, payment settlement, or a secure deployment.
- Buyer implementation, live runtime enforcement, settled payment, physical outcome, certification or permission to act are not established.
- No expanded capabilities or licences for existing INDEX executables.
Complete record JSON · Exact free preview JSON · Source review
OAuth RAR string comparison
May an OAuth RAR verifier normalize differently spelled identifiers before comparing authority?
RFC 9396 requires strings in authorization_details to be compared as defined by RFC 8259, without additional transformation or normalization. This is a rule for string values, not a requirement that serialized JSON documents be byte-identical. Applying an extra case or Unicode transformation can change the permission comparison.
Documentation reviewed 2026-10-25. Primary source.
Boundaries
- Clarify comparison after valid JSON decoding; this is not byte-for-byte equality of serialized JSON, object member order, or whitespace. Do not equate visually similar identifiers.
- Buyer implementation, live runtime enforcement, settled payment, physical outcome, certification or permission to act are not established.
- No expanded capabilities or licences for existing INDEX executables.
Complete record JSON · Exact free preview JSON · Source review
OAuth resource identifiers and token audience
Must an access token audience equal the exact OAuth resource parameter string?
RFC 8707 permits resource to identify a protected resource with an absolute URI, including an abstract identifier rather than a network locator. The authorization server can map that value to a more general URI or abstract audience. Endpoint location, resource identifier and issued audience therefore need an established mapping; none authorizes an arbitrary destination.
Documentation reviewed 2026-10-25. Primary source.
Boundaries
- Never authorize arbitrary audience mismatch. Establish the AS mapping and the relying resource validation rule; preserve protocol-specific stricter rules such as MCP.
- Buyer implementation, live runtime enforcement, settled payment, physical outcome, certification or permission to act are not established.
- No expanded capabilities or licences for existing INDEX executables.
Complete record JSON · Exact free preview JSON · Source review
OAuth omitted resource policy
Does omitting OAuth resource mean a token is valid at every resource server?
RFC 8707 allows an authorization server receiving no resource parameter to process the request without a specific resource, use a default resource, or reject it for lacking a resource. Omission does not establish unrestricted access or one universal default. Inspect the applicable policy and the resulting token restrictions.
Documentation reviewed 2026-10-25. Primary source.
Boundaries
- Include all three documented possibilities; the current buyer_decision mentions default or rejection but omits processing with no specific resource. No option alone establishes arbitrary-server acceptance.
- Buyer implementation, live runtime enforcement, settled payment, physical outcome, certification or permission to act are not established.
- No expanded capabilities or licences for existing INDEX executables.
Complete record JSON · Exact free preview JSON · Source review
OAuth refresh grant and requested resource subset
Can a multi-resource OAuth grant produce a token limited to one selected resource?
RFC 8707 allows a token request to select a subset of the resources authorized by the grant. The resulting access token can be restricted to that subset while a refresh token remains associated with the full authorized set. Resource selection must remain within the grant and authorization-server policy; a narrow access token does not prove the underlying grant was reduced.
Documentation reviewed 2026-10-25. Primary source.
Boundaries
- Preserve grant-type and AS-policy qualifications; a client request alone does not force universal issuance or narrow the original refresh grant.
- Buyer implementation, live runtime enforcement, settled payment, physical outcome, certification or permission to act are not established.
- No expanded capabilities or licences for existing INDEX executables.
Complete record JSON · Exact free preview JSON · Source review
OAuth multiple-resource token issuance trust
Is a multi-audience OAuth bearer token isolated from replay between its accepted recipients?
RFC 8707 explains that a bearer token usable at multiple resources can be replayed by one recipient at another. It recommends issuing access tokens for one resource at a time where possible, with authorization-server discretion over multi-resource requests. This is an issuance-policy decision; it does not introduce a new rule that every token is safe merely because an audience is present.
Documentation reviewed 2026-10-25. Primary source.
Boundaries
- Retain only with the RFC8707 multi-resource issuance decision and its single-resource recommendation explicit. Do not claim this is a novel replay principle or extend it to sender-constrained tokens.
- Buyer implementation, live runtime enforcement, settled payment, physical outcome, certification or permission to act are not established.
- No expanded capabilities or licences for existing INDEX executables.
Complete record JSON · Exact free preview JSON · Source review
Cloud Billing invoice month and usage period
Can Google Cloud invoice totals be reconciled by filtering only the usage calendar month?
Google Cloud detailed billing export distinguishes invoice.month from the timestamps of usage. Late-reported usage and adjustments can appear on a later invoice. Reconcile invoice totals by the invoice field and retain the usage interval separately; filtering only by usage month can omit or misplace invoiced charges.
Documentation reviewed 2026-10-25. Primary source.
Boundaries
- Invoice.month filtering is a comparison basis, not proof that the delivered dataset is complete or the invoice was paid. Retain export freshness, account, currency and correction scope.
- Buyer implementation, live runtime enforcement, settled payment, physical outcome, certification or permission to act are not established.
- No expanded capabilities or licences for existing INDEX executables.
Complete record JSON · Exact free preview JSON · Source review
Cloud Billing adjustment issue grouping
Does each Google Cloud adjustment_info.id identify exactly one billing line?
The detailed billing export uses adjustment_info.id to associate lines with the same adjustment issue. It is not a unique row identifier. Adjustment modes include partial correction and complete negation followed by remonetization. Keep the relevant rows, type and mode together before calculating the net correction; deduplicating solely on the issue ID can discard necessary entries.
Documentation reviewed 2026-10-25. Primary source.
Boundaries
- Do not invent a unique billing-line key or import FOCUS Ledger semantics into this native GCP format. Missing adjustment_info is not evidence of invalid usage.
- Buyer implementation, live runtime enforcement, settled payment, physical outcome, certification or permission to act are not established.
- No expanded capabilities or licences for existing INDEX executables.
Complete record JSON · Exact free preview JSON · Source review
Cloud Billing costs, credits and resource-less rows
Does summing Google Cloud exported cost alone include all credits in the invoice net amount?
Google Cloud detailed billing examples reconcile cost with signed credit amounts and include charges whose resource identity is unavailable. A resource-only filter can drop valid costs, and credits must be aggregated at the intended row grain without multiplying costs through repeated-field expansion. The resulting arithmetic is not proof that the export is complete or that an invoice has been paid.
Documentation reviewed 2026-10-25. Primary source.
Boundaries
- Sum signed credit amounts as documented; do not claim cost-plus-credits alone guarantees the final payable balance, completeness, settlement, or correct treatment of every contract-specific promotional credit.
- Buyer implementation, live runtime enforcement, settled payment, physical outcome, certification or permission to act are not established.
- No expanded capabilities or licences for existing INDEX executables.
Complete record JSON · Exact free preview JSON · Source review
Cloud Billing export writer access
Does an existing Google Cloud billing export table prove it is still receiving new records?
Google documents that removing the export service account's permissions prevents billing-export tables from updating. The setup guidance distinguishes the standard and detailed export writer from the CUD metadata case. A prior successful table is not evidence of continuing updates. Restore appropriate permissions and inspect actual freshness; this record makes no automatic backfill guarantee.
Documentation reviewed 2026-10-25. Primary source.
Boundaries
- Limit the account rule to the documented export types; CUD metadata export is expressly excepted. Table existence alone is weak evidence, but no stale table by itself proves this particular cause or promises backfill after repair.
- Buyer implementation, live runtime enforcement, settled payment, physical outcome, certification or permission to act are not established.
- No expanded capabilities or licences for existing INDEX executables.
Complete record JSON · Exact free preview JSON · Source review
Cloud Billing export schema maintenance
Is the BigQuery Cloud Billing export schema guaranteed not to change after integration?
Google warns that billing-export schemas can change and that queries referencing them directly can fail. It recommends normalization through views, which may themselves require maintenance as fields change. A once-valid query or view does not establish that current exports are still consumed completely or correctly.
Documentation reviewed 2026-10-25. Primary source.
Boundaries
- A view is not permanently immune to changes; its query must be maintained. Existing FOCUS native-column coverage does not promise schema stability or satisfy this provider-maintenance question.
- Buyer implementation, live runtime enforcement, settled payment, physical outcome, certification or permission to act are not established.
- No expanded capabilities or licences for existing INDEX executables.
Complete record JSON · Exact free preview JSON · Source review
Google-provided FOCUS export table expiry
Does the Google-provided FOCUS export retain every historical billing row indefinitely?
Google's setup guidance assigns a two-year time-to-live to Google-provided FOCUS export tables. This constraint is specific to that export arrangement and is not a statement that all Cloud Billing tables expire after two years. Preserve the relevant data under the buyer's approved retention process if a longer reconstruction window is required.
Documentation reviewed 2026-10-25. Primary source.
Boundaries
- Apply only to the Google-provided FOCUS table described in the capture, not all standard/detailed billing exports or buyer-owned copies. Retention is not a legal compliance guarantee.
- Buyer implementation, live runtime enforcement, settled payment, physical outcome, certification or permission to act are not established.
- No expanded capabilities or licences for existing INDEX executables.
Complete record JSON · Exact free preview JSON · Source review
Cloud Storage soft-deleted inventory visibility
Does an ordinary Cloud Storage object listing include retained soft-deleted copies?
Google Cloud Storage excludes soft-deleted objects and buckets from ordinary listings unless soft-deleted resources are specifically requested. To list soft-deleted objects inside a deleted bucket, the bucket must first be restored. An empty default listing is therefore not evidence that no recoverable objects remain.
Documentation reviewed 2026-10-25. Primary source.
Boundaries
- Keep the new claim at list-scope completeness; do not republish the generic retained-data fact as new. Listing contents of a soft-deleted bucket requires restoring the bucket first. Restoration is not authorized by an evidence answer.
- Buyer implementation, live runtime enforcement, settled payment, physical outcome, certification or permission to act are not established.
- No expanded capabilities or licences for existing INDEX executables.
Complete record JSON · Exact free preview JSON · Source review
Cloud Storage restore copy lineage
Does restoring a Cloud Storage soft-deleted object consume its retained original version?
Restoring a soft-deleted Cloud Storage object creates a new live copy while retaining the original soft-deleted object until its retention period ends. If restoration replaces an existing live object, that replaced object can itself become soft deleted. A successful restore therefore does not establish that only one copy or generation remains.
Documentation reviewed 2026-10-25. Primary source.
Boundaries
- Scope to documented soft-delete object restore behavior. Do not claim restoration consumes residual copies, proves erasure, preserves all permissions, or completes buyer recovery.
- Buyer implementation, live runtime enforcement, settled payment, physical outcome, certification or permission to act are not established.
- No expanded capabilities or licences for existing INDEX executables.
Complete record JSON · Exact free preview JSON · Source review
Cloud Storage hierarchical restore identity
Are object name and generation always sufficient to restore a soft-deleted hierarchical Cloud Storage object?
With hierarchical namespace, folder operations can produce soft-deleted objects sharing the same name and generation. Google documents restoreToken as the additional identifier used to select the intended object for restoration. Name and generation alone can therefore be ambiguous in this case; a restore token is an identity discriminator, not an access grant.
Documentation reviewed 2026-10-25. Primary source.
Boundaries
- Keep the rare duplicate/HNS condition and exact object identity explicit. A restoreToken is an identity discriminator, not an access grant. Do not generalize it to ordinary non-hierarchical objects.
- Buyer implementation, live runtime enforcement, settled payment, physical outcome, certification or permission to act are not established.
- No expanded capabilities or licences for existing INDEX executables.
Complete record JSON · Exact free preview JSON · Source review
MODBUS long-running programming response status
Does MODBUS exception 05 ACKNOWLEDGE establish that the requested programming command is complete?
MODBUS Application Protocol 1.1b3 defines exception 05 as acceptance of a specialized long-duration programming request, with a completion poll available. Exception 06 reports that the server is busy processing a long-duration program. Neither response proves completed physical work, and a busy response does not identify the current program or authorize a generic retry.
Documentation reviewed 2026-10-25. Primary source.
Boundaries
- The source marks both codes as specialized for programming commands. This does not prove physical equipment completion or make arbitrary retries safe; prior timeout/idempotency and broadcast candidate gaps remain open.
- Buyer implementation, live runtime enforcement, settled payment, physical outcome, certification or permission to act are not established.
- No expanded capabilities or licences for existing INDEX executables.
Complete record JSON · Exact free preview JSON · Source review
MODBUS illegal data value boundary
Does MODBUS Illegal Data Value establish whether a submitted register value is acceptable to the application?
MODBUS exception 03 reports a value in the query data field that is not allowed, such as an incorrectly structured request. The specification explicitly distinguishes this from an application judging whether a value submitted for storage is meaningful or acceptable. Protocol acceptance is not validation of a process range, calibration or engineering limit.
Documentation reviewed 2026-10-25. Primary source.
Boundaries
- Reword measured register value to value submitted for storage: that is the exact source contrast. The protocol cannot establish physical thresholds, device safety, measurement validity or a safe corrective action.
- Buyer implementation, live runtime enforcement, settled payment, physical outcome, certification or permission to act are not established.
- No expanded capabilities or licences for existing INDEX executables.
Complete record JSON · Exact free preview JSON · Source review
MODBUS device-identification response continuation
Does one MODBUS Read Device Identification response necessarily contain the complete identity object set?
MODBUS Read Device Identification uses More Follows and Next Object Id to continue stream access across multiple transactions when the response does not fit one message. Access modes 01 through 03 have different scope from individual-object mode 04. One successful response is not automatically a complete identity inventory, nor authenticated proof of a physical device.
Documentation reviewed 2026-10-25. Primary source.
Boundaries
- Scope completeness to the requested access mode and supported conformity level. Codes01-03 stream; code04 returns an individual object and More Follows is00. Do not claim authenticated physical device identity or all optional identity attributes.
- Buyer implementation, live runtime enforcement, settled payment, physical outcome, certification or permission to act are not established.
- No expanded capabilities or licences for existing INDEX executables.
Complete record JSON · Exact free preview JSON · Source review
MODBUS combined register operation order
In MODBUS function 23, is the returned register data captured before the write operation?
MODBUS function 23 decimal, 0x17, combines a write and a read of holding registers, with the write performed before the read. Returned data must be interpreted in that order, especially when the ranges overlap. This ordering does not establish physical actuator completion, safe repetition after a lost response, or a broader database transaction guarantee.
Documentation reviewed 2026-10-25. Primary source.
Boundaries
- Ordering alone is not an atomicity, concurrency isolation, physical actuator completion, or non-idempotent retry guarantee. It does not close ICE02-F036.
- Buyer implementation, live runtime enforcement, settled payment, physical outcome, certification or permission to act are not established.
- No expanded capabilities or licences for existing INDEX executables.
Complete record JSON · Exact free preview JSON · Source review
HTTP signature required component coverage
Does valid HTTP signature verification establish that every decision-relevant field was protected?
RFC 9421 requires applications to enforce their additional signature requirements, including required components. Unsigned portions of a message can be changed without invalidating the signature. A cryptographic pass is therefore insufficient when the application relies on an unsigned field or a component missing from its verification policy.
Documentation reviewed 2026-10-25. Primary source.
Boundaries
- Cryptographic validity alone does not protect unsigned fields or satisfy application coverage rules.
- Buyer implementation, live runtime enforcement, settled payment, physical outcome, certification or permission to act are not established.
- No expanded capabilities or licences for existing INDEX executables.
Complete record JSON · Exact free preview JSON · Source review
HTTP signature replay controls
Does a valid HTTP message signature prove that this request has not already been used?
RFC 9421 explains that a signature can remain valid when attached to another sufficiently similar message. Component coverage, a per-message nonce checked for repetition, and creation or expiry limits can help detect replay. The application must establish those controls; signature validity alone is not evidence of one execution or an idempotent business operation.
Documentation reviewed 2026-10-25. Primary source.
Boundaries
- Require the application replay policy, nonce uniqueness and time-window checks; a timestamp alone is not exactly-once execution.
- Buyer implementation, live runtime enforcement, settled payment, physical outcome, certification or permission to act are not established.
- No expanded capabilities or licences for existing INDEX executables.
Complete record JSON · Exact free preview JSON · Source review
HTTP response signature request context
Can a response signature using req be validated after the original request components have been discarded?
RFC 9421 permits a response signature to cover components from the triggering request using the req parameter. Those values are not repeated in the response, so the requester must retain the original components long enough to validate it. Proxy changes can prevent a match. A response signature alone does not reconstruct discarded request context.
Documentation reviewed 2026-10-25. Primary source.
Boundaries
- The signed response does not repeat original component values; proxy alterations and exact request context matter.
- Buyer implementation, live runtime enforcement, settled payment, physical outcome, certification or permission to act are not established.
- No expanded capabilities or licences for existing INDEX executables.
Complete record JSON · Exact free preview JSON · Source review
HTTP signature labels and covered meaning
Does an HTTP signature label establish the signer's approval role?
RFC 9421 signature labels connect entries in Signature and Signature-Input, but are chosen when attaching the signature and are not covered by the signing process. An intermediary may relabel them. A name such as approved therefore does not establish an approval role; application-specific meaning must use suitable covered parameters and the expected signer policy.
Documentation reviewed 2026-10-25. Primary source.
Boundaries
- Labels can be changed by intermediaries; application semantics need covered parameters and trusted signer policy.
- Buyer implementation, live runtime enforcement, settled payment, physical outcome, certification or permission to act are not established.
- No expanded capabilities or licences for existing INDEX executables.
Complete record JSON · Exact free preview JSON · Source review
HTTP multiple-signature acceptance policy
Can a verifier accept an HTTP message because any one attached signature is valid?
RFC 9421 requires a verifier to account for the expected signers, rather than accepting any cryptographically valid signature attached to a message. Applications must also decide how invalid additional signatures affect acceptance: rejecting a message for any invalid signature can permit denial of service by injection. Key, algorithm and acceptance policy must be assessed together.
Documentation reviewed 2026-10-25. Primary source.
Boundaries
- A valid attacker signature is insufficient; any-valid versus all-valid policy and invalid-signature denial of service require explicit handling.
- Buyer implementation, live runtime enforcement, settled payment, physical outcome, certification or permission to act are not established.
- No expanded capabilities or licences for existing INDEX executables.
Complete record JSON · Exact free preview JSON · Source review
HTTP signed digest and actual content
Does verifying a signature over Content-Digest alone establish the integrity of the received body?
RFC 9421 does not directly sign message content. A digest field can bind it indirectly, but the verifier must both verify the signature and recompute the digest against the received content. Otherwise substituted content can leave the signed digest field unchanged. Content-encoding changes can also change the digest and invalidate the existing signature.
Documentation reviewed 2026-10-25. Primary source.
Boundaries
- Signature verification covers the digest field value, not automatic recomputation of the actual content; content encoding changes matter.
- Buyer implementation, live runtime enforcement, settled payment, physical outcome, certification or permission to act are not established.
- No expanded capabilities or licences for existing INDEX executables.
Complete record JSON · Exact free preview JSON · Source review
HTTP signature context behind a proxy
Does successful signature verification behind a reverse proxy establish that the request targeted the correct service?
RFC 9421 warns that derived signature components must come from trusted context. A reverse-proxy deployment can use a configured external target URI, but a mistaken mapping may accept a request intended for another component. Signer and verifier must agree on the relevant message and authority; an arbitrary forwarded value is not trustworthy merely because it helps validation pass.
Documentation reviewed 2026-10-25. Primary source.
Boundaries
- Configured external context must match the intended recipient; an untrusted forwarded value can contaminate signature-base derivation.
- Buyer implementation, live runtime enforcement, settled payment, physical outcome, certification or permission to act are not established.
- No expanded capabilities or licences for existing INDEX executables.
Complete record JSON · Exact free preview JSON · Source review
HTTP content and representation digest scope
Does a Repr-Digest on an HTTP range or HEAD response prove that all representation bytes were delivered?
RFC 9530 defines Content-Digest over actual message content and Repr-Digest over the entire selected representation. HTTP methods and ranges can make those scopes differ, including partial responses and HEAD. A representation digest therefore does not establish that the complete representation was delivered in this message; inventory the bytes and semantics actually received.
Documentation reviewed 2026-10-25. Primary source.
Boundaries
- Content and selected representation are distinct byte scopes; digest presence does not prove full content was delivered.
- Buyer implementation, live runtime enforcement, settled payment, physical outcome, certification or permission to act are not established.
- No expanded capabilities or licences for existing INDEX executables.
Complete record JSON · Exact free preview JSON · Source review
HTTP state-changing representation digest
Does the representation digest on a state-changing request prove the final state of its target resource?
RFC 9530 ties Repr-Digest to representation data and metadata, not automatically to the target resource's final state. In a PATCH request it covers the patch document. A response can describe request status or a referenced resource; Content-Location can affect that interpretation, while Location alone does not. Establish the represented object before treating a digest as post-change evidence.
Documentation reviewed 2026-10-25. Primary source.
Boundaries
- A PATCH request digest covers the patch document, not the resulting target state; response representation metadata determines its digest scope.
- Buyer implementation, live runtime enforcement, settled payment, physical outcome, certification or permission to act are not established.
- No expanded capabilities or licences for existing INDEX executables.
Complete record JSON · Exact free preview JSON · Source review
HTTP digest preferences and actual validation
Does requesting an HTTP digest guarantee that the peer supplied and validated the preferred integrity evidence?
RFC 9530 treats Want-Content-Digest and Want-Repr-Digest as hints. A peer may use another algorithm or omit the digest without a protocol error. Applications can impose stronger requirements, and recipients may otherwise ignore supplied digests. Requested preferences do not establish delivery or validation of the integrity evidence required by a buyer.
Documentation reviewed 2026-10-25. Primary source.
Boundaries
- The peer may ignore preferences without a protocol error; application policy and actual digest validation must establish the requirement.
- Buyer implementation, live runtime enforcement, settled payment, physical outcome, certification or permission to act are not established.
- No expanded capabilities or licences for existing INDEX executables.
Complete record JSON · Exact free preview JSON · Source review
DPoP proof and client identity binding
Does a valid DPoP proof directly establish the authenticated client's identity?
RFC 9449 states that, when used with client authentication, DPoP is coincident with that authentication in the same TLS tunnel rather than directly cryptographically bound to it. The URI can partly limit copying risks, but additional authentication binding is outside this specification. A valid proof of key possession is not by itself a complete authenticated-client identity claim.
Documentation reviewed 2026-10-25. Primary source.
Boundaries
- Coincidence in one TLS tunnel is not a direct cryptographic client-authentication binding; additional mechanisms are outside this RFC.
- Buyer implementation, live runtime enforcement, settled payment, physical outcome, certification or permission to act are not established.
- No expanded capabilities or licences for existing INDEX executables.
Complete record JSON · Exact free preview JSON · Source review
DPoP request content limitations
Does DPoP verification prove that the request body, query terms and headers were unchanged?
RFC 9449 checks the proof's HTTP method and URI, excluding query and fragment components from URI comparison. Core DPoP does not protect the request body or general headers. A proof can therefore validate without authenticating business fields carried there. Identify the separate integrity protection before relying on an amount, recipient or payload as unchanged.
Documentation reviewed 2026-10-25. Primary source.
Boundaries
- Method and URI are checked, excluding query and fragment; body and general headers are not protected by core DPoP.
- Buyer implementation, live runtime enforcement, settled payment, physical outcome, certification or permission to act are not established.
- No expanded capabilities or licences for existing INDEX executables.
Complete record JSON · Exact free preview JSON · Source review
DPoP refresh-token binding by client type
Do public and confidential OAuth clients bind refresh tokens to DPoP keys in the same way?
RFC 9449 requires a refresh token issued to a public client using DPoP to be bound to that proof key, checked on later refreshes. Confidential-client refresh tokens instead use the existing client binding and authentication requirement. A reviewer must establish the client type and actual binding; the access token's DPoP status alone does not describe every refresh credential.
Documentation reviewed 2026-10-25. Primary source.
Boundaries
- Public-client refresh tokens bind to the proof key; confidential-client refresh tokens use the existing client authentication binding.
- Buyer implementation, live runtime enforcement, settled payment, physical outcome, certification or permission to act are not established.
- No expanded capabilities or licences for existing INDEX executables.
Complete record JSON · Exact free preview JSON · Source review
DPoP nonce server scope
Can a client reuse one DPoP nonce across authorization and resource servers?
RFC 9449 allows authorization servers and resource servers to supply DPoP nonces. A nonce must be used only at the issuing server and must not be confused with another server's nonce or an OpenID Connect nonce. Authorization-server challenges use a 400 response; resource-server challenges use 401 with the DPoP authentication challenge. Retry state must retain the issuing-server identity.
Documentation reviewed 2026-10-25. Primary source.
Boundaries
- Server-specific nonces cannot be interchanged; authorization-server and resource-server challenge status codes differ.
- Buyer implementation, live runtime enforcement, settled payment, physical outcome, certification or permission to act are not established.
- No expanded capabilities or licences for existing INDEX executables.
Complete record JSON · Exact free preview JSON · Source review
DPoP proof replay window
Does a valid, recent DPoP proof establish that it has been used only once?
RFC 9449 requires accepting proofs only for a limited time and describes tracking jti values in the target-URI context to reject reuse. A valid proof can otherwise be replayed at the same endpoint. Shared-state limitations can make strict single-use tracking impractical. A server nonce can be reused with fresh proofs; nonce reuse alone is not equivalent to proof reuse.
Documentation reviewed 2026-10-25. Primary source.
Boundaries
- Signature and endpoint checks do not ensure single use; jti tracking and its shared-state limits must be established.
- Buyer implementation, live runtime enforcement, settled payment, physical outcome, certification or permission to act are not established.
- No expanded capabilities or licences for existing INDEX executables.
Complete record JSON · Exact free preview JSON · Source review
DPoP authorization-code proof-key binding
What establishes that a DPoP token exchange used the proof key bound to its authorization code?
RFC 9449 defines optional dpop_jkt to bind an authorization request and its code to a proof-key thumbprint. At token exchange the authorization server must reject a proof whose key does not match that original value. The parameter can be combined with PKCE; similar injection protection requires a unique DPoP key per authorization request and is not a universal PKCE replacement.
Documentation reviewed 2026-10-25. Primary source.
Boundaries
- The proof-key thumbprint must match the original request binding; use is optional and is not a blanket replacement for PKCE.
- Buyer implementation, live runtime enforcement, settled payment, physical outcome, certification or permission to act are not established.
- No expanded capabilities or licences for existing INDEX executables.
Complete record JSON · Exact free preview JSON · Source review
DPoP token type and downgrade boundary
Does a DPoP token request guarantee sender-constrained protection at every resource server?
RFC 9449 allows an authorization server to return Bearer even when a DPoP proof was supplied; clients requiring DPoP access-token protection must discard that response. A resource supporting both schemes must reject a DPoP-bound token presented as Bearer. Legacy Bearer-only resources have different compatibility behavior, so issuance and each resource's support must be established separately.
Documentation reviewed 2026-10-25. Primary source.
Boundaries
- A server can issue Bearer; dual-support resources must reject downgrade of a DPoP-bound token, while legacy resources do not establish that protection.
- Buyer implementation, live runtime enforcement, settled payment, physical outcome, certification or permission to act are not established.
- No expanded capabilities or licences for existing INDEX executables.
Complete record JSON · Exact free preview JSON · Source review
Redis WAIT connection and threshold evidence
Does a successful Redis WAIT response establish the requested replication level for every prior application write?
Redis WAIT reports how many replicas acknowledged earlier writes on the current connection. It returns a count on timeout as well as success, so that count must be compared with the requested level. In MULTI and other nonblocking contexts it returns immediately rather than waiting. A WAIT call on another pooled connection does not establish the original writes' barrier.
Documentation reviewed 2026-10-25. Primary source.
Boundaries
- Timeout also returns a count; pooled connections and nonblocking MULTI/script contexts cannot be assumed to provide a global barrier.
- Buyer implementation, live runtime enforcement, settled payment, physical outcome, certification or permission to act are not established.
- No expanded capabilities or licences for existing INDEX executables.
Complete record JSON · Exact free preview JSON · Source review
Redis WAIT failover retention boundary
Does Redis WAIT guarantee that an acknowledged write survives failover?
Redis documents that WAIT does not make the store strongly consistent. Sentinel and Cluster attempt to promote a suitable replica, but this selection is best effort; even a write acknowledged by multiple replicas can be lost after failover. A replication acknowledgement is useful evidence, not a guarantee of survival under every failure sequence.
Documentation reviewed 2026-10-25. Primary source.
Boundaries
- Sentinel and Cluster select replicas best effort; acknowledged writes can still be lost.
- Buyer implementation, live runtime enforcement, settled payment, physical outcome, certification or permission to act are not established.
- No expanded capabilities or licences for existing INDEX executables.
Complete record JSON · Exact free preview JSON · Source review
Redis WAITAOF persistence counts
Does a WAITAOF return establish that the requested local and replica persistence levels were met?
Redis WAITAOF, available since 7.2, reports local and replica AOF fsync acknowledgements for prior writes on the same connection. Timeout can return counts below the requested levels; MULTI or script contexts do not block. AOF configuration and documented propagation limitations apply. Inspect both counts; the command does not create global strong consistency or guarantee every failover outcome.
Documentation reviewed 2026-10-25. Primary source.
Boundaries
- Redis 7.2+, AOF configuration, timeout, nonblocking context and replication/AOF propagation limitations apply; not global strong consistency.
- Buyer implementation, live runtime enforcement, settled payment, physical outcome, certification or permission to act are not established.
- No expanded capabilities or licences for existing INDEX executables.
Complete record JSON · Exact free preview JSON · Source review
Redis queued transaction and execution boundary
Does QUEUED establish that a Redis transaction executed before a connection interruption?
Redis queues commands after MULTI and executes them when EXEC is called. QUEUED is therefore scheduling evidence, not execution. Disconnecting before EXEC performs none of the queued operations. If EXEC was sent and its response was lost, that earlier guarantee does not establish non-execution or make repetition safe; inspect the actual command outcomes separately.
Documentation reviewed 2026-10-25. Primary source.
Boundaries
- Disconnect before EXEC means no queued operations executed; a lost response after sending EXEC is not proof of no execution or safe replay.
- Buyer implementation, live runtime enforcement, settled payment, physical outcome, certification or permission to act are not established.
- No expanded capabilities or licences for existing INDEX executables.
Complete record JSON · Exact free preview JSON · Source review
Redis transaction errors and no rollback
Does an error during Redis EXEC mean that every operation was rolled back?
Redis distinguishes errors while queueing from errors during EXEC. Since 2.6.5, detected queue-time errors cause EXEC to discard the transaction. Runtime errors do not stop the other queued commands, and Redis does not roll back successful operations. An error in the reply array is therefore not proof that the transaction made no changes.
Documentation reviewed 2026-10-25. Primary source.
Boundaries
- Runtime errors do not stop other commands or roll back successful commands; Redis 2.6.5 queue-error behavior is version scoped.
- Buyer implementation, live runtime enforcement, settled payment, physical outcome, certification or permission to act are not established.
- No expanded capabilities or licences for existing INDEX executables.
Complete record JSON · Exact free preview JSON · Source review
Redis WATCH expiration and eviction conflicts
Can a Redis WATCH transaction abort even when no other client wrote the watched key?
Redis WATCH makes EXEC conditional on watched keys remaining unchanged. Changes include client writes and Redis expiration or eviction; versions before 6.0.9 did not abort for expiration. A conflict returns a Null EXEC reply and aborts conditional execution. Merely seeing no competing client write does not establish that WATCH must succeed.
Documentation reviewed 2026-10-25. Primary source.
Boundaries
- Expiration behavior differs before Redis 6.0.9; a Null EXEC reply is failed conditional execution, not a committed result.
- Buyer implementation, live runtime enforcement, settled payment, physical outcome, certification or permission to act are not established.
- No expanded capabilities or licences for existing INDEX executables.
Complete record JSON · Exact free preview JSON · Source review
Redis stream acknowledgement evidence
Does Redis XACK prove completed business processing or erasure of the message payload?
Redis XACK removes entries from a consumer group's Pending Entries List and returns the number successfully acknowledged. Already absent IDs are not counted. Consumers should acknowledge after processing, but the command does not independently inspect that business outcome. Clearing the PEL entry is not itself evidence that the stream payload or every other retained copy was erased.
Documentation reviewed 2026-10-25. Primary source.
Boundaries
- XACK clears the group PEL entry and counts acknowledgements; it does not inspect external processing or certify erasure of stream content.
- Buyer implementation, live runtime enforcement, settled payment, physical outcome, certification or permission to act are not established.
- No expanded capabilities or licences for existing INDEX executables.
Complete record JSON · Exact free preview JSON · Source review
Redis XAUTOCLAIM recovery completeness
Does a completed XAUTOCLAIM scan establish that every pending Redis message was recovered and processed?
Redis XAUTOCLAIM scans pending entries and claims those meeting its idle-time condition. A returned 0-0 ends that scan, but later calls can find entries that have since become eligible. Since Redis 7.0, missing or trimmed stream entries are removed from the PEL and reported separately, not recovered. Cursor completion therefore does not prove all work was processed or all payloads were restored.
Documentation reviewed 2026-10-25. Primary source.
Boundaries
- 0-0 completes the scan, not all future idle eligibility; since 7.0 deleted entries are removed from the PEL and reported, not recovered.
- Buyer implementation, live runtime enforcement, settled payment, physical outcome, certification or permission to act are not established.
- No expanded capabilities or licences for existing INDEX executables.
Complete record JSON · Exact free preview JSON · Source review