[Openid-specs-authzen] An example framework for layered-semantics interop/compliance

[eve at xmlgrrl.com]

On this week’s call, I alluded to mechanisms in HEART that allow for communication between entities about their commonly understood “layered semantics". Below I explain; I thought they might be interesting as examples (and probably go some way to explaining why I thought of the phrase “obligation scopes”...).

====

By “layered semantics”, I mean switchable sets of functionality. They could be provided natively by the base spec, or could be published by third parties, or have a mix. That’s why I’m not saying “extension”, and why I’m not implying there has to be a hardcore assignment of “obligation” vs. “advice” about it.

HEART incorporates by reference a set of semantics/structures coming from the FHIR API/data model, which HEART variously maps to resource types and scopes. Here’s the start of the several sections where the FHIR artifacts are referenced: https://openid.net/specs/openid-heart-fhir-oauth2-1_0.html#Resource

HEART adds highly prescribed ways in which the special set of confidentiality and sensitivity scopes (example: sens/ETH means sensitive data about “Substance abuse”*), and the special break-the-glass scope, must be handled.

The confidentiality/sensitivity trick requires the resource server to know what it’s doing if it “advertises” its ability to handle this set of scopes. Quoting from https://openid.net/specs/openid-heart-fhir-oauth2-1_0.html#ConfidentialitySensitivity (emphasis mine):

“This specification makes no assumptions regarding the ability of resource servers to tag and filter data. A resource server that is capable of filtering information MUST advertise this capability through the use of these scopes. Resource servers SHOULD use this access information to filter out data being returned to a client, if possible. If an access token does not contain a given confidentiality or sensitivity marker, the resource server SHOULD assume that the client does not have access to that information and SHOULD apply appropriate filters to the data, where possible.”

(“Advertising” could merely mean OAuth-protected API documentation; if UMA is in use, HEART additionally imposes formal scope registration: https://openid.net/specs/openid-heart-fhir-uma2-1_0.html#resource-reg)

So if a client carries back to the RS a token that doesn't have, say, the sens/ETH scope associated, that’s effectively an instruction for the RS to actively filter out sensitive substance abuse data in the manner the RS claimed it could do. If the scope is present, then that data is “safe” to share.

The break-the-glass trick is simpler. The btg scope is baked into the spec and it works in the more usual way: its presence says to give access. But resource servers are obligated (ha) to take various operational-level actions upon giving access using it, such as logging access in a resource owner-friendly way, and (in UMA) enabling user-offline ways to set policies that can meaningfully control the parameters of break-the-glass access.

====

So let’s say we have a generic context block coming from a PDP that doesn’t imply what the PEP should/must do about it. Can we imagine empowering anyone (including ourselves) to profile context-related communications to enable, say, a) obligations to be imposed by PDPs (as in btg), b) PEPs to pre-declare their ability to handle different kinds of advice-or-obligations (as in conf/sens), and even c) PDPs and PEPs to dynamically negotiate what the PEP should try next? (I do have an example of that one too, but will leave it out for now!)

*A former colleague who’s a paramedic told me the ETH code comes from the word “ether”.

Eve Maler | cell and Signal +1 (425) 345-6756 <tel:+1-425-345-6756>
Visit the Venn Factory <http://vennfactory.com/>
Request a 15-minute consultation <https://fantastical.app/eve/15>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-authzen/attachments/20240410/14f473ef/attachment.html>