Binding reference chain for the ZETA Guard
The released ZETA Guard requirements profile 1.3.0-0, document 1.0.2 dated 30 June 2026, pins gemSpec_ZETA 1.3.2 and gemSpec_Krypt 2.47.0 in Table 1. Its assessment tables select specific requirement IDs; citing the specification does not automatically select every paragraph as a Guard duty. The public mapping therefore records the ID, source version, responsible component and listed assessment categories. The G-App base has its own draft reference to ZETA 2.0.1_CC and Krypt 2.49.1; that reference chain remains separate.
Discovery, certificates and registration per Guard
The client validates actively used certificates, including hostname, validity, trust chain and revocation, under A_25340-01; dependent operations are rejected after an invalid result. Well-known requests use ETag and If-None-Match. Without Cache-Control, Well-known and JWKS are reloaded every 24 hours; a 404 while establishing resource communication triggers discovery again. The Guard advertises exactly one logical authorization server. Registration is per Guard; client-id and registration/configuration data remain associated with that Guard. An application tile does not itself define a separate registration instance.
PEP: token binding and targeted step-up
The PEP HTTP Proxy checks the access-token signature, validity, audience and scope as well as its DPoP binding; DPoP validation follows RFC 9449. An invalid access token produces HTTP 401 under A_25668. A_28525-01 requires a step-up signal with HTTP 401 when a required scope is missing or the audience does not match an existing, supported URL. This does not define a blanket MFA prompt after every 401. The application evaluates the specific authorization context; a visible login indicator alone does not authorize access.
ASL: inner and outer target binding
A_26681-01 binds use of the ZETA/ASL channel to zeta_asl_use values required or required_passthrough. The inner request contains an access token and DPoP token for the resource-server endpoint. With required_passthrough, the outer request additionally carries a matching token pair for the ASL endpoint. When ASL terminates at the HTTP Proxy, it checks the inner pair. With passthrough, it checks the outer pair and forwards to the terminating resource server. The service and its product specification determine this boundary; a generally optional Guard setting does not remove a service-specific ASL requirement.
PDP, application authorization and token lifecycle
Before issuing a new token set, the authorization server asks the policy engine. A denied policy decision is represented by HTTP 403; token claims must match the decision. Access and refresh tokens are DPoP-bound to the registered client instance. Refresh tokens are exchanged only once and rotated; the client protects session tokens and DPoP keys. An application-specific authorization backend can participate through the defined plug-in interface. Client management, manual deregistration and access to the registration access log remain separate functions. These ZETA functions do not replace ePA entitlements or the business rules of a DiPag or TI-Flow operation.
Stage 1 is not a universal mobile flow
A_28827 and A_28803 explicitly concern stage 1: the requesting IP address is recorded in the access token and compared on client requests. A negative result blocks access and refresh tokens and aborts the business operation. The specification assigns this simplified impossible-travel check to the LEI role with a stationary device. The mobile HCSA illustration does not derive universal IP binding from it. Mobile statements from 2.0.0_CC retain their draft status; the 2.0.1_CC edition referenced by the G-App profile remains unreviewed until the exact source is available.
G-App: exact requirement selection with an unresolved source edition
The G-App profile contains 57 distinct ZETA requirement IDs with 66 assessment assignments. It explicitly names 2.0.1_CC. The inspected 2.0.0_CC context draft contains A_25783-01 and A_27379-02, whereas the profile selects A_25783-02 and A_27379-03. The 55 matching IDs do not establish text equivalence to the missing edition. The SDK exception in section 3.2.1 concerns only Table 7 requirements already covered by Zeta-SDK functionality; other assessments and manufacturer duties remain distinct. A_25735-01 appears both in general UX Table 5 and in Table 10 for the PushNotification option. Both assignments are retained. The catalogue makes the profile reference inspectable; the full content of 2.0.1_CC remains unresolved.
Mobile flow in the ZETA 2.0.0_CC draft
The public draft describes mobile registration using a locally generated key, attestation evidence and an email OTP confirmation on first contact. Fast-path registration requires an already valid ZETA attestation token and further key checks. Android hardware attestation and Apple App Attest receive platform-specific treatment; the software fallback has no hardware trust binding and receives a lower trust rating. For OIDC, the draft describes Authorization Code, PAR and PKCE with DPoP-bound access tokens. The application client determines the service request and IDP context; the ZETA Client manages registration, keys and the authentication flow. These statements apply exclusively to 2.0.0_CC. The illustrative twelve-screen walkthrough remains an ITL example without implementation evidence.