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

[Brian Campbell <[e-mail]>]

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]> 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]>
> *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") 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.*
>

-- 
_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._