# 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:**
   - Deployed on UEs
   - Receives and securely stores BAA from issuer
   - Verifies BAA for avatar authentication
   - Proves possession of private key corresponding to public key in BAA

2. **Issuer:**
   - May be part of operator network operating the IMS for avatar calls, or a trusted external entity
   - Verifies that a Base Avatar represents its owner
   - Provides Digital Credential (BAA) to avatar owner's UE
   - Verifies authenticator possesses the private/public key pair
   - 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.