Tech-
invite
3GPP
space
IETF
space
21
22
23
24
25
26
27
28
29
31
32
33
34
35
36
37
38
4‑5x
Content for
TR 23.700-95
Word version: 18.1.0
1…
4…
4
Key issues
5
Architectural requirements
6
Solutions
7
Overall evaluation
8
Conclusions
A
Use case examples
$
Change history
4
Key issues
p. 8
4.1
Key Issue #1: UE-originated API invocation
p. 8
4.1.1
Description
p. 8
4.2
Key Issue #2: AF-originated API invocation
p. 9
4.2.1
Description
p. 9
4.3
Key Issue #3: Providing and revoking resource owner consent upon invoking APIs
p. 9
4.3.1
Description
p. 9
4.4
Key Issue #4: Discovery of target API information
p. 10
4.4.1
Description
p. 10
5
Architectural requirements
p. 10
5.1
General requirements
p. 10
6
Solutions
p. 10
6.0
Mapping of Solutions to Key Issues
p. 10
6.1
Solution #1: Business relationship in SNA
p. 11
6.1.1
Solution description
p. 11
6.1.2
Solution evaluation
p. 12
6.2
Solution #2: Functional model description for SNA
p. 12
6.2.1
Solution description
p. 12
6.2.1.1
General
p. 12
6.2.1.2
Functional model
p. 12
6.2.1.2.1
Functional model description for the CAPIF with SNA enhancements
p. 12
6.2.1.2.2
Functional model description for the CAPIF with SNA enhancements to support 3rd party API provider
p. 13
6.2.1.3
Deployment models
p. 13
6.2.1.3.1
General
p. 13
6.2.1.3.2
Deployment of the authorization function within the CAPIF core function
p. 13
6.2.1.3.3
Collocated deployment of authorization function and CAPIF core function
p. 13
6.2.1.3.4
Deployment of the enhanced CAPIF by different organizations within the PLMN trust domain
p. 14
6.2.2
Solution evaluation
p. 15
6.3
Solution #3: Obtaining resource owner consent upon service API invocation
p. 15
6.3.1
Solution description
p. 15
6.3.1.1
General
p. 15
6.3.1.2
Resource owner registration
p. 15
6.3.1.3
Obtaining resource owner consent
p. 16
6.3.1.4
Updating resource owner consent
p. 17
6.3.2
Solution evaluation
p. 17
6.4
Solution #4: API invoker obtaining resource owner consent
p. 17
6.4.1
Solution description
p. 17
6.4.1.1
API invoker obtaining resource owner consent prior to the service API invocation
p. 18
6.4.2
Solution evaluation
p. 18
6.5
Solution #5: UE-originated API invocation within CAPIF
p. 18
6.5.1
Solution description
p. 18
6.5.2
Solution evaluation
p. 20
6.6
Solution #6: Discover a proper AEF with owner information
p. 20
6.6.1
Solution description
p. 20
6.6.2
Solution evaluation
p. 22
6.7
Solution #7: Reducing resource owner consent inquiry in a nested API invocation
p. 22
6.7.1
Solution description
p. 22
6.7.1.1
Reducing resource owner consent inquiry in a nested API invocation
p. 23
6.7.2
Solution evaluation
p. 24
7
Overall evaluation
p. 24
7.1
General
p. 24
7.2
Architecture evaluation
p. 24
7.3
Key issue and solution evaluation
p. 24
7.3.1
Introduction
p. 24
7.3.2
Overall evaluation of solutions for Key Issue #1
p. 25
7.3.3
Overall evaluation of solutions for Key Issue #2
p. 25
7.3.4
Overall evaluation of solutions for Key Issue #3
p. 25
7.3.5
Overall evaluation of solutions for Key Issue #4
p. 26
8
Conclusions
p. 26
A
Use case examples
p. 27
A.1
AF-originated API invocation (Gaming)
p. 27
A.1.1
General
p. 27
A.1.2
Pre-conditions
p. 27
A.1.3
Service flows
p. 27
A.1.4
Post-conditions
p. 27
A.2
UE-originated API invocation (Location tracking)
p. 27
A.2.1
General
p. 27
A.2.2
Pre-conditions
p. 27
A.2.3
Service flows
p. 28
A.2.4
Post-conditions
p. 28
$
Change history
p. 29