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
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 e
