A deployment can authorize access to GraphQL data at different places:

This profile specifies the first approach only: generic AuthZEN enforcement in front of a GraphQL endpoint. It does not need control over the implementation of the source, so it also applies when the deployer does not control that implementation. The other approaches are valid. They can give finer control, for example a decision on the data that a resolver loads. They are out of scope for this profile.

The approaches can be combined. A source can also enforce per resolver (2. Model). The source in front of which the PEP sits can itself be a gateway that combines other endpoints. This profile then treats the combined schema as the schema of the source.

Only OPA (Rego) has GraphQL builtins (graphql.parse, graphql.parse_query). Cedar, Cerbos, and OpenFGA have none. The Rego AST carries no type information: a field node is {Alias, Name, Arguments, SelectionSet}. To find the parent type of a nested field, a policy must fold the schema down the query path. Rego does not allow recursion, so this becomes one rule per depth level. The result is a large engine module, shipped in every policy bundle, that contains no domain logic and runs on one engine only.

A GraphQL-aware PEP needs the schema. The schema the policies were written against lives in the policy bundle, which lands at the PDP. A PEP-side mapper needs a second distribution channel for the schema and must keep it in sync with the bundle. This is the coupling constraint 5 forbids. It also replaces an off-the-shelf PEP with a custom one.

COAZ [COAZ] standardizes how a PEP builds an AuthZEN request from a declarative template. It forbids a mapping from fanning out per list element (COAZ Section 2.6). A selection set is a list of N fields, unknown until the request. Only a COAZ GraphQL binding could express this, in the way [COAZ-MCP] binds MCP. No such binding exists as of September 2026. What already matches COAZ: the single evaluation envelope, fail-closed on mapping error, and the trust-anchored subject.id set by the PEP.

[GRAPHQL-HTTP] allows GET with query parameters, several request media types, and lets servers accept batched or persisted documents. This profile restricts the transport so that the mapper sees exactly what the source executes.

The policy bundle names the GraphQL path (for example /graphql). The PEP MUST send every request it receives for the source, on any path and with any method, to the PDP. The mapper MUST accept only a request that meets all of the following, and MUST fail closed with subcode UNSUPPORTED_TRANSPORT (5.8 Fail-closed conditions) otherwise.

• resource.id is byte-equal to the GraphQL path in the bundle. No normalisation: /graphql/, /GraphQL, //graphql, and percent-encoded variants do not match. A resource.id with a query string (a bare ? included) does not match.
• action.name is POST.
• The Content-Type header in context.headers has media type application/json (compared case-insensitively per [RFC9110]) and no parameter other than charset=utf-8 (parameter name and value compared case-insensitively).
• No Upgrade and no Content-Encoding header is present.
• action.properties.body is present and is a string.

The mapper looks up header names case-insensitively. When more than one name matches, or a value is not a string, the mapper fails closed with UNSUPPORTED_TRANSPORT. A PEP MAY omit the body for a media type it does not forward (for example every value other than exactly application/json). The mapper then fails closed.

A deployment MUST configure the source to serve GraphQL on that one path only and to reject the same requests, so that a request the mapper never judged cannot execute (10. Enforcement Guarantees, H1).

The PEP MUST send an AuthZEN evaluation request as defined in [AUTHZEN-NLGOV] with the following content.

The PEP MUST also send the X-Request-ID header on the API call as [AUTHZEN-NLGOV] describes.

The PEP MUST NOT parse the GraphQL body. The PEP MUST NOT rewrite the request. The PEP forwards the request unchanged on allow (10. Enforcement Guarantees) and returns an error on deny (9. Decision and Error Transport).

The PEP calls the Access Evaluation API endpoint of the PDP as defined by [AUTHZEN-NLGOV]. The PEP MUST treat every outcome other than a well-formed response with "decision": true (timeout, transport error, 5xx, malformed body) as deny. The PEP MUST NOT cache decisions.

The mapper first checks the transport (4.1 Transport subset) and the body size limit (5.7 Limits), before it parses anything. It then reads action.properties.body. The body MUST be one JSON object with the members defined by [GRAPHQL-HTTP]:

The mapper MUST fail closed with subcode INVALID_BODY when:

• the body is not a JSON object (a JSON array is request batching, not a GraphQL over HTTP request);
• a member has a type other than listed, or operationName is the empty string;
• the body has a top-level member other than the four listed (for example documentId or id, which select a persisted document);
• extensions has a member the bundle does not list; persistedQuery MUST NOT be listed;
• any JSON object in the body, at any depth, has a duplicate member name. [RFC8259] leaves duplicate names undefined; parsers differ, so the mapper and the source could read different values;
• a JSON number in the body cannot be represented exactly by the mapper (for example an integer beyond 2^53 in a JavaScript mapper). A value the mapper rounds is not the value the source sees.

The mapper adds one object at resource.properties.graphql. The example uses the fictional schema of Appendix A and this request:

{
  "query": "query Inkomen($bsn: BSN!, $jaar: Int = 2024) { persoon(bsn: $bsn) { inkomens(jaren: [$jaar]) { jaar ... on LoonInkomen { bedrag { waarde valuta } } } } }",
  "variables": { "bsn": "999990011" }
}

{
  "profile": "ftv-graphql/0.1",
  "operation": { "type": "query", "name": "Inkomen" },
  "schema": { "digest": "sha256:9f2c…" },
  "fields": [
    { "path": ["persoon"], "parentType": "Query", "field": "persoon", "leaf": false,
      "args": { "bsn": { "value": "999990011", "origin": "variable:bsn", "variables": ["bsn"] } } },
    { "path": ["persoon", "inkomens"], "parentType": "Persoon", "field": "inkomens", "leaf": false,
      "args": { "jaren": { "value": [2024], "origin": "mixed", "variables": ["jaar"] } } },
    { "path": ["persoon", "inkomens", "jaar"], "parentType": "Inkomen", "field": "jaar", "leaf": true },
    { "path": ["persoon", "inkomens", "bedrag"], "parentType": "LoonInkomen", "on": "LoonInkomen", "field": "bedrag", "leaf": false },
    { "path": ["persoon", "inkomens", "bedrag", "waarde"], "parentType": "Bedrag", "field": "waarde", "leaf": true },
    { "path": ["persoon", "inkomens", "bedrag", "valuta"], "parentType": "Bedrag", "field": "valuta", "leaf": true }
  ],
  "unverifiable": null
}

Top-level properties:

Field record:

The mapper MAY also add resource.properties.declared (7.2 Resource). The mapper MUST NOT remove or change any other property of the AuthZEN request. The raw body stays in action.properties.body. The enriched request MUST remain a valid AuthZEN request.

The mapper MUST select the operation as follows.

1. Parse the full document. A parse error fails closed with subcode PARSE_ERROR.
2. When the document contains no operation definition, fail closed with subcode NO_OPERATION. This check runs before validation, because a fragment-only document also fails validation (Fragments Must Be Used) and the more specific code is the useful one.
3. Validate the full document (5.4 Validation and the walk.1) before selecting an operation. This catches an anonymous operation next to a named one ([GRAPHQL] Lone Anonymous Operation).
4. When operationName is present and no operation has that name, fail closed with subcode OPERATION_NOT_FOUND. This follows GetOperation in [GRAPHQL].
5. When operationName is absent and the document has exactly one operation, select it. When operationName is absent and the document has more than one operation, fail closed with subcode OPERATION_AMBIGUOUS.
6. When the selected operation is a mutation or subscription, fail closed with code OPERATION_NOT_SUPPORTED. This profile version covers queries only.

The mapper MUST perform validation and the walk as follows.

1. Validate the whole document against the bundled schema according to the Validation section of [GRAPHQL]. A validation error fails closed with subcode INVALID_QUERY. Because the bundled SDL defines no executable directives (6.1 The schema is part of the policy bundle), the Directives Are Defined rule rejects every executable directive other than the built-in @skip and @include. The set of directives the validator accepts at executable locations MUST be exactly @skip and @include, whatever the validator library knows by default (for example @defer).
2. The walk starts at the root operation type of the selected operation, with an empty path.
3. For every field selection with name f on parent type P, the mapper emits a Field with parentType = P, field = f, path = parent path + [response key], alias when present, and on when the selection set that directly contains the field belongs to a fragment with a type condition. When the selection has a sub-selection, leaf = false and the walk continues with the unwrapped return type of P.f as the new parent type (Section 7.2). Otherwise leaf = true.
4. For an inline fragment ... on T { ... }, the mapper walks the sub-selection with parent type T. The fragment adds no Field and no path segment. Its direct children get on = "T".
5. For an inline fragment without a type condition, the mapper walks the sub-selection with the current parent type. Its children get no on.
6. For a fragment spread ...F, the mapper walks the selection set of fragment F with parent type equal to the type condition of F. The spread adds no Field and no path segment. Its direct children get on equal to the type condition of F. A fragment spread more than once produces its fields more than once, once per position.
7. The mapper emits one Field per selection. It MUST NOT merge selections that share a response key. After validation, two selections with the same response key in the same merged selection set have identical field names and arguments, except when their parent types are different object types ([GRAPHQL] Fields In Set Can Merge). Only that case yields two records with the same path and different args.
8. Directives @include and @skip: the mapper MUST emit the field regardless of the directive. A field that may be skipped still counts. This is the conservative choice. See 15.3 @skip and @include.
9. Introspection fields (__typename, __schema, __type): the mapper emits them like any other field. The policy engine drops __typename and the descendants of __schema and __type (8.2 Data fields).
10. Limits (5.7 Limits) are checked during the walk. The walk MUST stop at the first exceedance.

For every selection, args holds one entry per argument that has a value after the resolution below, keyed by the argument name. Each entry has value and origin. When no entry remains, args is absent.

Variable coercion. Before the walk, the mapper MUST coerce the supplied variables against the variable definitions of the selected operation as CoerceVariableValues in [GRAPHQL] describes: built-in scalars, enums, lists, input objects, and non-null wrappers are coerced; a coercion failure, a null for a non-null variable, or a missing non-null variable without default fails closed with subcode VARIABLE_ERROR. Values of custom scalars (for example BSN) are passed through as the JSON received; the mapper cannot know the source's coercion for them (13. Security Considerations).

Value. value is the argument value as the source executes it: the result of input coercion of the argument literal against the argument's type as CoerceArgumentValues and Input Coercion in [GRAPHQL] define, after variable resolution. This includes: enum values as strings; a single value coerced to a one-item list where the type is a list; input-object fields that are absent and have a declared default filled in with that default; null as null.

Variable resolution. The table applies to the coerced variable values. Rows 3 to 5 concern nullable variables without default; a non-null variable without default that is not supplied already failed coercion.

Argument-definition defaults. When an argument is not provided (not written, or resolved to "not provided" above) and the schema declares a default for it, the entry is added with the schema default and origin: "schema-default". This is what the source executes (CoerceArgumentValues in [GRAPHQL]). When an argument is not provided and has no schema default, there is no entry.

Origin. Every entry has origin. Entries whose value references one or more variables also have variables: the list of referenced variable names. Entries whose value contains input-object fields that input coercion filled from a schema default also have schemaDefaults: the list of paths to those fields inside value. Each path is an array, for example ["minimum"], or [0, "minimum"] for an input object inside a list.

There is no global argument map. Two selections of the same field with different arguments produce two records with different args.

path is the list of response keys from the operation root to the field. The response key is the alias when present, else the field name ([GRAPHQL] Response Key). Fragments add no segment. Example: ["a", "naam"] for a: persoon(bsn: "1") { naam }.

The field id is path joined with .. It is a display form for messages and logs. It is not unique: two records can share a path when they sit under different concrete types of one abstract parent (5.4 Validation and the walk.7) or when a fragment is spread twice into one selection set. Where a record must be identified exactly, the profile uses its index in fields[].

The mapper MUST enforce the following limits at the stage named. Exceeding any of them MUST fail closed with subcode LIMIT_EXCEEDED. The values are bundle settings; the defaults apply when the bundle does not set a value.

A deployment SHOULD set these below the corresponding limits of the source, so that the PDP rejects before the source does.

When any condition below holds, the mapper MUST set unverifiable to an object with code, subcode (when listed), and message, and MUST leave fields empty.

message is for the decision log. For INVALID_QUERY it MUST contain only the name of the failed validation rule and the source location; it MUST NOT contain schema-derived suggestions such as "Did you mean".

The conditions are checked in the order of 5.1 Input and 6.3 to 6.7: transport, body size, body shape, parse, no operation, validation, operation selection, variables, walk limits. The schema is needed from validation onward, so SCHEMA_UNAVAILABLE is reported only for a request that passed the earlier checks.

The policy engine MUST deny when unverifiable is not null, before it evaluates any rule (8.5 Aggregation).

The policy bundle MUST contain the GraphQL SDL the rules were written against. The SDL MUST NOT define executable directives (Section 6.4.1). The SDL MAY be a subset of the source's schema: types and fields the policies never cover can be left out, except as 6.2 Type resolution requires. A query that selects a field absent from the bundled SDL fails validation and is denied.

The mapper MUST load the SDL from the policy bundle or from a location the bundle points to. The mapper MUST NOT fetch the schema from the source at runtime and MUST NOT use GraphQL introspection. One evaluation MUST use one bundle version for the SDL, the rules, and the bundle settings. When the mapper runs outside the policy engine or loads the SDL from a location outside the bundle, the pinned digest of 6.3 Schema digest is REQUIRED.

The mapper resolves parent types from the SDL. For a field P.f with a sub-selection, the next parent type is the named type of P.f with list and non-null wrappers removed: [Bedrag!]! gives Bedrag.

For a field selected on an interface without a type condition, the parent type is the interface. On a union, only __typename can be selected without a type condition ([GRAPHQL] Field Selections), so no data field ever has a union as parent type. For a field inside ... on T, the parent type is T.

A binding on an interface field key (Inkomen.jaar) covers that field on every implementing type the source has, whenever the consumer selects the field without a type condition. The bundled SDL MUST contain every implementing type of every interface it contains, and every member of every union it contains. H3 (10. Enforcement Guarantees) requires the source to have exactly those types, so a new implementing type at the source fails the H3 check instead of opening access. A concrete-type key never restricts what an interface key allows: the consumer chooses the parent type by writing or omitting ... on T. A bundle SHOULD NOT combine an unconditional interface key with a conditional concrete-type key for the same field, and a bundle check SHOULD reject it. Rules for sensitive fields SHOULD use concrete-type keys only (13. Security Considerations).

The mapper MUST compute schema.digest as "sha256:" followed by the lowercase hexadecimal SHA-256 of the UTF-8 bytes of the SDL text it loaded, and MUST put it in the output (5.2 Output). The digest identifies the schema artifact in the bundle. It does not identify the source's schema: the bundled SDL may be a subset and byte-level differences (whitespace, comments, order) change the digest.

The policy bundle MAY pin an expected digest. When it does, the policy engine MUST deny with CONFIG_ERROR / SCHEMA_MISMATCH when schema.digest differs from the pinned value. The digest appears in the decision log, so every decision records the schema artifact it was made against.

The policy author owns the schema in the bundle, together with the rules. When the source adds or renames a field, the new field is absent from the bundled schema. A query that selects it fails validation and is denied. Access reopens only when the policy author updates the schema and the rules in one bundle. Drift is safe, not invisible.

Four kinds of drift are not visible from the query:

• the source changes the return type of a field that is in the bundled schema: the mapper resolves the old type and rules bind to the old key;
• the source adds an implementing type to an interface, or a member to a union: interface keys cover it (6.2 Type resolution);
• the source adds an argument to a field, or an input field to an input object type, that is in the bundled schema: the consumer cannot write it, but the source executes its default;
• the source adds or changes an argument or input-field default: the mapper resolves the bundled default (5.5 Arguments).

Guarantee H3 (10. Enforcement Guarantees) covers all four. It runs in two places: in the bundle pipeline before a bundle is deployed, and in the source pipeline before a schema change is deployed. The second check closes the time window between a source deployment and the next bundle check. In addition, a rule never allows a checked argument value that comes from a schema default (8.4 Per-field evaluation).

Because the schema travels with the bundle, the mapper belongs where the bundle lands: on the PDP side. A PEP-side mapper would need a second distribution channel for the schema.

Unchanged from the PEP. subject.id is the trust anchor: the PEP sets it from mTLS. Policies MUST base the caller identity on subject.id and MUST NOT base it on a header.

Unchanged from the PEP. action.properties.body keeps the raw body.

See 9. Decision and Error Transport.

A rule is one unit of policy with conditions. A binding connects a data field to zero or more rules. The binding MUST be part of the policy bundle and MUST be deployed through the PAP together with the rules. It MUST NOT depend on the schema the source serves at runtime.

This profile does not prescribe how the binding is written. Section 9.6 shows rule data that names field keys.

The engine MUST take resource.properties.graphql.fields[] and drop:

• records whose field is __typename;
• records whose parentType starts with __ (the children of __schema and __type).

The rest are the data fields. Root fields other than __typename are data fields. The root introspection fields __schema and __type are data fields with keys Query.__schema and Query.__type: introspection executes and returns the source's full schema, so it needs a rule like any other root edge.

When the set of data fields is empty, the decision is deny with code NO_DATA_FIELDS.

When resource.properties.graphql is absent, or its profile is not "ftv-graphql/0.1", the engine MUST deny with CONFIG_ERROR / MAPPER_OUTPUT_MISSING. This covers a mapper deployed as middleware that was bypassed.

Whatever the notation, the binding MUST meet these requirements.

1. Closed world. A data field that no rule binds decides deny, with a client-class per-field code (reference code NO_APPLICABLE_RULE).
2. Field key. The rules that bind to a record MUST be chosen by its field key parentType.field. The choice MAY also use leaf and whether args is present. It MUST NOT use alias, path, or on: the consumer chooses those.
3. Arguments. A record with args MUST be allowed only by a rule bound to its field key specifically. A rule bound through the parent type, or through any other group of fields, does not see the arguments.
4. Root fields. A root field, Query.__schema and Query.__type included, MUST be allowed only by a rule bound to its field key specifically. A rule bound through the root type would cover every entry point, also entry points added to the bundled SDL later.
5. Each selection. Every record is bound and evaluated on its own, with its own args. Two records with the same field key are two decisions.

For every data field, the engine evaluates each bound rule against the evaluation context:

A field decides allow when at least one bound rule evaluates to allow. A field decides deny when no bound rule evaluates to allow. Each deny carries a per-field code (9.2 Reason codes). When several bound rules deny with different codes, a server-class code wins; else the code of the first denying rule in bundle order.

A condition MUST read the arguments it checks from field.args, not from another record in fields. A condition MUST NOT grant access because of the presence or absence of another record: records can share a path (5.6 Path and field id), and a field under @skip is present in fields but may not execute. fields exists for cross-record constraints that only deny (for example: deny when two persoon selections carry different bsn values).

A rule condition that reads an argument the rule needs (for example field.args.jaren) and finds no entry MUST evaluate to deny (reference code CONDITION_FAILED), never to undefined. An undefined result is never an allow.

A rule condition that checks an argument value MUST evaluate to deny (reference code CONDITION_FAILED) when the value comes from a schema default, in whole (origin is schema-default) or in part (schemaDefaults is present). The source executes its own default, which can differ from the bundled one. A consumer that needs the value writes it in the query.

A rule that needs an attribute from a PIP and gets none evaluates to deny with PIP_UNAVAILABLE.

The engine MUST aggregate as follows.

if graphql output absent or wrong profile: decision = false, code = CONFIG_ERROR, subcode = MAPPER_OUTPUT_MISSING
else if pin set and schema not null and
        digest differs from pin:            decision = false, code = CONFIG_ERROR, subcode = SCHEMA_MISMATCH
else if unverifiable is not null:          decision = false, code = unverifiable.code, subcode = unverifiable.subcode
else if data_fields is empty:               decision = false, code = NO_DATA_FIELDS
else if any field denied with a
        server-class per-field code:        decision = false, code = that code
else if all data fields allow:              decision = true
else:                                       decision = false, code = FIELD_NOT_PERMITTED

The decision context lists every denied field with its per-field code (9.1 AuthZEN response).

Aggregation is AND. A query is allowed only when every data field is allowed. There are no partial results in this profile version. See 15.2 Partial results.

This section is informative. It shows one rule model that meets 8.1 Rules and binding to 9.5. The test vectors of Appendix A use it for their reference decisions.

Rule shape. A rule is data with four parts:

{
  "rule_id": "r-0001",
  "covers_types":  ["Persoon", "Inkomen", "LoonInkomen", "Bedrag"],
  "covers_fields": ["Query.persoon",
                    "Persoon.inkomens",
                    "Inkomen.bedrag",
                    "LoonInkomen.bedrag"],
  "conditions": { "...": "engine-specific" }
}

In this model the rule is the catalog: there is no separate field-to-rule table. Interface fields and concrete-type fields are separate keys. A rule that must cover jaar on the interface and on the concrete type lists both Inkomen.jaar and LoonInkomen.jaar.

Root fields are covered like any other edge or leaf: Query.persoon is a field key. The rule that covers a root field is the natural place for conditions on its arguments, for example that the subject holds consent for the person bsn identifies.

Binding. For every data field with key k = parentType + "." + field:

1. If any rule has k in covers_fields, those rules bind. Stop.
2. Else, if the field is a leaf (leaf = true), the record has no args, and parentType is not a root operation type, the rules with parentType in covers_types bind. Stop.
3. Else no rule binds. The field decides deny with per-field code NO_APPLICABLE_RULE.

Consequences:

• A leaf inherits from its parent type only when no field-level rule names it. A field-level rule overrides the type-level rule.
• A leaf with arguments never inherits (8.3 Binding requirements, item 3).
• A root field binds by field key only (8.3 Binding requirements, item 4).
• An edge (a field with sub-selection) never inherits. Without a field key it denies with NO_APPLICABLE_RULE. 8.3 Binding requirements does not require this; it is a design choice of the reference model, so that every reachable object type is an explicit decision of the policy author.
• Two selections of the same field under different aliases bind to the same rules and are evaluated separately, each with its own args.

On allow:

{ "decision": true }

On deny, the PDP MUST return the decision context below. It follows the free-form context of [AUTHZEN-NLGOV]: reason_admin and reason_user carry human-readable text keyed by language tag, and graphql carries the structured detail this profile defines.

{
  "decision": false,
  "context": {
    "reason_admin": { "en": "2 fields denied: persoon.inkomens.werkgever (LoonInkomen.werkgever): NO_APPLICABLE_RULE; persoon.inkomens.werkgever.naam (Werkgever.naam): NO_APPLICABLE_RULE" },
    "reason_user":  { "en": "Field not permitted: persoon.inkomens.werkgever" },
    "graphql": {
      "client": {
        "code": "FIELD_NOT_PERMITTED",
        "field_id": "persoon.inkomens.werkgever"
      },
      "admin": {
        "code": "FIELD_NOT_PERMITTED",
        "schema_digest": "sha256:9f2c…",
        "denied_fields": [
          { "index": 6,
            "path": ["persoon", "inkomens", "werkgever"],
            "key": "LoonInkomen.werkgever",
            "code": "NO_APPLICABLE_RULE",
            "evaluated": [] },
          { "index": 7,
            "path": ["persoon", "inkomens", "werkgever", "naam"],
            "key": "Werkgever.naam",
            "code": "NO_APPLICABLE_RULE",
            "evaluated": [] }
        ]
      }
    }
  }
}

reason_user.en MUST NOT contain more than graphql.client reveals. Some PEPs return reason_admin to the consumer as well. For that reason reason_admin.en MUST NOT contain server-class codes or subcodes, rule ids, schema digests, or PIP detail, and MUST apply the same hiding settings as graphql.client (13. Security Considerations). That detail is in graphql.admin and in the decision log (9.4 Decision log).

A bundle MAY use other client-class per-field codes than the reference codes. They aggregate to FIELD_NOT_PERMITTED. The top-level codes and the classes are normative: the PEP and the consumer depend on them.

Server-class codes MUST NOT appear in graphql.client or reason_user. The consumer gets ACCESS_DENIED and the trace id (traceparent, else X-Request-ID).

On deny, the PEP MUST NOT forward the request to the source. It MUST return HTTP 403 or 401; 403 is RECOMMENDED, because the caller is authenticated and the request is refused ([RFC9110]). The PEP SHOULD return a body shaped like a GraphQL error response, built from graphql.client and reason_user. A PEP with its own error format MAY use that format instead:

{
  "errors": [
    {
      "message": "Field not permitted: persoon.inkomens.werkgever",
      "extensions": {
        "code": "FIELD_NOT_PERMITTED",
        "field_id": "persoon.inkomens.werkgever",
        "traceparent": "00-4bf92f3577b34da6a3ce929d0e0e4736-00f067aa0ba902b7-01"
      }
    }
  ]
}

When the PEP returns this GraphQL-shaped body, the response Content-Type MUST be application/graphql-response+json when the request Accept header allows it, else application/json.

Under [GRAPHQL-HTTP] a server that receives a well-formed request returns a GraphQL result; a 403 without a data entry is the shape of a request error result. The PEP is a proxy that never executes the document, so it returns a request error result with the status that [RFC9110] defines for a refused request. The consumer can distinguish "denied" (401 or 403, no data) from "executed with errors" (200, data present).

The PEP MUST NOT copy graphql.admin to the consumer. It SHOULD NOT copy reason_admin; 9.1 AuthZEN response limits its content for a PEP that does.

The PDP MUST log, per evaluation: traceparent when present, else X-Request-ID, subject.id, the enriched request, the decision, the full decision context of Section 10.1, and the bundle version. The log entry is a valid AuthZEN request plus response, so it can be replayed against a policy bundle.

This draft puts the field list in resource.properties.graphql (the fields are the thing accessed). The alternative is context.graphql (the list is derived by the PDP and never supplied by the caller). The workgroup decides.

All-or-nothing is a feature for data minimization and fits the single-decision hook. A future version could return the permitted fields and list the denied ones in GraphQL errors[]. That needs a response filter after the source, and touches H1.

Conservative today. Honoring them moves directive-argument evaluation into the mapper.

Denied today. A mutation asks a different question (which change with which input), and its root fields execute in sequence with side effects. A future version needs its own walk rules and rule model.

Outside this profile. The workgroup decides whether and where to specify it.

In this draft, one AuthZEN evaluation carries the whole field list, and the policy engine loops over it (8. The Policy Model). Engines that cannot loop over a list, such as Cedar and OpenFGA, need engine-specific code in the PDP. That code splits the list into one check per field and combines the results.

A future version can move that split into the mapper. The PEP still sends one evaluation and gets one decision. The mapper then:

1. makes one evaluation per data field, with the field record in the context;
2. sends the evaluations to the evaluations endpoint of [AUTHZEN] on the PDP, with the evaluations_semantic option deny_on_first_deny or execute_all;
3. combines the results as 8.5 Aggregation describes. A missing or malformed result is a deny.

A batch that the PEP builds is not an alternative. The PEP then needs a GraphQL parser and the schema (3.2 Why not solve it in the PEP), and the PEP combines the results. With a fan-out by the mapper, the field list comes from the component that validated the query against the bundled schema. The aggregation stays on the PDP side, and the PEP stays a standard component.

Points to decide:

• The aggregation of 8.5 Aggregation moves from the policy engine to the mapper. The mapper still knows no rules, but it decides how the per-field results make one decision.
• One evaluation per field needs its own information model: resource.type, resource.id (the field key), and the context.
• Rules that only deny over several records (8.4 Per-field evaluation) need the full field list in the context of every evaluation. Otherwise the profile drops these rules.
• With deny_on_first_deny, the decision log does not list every denied field (9.1 AuthZEN response). execute_all gives the full list, at a higher cost.
• The mapper must run on the PDP side. A mapper on the PEP side is a custom PEP (3.2 Why not solve it in the PEP).

The record shape of 5.2 Output is self-contained, so a fan-out needs no change to the records.

Rules list both the interface key and each concrete-type key when they want both. A future version could let the engine expand interface keys from the schema, with the drift consequence of 6.2 Type resolution made explicit.

Query.__schema and Query.__type need a rule like any root field; a query with only __typename denies with NO_DATA_FIELDS. A bundle-level switch for tooling access could replace the rule.

A level without a schema (rules bind on path only, no validation, no types) would let sources without a published schema start. This draft requires the schema.

The bundle could declare a pattern per custom scalar that the mapper enforces, closing the lenient-coercion gap of 13. Security Considerations.

Who maintains the reference mapper and the conformance vectors.