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

[eve at xmlgrrl.com]

Awesome!

This might be a dumb question and I might be looking in the wrong place, but: Would the still-extant reason-object be a candidate to go under context (as one kind of context, vs., say, another kind like required-actions or something), or would it ultimately turn into the context block everywhere?

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>

> On Apr 10, 2024, at 6:04 PM, Omri Gazitt <omri at aserto.com> wrote:
> 
> Thanks Eve!
> 
> As you point out, since we (now) have context in both the request and response payloads, we should have the mechanism to achieve PEP-PDP capability negotiation in exactly the manner you describe. 
> 
> That mechanism is flexible enough to support various negotiation scenarios, e.g.:
> a PEP may pass a capability in its context and outright reject a PDP that doesn't respond appropriately
> a PDP may look for a required capability from the PEP and deny any request that doesn't contain it
> 
> 
> On Wed, Apr 10, 2024 at 3:26 PM eve--- via Openid-specs-authzen <openid-specs-authzen at lists.openid.net <mailto:openid-specs-authzen at lists.openid.net>> wrote:
>> 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>
>> -- 
>> Openid-specs-authzen mailing list
>> Openid-specs-authzen at lists.openid.net <mailto:Openid-specs-authzen at lists.openid.net>
>> https://lists.openid.net/mailman/listinfo/openid-specs-authzen

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-authzen/attachments/20240410/d540c5df/attachment.html>