Boxcarring

[alexolivier]

• Moves existing app and backend into a spec-1.0 folder
• Extended application with boxcarring introduced in spec-1.1 folder
• Added v1.0 and v1.1 sections into documentation site

[netlify]

‼️ Deploy request for authzen-todo rejected.

Name	Link
🔨 Latest commit	2560988

[davidjbrossard]

@alexolivier I merged main into your branch. I had made some minor text edits on the API spec.

[ogazitt]

I've been thinking about how much commonality could we have between the v1.0 and v1.1 scenarios.

For authzen-interop-website, clearly a single project will work. The site organization I envisioned could add more scenarios (e.g., in addition to todo, it could have todo-boxcarred). And the results pages could be factored accordingly.

For authzen-todo-application, I agree that we need two different apps, unless we add some kind of selector in the app that tells us which behavior we want. So I think the work you did here makes sense.

For authzen-todo-backend, I'm torn. Seems like adding another route (DELETE /todos) could be done in an additive way to the existing todo backend project. I like the middleware you created - I think you could just add it to the existing project without breaking anything?

The only question is the list of pdps returned (i.e. pdps.json). I could see how we could add another endpoint (GET /v1.1/pdps) and have a separate pdps.json file for the 1.1-compliant PDPs.

[alexolivier]

For authzen-todo-application, I agree that we need two different apps, unless we add some kind of selector in the app that tells us which behavior we want. So I think the work you did here makes sense.

I can certainly do this - thinking some sort of feature toggle - but I will need to refactor it quite a bit which I'm happy to do if you are OK with it.

For authzen-todo-backend, I'm torn. Seems like adding another route (DELETE /todos) could be done in an additive way to the existing todo backend project. I like the middleware you created - I think you could just add it to the existing project without breaking anything?

That makes sense - I'll merge the backends

[alexolivier]

backends merged but frontends are kept separate by version for now

[ogazitt]

@alexolivier great work!

Given our recent spec changes, can you please update the PR to use an array for evaluations, and also the payloads for subject and resource should have subject.userID -> subject.properties.userID, and resource.ownerID -> resource.properties.ownerID.

[davidjbrossard]

Awesome work you two, thanks for pulling this together.

…

On Sun, Sep 15, 2024 at 1:48 AM Omri Gazitt ***@***.***> wrote: @alexolivier <https://github.com/alexolivier> great work! Given our recent spec changes, can you please update the PR to use an array for evaluations, and also the payloads for subject and resource should have subject.userID -> subject.properties.userID, and resource.ownerID -> resource.properties.ownerID. — Reply to this email directly, view it on GitHub <#131 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABPRFP5Y57XTRYSOQRHXSF3ZWTDNHAVCNFSM6AAAAABMN7MXVCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGNJRGIZDKOJQHA> . You are receiving this because you commented.Message ID: ***@***.***>

-- --- David Brossard http://www.linkedin.com/in/davidbrossard http://twitter.com/davidjbrossard http://about.me/brossard --- Stay safe on the Internet: IC3 Prevention Tips <https://www.capefearnetworks.com/wp-content/uploads/2017/05/Internet-Fraud-Prevention-Tips-IC3.pdf> Prenez vos précautions sur Internet: https://cyber.gouv.fr/bonnes-pratiques-protegez-vous

[alexolivier]

Given our recent spec changes, can you please update the PR to use an array for evaluations, and also the payloads for subject and resource should have subject.userID -> subject.properties.userID, and resource.ownerID -> resource.properties.ownerID.

Sure I'll pick this up next week when I'm back from PTO

[ogazitt]

superseded by PR #156