Stream: inferno
Topic: TR-02 Access Token Revocation Question
Matt Randall (Oct 04 2021 at 18:45):
Hello,
Our implementation team came across this particular test (TR-02) and found it to be surprising, at least within context of our implementation.
In particular, TR-02 wants an implementation to demonstrate that patient/consumer revocation of an access token is possible (a separate test for refresh token revocation exists in TR-03.)
The intent of the legislation text is unambiguous (patients/consumers should be given the opportunity to revoke access.) It's technically clear that this should be applied to the token refresh process (the register explicitly states this). The application to access tokens was, as mentioned before, surprising, given that access tokens are _typically_ short-lived (though, I suppose there is nothing in the SMART specification that constrains them to be as such...)
So, a few initial questions:
- Is the ability for a patient/consumer to revoke access expected to be provided even for "one-time" use cases (in other words, situations where a refresh token is not granted to the application because access is expected to be short-lived in duration?)
- Is the implementation of short-lived access tokens sufficient to demonstrate compliance with TR-02? In other words, is there any specific propagation delay value after which it is unacceptable for tokens from a specific grant to be usable? Or, is it expected that revocation operations are completely atomic (the user is kept waiting until the system, including resource servers and authorization servers, have reached a consistent state?)
Robert Scanlon (Oct 04 2021 at 21:21):
Inferno's G-10 certification tests verifies the access token no longer works to ensure that systems that do implement a very long-lasting access token (as technically is allowed in SMART as you noted) do not bypass the revocation requirement in spirit. However, our tests do not technically have to be run immediately after revocation... we leave it up to the tester to decide how long to wait between revocation and running the test. So technically a tester could wait some short amount of time (i.e. 5 minutes) to allow the revocation information to be propagated, or for any short-lived tokens to time-out, and as long as neither the refresh token nor the bearer token 'work' then the test will pass.
Robert Scanlon (Oct 04 2021 at 21:37):
ONC hasn't issued any specific guidance here that I'm aware of, beyond what is in the ccg (which isn't much on this topic), so it might be a good idea to ask them the question directly if you choose to rely on short-lived bearer tokens to help satisfy this requirement. Inferno isn't the official source of requirements, and we may be allowing more flexibility than is intended.
Matt Randall (Oct 05 2021 at 17:42):
@Robert Scanlon - thank you for the feedback; going to seek clarification from the ONC and will post back here for the benefit of the community when we hear back.
Last updated: Apr 12 2022 at 19:14 UTC
