There exists a description of a break-glass mechanism that needs some improvements.

http://build.fhir.org/security-labels.html#break-the-glass

In my view the use of an HTTP header to convey "Break The Glass" is not appropriate because the http header is not a security mechanism. The method of conveying break-the-glass, or any PurposeOfUse, needs to be done in a way that is testable that the user has the RIGHT to declare break-the-glass, and that the breaking of that glass does not violate policy, including Consent that might forbid it. Having this in an http header enables malicious individual to simply fixup a http header and gain access that they don't have authorization. However, given there is no good alternative at this time, it seems like this is as good of a experimental method as any.

Grahame countered asking why...

In the case of SMART, the OAuth and the Resource server are tightly bound. The Resource server does need to confirm the token, and scope; and it then must enforce the decision (which means constraining results to the scope). But in this case the Resource server is not expected to make any decisions, just enforce decisions that have already been made (by the OAuth authority).... This is a simplified model that can be done when the OAuth authority and the Resource server are tightly bound, like is defined in SMART.... This is not the only way to use OAuth, as you point out... and indeed in the case of IHE-IUA, the authorization decision is expected to be within the Resource Server..

Which means.. we likely just need to express the reality that use of http header has these risks, and thus these responsibilities.

Seems we could provide an altermative that uses IUA purposeOfUse mechanims, or a use of scope including PurposeOfUse. — Should these replace the existing http header recommendation?

This should also use the vocabulary value we have for this "ETREAT".

Further, this break-glass should be linked to the AuditEvent for broken glass

Further, this break-glass should be brought up on the top level security page

Further, we should express how a user/client knows that break-glass is a useful thing to do.