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

Thu Apr 11 15:29:56 UTC 2024

Replied in the PR. We agreed to put in a mechanism (context) and then layer
specific capability negotiations later (e.g. in additional profiles). The
base case requires no capability negotiation so this mechanism is optional.

On Wed, Apr 10, 2024 at 11:37 PM Alex Babeanu <alex at 3edges.com> wrote:

> 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/20240411/9d15d7eb/attachment.html>