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

[Alex Babeanu]

Thanks Eve, added a comment to the PR...
I fail to see how this will help if we don't formalize this context block
in the response. How would a PDP know what key/value pairs to add in there
? Is this supposed to be implementation-specific?

Cheers,

./\.

On Wed, Apr 10, 2024 at 8:15 PM Omri Gazitt via Openid-specs-authzen <
openid-specs-authzen at lists.openid.net> wrote:

> 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
>>>
>>
>> --
> Openid-specs-authzen mailing list
> Openid-specs-authzen at lists.openid.net
> https://lists.openid.net/mailman/listinfo/openid-specs-authzen
>


-- 
[image: This is Alexandre Babeanu's card. Their email is alex at 3edges.com.
Their phone number is +1 604 728 8130.]
<https://hihello.me/p/cda689b1-0378-4b9c-88cf-33a9bc8ef0c5>

-- 
CONFIDENTIALITY NOTICE: This e-mail message, including any attachments 
hereto, is for the sole use of the intended recipient(s) and may contain 
confidential and/or proprietary information.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-authzen/attachments/20240410/c66c714e/attachment-0001.html>