rodauth-ciba 0.1.0 → 0.2.1

data/docs/claims.md

@@ -37,7 +37,11 @@ Requested JSON and consent JSON are stored separately. Snapshot fields are froze
 - Rejected/unselected attributes are not requested from the account callback. Poll parameters cannot expand the stored request. Client-supplied `value` never becomes identity data.
 - The compiled selection is persisted on the issued OAuth row, separately from the request. UserInfo binds to the exact presented opaque token or a signed JWT's `urn:rodauth:ciba:token_id` reference, with account/client checks and DB revocation checks. The internal reference is omitted from ID Tokens. It is not authorization by itself.
 
-The application remains responsible for evaluating essential/value/values, acr, and localized claim requirements before approving. The stored request preserves those objects for that purpose; default attribute acquisition returns trusted account values rather than asserting that requested constraints were met. Aggregated/distributed claim processing is not implemented by this capability. These limits prevent claiming complete OIDC claims parity.
+The gem validates essential as a Boolean and values as an array, checks standard claim value types, and preserves qualifiers with each issued claim projection. It compares value/values to trusted output values and omits mismatching ordinary claims for both response targets. It never uses requested values as account data. Missing ordinary essential claims do not cause errors, as required by OIDC Core5.5.1. Voluntary ACR follows its specific rule and may return the achieved ACR rather than a preferred value.
+
+Requested sub must match the actual RP-facing public/pairwise subject. Essential ID Token acr with value/values requires a supplied matching achieved ACR. Approval rejects these mismatches before committing; issuance and refresh recheck saved requirements. Required auth_time cannot be missing or omitted to satisfy a conflicting qualifier. Mandatory ID Token fields, including a supplied nonce, cannot be removed to satisfy qualifiers. Signed UserInfo issuer/audience constraints are checked against upstream's final values; a later incompatible issuer change fails UserInfo with invalid_token. Pairwise UserInfo uses the issued subject after sector changes so it remains consistent with the ID Token.
+
+The application must perform actual authentication, select an achieved ACR, supply truthful authentication context, enforce freshness and business policy, and acquire trusted claim values. Localized, aggregated and distributed claim processing is not implemented. Custom claim semantic types remain application-owned. These limits prevent claiming complete OIDC claims parity.
 
 Legacy JWTs without an exact issuance reference never inherit explicit claims from another OAuth row for the same account/client. They retain the upstream scope-based path; this does not retroactively add per-row revocation to those JWTs. In particular, removing a legacy issuance row is not permission to reuse a newer row's explicit consent. This migration boundary has a regression test using an actual pre-capability JWT.
 

data/docs/max-age.md

@@ -22,7 +22,9 @@ from no policy. This is an internal representation adaptation, not an HTTP respo
 change. Client metadata changes after acceptance do not alter the saved policy.
 Applications must enforce freshness during authentication; approval does not reject
 an old supplied auth_time automatically. Selected max_age causes auth_time to be
-selected for ID Token output, but does not invent an authentication time.
+selected and required for ID Token output. Approval without a verified time is
+rejected, and issuance/refresh reject missing required context without consuming
+the source. This does not invent a time or automatically enforce freshness.
 Refresh preserves the original authentication claim selection/context and does
 not start a new authentication request or reapply current client defaults.
 

data/docs/operations.md

@@ -1,5 +1,32 @@
 # Deployment and operating boundaries
 
+## Upgrading the Core conformance boundaries
+
+Claim qualifiers now form an enforced backend contract. Old pending/refresh
+sources with incompatible sub, essential ACR or malformed options fail closed;
+supply valid authentication context or expire/drain those sources. Newly issued
+claim projections retain value/values filters. Existing issued projections have
+no qualifier history and cannot be upgraded by guessing which request produced
+them: drain or expire affected old tokens before relying on these guarantees.
+Upgrade every worker together; older workers ignore the new projection members.
+Pairwise UserInfo now returns the subject stored at issuance, including after
+sector configuration changes. This corrects the earlier recomputation behavior.
+
+Request expiry now starts at backchannel-handler entry rather than after hint
+resolution. Slow client authentication/resolvers/hooks/AD dispatch consume that
+budget; enqueue AD work promptly. An acknowledgement can arrive after expiry if
+dispatch is slow; polling then returns expired_token. The deadline is not extended
+by processing. Already committed requests remain for bounded cleanup.
+
+New requests save auth_time_required for selected max_age or essential ID Token
+auth_time, in addition to client require_auth_time=true. No schema migration is
+needed. Existing requests/refresh sources retain their old saved selection; the
+upgrade does not infer or fabricate missing authentication evidence. Drain or
+invalidate affected old work before advertising this stricter contract, update
+all workers together, and ensure approval callbacks provide actual auth_time.
+The application still enforces max_age freshness and other essential constraints.
+See [Core conformance boundaries and acceptance gates](ciba-conformance.md).
+
 Optional explicit claims require an additional schema migration and coordinated activation; see [claims operations](claims.md). The default base schema and default-disabled behavior do not require those columns.
 
 The same activation boundary applies to [resources](resources.md) and [RAR](authorization-details.md). Issuance checks both the original request and its saved consent: if either records a capability whose flag is now disabled, collection returns invalid_grant without consuming the request or issuing a token. This includes old requests bound to new-format consent after migration and explicitly stored empty permission values. Legacy request/consent pairs whose new fields are both null retain baseline behavior. Do not use feature deactivation as a way to erase approval restrictions; drain or explicitly resolve affected work before changing capabilities.
@@ -71,7 +98,7 @@ Limit unsolicited requests in your application. Optional [user_code](user-code.m
 
 ## Scope and compatibility
 
-0.1.0 targets poll with login_hint, public subjects and statically provisioned CIBA clients. It delegates confidential client authentication to enabled upstream mechanisms, preserves shared Discovery metadata, and issues signed ID Tokens using upstream's JWT implementation. Basic/post and private_key_jwt/client_secret_jwt have integration coverage; configured JWT algorithms, DPoP and optional mTLS have additional integration evidence in the [alignment status](alignment-closeout.md), including installed real-TLS examples. Production proxy trust remains application-owned. Unsupported features are not silently treated as implemented. Read the gemspec for narrow initial dependency bounds and `docs/release-validation.md` in the repository for actual tested environments.
+Version 0.2.1 targets poll with login_hint, public subjects and statically provisioned CIBA clients. It delegates confidential client authentication to enabled upstream mechanisms, preserves shared Discovery metadata, and issues signed ID Tokens using upstream's JWT implementation. Basic/post and private_key_jwt/client_secret_jwt have integration coverage; configured JWT algorithms, DPoP and optional mTLS have additional integration evidence in the [alignment status](alignment-closeout.md), including installed real-TLS examples. Production proxy trust remains application-owned. Unsupported features are not silently treated as implemented. Read the gemspec for narrow initial dependency bounds and `docs/release-validation.md` in the repository for actual tested environments. Follow the [0.2.1 upgrade notes](release-readiness.md#upgrade-to-021) for refresh-token reauthentication and coordinated worker updates.
 
 No OpenID certification, full Conformance Suite pass, security audit, or blanket support for all Sequel adapters is claimed. Existing authorization-code behavior has a regression test, not the complete upstream test suite. Consumers should use the included protocol mapping as a starting point for application-specific interoperability tests.
 

data/docs/pairwise.md

@@ -42,12 +42,23 @@ retain the canonical account ID. UserInfo must return the same pairwise subject
 as ID Token. With pairwise enabled, new CIBA issuances snapshot their subject in that token
 row. JWT UserInfo checks the signed subject against this snapshot and the bound
 client before using the internal account for lookup. After a management sector
-change, old tokens can therefore authenticate while UserInfo emits the new
-sector subject, as measured with node opaque tokens. Refresh also uses the new
-sector, and already-issued JWT bytes remain unchanged. Older rows with no
+change, old tokens can therefore authenticate while UserInfo retains their
+issuance subject, even if the client changes subject_type to public and the
+optional claims capability is disabled. Refresh chains retain the original ID Token subject using
+versioned authentication context, deliberately differing from the previously
+measured node current-sector behavior. Already-issued JWT bytes remain unchanged. Older rows with no
 snapshot retain the prior current-subject check; a sector change can invalidate
 those old JWTs. The migration does not invent historical subjects.
 
+Each token request snapshots client metadata immediately after successful client
+authentication. Initial and refreshed tokens use that snapshot for identity,
+signing and encryption recipients even if DCR commits before issuance validation
+or during its hooks. Reloading the client for current eligibility and permission
+checks does not replace the authenticated snapshot. The next HTTP request must
+authenticate against the new registration and uses its new metadata. This binds
+the pairwise sector to the JWKS URI used for proof of key possession; a prior
+key cannot authenticate a new sector merely by racing a registration update.
+
 For id_token_hint, configure the existing `resolve_ciba_id_token_subject` callback
 to recover the canonical account in the authenticated client's context. The gem
 first verifies the ID Token's issuer, audience and signature; the hint then starts
@@ -67,10 +78,15 @@ sector update; subsequent approved issuance uses the new sector subject. The
 installed-gem TLS fixture now covers hybrid DCR, real remote-key authentication,
 approval, verified ID Token, saved subject and matching UserInfo. Concurrent
 sector management/issuance tests now verify one issuance subject across storage
-and tokens, followed by current-sector UserInfo, on all three DBs. PostgreSQL and
+and tokens. UserInfo now retains the subject stored with the presented issuance
+after sector changes; the earlier current-sector expectation is superseded.
+The updated expectation is locally tested on SQLite; the historical three-DB
+result predates this correction. PostgreSQL and
 MySQL force the update to commit while issuance is paused; SQLite tests writer
 contention and either serial order. Concurrent refresh/key changes, arbitrary
 application hooks and additional deployment combinations remain unverified.
+Legacy refresh sources without original ID Token context fail closed; see the
+[refresh migration](refresh-tokens.md#original-id-token-binding-and-migration).
 This is not a completed pairwise parity or release-readiness claim.
 
 [Reference contract](research/pairwise-reference-contract.md).

data/docs/refresh-tokens.md

@@ -57,6 +57,38 @@ reference behavior and the remaining tests. Current authentication context outpu
 follows the gem's CIBA ID Token behavior; it is not identical to node's optional
 claim masking.
 
+## Original ID Token binding and migration
+
+New refresh sources use the existing `authentication_claims` TEXT column as a
+versioned JSON object: `version: 2`, a `selected` string array, and
+`initial_id_token` containing the actual initial `iss`, `sub`, `aud` and, when
+returned, `auth_time`. The values are captured from the final payload passed to
+signing/encryption, including encrypted ID Tokens. Request rows retain their
+previous selection-array format. Rotation copies the original object unchanged.
+No new database column or automatic data migration is required.
+
+[OIDC Core 12.2](https://openid.net/specs/openid-connect-core-1_0.html#RefreshTokenResponse)
+requires refreshed ID Tokens to retain the original issuer, subject and audience.
+Refresh preserves those values and the original disclosed authentication time;
+`iat` is the new issuance time. Refresh ID Tokens omit `nonce` as recommended by
+that section. Changing a pairwise sector does not reinterpret an existing chain:
+its ID Token, access-token subject and UserInfo retain the original subject.
+New CIBA authentications use the current sector. Changed issuer/client ID, or an
+incompatible current public-subject mapping, causes `invalid_grant`.
+
+Legacy nil/array JSON and unknown, malformed or incomplete objects are rejected
+with `invalid_grant` before refresh hooks, lock-version mutation, rotation or
+token creation. They are not backfilled from current settings or unrelated access
+rows. This applies to public as well as pairwise refresh tokens. Hook-side changes
+are revalidated after reload inside the transaction. A denied renewal alone does
+not revoke otherwise live access tokens; users need a new CIBA authentication.
+
+This changes the stored JSON and the `ciba_current_refresh` snapshot contract.
+Upgrade all workers together; old versions cannot safely process the new object.
+Drain/expire old refresh sources or require reauthentication, and account for
+this in rollback planning. Restoring an old implementation does not preserve
+the new binding guarantee. Do not rewrite live tokens automatically.
+
 ## Refresh-token revocation
 
 Enable upstream `:oauth_token_revocation` to expose its advertised endpoint.

data/docs/release-readiness.md

@@ -1,7 +1,26 @@
-# 0.1.0 release readiness
+# 0.2.1 release readiness
 
-RubyGems publication is pending. This document separates the supported release
-scope from historical development notes and opt-in experiments.
+Version 0.2.1 incorporates the unpublished 0.2.0 candidate and the documentation
+corrections in PR #3. The existing `v0.2.0` tag is retained; no 0.2.0 gem was
+published as of 2026-10-22. A source version or tag does not establish registry
+publication. Check [RubyGems](https://rubygems.org/gems/rodauth-ciba/versions) for
+published versions and the [changelog](../CHANGELOG.md) for changes.
+
+Version 0.1.0 was published on 2026-10-11 from commit
+`74ccc85e4f7af9596fec2b965bd43eed0ff708bc`. Version 0.2.1 contains the
+CIBA Core validation and authenticated-client metadata fixes in PR #2.
+
+## Upgrade to 0.2.1
+
+Old refresh tokens without the versioned identity context are rejected and require
+reauthentication. No automatic data migration or new database column is provided.
+Stop old workers before starting new workers: mixed 0.1.0/0.2.1 workers are not
+supported. Refresh tokens, pairwise subjects and dynamic registration remain
+experimental and disabled by default.
+
+The official OpenID Conformance Suite has not been executed. Local tests and
+hosted CI do not establish certification or full CIBA conformance. The evidence
+below is historical 0.1.0 evidence unless a different revision is stated.
 
 ## Scope
 

data/docs/release-validation.md

@@ -1,5 +1,10 @@
 # 0.1.0 release validation
 
+This is the historical 0.1.0 validation record. For the current 0.2.1 version's
+status, upgrade requirements and verification limits, see
+[release readiness](release-readiness.md). The versions and artifact names below
+identify the original test runs and have not been relabeled.
+
 Edwards client authentication follow-up: Ruby3.3/3.4 full SQLite suites each pass
 334 tests /4,316 assertions with2 row-lock skips
 ([log](validation/client-auth-edwards-rubies.txt)). Remote-key/ordinary-code-grant

data/docs/requirements-audit-current.json

@@ -3217,5 +3217,6 @@
       "execution": null
     }
   ],
-  "pending_ids": []
+  "pending_ids": [],
+  "superseded_for_current_changes_by": "ciba-core-requirements.json"
 }

data/docs/requirements-audit-current.md

@@ -1,3 +1,5 @@
+Historical 2026-09-30 audit overlay. For the current local Core final changes and remaining acceptance gates, see [conformance boundaries](ciba-conformance.md) and [requirement ledger](ciba-core-requirements.json). The older partial timing finding below is historical.
+
 # 現行構成の要件再監査
 
 2026-09-30。初期の159項目カタログを保持し、現在の任意機能に対する再監査を追記する。**159項目を再分類、未分類は0項目**。この分割は最終目標や監査範囲を縮小しない。CIBA以外のRFCやnode固有の挙動は[整合化計画](alignment-roadmap.md)で別途追跡する。

data/examples/extensions_smoke.rb

@@ -167,6 +167,10 @@ require_relative "demo_app"
 
     refresh = tokens.fetch("refresh_token")
     source = database[:ciba_refresh_tokens].first
+    stored_context = JSON.parse(source.fetch(:authentication_claims))
+    unless stored_context["version"] == 2 && stored_context["initial_id_token"] == identity.slice("iss", "sub", "aud", "auth_time")
+      raise "initial ID Token context was not persisted"
+    end
     raise "raw refresh persisted" if JSON.generate(database[:ciba_refresh_tokens].all).include?(refresh)
     raise "wrong refresh digest" unless source[:token_digest] == Digest::SHA256.hexdigest(refresh)
     now = Time.now.to_i
@@ -180,10 +184,23 @@ require_relative "demo_app"
     raise "lost RAR permission" unless renewed["authorization_details"] == expected_details
     renewed_identity, = JWT.decode(renewed.fetch("id_token"), nil, true, jwks: keys, algorithms: ["RS256"],
       verify_iss: true, iss: issuer, verify_aud: true, aud: "demo-client")
-    unless renewed_identity["auth_time"] == 1 && renewed_identity["nonce"] == "installed-extension-check" &&
+    unless renewed_identity["auth_time"] == 1 && !renewed_identity.key?("nonce") &&
            renewed_identity["email"] == "customer@example.test" && !renewed_identity.key?("email_verified")
       raise "refresh changed authenticated identity or permission"
     end
+    successor_ds = database[:ciba_refresh_tokens].where(token_digest: Digest::SHA256.hexdigest(renewed.fetch("refresh_token")))
+    successor_source = successor_ds.first
+    raise "rotation changed initial context" unless JSON.parse(successor_source[:authentication_claims]) == stored_context
+    successor_ds.update(authentication_claims: "[]")
+    before_legacy = [database[:ciba_refresh_tokens].all, database[:oauth_grants].all, database[:ciba_grants].all]
+    legacy = http.post(metadata.fetch("token_endpoint"), headers.merge(params: {
+      grant_type: "refresh_token", refresh_token: renewed.fetch("refresh_token"), resource: resource
+    }))
+    unless legacy.status == 400 && JSON.parse(legacy.body)["error"] == "invalid_grant" &&
+        before_legacy == [database[:ciba_refresh_tokens].all, database[:oauth_grants].all, database[:ciba_grants].all]
+      raise "legacy refresh binding failed closed"
+    end
+    successor_ds.update(authentication_claims: successor_source[:authentication_claims])
     replay = http.post(metadata.fetch("token_endpoint"), headers.merge(params: token_params))
     raise "replay accepted" unless replay.status == 400 && JSON.parse(replay.body)["error"] == "invalid_grant"
     raise "saved token not revoked" unless database[:oauth_grants].get(:revoked_at)

data/lib/rodauth/ciba/pairwise.rb

@@ -20,9 +20,13 @@ module Rodauth
 
       def fill_with_account_claims(claims, account, scopes, locales)
         result = super
-        if @ciba_userinfo_grant_id && request.path == userinfo_path && oauth_application &&
-            (oauth_application[oauth_applications_subject_type_column] || oauth_jwt_subject_type) == "pairwise"
-          claims["sub"] = jwt_subject(account[account_id_column], oauth_application)
+        if @ciba_userinfo_grant_id && request.path == userinfo_path && oauth_application
+          issued = db[oauth_grants_table].where(oauth_grants_id_column => @ciba_userinfo_grant_id).first
+          if issued && issued[ciba_token_subject_column]
+            claims["sub"] = issued[ciba_token_subject_column]
+          elsif (oauth_application[oauth_applications_subject_type_column] || oauth_jwt_subject_type) == "pairwise"
+            claims["sub"] = jwt_subject(account[account_id_column], oauth_application)
+          end
         end
         result
       end

data/lib/rodauth/ciba/registration.rb

@@ -317,6 +317,10 @@ module Rodauth
           @oauth_application_params = reset.merge(@oauth_application_params)
         end
         candidate = (existing || {}).merge(@oauth_application_params)
+        jwks_uri = candidate[oauth_applications_jwks_uri_column]
+        if jwks_uri && !ciba_https_uri?(jwks_uri)
+          register_throw_json_response_error("invalid_client_metadata", "CIBA client jwks_uri must use HTTPS")
+        end
         if !encryption.empty? &&
             !IdTokenEncryption::SYMMETRIC_ALGORITHMS.include?(candidate[oauth_applications_id_token_encrypted_response_alg_column]) &&
             !candidate[oauth_applications_jwks_column] && !candidate[oauth_applications_jwks_uri_column]

data/lib/rodauth/ciba/version.rb

@@ -1,6 +1,6 @@
 # frozen_string_literal: true
 module Rodauth
   module CibaSupport
-    VERSION = "0.1.0"
+    VERSION = "0.2.1"
   end
 end