TDoc: S4-260192

[Technical] The proposal introduces a “Digital Credential / Base Avatar Assertion (BAA)” but does not define its normative format, mandatory fields, cryptographic algorithms, or validation rules (Figure Y is referenced but not provided), making interoperability and conformance impossible.

[Technical] Trust model is underspecified: UE2 “verifies BAA validity” via issuer signature, but there is no definition of how UE2 obtains/validates issuer trust anchors (operator PKI, WebPKI, cross-operator federation, roaming), nor how revocation/expiry is handled.

[Technical] The procedure says UE2 may obtain the BAA “from UE1 or Issuer” without specifying the transport, integrity protection, and binding to the IMS session (e.g., SIP/SDP conveyance, MSRP, HTTP), leaving clear MITM/replay risks and no linkage to the authenticated IMS identity.

[Technical] The key binding is unclear: UE1 generates a key pair “associated with selected avatar presentation,” but the contribution does not specify what identifier of the avatar representation is signed into the BAA, how collisions/updates are handled, or how the avatar data hash/reference is bound to prevent substitution.

[Technical] There is no explicit binding between the BAA subject and the user’s IMS/3GPP identity (IMPU/IMPI/SUPI) or the access authentication (AKA), so a valid BAA could be presented in a different IMS context unless additional binding is specified.

[Technical] The issuer “verifies that a Base Avatar represents its owner” is a major security claim but no verification method is described (biometrics, KYC, operator registration, device attestation), making the assurance level undefined and potentially inconsistent across deployments.

[Technical] The “proof of possession of private key” is mentioned but no protocol is defined (challenge-response, signature over nonce, channel binding), and it’s unclear when UE2 verifies PoP versus only verifying issuer signature.

[Technical] Lifecycle management is missing: no procedures for BAA renewal, revocation (lost device, compromised key), avatar updates, key rotation, or multiple devices per user—critical for any credential-based scheme.

[Technical] Privacy implications are not addressed: a persistent BAA could enable cross-service/user tracking; there is no discussion of minimizing identifiers, using pairwise pseudonyms, selective disclosure, or limiting disclosure to UE2 vs network.

[Technical] The scope is inconsistent with the stated gap: the contribution targets “avatar-related APIs” but the described mechanism is UE-to-UE credential presentation; it does not cover API authentication/authorization semantics (OAuth2/3GPP NEF-style, tokens, scopes) or network-side enforcement.

[Technical] The proposal does not clarify whether authentication is end-to-end (UE1↔UE2) or network-mediated (IMS core involvement), and therefore does not specify where security termination points are and what entities are in the trust boundary.

[Editorial] The document proposes adding sub-clause “8.3.4” but does not indicate which specification/TR this clause belongs to, nor how it aligns with existing clause numbering and terminology in TS/TR 26.264/26.813/33.328.

[Editorial] Several key references are vague or missing (e.g., “Figure Z example implementation,” “Figure Y structure”), and terms like “Base Avatar Representation” vs “avatar presentation” are used inconsistently, which will cause ambiguity in normative text.

[Editorial] The contribution states “TR 26.813 and TS 33.328 do not address these security aspects” but does not cite specific clauses or gaps; adding targeted gap statements and requirements would strengthen the justification and help SA3 alignment.