Propose a path extension type by apg · Pull Request #115 · cedar-policy/rfcs

apg · 2026-06-05T21:11:31Z

Checklist

Added RFC to text/SUMMARY.md in numerical order

- Derived from discussion on @cedar-policy/rfcs cedar-policy#103 - path(..., ..., ...) becomes container to call .matches and .prefixMatches against Signed-off-by: Andrew Gwozdziewycz <andrew.gwozdziewycz@docker.com>

patjakdev

I wonder about the feasibility of generalizing the proposed path type to an ordered list type, where path becomes just a list[string].

The biggest wart that I think can think of is that list[string] would be the only type to allow for the special wildcard syntax when doing matching. A new any keyword could potentially be added to allow for wildcards in lists of other types.

patjakdev · 2026-06-10T21:11:34Z

+
+## Summary
+
+This RFC proposes a `path` extension type for Cedar. A path represents a variable-length, ordered sequence of strings — for example, the components of a filesystem path, S3 object key, URL path, MQTT topic, or reversed hostname. The `path` type exposes two matching methods, `.matches()` and `.prefixMatches()`, whose arguments must be string literals. This restriction keeps Cedar's SMT-based policy analysis decidable and efficient. String splitting and delimiter handling are intentionally out of scope; path values are constructed from pre-parsed components supplied by the application.


I might propose prefixLike instead of prefixMatches for symmetry with the like operator.

You might also consider a prefixEquals for situations where * should be treated as a literal asterisk rather than a wildcard without the need to escape it.

I'm not sure about the Like vs Matches. I think Matches might work better given its relationship to structual pattern matching, though, you're right about the name symmetry--prefixLike might be more ergonomic. Open to other feedback here!

patjakdev · 2026-06-10T21:22:08Z

+
+#### `.matches(pattern1, ..., patternN)`
+
+Returns `true` if the path has **exactly** `N` components and each matches the corresponding pattern:


Presumably, this method errors if a non-string is passed as an argument.

Yeah. That would make sense! I'll have to update this.

patjakdev · 2026-06-10T21:23:16Z

+path(resource.bucket, context.tenant)  // dynamic components
+```
+
+Arguments may be any string-typed expression — they are not required to be literals. Strict validation requires each argument to have type `string`.


Interesting. This might be the first extension type constructor that doesn't require a string literal for strict validation since it's not possible to pass an invalid value.

patjakdev · 2026-06-10T21:35:45Z

+
+### Schema
+
+```json


Include the Cedar format as well?

patjakdev · 2026-06-10T21:37:24Z

+
+Records with positional fields work for paths whose length is fixed by the schema. They fail for variable-length paths — S3 keys, URL paths, MQTT topics — which is exactly what this RFC targets.
+
+### Alternative C: String attributes with `like`


Isn't this the same thing as Alternative F? I suppose alternatives A and B are also the same thing as Alternative F.

patjakdev · 2026-06-10T21:41:30Z

+
+- **`.get()` inclusion.** Should element access be included here or deferred to a follow-on? The primary value of `path` comes from `.matches()` and `.prefixMatches()`; `.get()` adds convenience but also implementation and specification surface area.
+
+- **Wildcard semantics.** Pattern matching follows Cedar's `like` semantics: `*` matches zero or more characters within a single component and does not cross component boundaries. This means `path("foo", "bar").matches("*")` is `false` (length 2, not 1). The interaction between zero-length matches and the hostname use case (where `*.github.com` should require a non-empty subdomain) should be confirmed.


I don't quite understand what this is getting at.

Basically, matches("*") is strict on the number of components. In the example above path("foo", "bar").matches("*", "bar") is fine because it has two components. The variant prefixMatches supports the variable number of components.

patjakdev · 2026-06-10T21:43:36Z

+
+- **Wildcard semantics.** Pattern matching follows Cedar's `like` semantics: `*` matches zero or more characters within a single component and does not cross component boundaries. This means `path("foo", "bar").matches("*")` is `false` (length 2, not 1). The interaction between zero-length matches and the hostname use case (where `*.github.com` should require a non-empty subdomain) should be confirmed.
+
+- **Empty path behavior.** Should `path()` — a zero-component path — be a valid value? `path().matches()` and `path().prefixMatches()` would both return `true`, which seems correct, but edge cases in entity data deserve consideration.


Seems fine to me.

If we were to generalize path into list, though, it would be a problem because the type would be unknown.

apg · 2026-06-23T00:20:23Z

I wonder about the feasibility of generalizing the proposed path type to an ordered list type, where path becomes just a list[string].

The biggest wart that I think can think of is that list[string] would be the only type to allow for the special wildcard syntax when doing matching. A new any keyword could potentially be added to allow for wildcards in lists of other types.

I think this is something @emina would have to look at. I simply based this off of this comment #103 (comment). It seems as though general lists would be analyzable if they worked like the proposal (only integer literals for accessing elements, no length).

Signed-off-by: Andrew Gwozdziewycz <andrew.gwozdziewycz@docker.com>

Propose a path extension type

2f41532

- Derived from discussion on @cedar-policy/rfcs cedar-policy#103 - path(..., ..., ...) becomes container to call .matches and .prefixMatches against Signed-off-by: Andrew Gwozdziewycz <andrew.gwozdziewycz@docker.com>

apg force-pushed the apg/path-extension-type branch from f4f7c6b to 2f41532 Compare June 5, 2026 23:31

patjakdev reviewed Jun 10, 2026

View reviewed changes

Some basic updates replying to @patjakdev

1ba6996

Signed-off-by: Andrew Gwozdziewycz <andrew.gwozdziewycz@docker.com>

apg force-pushed the apg/path-extension-type branch from c250ee9 to 1ba6996 Compare June 23, 2026 00:32


		## Summary

		This RFC proposes a `path` extension type for Cedar. A path represents a variable-length, ordered sequence of strings — for example, the components of a filesystem path, S3 object key, URL path, MQTT topic, or reversed hostname. The `path` type exposes two matching methods, `.matches()` and `.prefixMatches()`, whose arguments must be string literals. This restriction keeps Cedar's SMT-based policy analysis decidable and efficient. String splitting and delimiter handling are intentionally out of scope; path values are constructed from pre-parsed components supplied by the application.


		#### `.matches(pattern1, ..., patternN)`

		Returns `true` if the path has exactly `N` components and each matches the corresponding pattern:


		Records with positional fields work for paths whose length is fixed by the schema. They fail for variable-length paths — S3 keys, URL paths, MQTT topics — which is exactly what this RFC targets.

		### Alternative C: String attributes with `like`


		- `.get()` inclusion. Should element access be included here or deferred to a follow-on? The primary value of `path` comes from `.matches()` and `.prefixMatches()`; `.get()` adds convenience but also implementation and specification surface area.

		- Wildcard semantics. Pattern matching follows Cedar's `like` semantics: `` matches zero or more characters within a single component and does not cross component boundaries. This means `path("foo", "bar").matches("")` is `false` (length 2, not 1). The interaction between zero-length matches and the hostname use case (where `*.github.com` should require a non-empty subdomain) should be confirmed.


		- Wildcard semantics. Pattern matching follows Cedar's `like` semantics: `` matches zero or more characters within a single component and does not cross component boundaries. This means `path("foo", "bar").matches("")` is `false` (length 2, not 1). The interaction between zero-length matches and the hostname use case (where `*.github.com` should require a non-empty subdomain) should be confirmed.

		- Empty path behavior. Should `path()` — a zero-component path — be a valid value? `path().matches()` and `path().prefixMatches()` would both return `true`, which seems correct, but edge cases in entity data deserve consideration.

Uh oh!

Conversation

apg commented Jun 5, 2026

Checklist

Uh oh!

patjakdev left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

apg Jun 23, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

apg commented Jun 23, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

apg Jun 23, 2026 •

edited

Loading