In this discussion, I introduce a new CredentialOfferProvider and how it enforces CredentialPolicies

Issue: #46262
Related: #46396 #46200

Lets first quickly summarize what the spec says about Credential Offers.

The basic assumption is, that the Issuer creates a Credential Offer and then passes it to the Wallet. This can be done
by credential_offer_uri, by qr-code (for cross device flows), by a Wallet provided credential_offer_endpoint
or by some other means (e.g. email, messaging, etc.).

The spec does not detail how to request a Credential Offer from an Issuer. In Keycloak, we provide an /create-credential-offer endpoint that requires various access privileges depending on the offer that is to be created. Other means to create a Credential Offer may exist in the Admin Console.

Depending on Credential Offer Policies for a given credential_configuration_id and Issuing User, these required
privileges may be permissible enough to allow for a "self-issued" Credential Offer.

A Credential Offer contains a set of credential_configuration_ids, which the Wallet can use to request a Credential as defined in the Issuer metadata

Credential Offers come in two variants

• authorization_code grant
• pre-authorized_code grant

Authorization Code Grant

With the authorization_code grant, the Wallet can send an Authorization Request that references one of the credential_configuration_ids in authorization_details. Part of the authorization_code grant
is also some opaque issuer_state that the Wallet must include in the Authorization Request. This allows the
Issuer to correlate the Authorization Request with a previously made Credential Offer.

The Wallet may also send an Authorization Request with a scope parameter and no authorization_details
nor issuer_state. This by-passes the Credential Offer process completely - the Authorization Server may
still return an Authorization Code, which can then be used in an AccessToken request and ultimately grants access
to Credentials associated with that scope.

Whether the Authorization Server grants access or the Credential Endpoint actually returns the wanted Credential again
depends on the effective Credential Policies. These may require an existing Credential Offer for a given credential_configuration_id and hence prevent such a Credential Request on scope alone.

Pre-Authorized Code Grant

As the name suggests, this is a "pre-authorized" grant that the Wallet can use directly in an AccessToken Request. No
further authorization is required on part of the Wallet. It works for cases where the Wallet cannot be expected to use
an authorization_code grant. Since this is bearer grant that gives direct access to the Credentials referenced
by credential_configuration_ids, the party that creates such a Credential Offer must take upmost care about
how to communicate that "pre-authorized" grant. As a second authorization factor, the Issuer can create a tx_code
together with the Credential Offer. The tx_code is to be communicated via an alternative channel (i.e. not together with the pre-authorized code).

As noted above, we have a /create-credential-offer as the primary entry point to initiate Credential Offer creation. This endpoint now delegates to the new CredentialOfferProvider to the actual creation of the internal CredentialOfferState. This an immutable instance that represents the CredentialOffer. It also holds the authorization_details that become part of the AccessToken response and the AccessToken JWT.

Using CredentialOfferProvider as the single access point for CredentialOfferState is important. It can reason about whether an Issuing User actually has the required privileges to make the required offer.

Currently we enforce these general rules ...

• The Issuing User must have an active login session
• The referenced credential_configuration_id must exist
• The potential targetUser must exist and be enabled
• If the targetUser is given, the Issuing User must hold the credential_offer_create role

... these rules for authorization_code grant

• If the targetUser is not given - it is an "Anonymous" offer not bound to a specific target user

... and these rules for pre-authorized_code grant

• If the targetUser is not given - it is a self-issued credential offer

Additionally, we now support theses Credential Policies ...

These policies an be set as Client Scope Attribute values.

In future may want to integrate fine grained role access to also cover the joe can offer foo to alice case. For now however, these three Credential Policies should be sufficient to deliver a "minimal viable product" (i.e. for oid4vci preview).

Secure-by-Default could mean ...

• vc.policy.offer.required=true
• vc.policy.offer.pre-auth.allowed=false
• vc.policy.offer.tx-code.required=true