[Openid-specs-authzen] Evolving the Todo interop scenario to be compliant with AuthZEN 1.0

[Alex Babeanu]

Hello there,

@Omri Gazitt <omri at aserto.com>  and all, the simplest solution for this is
to send the same todo ID to the PDP on every request. Graph-based system
can just use 1 single Node representing all possible TODOs, you're really
authorizing the action only in this use-case. This singular ID can be
ignored by Policy-as-code systems. It's the approach we used for 3Edges in
the 1st interop.

So  We don't need to store data, no need for events or APIs . This is what
the data looks like in 3Edges:
[image: image.png]

Bottom line, let's call this singular todo `todo1` or something, and always
pass that single value (I can just change the current Node ID I have
"TodoApp" to use whatever you guys prefer).

Cheers,

./\.



On Sun, Jul 7, 2024 at 5:16 PM eve--- via Openid-specs-authzen <
openid-specs-authzen at lists.openid.net> wrote:

> Hey Omri, thanks for all this. I’ll be on the road — Beryl willing — and
> can’t attend this coming week’s call. No comments on the new Evaluations
> section at this time, but here are quick thoughts fwtw on your Todo
> evolution writeup.
>
> Dynamic resources need to be catered for. A reliance on too-static
> resource URLs or IDs will not be sustainable for a lot of APIs needing
> protection. With SSF now in the picture, your idea to use it to help manage
> resource lifecycles is intriguing. We need a method that's lightweight and
> asynchronous from the tasks of policy decision making. Maybe such a
> solution could be an SSF profile that is optionally combinable with AuthZEN
> usage but on which the latter has no deep dependency.
>
> 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 Jul 7, 2024, at 4:51 PM, Omri Gazitt via Openid-specs-authzen <
> openid-specs-authzen at lists.openid.net> wrote:
>
> Hi folks! Hope everyone had a good weekend (and for US folks, a good
> holiday weekend).
>
> I took two action items in last week's call:
>
>    1. Create an AuthZEN 1.1 spec with the /access/v1/evaluations section.
>    This is now merged and published
>    <https://openid.github.io/authzen/authorization-api-1_1>!
>    2. Update the Todo backend and make it compliant with the new AuthZEN
>    1.0 spec, and specifically the resource ID field being mandatory.
>
> On #2, I ran into a significant design issue that I believe is worth
> discussing on Tuesday's call.  Please read this background document
> <https://hackmd.io/rOm3BA4qSGmX477UXRNUuw?view> so that we can dedicate
> some time on the agenda to picking a way forward.
>
> Thanks,
> Omri.
>
> --
> <http://www.aserto.com/>
> Omri Gazitt | CEO
> Aserto <http://www.aserto.com/> Inc. | (425) 765-0079
> --
> 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/20240708/f71a247c/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 225621 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-authzen/attachments/20240708/f71a247c/attachment-0001.png>