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

Thu Apr 11 16:22:06 UTC 2024

Ok then it makes sense, thanks for clarifying.

./\.

On Thu, Apr 11, 2024 at 8:30 AM Omri Gazitt <omri at aserto.com> wrote:

> 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.
>>
>

-- 
[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/3bce2a5c/attachment-0001.html>