Cedar standard library

[cdisselkoen]

Rendered

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[shaobo-he-aws]

A meta question: Is it for human-readable format only? If not, we should provide the JSON representation as well.

[D-McAdams]

I support the "extends" feature and have several scenarios where it would help us manage schemas in large-scale systems with many services and application builders, in which central teams define a common structure which others can expand.

The Cedar standard library is a special case in which a common structure is so ubiquitous as to be nearly universal. I think this could be useful, but will naturally take longer to finalize these types and so it makes sense to decouple the standard type definitions (like OIDC User) from the rest of the proposal. We'd probably want to run the standard types through a process that looks like a standards community, including audiences from the OpenID Foundation, for example.

[D-McAdams]

When it comes to bikeshedding the naming, if we sought to avoid "extends" because of it's object-oriented connotations, I would be in favor of the aforementioned suggestion of "expands".

[cdisselkoen]

@aaronjeline says

This RFC doesn't actually say what the type deceleration for OIDC::User is, is that intended?

@D-McAdams says

will naturally take longer to finalize these types and so it makes sense to decouple the standard type definitions (like OIDC User) from the rest of the proposal. We'd probably want to run the standard types through a process that looks like a standards community, including audiences from the OpenID Foundation, for example.

These are good thoughts. I would say that this RFC proposes three things:

• the concept/mechanisms for a standard library
• the extends keyword (or whatever we end up bikeshedding it as)
• the idea of adding OIDC::User as a standard library type

but this RFC does not propose a specific declaration for OIDC::User, only proposes that we somehow arrive at a consensus one, and then add it to the standard library. I propose that we can delay hashing out the details of the OIDC::User declaration to an implementation PR, or to some other kind of process with more stakeholders as @D-McAdams suggests.

[jszmajda]

I'm a big fan of extends, that will make my life easier in my own schema definitions. One detail on the stdlib - I like the idea of a reference library, but I'm not a fan of prepending it to the schema because from what I understand this would allow any policy author to reference those entities regardless of whether they're being used in a particular application. If there's a way to "not import unless referenced or used somehow," that would solve my concern.

[andrewmwells-amazon]

I think it would make more sense to break this into two RFCs: adding libraries to Cedar (combining this RFC with parts of https://github.com/cedar-policy/rfcs/pull/61) and an RFC proposing what types to include in the standard library.

[nynymike]

Here's a schema we're using for our Janssen Project Cedar science project that you might want to consider for your library:

A few things to think about that this schema has:

1. I left the user claim section pretty sparse, as domains can always extend.
2. I added the ubiquitous "Roles"
3. I added some standard "Context" claims... which will make all the AI/ML people excited
4. A lot of tokens share certain standard claims, like iss or jti... so I abstracted these
5. A lot of enterprise policies are about OAuth clients and OAuth access tokens, so these need to be modeled too
6. It's important to make the relationship between the trusted issuer and the assertion

I understand the desire to map these to RFC's, but there is a lot of interconnection... for example OpenID Connect Dynamic Client Reg, OAuth Client Reg and Draft OAuth Client Reg with Attestation. I don't think you should boil the ocean here. Just start with a small schema?

[cdisselkoen]

These last four comments (@mwhicks1, @khieta, @andrewmwells-amazon, and @nynymike) all make good points; I'll work on splitting this RFC into (at least) two parts, separating the ideas of library mechanisms, extends, and a Cedar-maintained "standard library".

[cdisselkoen]

As the first step of that, I just posted RFC 69: Schema libraries. Comments welcome.