SPECIFICATION

第 4 章：オンラインチケットプロトコル

本章は Trusted_Ticket の発行、照会、変換およびデグレードフローを定義する。本章のフローはブループリント §2.2 の設計意図に対応する。

4.1 適用前提

Trusted_Ticket は端末がオンラインで Ticket_Issuer またはオンライン失効サービスにアクセスできる場合にのみ使用される。オンラインサービスが利用不可の場合、端末は §4.5 に従い自動的にオフライン認可へフォールバックする。

端末は MUST Authorization_Descriptor（第 3 章）と Trusted_Ticket の両方をサポートする。端末は MUST NOT 合法な署名の Trusted_Ticket の受け入れを拒否する。当該端末ポリシーがオフライン認可を選好する場合でも同様。

4.2 発行フロー

4.2.1 発行要求

認可者は CAP をサポートするクライアント（モバイル App、Web コンソール等）を通じて Ticket_Issuer に発行要求を発信する。クライアントと Ticket_Issuer の間の相互作用は本仕様の範囲外であるが、Ticket_Issuer は MUST：

  1. 要求元が認証済みの認可者であることを検証
  2. 認可者が対象 Fay とリソースに認可する権限を持つことを検証
  3. ローカルポリシーで認可範囲を検証する（最長有効期間、リソースホワイトリスト等）

4.2.2 発行ステップ

Ticket_Issuer は MUST 以下のステップで Trusted_Ticket を生成する：

  1. Header 構築：§2.4.2 に従い alg、typ、kid を設定
  2. Payload 構築：§2.4.3 に従い TicketPayload を埋める、すべての required フィールドは MUST 設定する
  3. 制約検証：exp - nbf ≤ 7 日 をローカル検証
  4. JSON シリアライゼーション：Header と Payload を UTF-8 JSON バイトにシリアライズ
  5. Base64URL エンコーディング：Header と Payload バイトをそれぞれ Base64URL エンコード
  6. 署名：RFC 7515 に従い署名入力 base64url(header) + "." + base64url(payload) を計算
  7. Compact Serialization 生成：header.payload.signature 文字列に連結
  8. 記録登録：Ticket_Issuer 内部で発行済みチケット状態を維持（失効照会用）

4.2.3 発行後の交付

Trusted_Ticket は HTTPS 等の暗号化チャネルを通じて対象 Fay またはその iFay_Runtime に交付される。交付の具体的方式は本仕様の範囲外。

4.3 端末検証フロー

端末が Trusted_Ticket を検証するフローと Authorization_Descriptor の検証フローの違い：

  1. Trusted_Ticket は要求時に iFay_Runtime が完全に端末に伝送する（事前保管しない）
  2. 端末はオンライン時に MAY Ticket_Issuer の失効状態をリアルタイム照会できる
  3. 検証失敗時のエラーコードは E_TICKET_* プレフィックス

4.3.1 検証要求

iFay_Runtime が送信する AuthRequest は完全な Trusted_Ticket を携帯する：

AuthRequest (body of ProtocolMessage) {
  required fay_id        : Fay_ID
  required resource_id   : Resource_ID
  required access_mode   : AccessMode
  required credential    : CredentialContent
}

CredentialContent {
  required type : enum["descriptor_ref", "ticket"]
  oneof:
    descriptor_id : string                  // type == "descriptor_ref"
    ticket        : string                  // type == "ticket"、JWS Compact 文字列
}

4.3.2 検証ステップ（順序実行）

端末は MUST 以下の順序で検証を実行する。任一ステップ失敗時は直ちにエラーを返却する。

ステップ 1：JWS 解析

端末は JWS Compact 文字列を解析する：

  • header.payload.signature 三部分に分割
  • header と payload を Base64URL デコード
  • header.typ == "cap-ticket+jws" を検証
  • header.alg が §8 で許可されたアルゴリズム集合内にあることを検証

任一ステップ失敗 → E_TICKET_MALFORMED を返却

ステップ 2：署名検証

端末は header.kid に対応する Verification_Key で JWS 署名を検証する（RFC 7515 に従う）。

  • 署名検証失敗 → E_INVALID_SIGNATURE を返却
  • kid に対応する鍵が未登録または失効済み → E_VERIFICATION_KEY_INVALID を返却

ステップ 3：有効期間

§3.3.2 ステップ 3 の規則に従い nbf と exp を検証。

ステップ 4：主体、端末、リソース、モードマッチング

§3.3.2 ステップ 4–6 の規則に従いマッチングを行う。エラーコードは E_TICKET_* プレフィックスを使用する（§9 を参照）。

ステップ 5：オンライン失効照会（オプション）

端末ポリシーがオンライン失効検証を要求する場合、端末は MAY Ticket_Issuer に失効状態照会を発信する：

TicketRevocationQuery {
  required jti : uuid
}

TicketRevocationResponse {
  required jti      : uuid
  required revoked  : boolean
  optional revoked_at : timestamp
}
  • 照会タイムアウト（デフォルト 2 秒）→ 端末は SHOULD 当該要求を拒否し E_REVOCATION_QUERY_TIMEOUT を返却するが、MAY 通過を許可するよう設定できる（失効遅延リスクを受け入れ）
  • 照会が revoked == true を返却 → E_TICKET_REVOKED を返却
  • 照会失敗（サービス到達不可等）→ 端末は MAY ローカルキャッシュの失効状態で決定、キャッシュ有効期間超過時はタイムアウト処理

端末は SHOULD 失効照会結果をキャッシュする、キャッシュ有効期間は 5 分を超えない。

4.3.3 検証通過後

検証通過後の処理は §3.3.3 と一致し、Session を作成し AuthResult を返却する。

4.4 オフライン Authorization_Descriptor への変換

TicketPayload.convertible == true（デフォルト）の場合、端末は検証通過後に Trusted_Ticket をローカル Authorization_Descriptor に変換しオフライン使用に供することができる。

4.4.1 変換発動

変換は SHOULD 以下の状況で自動実行される：

  1. Trusted_Ticket 検証通過かつ convertible == true
  2. 端末ポリシーがオフライン後続アクセスを許可
  3. TicketPayload.exp が現在時刻から十分長い（推奨 > 1 時間）

4.4.2 変換ステップ

  1. フィールドマッピング：§2.4.4 表に従い TicketPayload フィールドを DescriptorPayload にマッピング
  2. 有効期間制約：変換後の not_after は MUST min(TicketPayload.exp, 変換時刻 + 7 日) を超えない
  3. メタデータ保持：元の Trusted_Ticket の重要監査情報を metadata に保存：
    • metadata["origin"] = "converted_from_ticket"
    • metadata["origin_jti"] = TicketPayload.jti
    • metadata["origin_iss"] = TicketPayload.iss
    • metadata["origin_kid"] = TicketHeader.kid
  4. ローカル署名：端末はローカル保管鍵を用いて変換後 payload を再署名（§4.4.3 を参照）
  5. ローカル保管：変換後の Authorization_Descriptor を §3.2.3 に従い暗号化保管

4.4.3 端末ローカル署名鍵

変換フローをサポートするため、端末は MUST 一対のローカル署名鍵を保有する：

  • 秘密鍵：端末安全保管に保存し、ローカル変換フローのみに使用
  • 公開鍵：source == "pre-installed" 種別の Verification_Key として自身の鍵保管に登録

変換後の Authorization_Descriptor の signature.key_id は MUST 当該ローカル鍵を識別し、payload.issuer_id は MUST "local-conversion:" + terminal_id に設定する。

端末はローカル変換した Authorization_Descriptor の検証時、ローカル公開鍵で署名を検証する。この設計により：

  • 変換後のクレデンシャルは独立してオフライン検証可能、元の Ticket_Issuer に依存しない
  • 変換信頼チェーンは端末自身の鍵セキュリティに錨定される

4.4.4 変換の限界性

ローカル変換した Authorization_Descriptor は MUST NOT：

  1. 他の端末で信頼される（その署名 key_id はローカルである）
  2. 端末を跨いで移行使用される
  3. Descriptor_Issuer の失効メカニズムで失効される（ローカル削除を経由する必要がある）

端末は SHOULD 以下の状況でローカル変換した Authorization_Descriptor を主動削除する：

  1. 元の Trusted_Ticket の失効通知を受領（jti で関連付け）
  2. クレデンシャルが期限切れ後 24 時間を超過

4.5 オンラインからオフラインへのデグレード

4.5.1 デグレード発動

端末はオンラインサービス可用性を継続的に監視する。以下のいずれかの条件を満たす場合、デグレードを発動する：

  1. Ticket_Issuer との接続が 30 秒以上到達不可
  2. 失効照会要求が連続 3 回タイムアウト
  3. ネットワークスタックがグローバルネットワーク利用不可を報告

4.5.2 デグレード動作

デグレード後、端末は以下の規則で処理する：

  1. 新しい Trusted_Ticket の受け入れを拒否（オフライン受け入れに設定されている場合を除く）——失効状態をオンライン検証できないことを回避
  2. 既にローカル Authorization_Descriptor に変換されたチケットは §3 規則に従い継続使用
  3. Authorization_Descriptor を直接用いた認可検証要求はデグレードの影響を受けない
  4. 端末は MAY iFay_Runtime に現在オフラインモードであることを示唆し、Fay が動作ポリシーを調整できるようにする

4.5.3 復旧

端末はオンラインサービス復旧を検出した後 MUST：

  1. 失効リストの同期を優先し、オフライン期間に取りこぼした可能性のある失効声明をローカル状態に適用
  2. アクティブ Session を再チェックし、ローカル変換 Authorization_Descriptor を使用しかつ元の ticket が失効済みの Session について、第 5 章規則に従い強制終了
  3. 通常の Trusted_Ticket 受け入れポリシーに復旧

復旧プロセスは iFay_Runtime に対して透明であるが、端末は MAY SessionStateChanged を通じてモード変更を通知できる。

4.6 二重クレデンシャルシナリオの優先順位

1 つの Fay が同一リソースに対する Trusted_Ticket と Authorization_Descriptor を同時に保有する場合、iFay_Runtime の選択ポリシー：

ネットワーク状態推奨選択理由
オンラインかつ Ticket_Issuer 到達可Trusted_Ticket時効性が強く、リアルタイム失効可能
オフラインAuthorization_Descriptor または変換後のローカルクレデンシャルTrusted_Ticket はオンライン失効検証不可

iFay_Runtime は MAY AuthRequest にフォールバッククレデンシャルを提供し、メインクレデンシャル検証失敗時に予備クレデンシャルを試行できるようにする。本仕様はフォールバックメカニズムの具体的形式を強制定義しないが、SHOULD 2 回の独立した AuthRequest で実現してプロトコル複雑化を回避する。

4.7 Trusted_Ticket と Authorization_Descriptor のセマンティクス整合性

iFay_Runtime が両クレデンシャル種別を同時に使用する場合、端末は MUST 以下を保証する：

  1. 検証結果整合性：同じ認可範囲が両クレデンシャル下での検証通過/拒否の判定結果が一致
  2. エラーコードセマンティクス整合性：等価な失敗原因（有効期間、署名、失効等）にはセマンティクス対応のエラーコードを使用（第 9 章を参照）
  3. Session 作成整合性：両クレデンシャルで作成された Session のライフサイクル管理に差異なし