+1 to have some "single point" in the Java code to create credential-offers as we would have more places from where the credential offers would be created (AIA , email sent by admin , REST endpoint you pointed). Maybe CredentialOfferProvider is a way to go (not 100% sure if we need dedicated provider, but seems OK to have something like this).

In regards to policies: It doesn't work if every Keycloak feature introduces it's own "policies" for various things. Instead, it is preferred to align with existing Keycloak features and capabilities. Keycloak has concept of client policies - those are in general used to enforce various things for multiple clients (or eventually for whole realm). The OID4VCI endpoints (including credential-offer creation) should be integrated with client policies instead of introducing it's own "policy framework" . I can see that client policies would allow ways like for example specify that pre-authorized grant is disabled for certain requests (or for whole realm). Or for example that "transaction code" is always required when pre-authorized grant is used. We can have dedicated client policy executors/conditions for those.

Also Keycloak has concept of fine-grained admin permissions . This allows to specify that for example some administrator can manage (or create credential permission) for user john, but not for user mary or for specific group of users etc. The cases when administrator creates credential-offer/credential-permission for specified user should be properly covered by admin endpoints instead of having dedicated realm role credential-offer-create . As creating credential permission (or credential-offer) for particular user is really "admin" functionality. One of the requirements from my team is that we may need to support permanent permission . When administrator grants user this permission, he can obtain credential-offer in a self-issued way multiple times. Regarding this (but not solely for this), we need credential permissions as the entities in the DB (in addition to short-lived credential offers stored only inside infinispan cache). The credential permission should be also available for admins/users to be able to query them and revoke them. Related issue is #46246 .

It seems that endpoint for CredentialOfferProvider should have the checks in place to see if there is credential-permission available (which may not be needed for credentials allowing user self-issuance) and also hook to call client policies.

I am not seeing how "credential policies" would fit into this. If you prefer, I think it is OK if those policies are used as "internal thing", which is handled inside code, but it is primarily managed by some other settings and not directly exposed externally. For example for the first option for vc.policy.offer.required: What I agreed so far with my team is to have client scope attribute in the admin console (On/OFF switch), which would manage whether the permission is required beforehand from the administrator before user can obtain the credential offer. Related issue #45777 . So that based on the configuration this switch on client scope, it can be internally translated to some "policy" like vc.policy.offer.required and checked inside CredentialOfferProvider. But not 100% there is value in "internal credential policies" rather than checking the client scope attribute directly...

For the vc.policy.offer.pre-auth.allowed and vc.policy.offer.tx-code.required - Not sure this should be switches controlled on client scope? I can see the use-case for pre-authorized grant is disabled for whole realm, but not sure if there is a use-case like Pre-authorized grant is allowed for the education-certificate credential, but not allowed for the driving-licence credential. Does it makes sense to enable/disable pre-authz grant at the level of individual credentials/client scopes? If not, then we should rather have different places where to disable pre-authz grant or enforce tx_code rather then at the level of individual credentials/client scopes. The pre-auth allowed - This is OAuth grant and hence should be switch on the client as we have switches on the clients for all other grants, so this should be aligned with that. Related issue:#46240 . I can think also about transaction code required and have this enabled/disabled per client/wallet? In addition to that, I can see client policies for cover use-cases like disabling pre-auth grant for the whole realm or for whole server. In this case, for example the pre-authz grant would be allowed just if it is enabled for the particular client and at the same time, not disabled by client policies.

For a quick recap ... the Client is the "application" that a user connects to when requesting a credential. A credential is defined in the issuer metadata by a credential_configuration_id in credential_configurations_supported. Currently we use the Client Scope to model both, the credential scope and the credential_configuration_id. Clients get assigned Client Scopes with N:M cardinality.

For example: The University Realm has a Client for the Biology and another one for the Engineering Department. Each department can issue their distinct set of credentials and there may also be credentials issued by both Departments (e.g. Calculus, Statistics)

Keycloak already has support for Client Policies. There is currently no such thing as "Client Scope Policies". Available is ...

public class ClientScopeRepresentation {

    protected String id;
    protected String name;
    protected String description;
    protected String protocol;
    protected Map<String, String> attributes;

    protected List<ProtocolMapperRepresentation> protocolMappers;

Lets consider the minimal set of policies from above

• vc.policy.offer.required
• vc.policy.offer.pre-auth.allowed

What effect would it have to define these policies on the Client

Without further distinction, all credential types (a.k.a. scopes, credential_configuration_id) would be subject to the same set of Client Policies. For example, all credentials issued by the Biology Department would require a credential offer - the same credential from the Engineering Department would perhaps not require an offer.

What effect would it have to define these policies on the Client Scope

Without further distinction, a given credential type would be subject to a defined set of policies - regardless which Client is the issuer. For example, the Statistics Credential would require a credential offer no matter which Department it is offered by.

Simple Client Scope Policies can be implemented using Client Scope attributes.

Can Client Policies be applied in combination with Client Scope Policies

Yes, Client Policies can be defined/applied independent of Client Scope Policies. In other words, adopting #46262 would not preclude policy decisions that can already be defined on the Client (see Executor)

Opinionated Conclusion

I personally believe that there is merit in defining simple policies like vc.policy.offer.required on the Client Scope. Even if a policy with the same effect becomes available on the Client, it would only add an additional choice (i.e. you can apply the policy on the client or the scope).