Summary of S4-260192: Authentication for Avatar Data

Document Overview

This contribution from Nokia proposes authentication mechanisms for avatar data in IMS-based avatar calls as part of the FS_Avatar_Ph2_MED study item (Rel-20). The document addresses security gaps identified in Rel-19 TS 26.264, specifically focusing on authentication schemes for avatar-related APIs.

Background and Motivation

The Rel-20 SID FS_Avatar_Ph2_MED (approved at SA#110, Dec 2025) includes an objective to study security implications in collaboration with SA3, covering:
- Identification and authentication (including schemes for Avatar related APIs)
- Privacy preservation
- Content protection (watermarking and DRM)
- Secure distribution mechanisms for Avatar data

Currently, TR 26.813 and TS 33.328 do not address these security aspects.

Main Technical Contributions

Proposed Security Framework for IMS-based Avatar Calls

The contribution proposes adding a new sub-clause 8.3.4 covering security considerations for IMS-based avatar calls.

Authentication Mechanism

Core Concept:
- Introduces a Digital Credential-based solution using Base Avatar Assertion (BAA)
- BAA cryptographically binds the Base Avatar Representation to the avatar owner
- Ensures that a base avatar represents the actual user of the avatar

Architecture Components:

1. Authenticator:
2. Deployed on UEs
3. Receives and securely stores BAA from issuer
4. Verifies BAA for avatar authentication

5. Proves possession of private key corresponding to public key in BAA

6. Issuer:

7. May be part of operator network operating the IMS for avatar calls, or a trusted external entity
8. Verifies that a Base Avatar represents its owner
9. Provides Digital Credential (BAA) to avatar owner's UE
10. Verifies authenticator possesses the private/public key pair
11. Provides authorization functions and provisioning server

Base Avatar Assertion (BAA) Structure:
- Digital Credential proving a Base Avatar represents a user owning a specific private/public key pair
- Generic structure shown in Figure Y (referenced but not detailed in text)

Operational Procedures

BAA Issuance Procedure (Steps 1-7):

1. Authorization Request: Application on UE1 generates authorization request for selected avatar representation and sends to Issuer
2. User Verification: Issuer verifies request and authorizes user (UE1) if verification succeeds
3. Authorization Response: Issuer sends response to UE1 indicating successful authorization, including Issuer ID
4. Key Pair Generation: Authenticator on UE1 creates public/private key pair associated with selected avatar presentation
5. Enrolment Request: Authenticator sends enrolment request to Issuer (including public key)
6. BAA Creation: Issuer verifies enrolment request (user-avatar match, public key validity), creates BAA with signature
7. BAA Delivery: Issuer sends enrolment response to UE1 including BAA; Authenticator stores BAA for future authentication

Avatar Authentication Procedure (Step 8):

• When UE1 initiates avatar call with UE2 using selected avatar
• UE2 obtains BAA from UE1 or Issuer
• Application/authenticator on UE2 verifies BAA validity (e.g., signature verification to confirm trusted issuer)
• Authentication typically occurs at:
• Beginning of avatar calls
• Session resumption or restart

Implementation Example

Figure Z provides an example implementation of authenticator and issuer in the current system architecture (specific details not provided in text).

Proposal

The contribution proposes to add the above content as a base CR to address authentication requirements for avatar data in IMS-based avatar calls.