ETSI TS 129 526 V19.4.0 (2026-03)

5G; 5G System; Network Slice-Specific and SNPN Authentication and Authorization services; Stage 3 (3GPP TS 29.526 version 19.4.0 Release 19)

RTS/TSGC-0429526vj40

General Information

• Status: Not Published
• Technical Committee: 3GPP CT 4 - MAP/CAMEL/GTP/BCH/SS/TrFO/IMS/GUP/WLAN (formely CN4)
• Current Stage: 8 - Draft receipt by ETSI Secretariat
• Completion Date: 10-Mar-2026

Standards Content (Sample)

TECHNICAL SPECIFICATION
5G;
5G System; Network Slice-Specific and SNPN Authentication
and Authorization services; Stage 3
(3GPP TS 29.526 version 19.4.0 Release 19)


3GPP TS 29.526 version 19.4.0 Release 19 1 ETSI TS 129 526 V19.4.0 (2026-03)

Reference
RTS/TSGC-0429526vj40
Keywords
5G
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: [phone]  Fax: [phone]

Siret N° 348 623 562 00017 - APE 7112B
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° w061004871

Important notice
The present document can be downloaded from the
ETSI Search & Browse Standards application.
The present document may be made available in electronic versions and/or in print. The content of any electronic and/or
print versions of the present document shall not be modified without the prior written authorization of ETSI. In case of any
existing or perceived difference in contents between such versions and/or in print, the prevailing version of an ETSI
deliverable is the one made publicly available in PDF format on ETSI deliver repository.
Users should be aware that the present document may be revised or have its status changed,
this information is available in the Milestones listing.
If you find errors in the present document, please send your comments to
the relevant service listed under Committee Support Staff.
If you find a security vulnerability in the present document, please report it through our
Coordinated Vulnerability Disclosure (CVD) program.
Notice of disclaimer & limitation of liability
The information provided in the present deliverable is directed solely to professionals who have the appropriate degree of
experience to understand and interpret its content in accordance with generally accepted engineering or
other professional standard and applicable regulations.
No recommendation as to products and services or vendors is made or should be implied.
No representation or warranty is made that this deliverable is technically accurate or sufficient or conforms to any law
and/or governmental rule and/or regulation and further, no representation or warranty is made of merchantability or fitness
for any particular purpose or against infringement of intellectual property rights.
In no event shall ETSI be held liable for loss of profits or any other incidental or consequential damages.

Any software contained in this deliverable is provided "AS IS" with no warranties, express or implied, including but not
limited to, the warranties of merchantability, fitness for a particular purpose and non-infringement of intellectual property
rights and ETSI shall not be held liable in any event for any damages whatsoever (including, without limitation, damages
for loss of profits, business interruption, loss of information, or any other pecuniary loss) arising out of or related to the use
of or inability to use the software.
Copyright Notification
No part may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying and
microfilm except as authorized by written permission of ETSI.
The content of the PDF version shall not be modified without the written authorization of ETSI.
The copyright and the foregoing restriction extend to reproduction in all media.

© ETSI 2026.
All rights reserved.
ETSI
3GPP TS 29.526 version 19.4.0 Release 19 2 ETSI TS 129 526 V19.4.0 (2026-03)
Intellectual Property Rights
Essential patents
IPRs essential or potentially essential to normative deliverables may have been declared to ETSI. The declarations
pertaining to these essential IPRs, if any, are publicly available for ETSI members and non-members, and can be
found in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to
ETSI in respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the
ETSI IPR online database.
Pursuant to the ETSI Directives including the ETSI IPR Policy, no investigation regarding the essentiality of IPRs,
including IPR searches, has been carried out by ETSI. No guarantee can be given as to the existence of other IPRs not
referenced in ETSI SR 000 314 (or the updates on the ETSI Web server) which are, or may be, or may become,
essential to the present document.
Trademarks
The present document may include trademarks and/or tradenames which are asserted and/or registered by their owners.
ETSI claims no ownership of these except for any which are indicated as being the property of ETSI, and conveys no
right to use or reproduce any trademark and/or tradename. Mention of those trademarks in the present document does
not constitute an endorsement by ETSI of products, services or organizations associated with those trademarks.
DECT™, PLUGTESTS™, UMTS™ and the ETSI logo are trademarks of ETSI registered for the benefit of its
Members. 3GPP™, LTE™ and 5G™ logo are trademarks of ETSI registered for the benefit of its Members and of the
3GPP Organizational Partners. oneM2M™ logo is a trademark of ETSI registered for the benefit of its Members and of ®
the oneM2M Partners. GSM and the GSM logo are trademarks registered and owned by the GSM Association.
Legal Notice
This Technical Specification (TS) has been produced by ETSI 3rd Generation Partnership Project (3GPP).
The present document may refer to technical specifications or reports using their 3GPP identities. These shall be
interpreted as being references to the corresponding ETSI deliverables.
The cross reference between 3GPP and ETSI identities can be found at 3GPP to ETSI numbering cross-referencing.
Modal verbs terminology
In the present document "shall", "shall not", "should", "should not", "may", "need not", "will", "will not", "can" and
"cannot" are to be interpreted as described in clause 3.2 of the ETSI Drafting Rules (Verbal forms for the expression of
provisions).
"must" and "must not" are NOT allowed in ETSI deliverables except when used in direct citation.
ETSI
3GPP TS 29.526 version 19.4.0 Release 19 3 ETSI TS 129 526 V19.4.0 (2026-03)
Contents
Intellectual Property Rights . 2
Legal Notice . 2
Modal verbs terminology . 2
Foreword . 6
1 Scope . 8
2 References . 8
3 Definitions, abbreviations . 9
3.1 Definitions . 9
3.2 Abbreviations . 9
4 Overview . 9
4.1 Introduction . 9
5 Services offered by the NSSAAF . 10
5.1 Introduction . 10
5.2 Nnssaaf_NSSAA Service . 10
5.2.1 Service Description . 10
5.2.2 Service Operations . 10
5.2.2.1 Introduction . 10
5.2.2.2 Authenticate . 11
5.2.2.2.1 General . 11
5.2.2.3 Re-Authentication Notification . 13
5.2.2.3.1 General . 13
5.2.2.4 Revocation Notification . 15
5.2.2.4.1 General . 15
5.3 Nnssaaf_AIW Service . 16
5.3.1 Service Description . 16
5.3.2 Service Operations . 16
5.3.2.1 Introduction . 16
5.3.2.2 Authenticate . 16
5.3.2.2.1 General . 16
6 API Definitions . 18
6.1 Nnssaaf_NSSAA Service API . 18
6.1.1 Introduction. 18
6.1.2 Usage of HTTP . 19
6.1.2.1 General . 19
6.1.2.2 HTTP standard headers . 19
6.1.2.2.1 General . 19
6.1.2.2.2 Content type . 19
6.1.2.3 HTTP custom headers . 19
6.1.3 Resources . 19
6.1.3.1 Overview . 19
6.1.3.2 Resource: slice-authentications (Collection) . 20
6.1.3.2.1 Description . 20
6.1.3.2.2 Resource Definition . 20
6.1.3.2.3 Resource Standard Methods . 20
6.1.3.2.4 Resource Custom Operations . 22
6.1.3.3 Resource: slice-authentication (Document) . 22
6.1.3.3.1 Description . 22
6.1.3.3.2 Resource Definition . 22
6.1.3.3.3 Resource Standard Methods . 22
6.1.3.3.4 Resource Custom Operations . 24
6.1.4 Custom Operations without associated resources . 24
6.1.4.1 Overview . 24
ETSI
3GPP TS 29.526 version 19.4.0 Release 19 4 ETSI TS 129 526 V19.4.0 (2026-03)
6.1.5 Notifications . 24
6.1.5.1 General . 24
6.1.5.2 Re-authentication Notification . 24
6.1.5.2.1 Description . 24
6.1.5.2.2 Target URI . 24
6.1.5.2.3 Standard Methods . 25
6.1.5.3 Revocation Notification . 25
6.1.5.3.1 Description . 25
6.1.5.3.2 Target URI . 25
6.1.5.3.3 Standard Methods . 26
6.1.6 Data Model . 26
6.1.6.1 General . 26
6.1.6.2 Structured data types . 27
6.1.6.2.1 Introduction . 27
6.1.6.2.2 Type: SliceAuthInfo . 28
6.1.6.2.3 Type: SliceAuthContext . 28
6.1.6.2.4 Type: SliceAuthConfirmationData . 28
6.1.6.2.5 Type: SliceAuthConfirmationResponse . 29
6.1.6.2.6 Type: SliceAuthReauthNotification . 29
6.1.6.2.7 Type: SliceAuthRevocNotification . 29
6.1.6.3 Simple data types and enumerations . 29
6.1.6.3.1 Introduction . 29
6.1.6.3.2 Simple data types . 29
6.1.6.3.3 Enumeration: SliceAuthNotificationType . 30
6.1.6.4 Data types describing alternative data types or combinations of data types . 30
6.1.6.5 Binary data . 30
6.1.7 Error Handling . 30
6.1.7.1 General . 30
6.1.7.2 Protocol Errors . 30
6.1.7.3 Application Errors . 30
6.1.8 Feature negotiation . 31
6.1.9 Security . 31
6.1.10 HTTP redirection . 31
6.2 Nnssaaf_AIW Service API . 32
6.2.1 Introduction. 32
6.2.2 Usage of HTTP . 32
6.2.2.1 General . 32
6.2.2.2 HTTP standard headers . 32
6.2.2.2.1 General . 32
6.2.2.2.2 Content type . 32
6.2.2.3 HTTP custom headers . 32
6.2.3 Resources . 33
6.2.3.1 Overview . 33
6.2.3.2 Resource: authentications (Collection) . 33
6.2.3.2.1 Description . 33
6.2.3.2.2 Resource Definition . 33
6.2.3.2.3 Resource Standard Methods . 34
6.2.3.3 Resource: authentication (Document) . 35
6.2.3.3.1 Description . 35
6.2.3.3.2 Resource Definition . 35
6.2.3.3.3 Resource Standard Methods . 35
6.2.4 Custom Operations without associated resources . 37
6.2.5 Notifications . 37
6.2.6 Data Model . 37
6.2.6.1 General . 37
6.2.6.2 Structured data types . 38
6.2.6.2.1 Introduction . 38
6.2.6.2.2 Type: AuthInfo . 38
6.2.6.2.3 Type: AuthContext . 38
6.2.6.2.4 Type: AuthConfirmationData . 38
6.2.6.2.5 Type: AuthConfirmationResponse . 39
6.2.6.3 Simple data types and enumerations . 39
ETSI
3GPP TS 29.526 version 19.4.0 Release 19 5 ETSI TS 129 526 V19.4.0 (2026-03)
6.2.6.3.1 Introduction . 39
6.2.6.3.2 Simple data types . 39
6.2.7 Error Handling . 39
6.2.7.1 General . 39
6.2.7.2 Protocol Errors . 39
6.2.7.3 Application Errors . 39
6.2.8 Feature negotiation . 40
6.2.9 Security . 40
6.2.10 HTTP redirection . 40
Annex A (normative): OpenAPI specification . 41
A.1 General . 41
A.2 Nnssaaf_NSSAA API. 41
A.3 Nnssaaf_AIW API . 47
Annex B (informative): Change history . 51
History . 54

ETSI
3GPP TS 29.526 version 19.4.0 Release 19 6 ETSI TS 129 526 V19.4.0 (2026-03)
Foreword
This Technical Specification has been produced by the 3rd Generation Partnership Project (3GPP).
The contents of the present document are subject to continuing work within the TSG and may change following formal
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an
identifying change of release date and an increase in version number as follows:
Version x.y.z
where:
x the first digit:
1 presented to TSG for information;
2 presented to TSG for approval;
3 or greater indicates TSG approved document under change control.
y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections,
updates, etc.
z the third digit is incremented when editorial only changes have been incorporated in the document.
In the present document, modal verbs have the following meanings:
shall indicates a mandatory requirement to do something
shall not indicates an interdiction (prohibition) to do something
The constructions "shall" and "shall not" are confined to the context of normative provisions, and do not appear in
Technical Reports.
The constructions "must" and "must not" are not used as substitutes for "shall" and "shall not". Their use is avoided
insofar as possible, and they are not used in a normative context except in a direct citation from an external, referenced,
non-3GPP document, or so as to maintain continuity of style when extending or modifying the provisions of such a
referenced document.
should indicates a recommendation to do something
should not indicates a recommendation not to do something
may indicates permission to do something
need not indicates permission not to do something
The construction "may not" is ambiguous and is not used in normative elements. The unambiguous constructions
"might not" or "shall not" are used instead, depending upon the meaning intended.
can indicates that something is possible
cannot indicates that something is impossible
The constructions "can" and "cannot" are not substitutes for "may" and "need not".
will indicates that something is certain or expected to happen as a result of action taken by an agency
the behaviour of which is outside the scope of the present document
will not indicates that something is certain or expected not to happen as a result of action taken by an
agency the behaviour of which is outside the scope of the present document
might indicates a likelihood that something will happen as a result of action taken by some agency the
behaviour of which is outside the scope of the present document
ETSI
3GPP TS 29.526 version 19.4.0 Release 19 7 ETSI TS 129 526 V19.4.0 (2026-03)
might not indicates a likelihood that something will not happen as a result of action taken by some agency
the behaviour of which is outside the scope of the present document
In addition:
is (or any other verb in the indicative mood) indicates a statement of fact
is not (or any other negative verb in the indicative mood) indicates a statement of fact
The constructions "is" and "is not" do not indicate requirements.
ETSI
3GPP TS 29.526 version 19.4.0 Release 19 8 ETSI TS 129 526 V19.4.0 (2026-03)
1 Scope
The present document specifies the stage 3 protocol and data model for the Nnssaaf Service Based Interface. It provides
stage 3 protocol definitions and message flows, and specifies the API for each service offered by the NSSAAF.
The 5G System stage 2 architecture and procedures are specified in 3GPP TS 23.501 [2] and 3GPP TS 23.502 [3].
The Technical Realization of the Service Based Architecture and the Principles and Guidelines for Services Definition
are specified in 3GPP TS 29.500 [4] and 3GPP TS 29.501 [5].
2 References
The following documents contain provisions which, through reference in this text, constitute provisions of the present
document.
- References are either specific (identified by date of publication, edition number, version number, etc.) or
non-specific.
- For a specific reference, subsequent revisions do not apply.
- For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same
Release as the present document.
[1] 3GPP TR 21.905: "Vocabulary for 3GPP Specifications".
[2] 3GPP TS 23.501: "System Architecture for the 5G System; Stage 2".
[3] 3GPP TS 23.502: "Procedures for the 5G System; Stage 2".
[4] 3GPP TS 29.500: "5G System; Technical Realization of Service Based Architecture; Stage 3".
[5] 3GPP TS 29.501: "5G System; Principles and Guidelines for Services Definition; Stage 3".
[6] OpenAPI: "OpenAPI Specification Version 3.0.0", https://spec.openapis.org/oas/v3.0.0.
[7] 3GPP TR 21.900: "Technical Specification Group working methods".
[8] 3GPP TS 33.501: "Security architecture and procedures for 5G system".
[9] IETF RFC 6749: "The OAuth 2.0 Authorization Framework".
[10] 3GPP TS 29.510: "5G System; Network Function Repository Services; Stage 3".
[11] IETF RFC 9113: "HTTP/2".
[12] IETF RFC 8259: "The JavaScript Object Notation (JSON) Data Interchange Format".
[13] IETF RFC 9457: "Problem Details for HTTP APIs".
[14] IETF RFC 4648: "The Base16, Base32 and Base64 Data Encodings".
[15] 3GPP TS 29.503: "5G System; Unified Data Management Services; Stage 3".
[16] 3GPP TS 29.518: "5G System; Access and Mobility Management Services; Stage 3".
[17] 3GPP TS 29.536: "5G System; Network Slice Admission Control Services; Stage 3".
[18] 3GPP TS 29.509: "5G System; Authentication Server Services; Stage 3".
[19] 3GPP TS 29.571: "5G System; Common Data Types for Service Based Interfaces; Stage 3".

ETSI
3GPP TS 29.526 version 19.4.0 Release 19 9 ETSI TS 129 526 V19.4.0 (2026-03)
3 Definitions, abbreviations
3.1 Definitions
For the purposes of the present document, the terms and definitions given in 3GPP TR 21.905 [1] and the following
apply. A term defined in the present document takes precedence over the definition of the same term, if any, in 3GPP
TR 21.905 [1].
3.2 Abbreviations
For the purposes of the present document, the abbreviations given in 3GPP TR 21.905 [1] and the following apply. An
abbreviation defined in the present document takes precedence over the definition of the same abbreviation, if any, in
3GPP TR 21.905 [1].
NSSAA Network Slice-Specific Authentication and Authorization
NSSAAF Network Slice-specific and SNPN Authentication and Authorization Function
SNPN Standalone Non-Public Network

4 Overview
4.1 Introduction
Within the 5GC, the NSSAAF offers services to the AMF and the AUSF via the Nnssaaf service-based interface.
The AMF shall make use of the NSSAAF service when it needs to invoke network slice-specific authentication and
authorization for a specific UE and a specific S-NSSAI (see 3GPP TS 23.502 [3] clause 4.2.9.2, and
3GPP TS 33.501 [14] clause 16.2 and 16.3).
The NSSAAF service shall also be used by the AMF to receive slice re-authentication notification or slice authorization
revocation notification sent from the AAA-S (see 3GPP TS 23.502 [3] clause 4.2.9.3, 4.2.9.4 and 3GPP TS 33.501 [14]
clause 16.3 and 16.4).
The AUSF shall make use of the NSSAAF service when it needs to invoke a primary authentication in SNPN with
Credentials holder using AAA server; the AUSF shall also make use of this service during the UE onboarding
procedure in SNPN scenarios, when the Default Credentials Server (DCS) uses an AAA server for primary
authentication.
Figure 4.1-1 provides the reference model with focus on the NSSAAF.

Figure 4.1-1: Reference model – NSSAAF

ETSI
3GPP TS 29.526 version 19.4.0 Release 19 10 ETSI TS 129 526 V19.4.0 (2026-03)
5 Services offered by the NSSAAF
5.1 Introduction
The NSSAAF offers the following services via the Nnssaaf interface:
- Nnssaaf_NSSAA Service
- Nnssaaf_AIW Service
Table 5.1-1 summarizes the corresponding APIs defined for this specification.
Table 5.1-1: API Descriptions
Service Name Clause Description OpenAPI Specification File apiName Annex
Nnssaaf_NSSAA 5.2 Slice-specific TS29526_Nnssaaf_NSSAA.yaml nnssaaf- A.2
authentication and nssaa
authorization service
Nnssaaf_AIW 5.3 AAA Interworking TS29526_Nnssaaf_AIW.yaml nnssaaf- A.3
service aiw
5.2 Nnssaaf_NSSAA Service
5.2.1 Service Description
The Nnssaaf_NSSAA service provides slice-specific authentication and authorization for a given UE. The NSSAAF is
acting as NF Service Producer, while the AMF is the NF Service Consumer.
Following functionalities are provided by the Nnssaaf_NSSAA service:
- Perform slice-specific authentication and authorization for a given UE;
- Trigger slice-specific re-authentication to a given UE;
- Revoke the slice-specific authentication and authorization for a given UE.
The Nnssaaf_NSSAA service supports the following service operations.
Table 5.2.1-1: Service operations supported by the Nnssaaf_NSSAA service
Service Operations Description Operation Example
Semantics Consumer(s)
Authenticate Perform slice-specific authentication and Request/Response AMF
authorization for a given UE.
Re-Authentication Request slice-specific re-authentication and re-Callback AMF
Notification authorization for a given UE.
Revocation Request revocation of slice-specific Callback AMF
Notification authentication and authorization result for a
given UE.
5.2.2 Service Operations
5.2.2.1 Introduction
See Table 5.2.1-1 for an overview of the service operations supported by the Nnssaaf_NSSAA service.
ETSI
3GPP TS 29.526 version 19.4.0 Release 19 11 ETSI TS 129 526 V19.4.0 (2026-03)
5.2.2.2 Authenticate
5.2.2.2.1 General
The Authenticate service operation permits the NF Service Consumer (i.e. the AMF) to initiate slice-specific
authentication and authorization, e.g. during a UE Registration procedure or upon reception of a re-authentication
notification from the NSSAAF (see clause 5.2.2.3). The NSSAAF may relay the EAP message to an AAA-S and collect
the result of slice-specific authentication and authorization from the AAA-S, as specified in clause 4.2.9.2 of
3GPP TS 23.502 [3], and clause 16.3 of 3GPP TS 33.501 [8].
The NF Service Consumer (i.e. the AMF) shall send a POST request to the resource representing slice authentication
collection (i.e. …/slice-authentications) to request the NSSAAF to create the corresponding resource context and
perform slice-specific authentication and authorization.

Figure 5.2.2.2.1-1: Slice-Specific Authentication and Authorization
1. The NF Service Consumer (AMF) shall send a POST request to the NSSAAF, targeting the resource of slice
authentication collection (i.e. …/slice-authentications), to perform slice-specific authentication and
authorization.
The HTTP content shall contain the slice authentication information, which includes:
- UE ID (i.e. GPSI), if multiple GPSIs received from the UDM, the NF Service Consumer shall include any
one of the GPSIs.
- S-NSSAI
- EAP ID Response message (if it is received from the UE), or the EAP ID Response message with EAP ID
stored, or the EAP ID Response message with Null value (if EAP ID is not requested or received);
- optionally, the callback URI of the AMF to receive re-authentication notification from the NSSAAF;
ETSI
3GPP TS 29.526 version 19.4.0 Release 19 12 ETSI TS 129 526 V19.4.0 (2026-03)
- optionally, the callback URI of the AMF to receive revocation notification from the NSSAAF.
Based on local policy, the AMF may determine to provide callback URI(s) for receiving re-authentication
notification or revocation notification. For example, the callback URIs are provided for an UE identified with
low mobility characteristic.
If Slice-Specific Authentication and Authorization is triggered by the AMF during a Registration procedure as
described in clause 4.2.9.2 of 3GPP TS 23.502 [3], the AMF shall set "status" attribute for the given slice listed
in "nssaaStatusList" attribute to "PENDING" (See 3GPP TS 29.518 [16]).
2. The NSSAAF creates slice authentication context for the UE, and starts the slice-specific authentication and
authorization procedure. If the AAA-S is involved in slice-specific authentication and authorization procedure,
the NSSAAF shall forward the EAP ID Response message to the AAA-S if the EAP ID Response message does
not contain the Null value. Depending on the result, either step 3a or step 3b is performed. The NSSAAF obtains
the AAA-S address from local configuration, based on S-NSSAI.
3a. On success, "201 Created" shall be returned. The "Location" header shall contain the URI of the created resource
(e.g. ./slice-authentications/{authCtxId}). The content shall contain the slice authentication context, which
includes the EAP message generated by the NSSAAF or from the AAA-S. The NF Service Consumer (i.e. the
AMF) shall forward the received EAP message to the UE in NAS message, as specified in clause 4.2.9.2 of
3GPP TS 23.502 [3].
3b. On failure, one of the HTTP status code listed in Table 6.1.7.3-1 shall be returned. For a 4xx/5xx response, the
message body containing a ProblemDetails structure with the "cause" attribute set to one of the application error
listed in Table 6.1.7.3-1. If the slice is not authorized, the NSSAAF shall use the "SLICE_AUTH_REJECTED"
application error code.
3c. On redirection, the appropriate HTTP status code (e.g. "307 Temporary Redirect") shall be returned. A
RedirectResponse IE may be included in the content of POST response, as specified in table 6.1.3.2.3.1-3.
4. Once receiving EAP message from the UE, the NF Service Consumer (i.e. the AMF) shall send a PUT request to
the NSSAAF, targeting the resource of the slice authentication context (i.e. …/slice-
authentications/{authCtxId}).
The HTTP content shall carry the slice authentication confirmation data which includes:
- UE ID (i.e. GPSI)
- S-NSSAI
- EAP Message (which is received from the UE)
5. The NSSAAF checks and confirms the slice-specific authentication and authorization. If the AAA-S is involved,
the NSSAAF shall forward the EAP Message to the AAA-S to confirm the slice-specific authentication and
authorization. Depending on the result, either step 6a or step 6b is performed.
6a. On success, "200 OK" shall be returned. The content shall contain the slice authentication confirmation
response, which includes the EAP message (e.g. EAP success/failure message) generated by the NSSAAF or
from the AAA-S. The NF Service Consumer (i.e. the AMF) shall forward the EAP message to the UE in NAS
message.
If the UE is authenticated, the NSSAAF shall set the "authResult" attribute to "EAP_SUCCESS". If failed to
authenticate the UE, the "authResult" attribute shall be set to "EAP_FAILURE".
If subsequent EAP message exchange is needed between the UE and the NSSAAF(AAA-S), the NSSAAF shall
not include SliceAuthResult in the response message.
6b. On failure, one of the HTTP status codes listed in Table 6.1.7.3-1 shall be returned. For a 4xx/5xx response, the
message body containing a ProblemDetails structure with the "cause" attribute set to one of the application error
listed in Table 6.1.7.3-1.
6c. On redirection, the appropriate HTTP status code (e.g. "307 Temporary Redirect") shall be returned. A
RedirectResponse IE may be included in the content of POST response, as specified in table 6.1.3.3.3.1-3.
7-9. If subsequent EAP message exchange is needed between the UE and the NSSAAF to finish the EAP based
authentication, step 7-9 are performed. On failure, one of the HTTP status codes listed in Table 6.1.7.3-1 shall be
ETSI
3GPP TS 29.526 version 19.4.0 Release 19 13 ETSI TS 129 526 V19.4.0 (2026-03)
returned. For a 4xx/5xx response, the message body containing a ProblemDetails structure with the "cause"
attribute set to one of the application error listed in Table 6.1.7.3-1. On redirection, the appropriate HTTP status
code (e.g. "307 Temporary Redirect") shall be returned, and a RedirectResponse IE may be included in the
message body, as specified in table 6.1.3.3.3.1-3.
In above steps, if the AAA-S is involved in the slice-specific authentication and authorization procedure while
there is no expected response from the AAA-S in the case of time out, the NSSAAF shall return HTTP status
code "504 Gateway Timeout", with the message body containing a ProblemDetails structure with the "cause"
attribute set to "TIMED_OUT_REQUEST".
After the completion of slice-specific authentication and authorization procedure, it is up to implementation
whether the NSSAAF stores the slice authentication context and related resources for a configured period, or
deletes the context and resource immediately, e.g. depending on the potential need for AAA-S initiated slice-
specific re-authentication/revocation notification.
If the slice-specific authentication and authorization was successful (i.e. "authResult" attribute received from
NSSAAF in step 6a is set to "EAP_SUCCESS"), the AMF shall set "status" attribute for the given slice listed in
"nssaaStatusList" attribute to "EAP_SUCCESS" (see 3GPP TS 29.518 [16]).
If the slic
...