zyphr 0.1.39 → 0.1.41

data/lib/zyphr/api/auth_registration_api.rb

@@ -224,7 +224,7 @@ module Zyphr
     end
 
     # Sign in with Apple Game Center
-    # Exchange an Apple Game Center identity-verification assertion for a Zyphr end-user session. Zyphr independently re-verifies the assertion server-side (Apple certificate chain, RSA-SHA256 signature, timestamp freshness, single-use replay guard, and bundle-id binding) before provisioning-or-looking-up the user and minting tokens. The user is keyed on the modern scoped `playerId` (gamePlayerID).  ## Producing the assertion (Integration)  The assertion is produced **on-device by the iOS app** — there is no server-side way to mint it. The app calls GameKit's `GKLocalPlayer.fetchItems(forIdentityVerificationSignature:)`, which returns `publicKeyURL`, `signature`, `salt`, and `timestamp`; combine those with the local player's `gamePlayerID` and the app's bundle identifier and submit them here.  Two integration shapes are supported:   - **client-direct** — the iOS app holds the Zyphr application public     key and calls this endpoint itself.   - **backend-relayed** — the app forwards the fetched assertion fields     to the customer's own backend, which relays them to this endpoint;     the app never holds Zyphr keys. (This is the common shape for games.)  On any verification failure the response is a single opaque `401` `invalid_assertion` — the specific control that failed is never disclosed. 
+    # Exchange an Apple Game Center identity-verification assertion for a Zyphr end-user session. Zyphr independently re-verifies the assertion server-side (Apple certificate chain, RSA-SHA256 signature, timestamp freshness, single-use replay guard, and bundle-id binding) before provisioning-or-looking-up the user and minting tokens. The user is keyed on the player's `teamPlayerID` (the id GameKit signs the assertion over).  ## Producing the assertion (Integration)  The assertion is produced **on-device by the iOS app** — there is no server-side way to mint it. The app calls GameKit's `GKLocalPlayer.fetchItems(forIdentityVerificationSignature:)`, which returns `publicKeyURL`, `signature`, `salt`, and `timestamp`; combine those with the local player's `teamPlayerID` (NOT `gamePlayerID`) and the app's bundle identifier and submit them here.  Two integration shapes are supported:   - **client-direct** — the iOS app holds the Zyphr application public     key and calls this endpoint itself.   - **backend-relayed** — the app forwards the fetched assertion fields     to the customer's own backend, which relays them to this endpoint;     the app never holds Zyphr keys. (This is the common shape for games.)  On any verification failure the response is a single opaque `401` `invalid_assertion` — the specific control that failed is never disclosed. 
     # @param sign_in_with_game_center_request [SignInWithGameCenterRequest] 
     # @param [Hash] opts the optional parameters
     # @return [AuthResultResponse]
@@ -234,7 +234,7 @@ module Zyphr
     end
 
     # Sign in with Apple Game Center
-    # Exchange an Apple Game Center identity-verification assertion for a Zyphr end-user session. Zyphr independently re-verifies the assertion server-side (Apple certificate chain, RSA-SHA256 signature, timestamp freshness, single-use replay guard, and bundle-id binding) before provisioning-or-looking-up the user and minting tokens. The user is keyed on the modern scoped `playerId` (gamePlayerID).  ## Producing the assertion (Integration)  The assertion is produced **on-device by the iOS app** — there is no server-side way to mint it. The app calls GameKit's `GKLocalPlayer.fetchItems(forIdentityVerificationSignature:)`, which returns `publicKeyURL`, `signature`, `salt`, and `timestamp`; combine those with the local player's `gamePlayerID` and the app's bundle identifier and submit them here.  Two integration shapes are supported:   - **client-direct** — the iOS app holds the Zyphr application public     key and calls this endpoint itself.   - **backend-relayed** — the app forwards the fetched assertion fields     to the customer's own backend, which relays them to this endpoint;     the app never holds Zyphr keys. (This is the common shape for games.)  On any verification failure the response is a single opaque `401` `invalid_assertion` — the specific control that failed is never disclosed. 
+    # Exchange an Apple Game Center identity-verification assertion for a Zyphr end-user session. Zyphr independently re-verifies the assertion server-side (Apple certificate chain, RSA-SHA256 signature, timestamp freshness, single-use replay guard, and bundle-id binding) before provisioning-or-looking-up the user and minting tokens. The user is keyed on the player's `teamPlayerID` (the id GameKit signs the assertion over).  ## Producing the assertion (Integration)  The assertion is produced **on-device by the iOS app** — there is no server-side way to mint it. The app calls GameKit's `GKLocalPlayer.fetchItems(forIdentityVerificationSignature:)`, which returns `publicKeyURL`, `signature`, `salt`, and `timestamp`; combine those with the local player's `teamPlayerID` (NOT `gamePlayerID`) and the app's bundle identifier and submit them here.  Two integration shapes are supported:   - **client-direct** — the iOS app holds the Zyphr application public     key and calls this endpoint itself.   - **backend-relayed** — the app forwards the fetched assertion fields     to the customer's own backend, which relays them to this endpoint;     the app never holds Zyphr keys. (This is the common shape for games.)  On any verification failure the response is a single opaque `401` `invalid_assertion` — the specific control that failed is never disclosed. 
     # @param sign_in_with_game_center_request [SignInWithGameCenterRequest] 
     # @param [Hash] opts the optional parameters
     # @return [Array<(AuthResultResponse, Integer, Hash)>] AuthResultResponse data, response status code and response headers