Stream: implementers
Topic: Caching of Consent linked in X-Consent header
Michael Donnelly (Jan 15 2019 at 22:02):
In Q3, Security and CBCP approved adding an X-Consent header.
The custodian of the data can certainly retrieve the Consent resource from that URI every time it appears in the X-Consent header, but it would be preferable to allow the custodian to trust a cached copy of the Consent. Of course, the details of the Consent may have changed, so we need a way to expire that cache.
In Q3 we discussed two possibilities:
1. Add an element to the Consent resource indicating for how long it could be cached before it should be retrieved again (similar to the expiration of a Certificate Revocation List).
2. Include a lifetime or expiration with the X-Consent header.
The workgroup preferred the latter.
I've thought about it more since then and have thought of another possibility:
3. Include an e-tag with the X-Consent header.
The custodian could compare the e-tag of its cached version to the e-tag included in the X-Consent header. At any point that a request comes in with a different e-tag, the custodian knows its copy is stale.
Bear in mind that the client is obligated to only use the X-Consent header when it knows that the Consent in the URI fulfills the policy requirements for the custodian to share data with it.
Security/CBCP folks, what do you think of this option?
Michael Donnelly (Jan 15 2019 at 22:11):
@John Moehrke @David Pyke
John Moehrke (Jan 15 2019 at 22:17):
interesting... I am happy to hear improvement requests and comments
John Moehrke (Jan 15 2019 at 22:17):
Note that @Jenni Syed has questioned the use of X-Header -- " They have officially deprecated that convention. See https://stackoverflow.com/questions/3561381/custom-http-headers-naming-conventions for a good explanation of history." I expect I will just follow the lead of FHIR-I who has used this model quite extensively.
Michael Donnelly (Jan 15 2019 at 22:22):
Oh, I'd forgotten about that. Yeah, I saw that too.
Matt Blackmon (Jan 15 2019 at 22:27):
RFC6648 has much to say as noted above. That said, of concern may be firewalls and gateways that may now (or at some time in the future) filter out those header elements as non-standard, and therefore subject to risk--rightly so or not. To the extent that this would be standardization by us contrary to the "do not standardize this" guidance, this might should give pause.
John Moehrke (Jan 15 2019 at 23:10):
if it gets dropped, there is loss of benefit, but I think the X-header uses in FHIR today are there to enable automation. In the case of X-Consent and X-Provenance (the two I know best) the server can always just FAIL the transaction and that failure message (OpertionOutcome) would indicate the lack of the X-header it is looking for... so, this degrades gracefully....... That said, if there is a better mechanism that FHIR-I defines, I am happy to use it.
John Moehrke (Jan 15 2019 at 23:11):
What does the community think about the e-tag improvement?
Lloyd McKenzie (Jan 15 2019 at 23:18):
I like it - it's more efficient than a time-out process and also safer
Last updated: Apr 12 2022 at 19:14 UTC
