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

[Omri Gazitt]

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> 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 <+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
> 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/5351846b/attachment-0001.html>