$schema: "http://json-schema.org/draft-07/schema#"
schemaVersion: "1.0.0"
title: RegistrationRequest
description: Payload Schema für den DCR POST /register Body
type: object

oneOf:
  # -----------------------------------------------------------------
  # 1. TPM Hardware Attestation (Windows / Linux)
  # -----------------------------------------------------------------
  - title: TPM Attestation
    required:
      - attestation_type
      - client_name
      - jwks
      - puk_ek_enc
      - c_ek_enc
      - puk_ak_sig
      - signed_hash_puk_client_sig
    properties:
      attestation_type:
        type: string
        const: tpm
      client_name: { type: string }
      token_endpoint_auth_method: { type: string }
      grant_types:
        type: array
        items: { type: string }
      redirect_uris: { $ref: "#/definitions/redirect_uris" }
      jwks:
        description: >-
          Öffentlicher Client-Signaturschlüssel (ECDSA P-256).
        type: object
        properties:
          keys:
            type: array
            items: { $ref: "#/definitions/jwk" }
        required: [keys]
      puk_ek_enc:
        type: string
        description: >-
          Öffentlicher Endorsement Key (EK) des TPM als Base64-kodierte 
          TPM2B_PUBLIC Struktur. Wird zur MakeCredential-Operation verwendet.
      c_ek_enc:
        type: string
        description: >-
          Zertifikat des Endorsement Key (EK) des TPM im DER Format Base64-kodiert.
      puk_ak_sig:
        type: string
        description: >-
          Öffentlicher Attestation Key (AK) des TPM (Base64-kodierte TPM2B_PUBLIC-Bytes).
          Wird vom AuthS zur Verifikation der TPM-Quote und von
          signed_hash_puk_client_sig verwendet.
      signed_hash_puk_client_sig:
        type: string
        description: >-
          Signatur des SHA-256-Hashes von puk_client_sig, erstellt mit
          dem TPM Attestation Key (prk_ak_sig). Base64url-kodiert.

  # -----------------------------------------------------------------
  # 2. Apple Hardware Attestation (iOS, iPadOS & macOS)
  # -----------------------------------------------------------------
  # Die Apple App Attest API (DeviceCheck-Framework) ist auf iOS,
  # iPadOS und macOS identisch: gleiches CBOR-Format, gleiche Felder
  # (attStmt mit x5c + receipt, authData) und gleiches Key-Binding.
  # -----------------------------------------------------------------
  - title: Apple Attestation
    required:
      - attestation_type
      - client_name
      - jwks
      - apple_attestation_object
      - signed_hash_puk_client_sig
      - user_email
    description: >-
      Für iOS, iPadOS und macOS identisch. Die Apple App Attest API
      (DeviceCheck-Framework) produziert auf allen Plattformen dasselbe
      Objekt-Format und Key-Binding-Protokoll.
    properties:
      attestation_type:
        type: string
        const: apple
      client_name: { type: string }
      token_endpoint_auth_method: { type: string }
      grant_types:
        type: array
        items: { type: string }
      redirect_uris: { $ref: "#/definitions/redirect_uris" }
      user_email: { $ref: "#/definitions/user_email" }
      jwks:
        description: >-
          Öffentlicher Client-Signaturschlüssel (ECDSA P-256).
        type: object
        properties:
          keys:
            type: array
            items: { $ref: "#/definitions/jwk" }
        required: [keys]
      apple_attestation_object:
        type: string
        description: >-
          CBOR-kodiertes Attestation-Objekt der Apple App Attest API
          (fmt: "apple-appattest"). Enthält attStmt (x5c-Zertifikatskette inkl.
          puk_ak_sig + receipt) sowie authData (rpIdHash, counter, credentialId).
          Base64-kodiert.
      signed_hash_puk_client_sig:
        type: string
        description: >-
          Selbstsignatur: Signatur des SHA-256-Hashes von PuK.Client.Sig,
          erstellt mit PrK.Client.Sig (Proof-of-Possession des Client
          Instance Keys). Base64url-kodiert. Die Bindung
          AK ↔ PuK.Client.Sig weist bereits das apple_attestation_object
          nach (clientDataHash == SHA-256(PuK.Client.Sig)); eine
          AK-Signatur ist hier daher nicht erforderlich.

  # -----------------------------------------------------------------
  # 3. Android Hardware Attestation
  # -----------------------------------------------------------------
  # Nutzt die Android Keystore Key Attestation (TEE / StrongBox).
  # Der AuthS validiert die Zertifikatskette gegen die Google Hardware
  # Attestation Root CA. Optional kann ein Play Integrity Token zur
  # zusätzlichen App-Integritätsprüfung mitgeliefert werden.
  # -----------------------------------------------------------------
  - title: Android Attestation
    required:
      - attestation_type
      - client_name
      - jwks
      - android_key_attestation_certificate_chain
      - signed_hash_puk_client_sig
      - user_email
    properties:
      attestation_type:
        type: string
        const: android
      client_name: { type: string }
      token_endpoint_auth_method: { type: string }
      grant_types:
        type: array
        items: { type: string }
      redirect_uris: { $ref: "#/definitions/redirect_uris" }
      user_email: { $ref: "#/definitions/user_email" }
      jwks:
        description: >-
          Öffentlicher Client-Signaturschlüssel (ECDSA P-256).
        type: object
        properties:
          keys:
            type: array
            items: { $ref: "#/definitions/jwk" }
        required: [keys]
      android_key_attestation_certificate_chain:
        type: array
        description: >-
          X.509-Zertifikatskette der Android Key Attestation, beginnend
          mit dem Blatt-Zertifikat des attestierten Schlüssels (C.AK.Sig) bis zur
          Google Hardware Attestation Root CA. Jedes Zertifikat ist
          Base64-kodiert (DER-Format).
        items:
          type: string
          description: Base64-kodiertes DER X.509-Zertifikat.
        minItems: 3
      signed_hash_puk_client_sig:
        type: string
        description: >-
          Selbstsignatur: Signatur des SHA-256-Hashes von puk_client_sig,
          erstellt mit prk_client_sig (Proof-of-Possession des Client
          Instance Keys). Base64url-kodiert. Die Bindung
          AK ↔ puk_client_sig weist bereits die attestationChallenge im
          Blatt-Zertifikat der android_key_attestation_certificate_chain
          nach (attestationChallenge == SHA-256(puk_client_sig)); eine
          AK-Signatur ist hier daher nicht erforderlich.
      play_integrity_token:
        type: string
        description: >-
          Optionales Token der Google Play Integrity API (Base64-kodiert).
          Ermöglicht dem AuthS die zusätzliche App-Integritätsprüfung
          (meets_basic_integrity, meets_device_integrity).

  # -----------------------------------------------------------------
  # 4. ZETA Attestation Token (Fast-Path)
  # -----------------------------------------------------------------
  # Wird verwendet, wenn bereits ein gültiger ZETA Guard Attestation
  # Token vorliegt (aus einer früheren Hardware-Attestierung).
  # Der AuthS prüft die Token-Signatur, verifiziert
  # signed_hash_puk_client_sig als Selbstsignatur mit puk_client_sig
  # (aus jwks) und extrahiert attestation_type sowie puk_ak_sig
  # (cnf.jwk) aus dem Token, um attestation_pop plattformspezifisch
  # zu verifizieren (apple: CBOR-Assertion; android/tpm: rohe Signatur).
  # -----------------------------------------------------------------
  - title: ZETA Attestation Token
    required:
      - attestation_type
      - client_name
      - jwks
      - zeta_attestation_token
      - signed_hash_puk_client_sig
      - attestation_pop
    properties:
      attestation_type:
        type: string
        const: zeta_attestation_token
      client_name: { type: string }
      token_endpoint_auth_method: { type: string }
      grant_types:
        type: array
        items: { type: string }
      redirect_uris: { $ref: "#/definitions/redirect_uris" }
      jwks:
        description: >-
          Öffentlicher Client-Signaturschlüssel (ECDSA P-256).
        type: object
        properties:
          keys:
            type: array
            items: { $ref: "#/definitions/jwk" }
        required: [keys]
      zeta_attestation_token:
        type: string
        description: >-
          Signiertes JWT, ausgestellt vom ZETA Guard nach erfolgreicher
          Hardware-Attestierung. Enthält attestation_type
          (tpm | apple | android), puk_ak_sig (cnf.jwk) und verifizierte
          Plattform-Claims. Siehe zeta-attestation-token.yaml.
      signed_hash_puk_client_sig:
        type: string
        description: >-
          Selbstsignatur: Signatur des SHA-256-Hashes von puk_client_sig,
          erstellt mit prk_client_sig (Proof-of-Possession des Client
          Instance Keys). Base64url-kodiert. Einheitlich für alle
          Plattformen.
      attestation_pop:
        type: string
        description: >-
          Frischer Besitznachweis des Attestation Keys (prk_ak_sig). Bindet
          den (ggf. neuen) Client Instance Key an den bereits attestierten
          Attestation Key. Das Format bestimmt der AuthS anhand des
          attestation_type-Claims im zeta_attestation_token:

          apple: Base64-kodiertes CBOR-Assertion-Objekt aus
          DCAppAttestService.generateAssertion(keyId:clientDataHash:) mit
          clientDataHash = SHA-256(puk_client_sig). Der AuthS verifiziert
          die Signatur über SHA-256(authenticatorData || clientDataHash)
          gegen cnf.jwk (puk_ak_sig) aus dem Token und prüft rpIdHash
          sowie die Monotonie des Counters.

          android | tpm: Base64url-kodierte Signatur über
          SHA-256(puk_client_sig), erstellt mit prk_ak_sig. Der AuthS
          verifiziert gegen cnf.jwk (puk_ak_sig) aus dem Token.

  # -----------------------------------------------------------------
  # 5. Legacy / Software Attestation
  # -----------------------------------------------------------------
  - title: Legacy / Software Attestation
    required:
      - client_name
      - jwks
      - token_endpoint_auth_method
    properties:
      attestation_type:
        type: string
        enum: [software]
      client_name: { type: string }
      token_endpoint_auth_method: { type: string }
      grant_types:
        type: array
        items: { type: string }
      redirect_uris: { $ref: "#/definitions/redirect_uris" }
      user_email: { $ref: "#/definitions/user_email" }
      jwks:
        description: >-
          Öffentlicher Client-Signaturschlüssel (ECDSA P-256).
        type: object
        properties:
          keys:
            type: array
            items: { $ref: "#/definitions/jwk" }
        required: [keys]

definitions:
  user_email:
    type: string
    format: email
    description: >-
      E-Mail-Adresse des Nutzers für die Trust-On-First-Use (TOFU) Bindung
      mobiler Clients (Android, Apple). Der AuthS sendet an diese Adresse
      Out-of-Band eine E-Mail mit einem OTP-Bestätigungscode, den der Nutzer
      anschließend über POST /register/verify bestätigt
      (siehe Abb-ZETA-DCR-für-mobile-Clients.puml).
  redirect_uris:
    type: array
    description: >-
      Liste der Redirection-Endpunkte des Clients (RFC 6749 Abschnitt 3.1.2,
      RFC 8252 für native Apps). Die URIs werden NICHT zur Laufzeit frei gewählt,
      sondern vom Hersteller vorab bei der gematik registriert. Erst dadurch können
      sie (a) im AuthS für die DCR-Prüfung hinterlegt werden — beim DCR muss jede
      übergebene redirect_uri exakt (String-Vergleich) einer registrierten URI
      entsprechen — und (b) in das Entity Statement des AuthS aufgenommen werden,
      gegen das der sektorale IDP die oidc_redirect_uri beim PAR prüft. Die URIs liegen
      auf einer vom App-Hersteller kontrollierten Domain (dem Universal-/App-Link-Host)
      und stehen damit schon zur Entwicklungszeit fest — unabhängig vom AuthS, dessen
      FQDN der Client erst nach Abruf von opr-well-known/as-well-known auflöst. Die
      redirect_uris zeigen also NICHT auf die AuthS-Domain.

      Für native mobile Clients werden zwei claimed-HTTPS-URIs (Universal Links /
      App Links) je App registriert. Beide Auth Code Flows enden über denselben
      App-/Universal-Link in der App; der ZETA Client unterscheidet den beim AuthS zu
      nutzenden Endpunkt über den LETZTEN Pfad-Abschnitt (Konvention "/cb/<app>/<flow>"):
        - ".../oidc" = oidc_redirect_uri → SekIDP Auth Code Flow; der ZETA Client reicht
          den über diese URI empfangenen Code an den redirection_endpoint des AuthS
          weiter (NICHT /token). Diese URI wird ins AuthS-Entity-Statement aufgenommen;
          der AuthS erkennt am Suffix, welche URI für den SekIDP bestimmt ist.
        - ".../app" = app_redirect_uri → ZETA Guard Auth Code Flow; der ZETA Client
          reicht den Code an den /token-Endpunkt des AuthS weiter.
      Die OS-seitige Verknüpfung erfolgt über apple-app-site-association bzw.
      assetlinks.json (Deployment, kein Laufzeit-Flow).
    items:
      type: string
      format: uri
      description: >-
        Claimed-HTTPS-Redirection-URI. Der letzte Pfad-Abschnitt (oidc|app) bestimmt,
        welchem Auth Code Flow die URI zugeordnet ist (siehe Beschreibung des Arrays).
      pattern: '^https://.+/(oidc|app)$'
    minItems: 1
  jwk:
    type: object
    properties:
      kty: { type: string }
      crv: { type: string }
      x: { type: string }
      y: { type: string }
      n: { type: string }
      e: { type: string }
    required: [kty]