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

[Justin Richer <[e-mail]>]

On top of that, since the RAR structure is fundamentally an array, existing open banking stuff could still use their types alongside the cedar type, if they wanted. Combining them would be an interesting exercise for each ecosystem, but you’ll run into that regardless of the vertical.

— Justin

On Feb 23, 2024, at 4:14 PM, Brian Campbell <[e-mail]> wrote:

Yeah, communication of intent was not supposed to be the purpose of the type parameter value. Although I do (now) see how many of the examples in RAR/RFC9396 kinda read that way. The https://www.rfc-editor.org/rfc/rfc9396.html#section-2-2.2 definition of type tries to convey what it is intended to do, which is that it "determines the allowable contents of the object that contains it." Shortly after at https://www.rfc-editor.org/rfc/rfc9396.html#section-2.1-2 it talks about using a collision-resistant value for applications expected to be widely deployed (e.g., beyond a single AS), which seems appropriate for Cedar, and is followed by an example that uses a URL as the type value.




On Fri, Feb 23, 2024 at 1:38 PM Cecchetti, Sarah <sarahcec=[e-mail]<mailto:[e-mail]>> wrote:

Interesting. We considered using the type parameter, but decided against it. In the examples in the spec, the spirit of type seems to be an indication of the intent of the request (for example "customer_information" or "payment_initiation.") We were concerned about breaking existing open banking implementations if we took away the ability for the client to include an intent in the request and substitute the format of the request. We would like for existing open banking implementations to simply use a consistent format for their requests, not to override the intent of the request if that's something that's important for them to communicate.

If communication of intent is not important, we're happy to just specify the content the type parameter and define a new policySet parameter, or possibly just give guidance to put a policy set within "privileges."


Sarah Cecchetti


________________________________
From: Brian Campbell <bcampbell=[e-mail]<mailto:[e-mail]>>
Sent: Friday, February 23, 2024 11:25:56 AM
To: Justin Richer
Cc: Cecchetti, Sarah; oauth
Subject: RE: [EXTERNAL] [OAUTH-WG] For review/discussion: Cedar profile of OAuth Rich Authorization Requests


CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.

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<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<https://cedarpolicy.com/>"
"policySet": "
  permit (
        principal == BankA::User::\"696d28c8-8912-41d2-b182-aa7087323318\",
        action == BankA::Action::\"initiate\",
    resource == Creditor::\"https://example.com/payments\<https://example.com/payments%5C>"
        )
        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]<mailto:[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]<mailto:[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]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
[e-mail]<mailto:[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.

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.