Closed ogazitt closed 4 months ago
Name | Link |
---|---|
Latest commit | 5cf6c5bcc66936f7425e88613f58e9f06d5a2933 |
Latest deploy log | https://app.netlify.com/sites/authzen-todo/deploys/6615c31ba0024100082b2fcb |
The proposed context being apparently a "free form" JSON, how would a PDP "know" what values to add in there? Are we saying this is implementation-specific, and therefore PDPs need to be parametrized somehow to reply whatever is desired?
Or is there a way to formalize this for easier interop ?
The proposed context being apparently a "free form" JSON, how would a PDP "know" what values to add in there? Are we saying this is implementation-specific, and therefore PDPs need to be parametrized somehow to reply whatever is desired?
Or is there a way to formalize this for easier interop ?
We agreed to first add the mechanism, and then add profiles that would define specific capability negotiations.
Did someone review / approve the changes? I don't see the approvals in the GitHub history
On Thu, Apr 11, 2024 at 1:16 PM Omri Gazitt @.***> wrote:
Merged #90 https://github.com/openid/authzen/pull/90 into main.
— Reply to this email directly, view it on GitHub https://github.com/openid/authzen/pull/90#event-12441231655, or unsubscribe https://github.com/notifications/unsubscribe-auth/AB55UG3MMTQIQXW3PKBCIGLY43VS5AVCNFSM6AAAAABF7MK3QGVHI2DSMVQWIX3LMV45UABCJFZXG5LFIV3GK3TUJZXXI2LGNFRWC5DJN5XDWMJSGQ2DCMRTGE3DKNI . You are receiving this because your review was requested.Message ID: @.***>
@Alexandre Babeanu @.> , in XACML you can already specify freeform content inside an obligation. It's essentially an obligation ID e.g. "doMFA" and then key-value pairs e.g. @. and loa=2
On Thu, Apr 11, 2024 at 1:23 PM Atul Tulshibagwale @.***> wrote:
Did someone review / approve the changes? I don't see the approvals in the GitHub history
On Thu, Apr 11, 2024 at 1:16 PM Omri Gazitt @.***> wrote:
Merged #90 https://github.com/openid/authzen/pull/90 into main.
— Reply to this email directly, view it on GitHub https://github.com/openid/authzen/pull/90#event-12441231655, or unsubscribe < https://github.com/notifications/unsubscribe-auth/AB55UG3MMTQIQXW3PKBCIGLY43VS5AVCNFSM6AAAAABF7MK3QGVHI2DSMVQWIX3LMV45UABCJFZXG5LFIV3GK3TUJZXXI2LGNFRWC5DJN5XDWMJSGQ2DCMRTGE3DKNI>
. You are receiving this because your review was requested.Message ID: @.***>
— Reply to this email directly, view it on GitHub https://github.com/openid/authzen/pull/90#issuecomment-2050464191, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABPRFP3N5M4C6SAPLCMSL3DY43WM7AVCNFSM6AAAAABF7MK3QGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANJQGQ3DIMJZGE . You are receiving this because your review was requested.Message ID: @.***>
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: http://www.securite-informatique.gouv.fr/gp_rubrique34.html
Having a consistent representation of the http request and headers received by the application makes it dramatically easier to write policy conditions. If the policy writer has to know what the application will give in advance, it leads to tightly coupled policy systems and applications.
IOW. Context should be defined and sent every time because the app owner doesn't know the specific policy rules are now how they will change.
This feels like an important benefit for authzen.
In IDQL with OPA we are currently sending a common request object (ReqParams)...
https://github.com/hexa-org/policy-opa/blob/main/client/hexaOpaClient/hexaOpaClientTools.go