Background
PR #4227 added auth.experimental.jwt_bearer_client (bool, default false) to gate the new RFC 7523 jwt-bearer two-VP client flow. During review @reinkrul suggested replacing it with a list-style config so the same mechanism can later enable/disable other grant types (authorization_code, vp_token-bearer, openid4vp, etc.).
We agreed to defer the refactor (rather than do it inside #4227) because doing it properly means touching every grant type that we currently support unconditionally, not just the new one.
Proposed change
Introduce a list-style config:
auth.granttypesenabled: [authorization_code, urn:ietf:params:oauth:grant-type:vp_token-bearer]
- Default: the grant types we currently support without a flag (
authorization_code, vp_token-bearer).
- Operators opt into the experimental two-VP flow by appending
urn:ietf:params:oauth:grant-type:jwt-bearer.
- Drop
auth.Config.Experimental.JwtBearerClient once the new config is in place.
Knock-on: AS metadata advertisement
The same config should drive what the local Authorization Server advertises in its metadata under grant_types_supported. Today the metadata is built from a fixed list; once the config exists, the metadata builder must read from it so AS clients can negotiate correctly.
This is the main reason we deferred the refactor out of #4227: the metadata thread reaches further than the client-side gate, and doing it half-way would hide the change from any peer node fetching our AS metadata.
Scope
- New config field + flag registration in `auth/cmd` and `auth/config.go`.
- Replace the `OpenID4VPClient.experimentalJwtBearerClient bool` with a membership check against the enabled set.
- Wire the same set into `AuthorizationServerMetadata.GrantTypesSupported` construction.
- Migrate / remove `auth.experimental.jwt_bearer_client`.
- Update tests, docs (`server_options.rst`), and the release notes.
Related
Background
PR #4227 added
auth.experimental.jwt_bearer_client(bool, defaultfalse) to gate the new RFC 7523 jwt-bearer two-VP client flow. During review @reinkrul suggested replacing it with a list-style config so the same mechanism can later enable/disable other grant types (authorization_code, vp_token-bearer, openid4vp, etc.).We agreed to defer the refactor (rather than do it inside #4227) because doing it properly means touching every grant type that we currently support unconditionally, not just the new one.
Proposed change
Introduce a list-style config:
authorization_code,vp_token-bearer).urn:ietf:params:oauth:grant-type:jwt-bearer.auth.Config.Experimental.JwtBearerClientonce the new config is in place.Knock-on: AS metadata advertisement
The same config should drive what the local Authorization Server advertises in its metadata under
grant_types_supported. Today the metadata is built from a fixed list; once the config exists, the metadata builder must read from it so AS clients can negotiate correctly.This is the main reason we deferred the refactor out of #4227: the metadata thread reaches further than the client-side gate, and doing it half-way would hide the change from any peer node fetching our AS metadata.
Scope
Related