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

[Omri Gazitt]

The PR I created yesterday puts the reason-code etc under the context.

https://github.com/openid/authzen/pull/90


<http://www.aserto.com/>

Omri Gazitt | CEO

Aserto <http://www.aserto.com/> Inc. | (425) 765-0079


On Wed, Apr 10, 2024 at 4:57 PM <eve at xmlgrrl.com> wrote:

> 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 <+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> 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/75c09774/attachment.html>