Application evidence informs access decisions but does not establish an account's rights to every object and function. Keep those responsibilities explicit.
Evaluation approach
Continue identity, role, ownership and transaction-limit checks. Positive integrity evidence does not grant access to every requested resource.
Application example
Reject a request for another user's document even when the caller supplies valid attestation for their own account.
Limits and considerations
Accepting a client-supplied role or risk score without verification crosses the trust boundary.
Make an independent decision for each request
Verify that the authenticated session is authorized for the requested object and action. Positive RASP or attestation results do not remove that requirement. Hiding a button is not an access policy.
Review tenant boundaries in shared systems. Derive or validate account and organization identifiers using trusted information. Test older clients after permission changes and session revocation.
Checks and decisions
- Authorize every request
- Verify resource ownership
- Deny by default
Use RASP to add context to server controls rather than removing them.
Sources
The primary references above provide the technical basis. Example workflows and evaluation suggestions are this publication’s explanations, not independent test results for a particular product.