ahus1 · Oct 20, 2026
@@ -70,9 +70,7 @@ include::topics/assembly-managing-organizations.adoc[]
 include::topics/assembly-managing-workflows.adoc[]
 include::topics/assembly-managing-scim.adoc[]
 include::topics/assembly-managing-clients.adoc[]
-ifeval::[{project_community}==true]
 include::topics/oid4vci/vc-issuer-configuration.adoc[]
-endif::[]
 include::topics/vault.adoc[]
 include::topics/events.adoc[]
 include::topics/threat.adoc[]

@@ -1,4 +1,5 @@
 
+[#auditing-user-events]
 === Auditing user events
 
 You can record and view every event that affects users. {project_name} triggers login events for actions such as successful user login, a user entering an incorrect password, or a user account updating. By default, {project_name} does not store or display events in the Admin Console. Only the error events are logged to the Admin Console and the server’s log file.

@@ -43,9 +43,12 @@ The JSON configuration object has the following properties:
 | Yes
 | The type of credential to offer. This value must match the *Credential Configuration ID* attribute of an existing OID4VCI client scope (see <<_oid4vci_client_scope,Create Client Scopes with Mappers>>), and the authenticated user must already have this credential assigned (see <<_oid4vci_user_setup,Creating a User Account>>). If the user does not have the credential, the AIA returns `kc_action_status=error`. It identifies a credential _type_ (such as "membership-credential" or "employee-badge"), not a specific issued credential. This is the same identifier that appears in the issuer metadata under `credential_configurations_supported`.
 
+ifeval::[{project_community}==true]
 | `preAuthorized`
 | No
-| If `true`, the credential offer uses the pre-authorized code grant, which requires the `oid4vc-vci-preauth-code` feature to be enabled (`--features=oid4vc-vci-preauth-code`). If `false` or omitted, the authorization code grant is used.
+| If `true`, the credential offer uses the pre-authorized code grant, which requires the experimental `oid4vc-vci-preauth-code` feature to be enabled (`--features=oid4vc-vci-preauth-code`). If `false` or omitted, the authorization code grant is used.
+
+endif::[]
 
 | `clientId`
 | No

@@ -26,9 +26,14 @@ OpenID4VCI supports multiple credential formats for encoding and issuing credent
 
 - https://www.ietf.org/archive/id/draft-ietf-oauth-sd-jwt-vc-13.html[SD-JWT VC] – Selective Disclosure JSON Web Token Verifiable Credential
 - https://github.com/decentralized-identity/jwt-vc-presentation-profile[JWT VC] – JSON Web Token Verifiable Credential
+ifeval::[{project_community}==true]
 - https://www.iso.org/standard/69084.html[mDL/mdoc] – Mobile driver's license / mobile document format
+endif::[]
 
-{project_name} currently supports both SD-JWT VC and JWT VC for issuance. mDL/mdoc format has just experimental support in {project_name} and should not be used in production environments. It is planned for a proper support in the future releases.
+{project_name} currently supports both SD-JWT VC and JWT VC for issuance.
+ifeval::[{project_community}==true]
+mDL/mdoc format has just experimental support in {project_name} and should not be used in production environments.
+endif::[]
 
 === The Issuer-Holder-Verifier Model
 
@@ -88,9 +93,12 @@ image::images/oid4vci/authorization-code-flow.drawio.svg[Sequence diagram of the
 
 This flow is best suited for scenarios where the user should be in control and give explicit permission for each credential issued.
 
+ifeval::[{project_community}==true]
 [[_oid4vci_pre_authorized_code_flow]]
 ==== Pre-Authorized Code Flow
 
+WARNING: The Pre-Authorized Code Flow is experimental and not supported. It is disabled by default and requires the experimental `oid4vc-vci-preauth-code` feature in addition to `oid4vc-vci`. Creating offers via the `/protocol/oid4vc/create-credential-offer` endpoint additionally requires the experimental `oid4vc-vci-rest-credential-offer` feature. Do not use these features in production environments.
+
 The Pre-Authorized Code Flow is a non-interactive flow. The issuer creates a pre-approved credential offer, and the wallet can claim the credential without real-time user authentication. This is useful for bulk issuance, offline-capable scenarios, or when the user has already been authenticated through other means.
 
 Pre-authorized credential offers can be created through the {project_name} Admin Console, the Admin REST API, or programmatically through a dedicated endpoint (`/protocol/oid4vc/create-credential-offer`). The wallet communicates through a registered OIDC client that must have OID4VCI enabled.
@@ -108,6 +116,7 @@ Pre-authorized credential offers can be created through the {project_name} Admin
 image::images/oid4vci/pre-authorized-code-flow.drawio.svg[Sequence diagram of the Pre-Authorized Code Flow, width=700]
 
 An optional transaction code (`tx_code`) can add a second layer of security. The `tx_code` must be communicated through a separate channel from the pre-authorized code itself.
+endif::[]
 
 === What This Chapter Covers
 
@@ -407,7 +416,10 @@ After selecting the OID4VCI protocol, the following configuration fields become
 
 | Supported Format
 | SD-JWT VC (`dc+sd-jwt`)
-| The credential format. Supported options: *SD-JWT VC* (`dc+sd-jwt`) and *JWT VC* (`jwt_vc_json`). There is also experimental support for the mdoc format, which is available just if the {project_name} server is started with the feature `oid4vc-mdoc` (Not recommended to use in the production environments).
+| The credential format. Supported options: *SD-JWT VC* (`dc+sd-jwt`) and *JWT VC* (`jwt_vc_json`).
+ifeval::[{project_community}==true]
+There is also experimental support for the mdoc format, which is available just if the {project_name} server is started with the feature `oid4vc-mdoc` (Not recommended to use in the production environments).
+endif::[]
 
 | Token JWS Type
 | (auto)
@@ -431,7 +443,10 @@ After selecting the OID4VCI protocol, the following configuration fields become
 
 | Cryptographic Binding Methods
 | (when binding enabled)
-| Comma-separated cryptographic binding methods. The default is `jwk` for SD-JWT VC and JWT VC, while mdoc uses `cose_key`.
+| Comma-separated cryptographic binding methods. The default is `jwk` for SD-JWT VC and JWT VC.
+ifeval::[{project_community}==true]
+The mdoc format uses `cose_key`.
+endif::[]
 
 | Binding Supported Proof Types
 | (when binding enabled)

@@ -32,10 +32,18 @@ Valera Wallet by A-SIT Plus is a demo wallet that can be used to test OpenID4VCI
 | `dc+sd-jwt`
 
 | Flows tested
+ifeval::[{project_community}==true]
 | Authorization Code Flow and Pre-Authorized Code Flow
 
 | Result
 | Both flows completed successfully and returned the issued credential to the wallet
+endif::[]
+ifeval::[{project_community}!=true]
+| Authorization Code Flow
+
+| Result
+| The flow completed successfully and returned the issued credential to the wallet
+endif::[]
 |===
 
 [[_oid4vci_valera_wallet_server_setup]]
@@ -133,9 +141,15 @@ The credential offer must target the same client id that the wallet uses during
 [NOTE]
 ====
 Instead of REST credential-offer, it is recommended to use AIA for creating credential offer. That is easier and does not need feature `oid4vc-vci-rest-credential-offer` to be enabled.
-Follow <<_oid4vci_lissi_wallet_authz_code_flow,Lissi wallet Authorization code section>> or <<_oid4vci_lissi_wallet_preauthz_flow,Lissi wallet Pre-authorized code section>> for the details.
+Follow <<_oid4vci_lissi_wallet_authz_code_flow,Lissi wallet Authorization code section>>
+ifeval::[{project_community}==true]
+or <<_oid4vci_lissi_wallet_preauthz_flow,Lissi wallet Pre-authorized code section>>
+endif::[]
+for the details.
 ====
 
+WARNING: The REST credential-offer endpoint requires the experimental `oid4vc-vci-rest-credential-offer` feature. Do not use it in production environments.
+
 The examples in the flow sections below use the REST credential-offer endpoint. The bearer token must be issued to the Valera client for the user who creates the offer. When creating an offer for a different target user, that issuing user must have permission to create credential offers.
 
 For the Authorization Code Flow test, create an offer for the `IdentityCredential` credential configuration and request a response that includes a QR code:
@@ -152,6 +166,7 @@ curl -G "$ISSUER_BASE/protocol/oid4vc/create-credential-offer" \
   --data-urlencode "type=uri_qr"
 ----
 
+ifeval::[{project_community}==true]
 For the Pre-Authorized Code Flow test, create a pre-authorized offer for the user who owns the credential:
 
 [source,bash]
@@ -167,6 +182,7 @@ curl -G "$ISSUER_BASE/protocol/oid4vc/create-credential-offer" \
   --data-urlencode "target_user=$TARGET_USER" \
   --data-urlencode "type=uri_qr"
 ----
+endif::[]
 
 The JSON response contains an `issuer`, a `nonce`, and a `qr_code` data URL. Display the `qr_code` value as an image for the wallet to scan, or use the returned issuer and nonce with your offer display component to create a deep link.
 
@@ -236,6 +252,7 @@ The test succeeded with Valera Wallet 5.8.0. The final credential request used t
 }
 ----
 
+ifeval::[{project_community}==true]
 ===== Pre-Authorized Code Flow Test
 
 Use this flow when the user has already been authenticated by the issuer and the wallet can redeem a pre-authorized credential offer without starting an interactive login flow on the phone.
@@ -251,6 +268,7 @@ This flow requires the dedicated experimental `oid4vc-vci-preauth-code` feature
 . {project_name} returns the issued `IdentityCredential` to the wallet.
 
 The test succeeded with Valera Wallet 5.8.0. Earlier testing with Valera Wallet 5.7.6 failed because the JWT proof issuer claim did not match the client id used for the token request. This was no longer reproducible with the tested 5.8.0 version.
+endif::[]
 
 ===== Test Result
 
@@ -264,9 +282,11 @@ The test succeeded with Valera Wallet 5.8.0. Earlier testing with Valera Wallet
 | Success
 | Valera completed PAR, user authentication, token exchange, and the final credential request with `credential_identifier` set to `IdentityCredential`.
 
+ifeval::[{project_community}==true]
 | Pre-Authorized Code Flow
 | Success
 | Valera exchanged the pre-authorized code and requested the credential with `credential_identifier` set to `IdentityCredential`.
+endif::[]
 |===
 
 [[_oid4vci_valera_troubleshooting]]
@@ -303,10 +323,18 @@ Lissi wallet is another demo wallet that can be used to test OpenID4VCI credenti
 | `dc+sd-jwt`
 
 | Flows tested
+ifeval::[{project_community}==true]
 | Authorization Code Flow and Pre-Authorized Code Flow
 
 | Result
 | Both flows completed successfully and returned the issued credential to the wallet
+endif::[]
+ifeval::[{project_community}!=true]
+| Authorization Code Flow
+
+| Result
+| The flow completed successfully and returned the issued credential to the wallet
+endif::[]
 |===
 
 [[_oid4vci_lissi_wallet_server_setup]]
@@ -392,10 +420,11 @@ image::images/oid4vci/lissi2-adding-credential.png[Lissi wallet confirmation scr
 .Lissi wallet - credential
 image::images/oid4vci/lissi3-credential.png[Lissi wallet - credential, width=320]
 
+ifeval::[{project_community}==true]
 [[_oid4vci_lissi_wallet_preauthz_flow]]
 ===== Pre-Authorized Code Flow Test
 
-This flow requires {project_name} running with the features `oid4vc-vci` and `oid4vc-vci-preauth-code`
+WARNING: This flow is experimental. It requires {project_name} running with the features `oid4vc-vci` and the experimental `oid4vc-vci-preauth-code`. Do not use it in production environments.
 
 . Logout from account console on your laptop (from previous step) and make sure that login screen is displayed.
 It should display `client_id=account-console` in the browser URL (among many other parameters).
@@ -422,6 +451,7 @@ The parameter is base64Url-encoded value of the credential-offer config, which l
 
 . Additional steps are the same as for <<_oid4vci_lissi_wallet_authz_code_flow,Authorization code flow>>. With the exception, that with the pre-authorized code flow, the mobile
 application does not request login from the user as it is assumed that user was "pre-authorized" in some other way - which in this use-case was done in fact by user authentication on the laptop to the {project_name} account console.
+endif::[]
 
 [[_oid4vci_lissi_troubleshooting]]
 ===== Troubleshooting

@@ -13,5 +13,7 @@ At this moment, transient sessions are automatically used for example in the fol
 * <<_service_accounts, Service account authentication>> with disabled token refresh. Note that token refresh is automatically disabled during service account authentication unless explicitly enabled by client switch `Use refresh tokens for client credentials grant`, but this client switch is deprecated and not recommended to be used.
 * link:{securing_apps_jwt_authorization_grant_link}[JWT Authorization Grant].
 * Some scenarios related to link:{authorizationguide_link}[Authorization Services].
+ifeval::[{project_community}==true]
 * <<_oid4vci_pre_authorized_code_flow, OID4VCI Pre-Authorized Code Flow>>.
+endif::[]
 
@@ -74,9 +74,7 @@ displays the confirmation screen where the user can confirm agreement to delete
 NOTE: The <<_account-service,{project_name} Account Console>> typically uses the `Delete Credential` action when deleting a 2nd-factor credential.  You can check the Account Console for examples if you want
 to use this action directly from your own applications. However, relying on the Account Console is best instead of managing credentials from your own applications.
 
-ifeval::[{project_community}==true]
 Similarly, the `verifiable_credential_offer` action is a parameterized AIA used to trigger verifiable credential issuance. The parameter is a Base64Url-encoded JSON object containing the credential configuration ID and optional fields. For example: `kc_action=verifiable_credential_offer:eyJjcmVkZW50aWFsQ29uZmlndXJhdGlvbklkIjoibWVtYmVyc2hpcC1jcmVkZW50aWFsIn0`. This action is available when the `OID4VC_VCI` feature is enabled. See <<_oid4vci_credential_offer_aia,Credential Offer via Application Initiated Action>> for full details.
-endif::[]
 
 [id="con-aia-available-actions_{context}"]
 == Available actions