Stream: bulk data
Topic: Attachments and "additional authentication credentials"
Dennis Patterson (Jul 15 2021 at 21:46):
Imagine a successful export with requiresAccessToken = true in the response. The bulk client retrieves a DocumentReference .ndjson file and is about to resolve one of the DocumentReference's content attachment urls. The attachment section of the build spec says "the url location must be accessible by a client with a valid access token, and SHALL NOT require the use of additional authentication credentials."
I have always read this as requiring a holistic approach where the client's JWT credentials are used in a client assertion presented to a single authorization server token url and the resulting access token used consistently from export request to checking the status to downloading both ndjson files and attachments (noting of course that tokens expire and they may need to ask for another). Consistent "authentication credentials" is not solely referring to the client's own identify assertion, but rather in conjunction with a consistent authorization server url (i.e. no switching mid-workflow for a different type of token). It's a bit legalese but I wanted to state it explicitly to ensure agreement.
Josh Mandel (Jul 15 2021 at 21:55):
The intention is that when requiresAccessToken==true, the client can use the same process it used for getting access tokens to manage the export to also
- get an access token for fetching the output ndjson files
- get an access token for fetching binary attachment content
Josh Mandel (Jul 15 2021 at 21:56):
I'm not sure if you've looked through the ballot responses, but we did have some clarifying language on his front that was part of the block vote this week.
Dennis Patterson (Jul 21 2021 at 14:10):
Thanks @Josh Mandel ! Could you or @Dan Gottlieb post the jira(s) with the updated language?
Dan Gottlieb (Jul 21 2021 at 14:16):
https://jira.hl7.org/browse/FHIR-32114 and https://jira.hl7.org/browse/FHIR-32772
Dennis Patterson (Jul 21 2021 at 14:49):
For this discussion, the sentence I found most helpful from the first jira is "This definition [of requiresAccessToken] should be clear that we're talking about 'downloading the generated files requires the same authorization mechanism as the $export operation itself' – not just any bearer token, but the same scheme as the kickoff, polling, etc."
Dennis Patterson (Jul 22 2021 at 17:16):
It might be even clearer to say "the same scheme and same token url"
Josh Mandel (Jul 22 2021 at 17:45):
The sentence you are quoting was just the issue description; it's important to evaluate the actual resolution if you want to make wording tweaks. Resolution was to add
downloading the generated files requires the same authorization mechanism as the $export operation itself
Josh Mandel (Jul 22 2021 at 17:45):
If this is unclear, feel free to submit a follow up requesting specific additional changes.
Yunwei Wang (Jul 22 2021 at 18:43):
"servers SHALL populate the Attachment.contentType code as well as either the data element or the url element". Should that be either data or url or both?
Josh Mandel (Jul 22 2021 at 18:44):
either the data element or the url element
I haven't heard a use case for populating both; has this come up in your experience?
Yunwei Wang (Jul 22 2021 at 18:45):
It is mentioned in US Core IG: "us-core-6: DocumentReference.content.attachment.url or DocumentReference.content.attachment.data or both SHALL be present."
Josh Mandel (Jul 22 2021 at 18:51):
We don't currently prohibit this, but (again) we haven't heard a use case for populating both.
Yunwei Wang (Jul 22 2021 at 18:52):
So it is an "inclusive OR".
Josh Mandel (Jul 22 2021 at 18:52):
I mean, ... if you want it to be? I don't know that we have super strict semantics on this. (And I'm trying to understand whether it matters.)
Last updated: Apr 12 2022 at 19:14 UTC
