Endpoint-level and field-level role/permission support

[rlondner]

At the company we work at, we have a need to expose APIs to different actors who have different roles and thus accesses. Essentially, some users have more or less access to the same API endpoints and on each endpoint, they may have access to some response fields or not.

However, at this point, there is no way to include this concept of role/permission support which we would at least want to use when generating documentation (and use one single OpenAPI definition file) - of course, it would mean that documentation support that new role/permission construct, but it starts with implementing it in the spec.

Is this something other folks are interested in?

Ideally, this issue should be assigned the Next.Proposal label.

[LasneF]

should not limited to read, but as well to write operation,
the mechanism should follow a kiss principle that would handle 80% use case (even if sometime access control are tricky and goes functionnal)

but basic like
field X , is write : admin only (what ever means admin ... like beeing part of a group , or a custom claim , or whatever)
this field Z is read by boss, admin

would looks nice , then should it be as Json schema extension in OAS , or in core json schema is also a topic as readOnly / writeOnly )