Support for RFC 8707 OAuth2 Resource Indicators #35743

thomasdarimont · 2024-12-09T20:14:49Z

thomasdarimont
Dec 9, 2024
Collaborator

This discussion aims to arrive at a design proposal to properly support RFC 8707 Resource Indicators for OAuth 2.0 as a feature for Keycloak.
Resource Indicators allow the restriction of Access Tokens for Resource Servers to specific resources, enabling fine-grained control over an access token's capability.

A part of the functionality enabled by the Resource Indicators could also be solved with scopes, however the audience aud claim is be used to express the systems whereas the scope claim is often used to express the capabilities / permissions associated with a token.

Supporting Resource Indicators in Keycloak includes the following requirements:

R1) Concept and mechanism for validating allowed "resource indicators" for clients
R2) The Authorization endpoint (Auth Code Flow) must be able to process resource parameters
R3) The token endpoint must be able to process resource parameters
R4) The aud claim must be updated according to the requested resource
R5) Allow to query a client by a resource indicator value
R6) Clients should be able to opt-in to "resource indicators" support

Related issues:

Considerations for R1)
According to RFC 8707 Section 2, the value of the resource parameter must be an absolute URI, however RFC 8707 Section 2 also later says:
'...the parameter value identifies a resource to which the client is requesting access. The parameter can carry the location of a protected resource, typically as an HTTPS URL or a more abstract identifier....', which might also allow custom schemes, e.g., acme://foo.
Since the resource indicator support is about managing the audience aud claim, we might need to allow to use a client_id as resource indicators. This eases using the resource indicator support in existing Keycloak ecosystems, without having to assign resource indicators to resource servers / clients managed by Keycloak.

Currently, Keycloak does not support configuring allowed resource URIs for a registered client, which can act as an OAuth 2.0 resource server.

However, support for restricting the resource identifiers is crucial to supporting the resource identifiers feature.
Some requirements for specifying resource identifiers:

Must support to configure a set of allowed resource identifiers per client
Must allow URI values as resource identifiers

Considerations for R2)
An authorization request might contain one or more resource parameters. Currently, Keycloak does not support repeated request parameters; therefore, the parameter processing in services/src/main/java/org/keycloak/protocol/oidc/endpoints/request/AuthzEndpointRequestParser.java and related code must be updated to allow multiple resource parameters.
The validation of the authorization request parameters must be extended to include a check for the requested resource parameters against the set of allowed resource identifiers.

The initially requested resource values must be available for later processing by the token endpoint handling. One way to solve this is to store the requested resource identifiers in the client session.

Considerations for R3)
The token endpoint must be extended to support the resource parameter in the token request. Additionally, it must support validating the requested resource(s) against the resources previously associated with the authorization code grant stored in the client session.

Considerations for R4)
To adjust the audience aud claim in the access token based on the requested resource, we can use a custom OIDC protocol mapper. A suitable name for the protocol mapper might be Resource Identifier Mapper.

Usage example

For example, we use a photoz SaaS application comprising multiple services that expose various parts of user data.
We now imagine that we have a photoz client configured in Keycloak
that allows the following resource identifiers, which represent the internal resource servers / or logical resources:

https://api.acme.com/accounts
https://api.acme.com/photos
https://api.acme.com/galleries
https://api.acme.com/invoices
https://api.acme.com/payments
https://api.acme.com/orders

Note that this denotes an abstract list of resource types. Resources could also refer to more concrete resources, e.g., https://api.acme.com/photos/42.

Authorization request

We want our application to have access to photos and accounts of the photoz service.
The following authorization request will register the allowed resource identifiers https://api.acme.com/photos and https://api.acme.com/galleries with the client session created after successful end-user authentication.

$ISSUER/protocol/openid-connect/auth
?client_id=photoz
&redirect_uri=...
&state=...
&response_mode=fragment
&response_type=code
&scope=openid
&nonce=...
&code_challenge=...
&code_challenge_method=S256
&resource=https://api.acme.com/photos
&resource=https://api.acme.com/galleries

Note that this authorization request determines which resources a client can request access to in subsequent token requests. In this example, the application can only request access to photos and galleries but no other resources.

Request Token for accessing photos

The application wants an access token that supports accessing the photos resource. To do this, it sends the following token request:

POST $ISSUER/protocol/openid-connect/token
grant_type=authorization_code
&client_id=photoz
&code=...
&resource=https://api.acme.com/photos
...

Access Token for accessing photos

The returned access token now contains the following aud audience claim:

{
 ...
 aud: ['https://api.acme.com/photos']
 ...
}

Note that due to checks in the photos application backend, this Token does not allow access to other resources like gallery, etc.

Request Access Token for accessing photos & galleries

Now, the application also wants to access information about registered galleries.
This requires us to upgrade the audience claim, by adding https://api.acme.com/galleries.
To do this, it sends the following token refresh request:

POST $ISSUER/protocol/openid-connect/token
Authorization: ...
Content-Type: application/x-www-form-urlencoded
grant_type=refresh_token
&refresh_token=...
&resource=https://api.acme.com/photos
&resource=https://api.acme.com/galleries
...

Access Token for accessing photos and galleries

The returned access token now contains the following aud audience claim:

{
 ...
 aud: [
 'https://api.acme.com/photos',
 'https://api.acme.com/galleries'
 ]
 ...
}

Note that this Token now allows access to photos and gallery resources.
It is also possible to obtain an access token that can only access galleries but no photos:

Request Access Token for accessing galleries only

Now, the application also wants to downgrade the token access to only access galleries.
This requires us to downgrade the audience claim, by removing https://api.acme.com/photos.
To do this, it sends the following token refresh request:

POST $ISSUER/protocol/openid-connect/token
Authorization: ...
Content-Type: application/x-www-form-urlencoded
grant_type=refresh_token
&refresh_token=...
&resource=https://api.acme.com/galleries
...

Access Token for accessing photos and galleries

The returned access token now contains the following aud audience claim:

{
 ...
 aud: [
 'https://api.acme.com/galleries'
 ]
 ...
}

Note that this Token now allows access to photos and gallery resources.
It is also possible to obtain an access token that can only access galleries but no photos:

Attempt to Access Token for other resources

If the application attempts to access other resources, which were not part of the initial authorization request, this request will fail, because the requested resource https://api.acme.com/invoices was not part of the initial request.

POST $ISSUER/protocol/openid-connect/token
Authorization: ...
Content-Type: application/x-www-form-urlencoded
grant_type=refresh_token
&refresh_token=...
&resource=https://api.acme.com/invoices
...

Access Token Error Response

{"error":"invalid_grant","error_description":"Invalid resource"}

Implementation options

O1) Using a Protocol Mapper to define allowed clients to solve R1

Idea: Use the configuration of the Resource Identifier Mapper OIDC protocol mapper that is necessary to adjust the audience based on the requested resources to also store the list of allowed resource identifiers per client.

Example Resource Identifier Mapper configuration with Resource Identifiers

Pros:

A protocol mapper offers a standard functionality to declare list of strings (resource identifiers)
A protocol mapper can be specific to a client or shared between clients, and this allows the declare resource identifiers for a client or a set of clients.
Resource identifier definitions can be reused/shared across multiple clients.
Adding a "Resource Identifier Mapper" can be a natural way to enable support for resource identifier handling for a client: If the mapper is configured for a client, then the resource parameter handling is enabled. If the mapper is not configured for a client, then requests with a resource parameter will be rejected.
No database changes are required because the allowed resource identifier values are stored in the protocol mapper configuration.
Mechanism for import / export of resource identifiers part of realm import / export.
"Self-Contained" configuration - only one place to configure the feature
Cons:
Using a protocol mapper to enable functionality for a client is a new concept for Keycloak that is unfamiliar to users.
Resource Identifier Mapper configuration is more complex as we need to define the list of identifiers
Users could accidentally configure multiple "Resource Identifier Mapper" protocol mappers with conflicting configurations.
Resource identifier checks rely on the "Resource Identifier Mapper" configuration, which is an implementation detail.
No easy way to find a client based on a resource identifier (as it is hidden in the protocol mapper configuration)

O2) Add direct support for configuring resource identifiers for clients to solve R1

Idea: Users can specify allowed resource identifiers directly on the client configuration. This could be implemented similarly to how allowed redirect URIs are configured, e.g., using a resource_identifiers table similar to how the "Allowed redirect URIs" are stored in the redirect_uris table. However, for better database usage, we should add a realm column.
Note that this approach would include changes to the admin UI to allow configuring the set of permitted resource identifiers.

Example for custom client configuration with additional resource identifiers list:

Pros:

A more natural way to support resource identifiers per client
Resource Identifier Mapper configuration can be simple. If present, the aud claim is adjusted based on the requested resources.
Resource identifiers could be configured with dynamic client registration.
Easy way to find a client based on a resource identifier with a simple (and fast) database query
Mechanism import / export of resource identifiers part of client import / export.

Cons:

More work to implement as it requires updates to client model, a new database table, and admin UI work
Additional database query necessary when loading a client
Not all clients might want to configure resource identifiers, but the configureationoption would always be present for a client
Resource identifier definitions cannot be reused/shared across multiple clients.

O3) Leverage resource definitions from authorization services to solve R1

Idea: Use the existing authorization services to express client specific resource identifiers.
We could use a custom resource type like: urn:keycloak:resource-identifier to declare a resource identifier. The actual resource identifier can be expressed via the resource identifier URI(s). Support for finding a client by a resource identifier could be implemented on top of resource lookup against the authorization services.

Definition of a photo resource identifier:

Overview of allowed resource identifiers:

Pros:

Uses existing way to express resource identifier definitions
No Admin UI changes required
Allows to associate multple resource identifiers with a logical resource

Cons:

Require to enable and use authorization services which is currently in preview
No easy way to share resource identifiers across multiple clients (need to repeat configuration)
import / export mechanism of resource identifiers needs to be added

O4) Add new dedicated SPI to validate allowed resource indicators R1, R5

Idea: Introduce a OAuth2ResourceIndicatorResolver SPI that allows users to implement their own
Resource Indicator validation mechanisms. In order to allow client specific behaviour uses could use a client attribute to select
a specific OAuth2ResourceIndicatorResolver implementation.
This spi could also support to lookup a client by a resource indicator.

/**
 * Provider to customize OAuth2 Resource Indicators resolving.
 *
 * @link <a href="https://www.rfc-editor.org/rfc/rfc8707">RFC 8707 OAuth2 Resource Indicators</a>
 */
public interface OAuth2ResourceIndicatorResolver extends Provider {

    /**
     * Returns a client associated with the given {@code resourceIndicator} or {@literal null} if no client could be found.
     * @param resourceIndicator
     * @return client model
     */
    ClientModel findClientByResourceIndicator(String resourceIndicator);

    /**
     * Filters the given resource indicators to the supported resource indicators by the given {@link ClientModel client}.
     *
     * @param client client to find the resource indicators
     * @param resourceIndicatorCandidates resource indicators to check
     *
     * @return Set of the resource indicators that are supported by the given client.
     */
    Set<String> narrowResourceIndicators(ClientModel client, Set<String> resourceIndicatorCandidates);

    @Override
    default void close() {
    }
}

Pros:

Allows users to implement their own resource indicator validators
No Admin UI changes required initially, later implementations can provide more customization
Can serve as the foundation to implement support for validating resource indicators from various sources

Cons:

Requires the user to write custom code
Currently no way to configure resource indicators via admin UI

O5) Use a Validator to to check for allowed resource indicators R1

Idea: Use a org.keycloak.validate.Validator for resource indicators to check if given resource indicator is allowed for a client.
In order to allow client specific behaviour uses could use a client attribute to select a specific Validator implementation.

Pros:

Allows users to implement their own resource indicator validators
Uses an existing SPI
No Admin UI changes required, later implementations can provide more customization
Can serve as the foundation to implement support for validating resource indicators from various sources

Cons:

Requires the user to write custom code

Existing implementation proposals

Initial (but incomplete) exploration of Resource Parameter handling resource request parameter and audience in access token #13622 (closed)
Implementation with Authorization Services and Resources + Resource Indicator SPI Add support for RFC 8707 OAuth2 Resource Indicators (#14355) #35711 (draft)

What do you think about adding Resource Server support? Feedback and remarks are very welcome :)

cgeorgilakis · 2024-12-20T14:38:19Z

cgeorgilakis
Dec 20, 2024

I am the contributor of resource request parameter and audience in access token PR.

Thanks @thomasdarimont for your work and detail post.
We agree that Keycloak must support resource indicators.

By the way, the 10BC8 original issue is wrong. Keycloak correctly support audience request parameter only for Token Exchange (most commonly used than resource for Token Exchange. Based on 2.1 of OAuth 2.0 Token Exchange, both audience and resource should be possible. It is complex. We may leave it out of first implementation. What will be done for token exchange with resource and audience based on your PR @thomasdarimont ? Unfortunately, @stianst has closed my more detailed issue.

@mposolda has proposed 'use the approach based on protocol mapper'. So, your PR approach. We like that you have added also URI checks. Although we do not support it now, it is nice to have it. The most important for us is supporting Resource Indicators. Way is less important. We propose continuing reviewing your PR.

PS. JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens mentions aud as required parameter in access token. We have proposed also Keycloak supporting this with an optional default value (no migration needed) if aud does not exist.

0 replies

thomasdarimont · 2025-03-05T12:24:52Z

thomasdarimont
Mar 5, 2025
Collaborator Author

New use case:
When refreshing the token without specifying the resource parameter, we should reuse the initially provided resource indicators instead if emitting an empty aud claim.

0 replies

thomasdarimont · 2025-03-06T20:09:16Z

thomasdarimont
Mar 6, 2025
Collaborator Author

FYI the way to configure allowed resource indicators via the authorization services resources is similar to what Ping Federate offers:
https://docs.pingidentity.com/pingfederate/latest/administrators_reference_guide/help_beareraccesstokenmgmtplugintasklet_atmselectionsettingsstate.html

0 replies

tnorimat · 2025-06-19T03:57:24Z

tnorimat
Jun 19, 2025
Collaborator

@thomasdarimont
Hello, it seems that the Version 2025-06-18 of MCP specification states that an MCP client need to comply with RFC 8707. Therefore, this might be a prausible usecase of RFC 8707 if we use keycloak as an autorization server acompanying with an MCP server

Also, in section 2.5.1.1 Canonical Server URI, it states that

MCP clients MUST send this parameter regardless of whether authorization servers support it.

which might means that supporting RFC 8707 by an Authorization Server is not mandatory.

What do you think about that?

3 replies

thomasdarimont Jun 19, 2025
Collaborator Author

Thanks for bringing this up. I think this is indeed a good indicator that RFC 8707 support could be benefitional. Does currently happen if a client sends a resource parameter with the authorization / token request?

The main challenge of Resource Indicator support is to find a way to declare which resource indicators are allowed for a given resource server. In my PR I currently use the authroization services for this. However, I can image, that in many cases one resource-indicator per resource server might be enough for some use-cases. In this case it might help if we could just use the root-url of a client definition for a resource server (with all flows disabled) as the resource-indicator. In this simple case we won't need to configure additonal URLs via the authorization server.

Another option would be to fetch the RFC9728 metadata of a resource server and extrect the resource indicator from the "resource" attribute in the "OAuth 2.0 Protected Resource Metadata".

pksorensen Aug 4, 2025

I have and are working on some remote mcp servers and decided to use keycloak as my authorization server. got things working and can show examples if anyone needs - however i think this is the missing part right now as i on the resource server need to disable the audience validation until we figure out how to map the resource param of authorize/token requests into the audience token.

achetronic Aug 5, 2025

For others out there looking for the same. Got the things working by forcing the value of 'aud' field for specific custom scope. This way, you can enable some scopes by default for some clients related to APIs checking specific values :)

achetronic · 2025-07-14T14:22:45Z

achetronic
Jul 14, 2025

Hello there! :) what is the status of this? @thomasdarimont

2 replies

thomasdarimont Jul 14, 2025
Collaborator Author

I'm currently waiting for additional feedback on the following PR #35711

achetronic Jul 15, 2025

I have read the discussion. IMHO i don't feel the use of mappers as an abuse at all, but may be i don't have the entire scope in the project to have a really good opinion. I think I have to wait for others to give their own :)

thomasdarimont · 2025-09-10T07:36:25Z

thomasdarimont
Sep 10, 2025
Collaborator Author

The latest 2025-06-18 MCP authorization specification requires the use of OAuth2 Resource Indicators.

From the Note about Resource Indicators from Quarkus MCP OIDC Client blog post.

0 replies

stianst · 2026-03-03T04:36:27Z

stianst
Mar 3, 2026
Maintainer

I have an alternative proposal for resource indicators that is aiming to be more aligned with existing mechanisms for audience scoped tokens in Keycloak:

Resource indicator support could be implemented many different ways in Keycloak; in fact there are at least 3 pull requests already:

resource request parameter and audience in access token #13622 an older pull request that adds support for resource parameters, which are then added directly to the audience claim in the token manager. In this PR there is no mechanism to configure what resource parameter values should be permitted for a specific client; with the exception of a default resource indicator for all clients within a realm
MCP requirement - Audience Mapper and Checker referring RFC 8707 resource parameter #45739 the most recent pull request that uses a protocol mapper to add all resource parameter values to the audience claim; with the addition of client policies to allow configure permitted resource parameter values
Add support for RFC 8707 OAuth2 Resource Indicators (#14355) #35711 adds support for multiple resource parameters a mapper to add resource parameter values to audience claim; and in addition uses authorization services configure permitted resource parameter values

One challenge with the above pull requests is not aligning well with how audience scopes tokens can already be issued by Keycloak today.

Keycloak supports two mechanisms currently to audience scope tokens:

Client scopes can be associated with one or more audience values
- Audience resolve mapper will include any client for which the requesting client has a scope on at least one client role
- Audience mapper adds a specific client as the audience, or can also be used to add a custom audience in any format
Token exchange su 10BC8 pports aud query parameter by filtering the aud claim to only include requested audiences

Taking the current support for audience scoped tokens in Keycloak today the ideal would be to introduce resource indicators in a similar fashion.

At a very high-level this proposal introduces two things:

Support resource parameter(s) in token requests
Post-processing of aud claim to match requested resources (audiences)

This effectively leaves client scopes and protocol mappers unchanged and makes behaviour consistent with token exchange.

Starting very simple if we support a single resource parameter in the request that allows specifying the target client with resource=urn:client:myservice this is the equivalent of as a token exchange request with aud=myservice.

In this case we will simply filter the values of the aud claim to only include myservice. Exactly the same as what happens in token exchange.

Evolving on the above we want to support resource=https://myservice now we need a mapping between https://myservice and myservice. This can be achieved by adding a Resource URI option to the myservice client. Now when processing the audience values we include any resource that matches the resource parameters by client-id or has a matching resource URI.

Supporting multiple resource parameters in a request follows the same pattern as token exchange; when processing the audience values we simply check if there is a resource parameter that matches, and include all audience values that have a matching resource parameter.

The next question is the format of the value in the aud claim. When resource indicators are used the expectation is the aud claim includes the audience by URL, and not by client-id. For now we simply make this configurable on the client itself by introducing a capability for clients enabling or disabling resource indicators as well as considering whether or not the targeting client has a resource URI configured or not.

The full implementation would be:

Add an experimental resource-indicators feature
Add support for resource parameter to authorization and token requests
Add processing of tokens based on resource parameters in token manager

Processing of tokens in token manager would do the following:

If resource parameter(s) are included; filter aud values to only include values where
1. urn:client:<aud value> matches a resource parameter, or
2. Client with client_id=<aud value> has a Resource URI that matches a resource parameter
If any resource parameter(s) did not match an aud value return invalid_target
Mapping audience values to Resource URIs
1. For all audience values if there is a client_id=<aud value> and the client has a Resource URI configured the audience value (client_id) is replaced with the configured Resource URI.

Making things a little bit more complicated we want to support multiple Resource URIs per client. Initially we will support a wild-card approach, where a client can have a resource URI of https://myservice/*

If the client requests https://myservice/mytenant the above example would match; and we would now use https://myservice/mytenant in the aud claim.

A benefit to this approach compared to other proposals is flexibility in terms of clients can leverage multiple mechanisms for audience scoping tokens while all result in the same behaviour and does not require additional configuration through extra protocol mappers, etc.

As a follow-up later on when we introduce more formal linking of clients and services; as well as services being able to advertise the format of tokens they expect; we can then allow the client to select what audience included using different mechanisms (scope, aud, or resource parameters), while at the same time allow services to decide what value(s) they require in the aud claim. For example a client may request scope=theservice, which then translates into aud=[https://theservice] in the token.

Proposed milestones

We’ll want to break the implementation of resource indicators into multiple parts aka milestones, rather than deliver it all in a single pull request.

Milestone 1 - Support resource=urn:client:<client-id>

This milestone aims to be the initial wiring of supporting resource indicators and we will only support the simplest case of a resource indicator that matches a client by client-id.

In this milestone we know that resource parameters should behave exactly like audience parameters in token exchange.

Milestone 2 - Support URLs as resource values

Add support to configure a Resource URL for a client; which then allows a client to use resource parameter values matching the resource URL of a client included in the audiences of the token.

Milestone 3 - Support multiple resource parameters

Update authorization and token request handling to support multi-valued parameters.

Milestone 4 - Support multiple Resource URIs per-client

Add support to configure more than a single Resource URI for a client; and/or support sub-resources (from the wildcard example earlier).

Milestone 5 - Add support for resource parameters to token exchange

Support both aud and resource parameters in token exchange, including a combination of both at the same time.

0 replies

stianst · 2026-03-03T04:38:05Z

stianst
Mar 3, 2026
Maintainer

The issue for resource indicators has been updated with more details:
#14355

0 replies

stianst · 2026-03-03T07:47:26Z

stianst
Mar 3, 2026
Maintainer

Very rough PoC for the above proposal: #46763

0 replies

trixpan · 2026-05-20T07:58:51Z

trixpan
May 20, 2026

@stianst given the severe changes caused by #49113 this should be fixed soon rather than later.

At the moment, unless the workaround is put in place, people will have to token exchange just to get the right audience to use introspection endpoint

0 replies

Support for RFC 8707 OAuth2 Resource Indicators #35743

Uh oh!

Uh oh!

thomasdarimont Dec 9, 2024 Collaborator

Usage example

Authorization request

Request Token for accessing photos

Access Token for accessing photos

Request Access Token for accessing photos & galleries

Access Token for accessing photos and galleries

Request Access Token for accessing galleries only

Access Token for accessing photos and galleries

Attempt to Access Token for other resources

Access Token Error Response

Implementation options

O1) Using a Protocol Mapper to define allowed clients to solve R1

O2) Add direct support for configuring resource identifiers for clients to solve R1

O3) Leverage resource definitions from authorization services to solve R1

O4) Add new dedicated SPI to validate allowed resource indicators R1, R5

O5) Use a Validator to to check for allowed resource indicators R1

Existing implementation proposals

Replies: 10 comments · 5 replies

Uh oh!

cgeorgilakis Dec 20, 2024

Uh oh!

thomasdarimont Mar 5, 2025 Collaborator Author

Uh oh!

thomasdarimont Mar 6, 2025 Collaborator Author

Uh oh!

Uh oh!

tnorimat Jun 19, 2025 Collaborator

Uh oh!

thomasdarimont Jun 19, 2025 Collaborator Author

Uh oh!

pksorensen Aug 4, 2025

Uh oh!

achetronic Aug 5, 2025

Uh oh!

achetronic Jul 14, 2025

Uh oh!

thomasdarimont Jul 14, 2025 Collaborator Author

Uh oh!

achetronic Jul 15, 2025

Uh oh!

thomasdarimont Sep 10, 2025 Collaborator Author

Uh oh!

stianst Mar 3, 2026 Maintainer

Proposed milestones

Milestone 1 - Support resource=urn:client:<client-id>

Milestone 2 - Support URLs as resource values

Milestone 3 - Support multiple resource parameters

Milestone 4 - Support multiple Resource URIs per-client

Milestone 5 - Add support for resource parameters to token exchange

Uh oh!

stianst Mar 3, 2026 Maintainer

Uh oh!

stianst Mar 3, 2026 Maintainer

Uh oh!

trixpan May 20, 2026

thomasdarimont
Dec 9, 2024
Collaborator

Replies: 10 comments 5 replies

cgeorgilakis
Dec 20, 2024

thomasdarimont
Mar 5, 2025
Collaborator Author

thomasdarimont
Mar 6, 2025
Collaborator Author

tnorimat
Jun 19, 2025
Collaborator

thomasdarimont Jun 19, 2025
Collaborator Author

achetronic
Jul 14, 2025

thomasdarimont Jul 14, 2025
Collaborator Author

thomasdarimont
Sep 10, 2025
Collaborator Author

stianst
Mar 3, 2026
Maintainer

stianst
Mar 3, 2026
Maintainer

stianst
Mar 3, 2026
Maintainer

trixpan
May 20, 2026