What's new in Early Access Drop 2 Refresh?

Domino IQ updates

Domino IQ server now ships with NVIDIA CUDA built AI Inferencing server components that work only with Windows or Linux servers running with NVIDIA GPU hardware. See Domino IQ for details.
The Domino IQ configuration database (dominoiq.nsf) has enhancements for handling LLM downloads from various sites like the Hugging Face repository, and for Configuration and Command documents. See Configuring the Domino IQ database.
DominoIQ task status and controls now show different thread states, and new console/tell commands are added.
The dominoiq_server.log is now unique to each run with the format of the name being: dominoiq_server_<servername>_<YY_MM_DD@HH_MM_SS>.log

Administrator Client Files panel updates

File > Preferences > Administrator Preferences > Files now includes options for to display columns for Large Summary property and DAOS Tier 2 full-text indexing on the Files panel.
On the Files panel, in the Tools pane, options when creating one or more full-text indexes for a database now include the Index DAOS Tier 2 attachments option. See Creating and updating full-text indexes for single databases.

Passkey updates

The following notes.ini settings have been removed. Their functionality is now controlled through new settings in the Internet Site document's Security tab.
1. PASSKEY_RESIDENTKEY_REQUIRED
2. PASSKEY_REQUEST_DIRECT_ATTSTMT
3. PASSKEY_REQUIRE_USER_VERIFICATION
4. PASSKEY_USE_ALLOWCREDENTIALS
5. PASSKEY_SKIP_LEVEL
6. PASSKEY_DOMAIN_LEVELS
A new setting in the Internet Site document's Security tab, Prefer passkeys over passwords, can be used with the domcfg.nsf passkey login form to permit passkey authentication only for users with registered passkeys and to strongly encourage users without registered passkeys to create passkeys.
When "Prefer passkeys over passwords" is being used, end users with multiple devices should register their first passkey on a roaming authenticator, such as a smartphone or tablet, to make subsequent creation of passkeys on other devices and platform authenticators such as Windows Hello simpler.
Google Chrome in Incognito mode on Windows 10 might refuse to register passkeys with the Windows Hello platform authenticator. Once the passkey has been registered, it can still be used in Incognito mode.

Web login with OIDC updates

The Domino HTTP server's OIDC Relying Party (RP) now supports the "form_post" response mode in addition to the default "query" response mode. If the configured Trusted OIDC Provider advertises form_post support in their well known endpoint and the OIDC_RESPONSE_MODE_FORM_POST=1 notes.ini variable is set on the Domino RP, the Domino RP will request response_mode=form_post. Note that the Domino OIDC Provider does not currently support form_post.

Web federated login with OIDC updates

SPR RPAIDBKQER - The ID vault "host" name (with leading bearer.vault.) no longer needs to be the first hostname listed in order to be read and used.
Access tokens can no longer be replayed against an ID vault server.

Domino OIDC provider updates

Support for key rotation has been added; for details, see the section that follows this section.
New server console commands to help manage your Domino OIDC provider.
Note that authenticating to the authorization endpoint using HTTP basicAuth will not result in a session being created. Any authorization grants issued in this way will display a blank username field when oidcp show grants is run on the server console.
The oidcp revoke console commands will revoke the specified session or sessions, and send back-channel logout requests to the clients' registered back-channel logout endpoints if a username was associated with the authorization grants. Revoking a user session will attempt to send back-channel logout requests for all authorization grants issued from that user session.
In addition to revoking the received refresh token, the Revocation endpoint now also revokes the authorization grant associated with that refresh token per RFC 7009, and will send a back-channel logout request to the client's registered back-channel logout URI.
Note that revoking the authorization grant for a "Web Login with OIDC" user will have minimal visible impact unless the user's login session with the OIDC provider has expired, been logged out, or been revoked.
The Registered OAuth Client form in idpcat has been reorganized. The user consent-related fields have been moved to the "Advanced" section of the document, and the Post logout redirect URI(s) and Back channel logout URI fields have been moved to the top of the Advanced section.
A new Trusted root field has been added to the Registered OAuth Client form in idpcat. This field can be used to select a trusted root in certstore.nsf that will be used when the Domino OIDC provider makes outbound back-channel logout requests to the OAuth client. Any root selected here will override the default, which is the list of roots in the cacert.pem file in the server's data directory.
Tip: When creating a new Domino OIDC provider, we suggest making any changes to the Internet Site document before creating the provider document in idpcat.nsf. Changes made to an existing Internet Site document will need to be pulled into the provider document by using the Refresh Internet Site Servers button.
Tip: Any changes to the Domino OIDC provider configuration should be made on the primary Domino server and followed by restarting the primary Domino server, replicating idpcat.nsf to any secondary Domino servers, and then restarting those servers as well. Adding dynamic polling of configuration changes is under investigation for a future drop.
Limitation: The Domino OIDC provider does not currently support redirect URIs containing a "?", such as https://www.example.com/names.nsf?OIDCLogin. When configuring a Domino RP, it is best to use the Simplify redirect URL setting, which results in a redirect URI of https://www.example.com/auth/protocol/oidc.

Domino OIDC provider - Key rotation

This update adds support to rotate (roll over) the signing and encryption keys used by the Domino OIDC provider. Note that keys can be generated and managed only on the primary Domino server.

The oidcp show keys server console command can be used to view the keys used for signing and encyption by the Domino OIDC provider. The first character of the "type" column shows the state of the key -- (A)ctive, (P)ending, or (O)ld, and the second character shows whether the key is used for (e)xternal consumers to sign access tokens and ID tokens, or for (i)nternal consumption by the OIDC provider itself to sign and encrypt authorization codes and FailoverCookies.
Active keys are actively being used to sign and encrypt new tokens. External pending keys are being published at the jwks_uri endpoint for clients to load and prepare to use, but are not being used yet. Old keys are no longer being actively used for signing and encryption, but external old keys are still published so clients and relying parties can use them to decrypt and verify previously generated tokens.
The jwks_uri endpoint now sends a Cache-Control header for one day (86400 seconds) by default which aligns with common usage. These cache-control headers let clients know how long they can safely cache a set of published keys before they need to re-poll the jwks_uri endpoint and update their local cache. Administrators can use the OIDCP_JWKS_URI_CACHE_SEC notes.ini to change this value from the default of one day; the minimum value is 5 minutes (300 seconds) and the maximum value is one week. We recommend only using values of less than one day for testing purposes.
Use the OIDCP KEYS NEW <algorithm> server console command to create a new pending key of type algorithm. The algorithms are defined by JWS and are strings like "ES256" and "RS256"; the algorithms that are configured for use by a Domino OIDC provider can be determined with theoidcp show keys server console command. Pending keys will be published for a period of time before being activated and used to give clients time to update their local caches of signing keys. By default, this period of time will be identical to the Cache-Control time sent by the jwks_uri endpoint. This time may be increased but not decreased by adding an additional number to the end of the server console command, as in oidcp keys new <algorithm> <time> Longer times may be useful to accomodate applications that ignore jwks_uri endpoints' published cache-control headers.
Once per hour the Domino server checks for pending keys that are ready to be promoted into active use; when a pending key is promoted, the corresponding active key is "retired" and becomes an old key.