Re: [OAUTH-WG] For review/discussion: Cedar profile of OAuth Rich Authorization Requests

[Brian Campbell <[e-mail]>]

I'm inferring some intent (apologies if I've got it wrong!) but I think
it'd make the most sense for this work to start with defining a RAR type
value (something like "https://cedarpolicy.com") and define that type as
having the "policySet"  parameter. An updated example figure 1 from the
draft would look like the below.  As Justin said, RAR intends the “type”
field as the extensibility point that defines the semantics of all other
parts in the typed object. So it would be saying this is a Cedar
type authorization_details element and it contains this "policySet"
parameter that has the actual Cedar policy in it.


{
"type": "https://cedarpolicy.com"
"policySet": "
  permit (
        principal == BankA::User::\"696d28c8-8912-41d2-b182-aa7087323318\",
        action == BankA::Action::\"initiate\",
    resource == Creditor::\"https://example.com/payments\"
        )
        when { context.instructedAmount.currency == \"EUR\" &&
    context.instructedAmount.amount == decimal(\"123.50\") &&
    resource.creditorName == \"Merchant A\" &&
    resource.creditorAccount.bic == \"ABCIDEFFXXX\" &&
    resource.creditorAccount.iban == \"DE02100100109307118603\" &&
    context.remittanceInformationUnstructured == \"Ref Number Merchant\"
        };
"
}


On Thu, Feb 22, 2024 at 11:15 AM Justin Richer <[e-mail]> wrote:

> Hi Sarah,
>
> Thanks for putting that draft together. As one of the authors of RAR, I
> wanted to chime in.
>
> First, I do think that this is a great use of RAR. The whole idea behind
> RAR was to give people structures that they could use beyond what scopes
> allow, and tying this to a computable policy language like Cedar makes a
> lot of sense to a lot of use cases. In particular, as with any other RAR
> object, this could show up in the client’s request to the AS, the AS’s
> response to the client, or the token’s resulting metadata (basically AS
> message to the RS via the token), and having an explicit policy in each of
> those places deserves discussion.
>
> Next, I wanted to provide some specific feedback about the implementation
> proposed in the draft, because I think there are a few ways it could go and
> each might make sense.
>
> One of the benefits to RAR is that it’s the “type” field that defines the
> semantics of all other parts in the typed object — which also makes
> interoperable definitions a bit trickier. With that in mind, what is the
> intended target of the “rarFormat” and “policySet” fields?
>
> Is the goal of this draft to define another set of “Common Data Fields” to
> be used across different types, as is done in RAR section 2.2? (
> https://www.rfc-editor.org/rfc/rfc9396.html#name-common-data-fields) If
> so, that should be called out explicitly, as is done in RFC9396. Are there
> intended interactions with other common data fields, such as filtering the
> policy based on location or action, for example?
>
> Or is the goal that these be defined in a specific set of “type” values
> that would comply to this format? If so, what are the conditions for using
> and extending this format? The way the “rarFormat” text is currently
> written, it seems to put constraints on the rest of the object defined by
> the “type”, so is the intent that you’d have rar-cedar-compliant types that
> follow this pattern?
>
> Or is the goal to define a generic and extensible field set that can be
> re-used by other policy languages? That seems to be hinted at with the
> separate format and data fields, but as written only one is defined so it’s
> difficult to tell, at this stage, what the intended abstraction points are.
> If only one is defined, then would it make sense to just define a single
> “cedarPolicy” parameter instead of the two? And if there’s another format
> that comes along, it can follow Cedar’s example and do something similar.
> The “type” would define how to handle having different policy formats in a
> single object, to avoid overlaps.
>
> And if the answer to all of this is “I don’t know”, that’s also reasonable
> at this stage as these are great questions for the WG to answer. :)
>
> Finally, since RAR is based on JSON data types, and Cedar uses multi-line
> strings (at least for display in the examples), the intent of this value
> translation is going to have to be spelled out. As in, a real example on
> the wire would need to have all the newlines encoded as \n and the like, in
> order to be JSON. This is almost certainly me reading too much into the
> hand-crafted examples on a new drafts, but I wanted to raise this as
> something that’ll need to be solved for Cedar and, depending on the answers
> above, other languages. In other words, can we always assume that a policy
> is always encoded as a single string, or is there other structure that
> might work better? This is not my area of expertise and I have no opinions
> on the answer, so if strings are good enough that’s fine by me. :)
>
> Thank you, and I hope to see this work continue!
>
>  — Justin
>
> On Feb 21, 2024, at 5:06 PM, Cecchetti, Sarah <sarahcec=
> [e-mail]> wrote:
>
> I have submitted a new draft:
>
> https://datatracker.ietf.org/doc/html/draft-cecchetti-oauth-rar-cedar
>
> This is intended to be a profile of RFC 9396 OAuth 2.0 Rich
> Authorization Requests (OAuth RAR). OAuth RAR defines an
> authorization_details parameter, but leaves the format of the parameter
> open. This profile defines a rarFormat parameter to further constrain
> authorization_details to use a specific format called "cedar."
>
> The use case for this draft is the same as the OAuth RAR use case - i.e.
> open banking specifically, and fine-grained authorization generally. The
> intent is to make the standard more interoperable by specifying the policy
> language which will be used to communicate the authorization request and
> response. The language used in these examples is Cedar, an open-source
> policy language - https://www.cedarpolicy.com/en. Putting Cedar policy
> sets within an OAuth token enables the client and RS to conduct
> transactions which conform to specific fine-grained policies which have
> been blessed(signed) by the AS.
>
> Open Questions:
>
>    1. Should we create a separate informational draft defining the Cedar
>    language itself within the universe of the IETF? Or is it fine to leave
>    that undefined?
>    2. Is rarFormat the right name for this parameter?
>    3. Should policySet be required?
>    4. I tried to keep this draft fairly simple and duplicate examples in
>    the OAuth RAR RFC without redundantly stating what is already defined
>    there. Did I include too little? Too much?
>
>
> This is my first draft submission, so any and all feedback is welcome, and
> apologies if my xml is incorrectly formatted. I'm ignorant about many
> things in the standards process. :)
>
>
> Sarah Cecchetti
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._