Resource creation when ID is not yet known

[krotscheck]

The Section 5.2 marks the id as required, however there are situations in which an ID is not yet known. How might I construct a request to create a resource? Should I attempt to pre-generate the ID before making the policy request, or make a request with an optional ID?

{
  "subject": {
    "type": "account",
    "id": "12345678-aaaa-bbbb-cccc-1234567890ab"
  },
  "action": {
    "name": "create"
  },
  "resource": {
    "type": "home_listing",
    "id": null | "pre-generated" // should this be optional?
  }
}

[davidjbrossard]

This is a good point: generally, when the authorization request is about creating an item (say Alice wants to create a document), we don't know the identifier yet because best practice says the act of creating generates the identifier.

We need to discuss this on the next available meeting. There are a couple options:

• make identifiers optional: in this way we can send "Can user Alice create a new record?" (in this request, the resource identifier is unspecified)
• keep identifiers mandatory: in this case, we need to define patterns/best practices on how to handle yet-to-be-known identifiers e.g. "Can Alice create a new record?" would have to be encoded with a resource id where the value is either a well-known placeholder e.g. -1 or the supposed future identifier

Moving this to the agenda for the 6/24 meeting.

@alexolivier thoughts? Any impact on gRPC stubs or OpenAPI specs?

[baboulebou]

Well the actual ID to create could be passed, even though it doesn't correspond to any data yet. Create is a special case anyway.

[davidjbrossard]

1. We need to relax the schema for validation: resource ID becomes optional
2. On a case-by-case basis, we make resource ID optional or mandatory.
   1. When using an action that implies there is no such item yet (create, manufacture...) then ID should be optional
   2. When using an action that implies there is already an item (update, view, read, transfer...), then the ID needs to be passed in

AuthZEN recommendation: set an ID where there should be one and leave it optional when it doesn't make sense (resource creation).

[ogazitt]

As I've said many times, this all but guarantees that you've prevented the ReBAC implementations from implementing the AuthZEN core standard successfully. A huge mistake in my opinion.

ReBAC asks for ONE concession from the ABAC implementations (which of course can have everything be optional): make the 5-tuple { subject_type, subject_id, action_name, resource_type, resource_id } mandatory.

The pattern for "create" is indeed different, in the sense that it requires you to think about the object type differently.

For example, the permission to create a todo would be expressed as in the context of a specific todo-list. In AuthZEN terms, the request would be:

{
  "subject": {
    "type": "user",
    "id": "alice"
  },
  "action": {
    "name": "create_todo"
  },
  "resource": {
    "type": "todolist",
    "id": "1"
  }
}

@aaguiarz has made this point many times as well.

One may ask "how do you then express the permission to create a todo-list?" The answer typically is a specific type (e.g. "todo-list-creator-type") with a singleton instance ("todo-list-creators") which essentially acts as a role.

[baboulebou]

Ok, checked my notes, 100% agreed with Omri here: we did say the 5-tuple IS mandatory, pass-in the ID to create, or a dummy value, let's not revisit that. We also implemented it that way (and interop'ed it already twice), so please let's not change that!

For the curious though, there is more than 1 way to do this in ReBAC, read on (or not if not curious)...

ReBAC looks at paths. So given that the Node to create doesn't exist yet, there is obviously no paths to it - yet. To authorize a CREATE action then, all you have is the path in the graph up to the node after which you would create this new Node. E.g., Alice wants to create todo2 given this graph:

(Alice)->(todolist-01)->(todo1)

if Alice can access a todolist node, through a path (Alice)->(todolist), then Alice should be able to create the next node after that. So here, Alice can access todolist-01, she therefore can create any todo node after that.

Now Omri's request translates to: "Can Alice perform a create_todo action from resource todolist-01" : the request pertains to todolist and the todo node creation is inferred by the semantics of the Action. It's the same idea: checking the Node-1 in the path, the authzen request is different though.

That's fair, but we do it differently.

For my own implementation, the request would actually looks like you all ABAC'ers expect:

{
  "subject": {
    "type": "user",
    "id": "alice"
  },
  "action": {
    "name": "create"
  },
  "resource": {
    "type": "todo",
    "id": "todo2"
  }
}

=> i.e., we're actually asking the "proper" question: "Can Alice Create todo2". We can figure this out because we know the ontology of the graph. But that requires a proper knowledge graph to compute ;-) .

[ogazitt]

@baboulebou your ReBAC implementation is special :)

Regardless of the technique, we cannot break the current semantics (the five required fields) without dismantling the goals of the AuthZEN roject, which is to define a set of "opinions" in the protocol that are able to emcompass the widest set of PDPs, and specifically include the class of ReBAC PDPs that require the 5-tuple.

I'm closing this issue as "won't fix".

[krotscheck]

Hi @ogazitt — I’m a bit confused by what feels like a contradiction. On one hand, you’ve stated that the goal is to “encompass the widest set of PDPs.” But on the other, there’s a firm insistence on requiring resource_id, which effectively excludes PDPs that operate with unanchored resources, or follow attribute-based or capability-based patterns where an ID may not yet exist, or be meaningful.

Could you help clarify how that requirement aligns with the broader inclusivity goal? From my perspective, it seems to narrow the scope of what’s considered interoperable by privileging one model’s assumptions (ReBAC) over others.

Also — and perhaps this got lost in the thread — the reason I used the example I did above is because the resource being created is intentionally unanchored. There isn’t a parent context I can attach it to... unless I muddy up my model with synthetic resources. That’s what prompted the question about whether resource_id should be optional in the first place.

Lastly - I want to question whether we're clear on the audience of the AuthZen spec and working group. While the examples being discussed work well for folks like us who live and breathe auth models, the vast majority of engineers I work with aren’t thinking in terms of graph paths, parent nodes, or relationship semantics. They think in terms of resources — “I’m trying to create a ” — and that’s the mental model that shows up in their code.

The AuthZEN API, in my view, is meant to be consumed by them, not by us. If we make the API ergonomics tightly coupled to ReBAC-specific modeling assumptions, we risk alienating implementers who just want to ask: "Can User X Create a Todo list?" Optional resource_id's to me is much more about developer ergonomics than purity.

[baboulebou]

@krotscheck - it's pretty simple. If Resource ID is optional, you are breaking all the ReBAC implementations, which contradicts the inclusiveness criteria.

If Resource id is mandatory, everybody can just pass a dummy value. Easy workaround. If you want, we can specify this, and/or state what this dummy value should be (e.g., " _new ").

The reasons why ReBAC implementations need it are expressed in my prior comment, if you need more details, let's take it offline, but it will involve a conversation about how graphs work.

[krotscheck]

That's just the thing - your argument can be sculpted from either perspective. Either

1. "If resource ID is optional, you are breaking all the ReBAC implementations."
2. "If resource ID is required, you are forcing ABAC implementations to include brittle dummy value logic"

In either case, the spec is being preferential of a particular implementation, and not being truly inclusive. I think we'd be far better served not by offering workaround or purity arguments, by looking at what the solution looks like from the end user's perspective.

1. "If resource ID is spec-optional, the ReBAC PDP can just declare it required"
2. "If resource ID is spec-optional, the ABAC PDP can use its omission as a true input signal"

Softening the language in the spec to support both use cases is, I feel, the right path forward here. Instead of saying "Required", we can say "May be required" or "May be optional".

[ogazitt]

As @baboulebou stated, we made a call two years ago that the spec would incorporate the minimal opinions to be compatible with ReBAC implementations. Otherwise it’s just another rehash of XACML.

ABAC is more permissive. As Alex suggested, a trivial workaround for a mandatory resource ID is a dummy value. With ReBAC, there is no workaround unless you get all 5 required values. Hence the opinion that we adopted with AuthZEN.

We have 4 successful interops under our belt with a wide array of implementations. Changing the requirement would break some of them.

For all those reasons, we are not revisiting that decision.

[krotscheck]

@ogazitt – I’m not proposing to break interop. I’m proposing to soften the normative requirement on a single field to reduce implementation burden for future adopters.

The OIDF has numerous precedents where consensus has been revised in response to real-world developer feedback. That’s what I’m offering here.

To pull on this thread: What would concretely break if resource_id became selectively optional? Would any PDPs behave differently if it were explicitly set to null or unset? Especially if, as @baboulebou noted, the PDP knows the ontology of the graph? If not, the cost of enforcing this requirement appears unjustified.

[aaguiarz]

Hey, I work for OpenFGA and I don't see an issue with making it optional.

My main concern is with the interop scenarios. We should make sure they can be implemented in a wide range of Authorization servers, and they should be designed with that in mind.

[baboulebou]

We would be breaking the interops, and likely a lot of other things. Also, do we really need this, when the workaround is as trivial as passing is a dummy (e.g., _new) value. That IS the consensus we already reached 2 years ago. I don't see why we should be revisiting that now. This was literally the 1st thing we discussed within the working group.

Also, not all implementations use a knowledge graph (Zanzibar isn't a knowledge graph for example) so requesting vendors to use one is too heavy handed, and would be total rewrite. That would be completely unacceptable imho. Again, we already had consensus.

@aaguiarz I think I remember you being there for those discussions a while ago...