The OpenID Foundation conformance suite tests a Policy Decision Point (PDP) Server that implements the AuthZEN Authorization API 1.0. The suite acts as the Policy Enforcement Point (PEP): it calls your PDP’s API endpoints and checks the responses against the specification and the AuthZEN certification profile.

References

• AuthZEN Authorization API 1.0
• AuthZEN Authorization API 1.0 Certification Scenario (the certification profile)
• Conformance suite

Getting started

1. Go to https://www.certification.openid.net and log in with your Google or GitLab account.
2. Click Create a new test plan.
3. Choose one of the AuthZEN test plans listed under Test an AuthZEN PDP server (see Available test plans).
4. Select the variants that describe your PDP (see Test plan variants).
5. Fill in the configuration (see Configuring the test).
6. Click Create Test Plan and continue to Running the tests.

Prepare your PDP: the certification fixture

The certification profile (section 4) defines a small fixture of subjects, resources and actions that your PDP must load before testing. The suite only validates decision values for the requests the fixture defines; every other request is checked for structure and status codes only.

Decisions the suite validates (certification profile section 4.4)

Search results the suite expects (certification profile section 4.5) include, for example: users who can read record-1 include alice and bob; records alice can read include record-1; actions alice can perform on record-1 include read and write. The Properties search scenarios add the admin and archived-record cases. Your PDP may return additional entities beyond the fixture.

Available test plans

Plans 1 to 5 each test one AuthZEN API endpoint, and plan 6 tests the PDP metadata. Run every plan that matches what your PDP implements.

Not part of the certification program

Certification profile names

When you publish results for certification, each plan reports the profile it certifies. For plans 1 to 5 it depends on the AuthZEN Specification Support variant:

The Discovery plan reports AuthZEN Discovery.

Test plan variants

Plans 1 to 5 each have three dropdowns. Create a separate plan for each combination your PDP supports. The Discovery plan has none.

PDP Authentication Type (pdp_auth_type)

How the suite authenticates to your PDP. The AuthZEN specification leaves PEP authentication out of scope (section 11.2) and the certification profile does not require it, so choose what your deployment uses. If your PDP supports several methods, test each one in its own plan.

With client_secret_basic and api_key, each plan for an API endpoint (plans 1 to 5) also checks that the PDP returns HTTP 401 for a request with missing credentials and for one with invalid credentials (spec section 11.3).

PDP server metadata location (pdp_server_metadata)

AuthZEN Specification Support (authzen_support)

Configuring the test

The configuration form shows only the fields that apply to the plan and variants you selected. You can fill in the form or edit the JSON directly.

Test information

AuthZEN (the pdp object)

<PDP Identifier>/access/v1/evaluation
<PDP Identifier>/access/v1/evaluations
<PDP Identifier>/access/v1/search/subject
<PDP Identifier>/access/v1/search/resource
<PDP Identifier>/access/v1/search/action

Client credentials (pdp_auth_type=client_secret_basic)

API key (pdp_auth_type=api_key)

Mutual TLS (pdp_auth_type=mtls)

The certificate is presented in the TLS handshake of every API call. The missing-credentials and invalid-credentials 401 tests do not run with mtls.

Example configurations

Static metadata, no authentication:

{
    "alias": "my-company",
    "description": "Example PDP, static endpoints",
    "pdp": {
        "policy_decision_point": "https://pdp.example.com",
        "access_evaluation_endpoint": "https://pdp.example.com/access/v1/evaluation",
        "access_evaluations_endpoint": "https://pdp.example.com/access/v1/evaluations",
        "search_subject_endpoint": "https://pdp.example.com/access/v1/search/subject",
        "search_resource_endpoint": "https://pdp.example.com/access/v1/search/resource",
        "search_action_endpoint": "https://pdp.example.com/access/v1/search/action"
    }
}

Discovery plan, with signed metadata:

{
    "alias": "my-company",
    "description": "Example PDP, metadata",
    "pdp": {
        "policy_decision_point": "https://pdp.example.com",
        "jwks": {
            "keys": [
                { "kty": "EC", "crv": "P-256", "kid": "metadata-key",
                  "x": "...", "y": "..." }
            ]
        }
    }
}

Discovery variant on an API plan, with signed metadata and an API key:

{
    "alias": "my-company",
    "description": "Example PDP, discovery",
    "pdp": {
        "policy_decision_point": "https://pdp.example.com",
        "jwks": {
            "keys": [
                { "kty": "EC", "crv": "P-256", "kid": "metadata-key",
                  "x": "...", "y": "..." }
            ]
        }
    },
    "client": {
        "api_key": "test-api-key"
    }
}

Running the tests

In the test plan overview you are presented with a list of individual tests. Click Run Test to execute each one. Each test calls your PDP and finishes on its own; none of them needs any action in a browser.

Status codes for rejected requests

Several tests send a request your PDP should reject. These statuses follow the AuthZEN working group’s guidance:

Run every test in the plan. For certification, all tests must have finished without failures.

Publishing the results

In the test plan overview, click Publish everything to make the results visible to anyone, not just logged-in users. Use Publish summary if your configuration contains secrets (client_secret, API key, mTLS key, or an HMAC signing key) that must stay private.

To apply for certification, follow the OpenID Foundation certification process at https://openid.net/certification/ with the published results and the certification profile name for each plan.

Getting help

Do not hesitate to register issues in the conformance suite project if you see unexpected or incorrect behaviour. You can also contact certification@oidf.org.