Subscriber onboarding using a verified digital identity

Abstract

Apparatuses, methods, and systems for digital identifier based subscription onboarding are disclosed. An apparatus includes a memory coupled to a processor, the memory storing instructions executable by the processor to control the apparatus to obtain a digital identifier (“DIG-ID”), the DIG-ID including a verifiable secure identity, and generate a digital signature of the DIG-ID and a timestamp using a private key. The instructions are executable by the processor to control the apparatus to send a first request to a mobile communication network and receive a response containing an indication of successful onboarding authentication and the verified DIG-ID, the first request including the DIG-ID, the timestamp, and the generated digital signature. The instructions are executable by the processor to establish a provisioning connection to the mobile communication network and receive a subscription credential and / or a user subscription profile via the provisioning connection.

Description

Technical Field

[0001] The topics disclosed in this article generally relate to wireless communication, and more specifically to onboarding based on digital IDs. Background Technology

[0002] The following abbreviations are defined herein, and at least some of them are mentioned in the following description: 3rd Generation Partnership Project (“3GPP”), 5th Generation Access Network (“5G-AN”), 5th Generation Core Network (“5CG”), 5th Generation System (“5GS”), Authentication, Authorization and Accounting (“AAA”), AAA Agent (“AAA-P”), Affirmative Acknowledgment (“ACK”), Authentication and Key Negotiation (“AKA”), Access and Mobility Management Function (“AMF”), Application Programming Interface (“API”), Authentication Credentials Storage and Processing Function (“ARPF”), Access Layer Application Server (“AS”), Authentication Server Function (“AUSF”), Authentication Token (“AUTN”), Authentication Vector (“AV”), Base Station (“BS”), Blockchain Service Enabler Function (“BSEF”), Bandwidth Component (“BWP”), Idle Channel Assessment (“CCA”), Code Division Multiple Access (“CDMA”), Control Element (“CE”), Cyclic Prefix (“CP”), Channel State Information (“CSI”), Configuration License (“CG”), Core Network (“CN”), Control Plane (“CP”), Decentralized Identifier (“…”) Digital Identifier (“DIG-ID”), Digital Signature (“DS”), Distributed Ledger Technology (“DLT”), Digital Identification, Authentication and Trust Services Enabler Function (“D-IDASEF”), Subscription Persistent Identifier Based on Digital ID (“D-SUPI”), Downlink Control Information (“DCI”), Downlink (“DL”), Discontinuous Transmission (“DTX”), Enhanced Free Channel Assessment (“eCCA”), Electronic Identification, Authentication and Trust Services (“elDAS”), Enhanced Mobile Broadband (“eMBB”), Evolution of Nodes Point B (“eNB”), Evolved Packet Core (“EPC”), Evolved Packet System (“EPS”), Evolved UMTS Terrestrial Radio Access (“E-UTRA”), Evolved UMTS Terrestrial Radio Access Network (“E-UTRAN”), European Telecommunications Standards Institute (“ETSI”), General Packet Radio Service (“GPRS”), Global System for Mobile Communications (“GSM”), Hybrid Automatic Repeat Request (“HARQ”), Home Subscriber Server (“HSS”), Home Public Land Mobile Network (“HPLMN”), Identifier (“ID”),It is also an abbreviation for related concepts such as “identifier” or “identifier”, Identifier Provider (“IDP”), Identifier Service Provider (“IDSP”), Identifier Framework (“IDF”), Information Element (“IE”), Internet of Things (“IoT”), Listen Before You Talk (“LBT”), Long Term Evolution (“LTE”), Multiple Access (“MA”), Mobility Management (“MM”), Mobility Management Entity (“MME”), Mobile Network Operator (“MNO”), Master Session Key (“MSK”), Narrowband (“NB”), Negative Acknowledgment (“NACK”) or (“NAK”), Next Generation (5G) Node-B (“gNB”), Next Generation Radio Access Network (“NG-RAN”), RAN for 5GS Networks, New Radio (“NR”, 5G Radio Access Technology; also known as “5G NR”), NR Using Unlicensed Spectrum (“NR-U”), Non-Access Stratum (“NAS”), Network Exposure Function (“NEF”), Number Used Once (“Nonce”), Network Slice Selection Assistance Information (“NSSAI”), Network Access Assistance Information (“OAI”), Permitted Distributed Ledger (“PDL”), Packet Data Unit (“PDU”, used in conjunction with a “PDU session”), Packet Switching (“PS”, e.g., Packet Switching Domain or Packet Switching Service), Primary Cell (“LTE”), Physical Downlink Control Channel (“PDCCH”), Packet Data Network (“PS”), Physical Downlink Shared Channel (“PDSCH”), PDN Gateway (“P-GW”), Physical Hybrid Automatic Repeat Request Indicator Channel (“PHICH”), Physical Random Access Channel (“PRACH”), Physical Resource Block (“PRB”), Physical Uplink Control Channel (“PUCCH”), Physical Uplink Shared Channel (“PUSCH”), Public Land Mobile Network (“PLMN”), Quality of Service (“QoS”), Radio Access Network (“RAN”), Radio Resource Control (“RRC”), Random Access Channel (“RACH”), Random Access Response (“RAR”), Reference Signals (“RS”), Registration Area (“RA”),Similar to the tracking area list used in LTE / EPC, receive (“RX”), radio link control (“RLC”), single-carrier secondary cell (“SCell”), shared channel (“SCH”), serving gateway security anchor function (“SEAF”), subscription identifier de-hiding function (“SIDE”), (“S-GW”), session management (“SM”), security mode command (“SMC”), session management function (“SMF”), and serving network identifier (“SN”). The following are listed: ID, Service Provider (SP), Single Network Slice Selection Auxiliary Information (S-NSSAI), Sounding Reference Signal (SRS), Self-identifying Identifier (SSI), Subscription Hidden Identifier (SUPI), Subscription Permanent Identifier (TSP), Timing Alignment Timer (TAT), Tracking Area (TA), Transport Block (TB), Transport Block Size (UDR), Timestamp (TS), Trusted Service Provider (TSP), Transmission Time Interval (TTI), Transmission (TX), Unified Data Management (UDR), User Data Repository (UDR), Uplink Control Information (UCI), User Entity / Equipment (Mobile Terminal) (UE), Uplink (UL), User Plane (UP), Universal Mobile Telecommunications System (UMTS), UMTS Terrestrial Radio Access (UTRA), UMTS Terrestrial Radio Access Network (UTRAN), World Wide Web Consortium (W3C), and Global Microwave Access Interoperability (WiMAX). As used herein, "HARQ-ACK" can collectively represent a positive acknowledgment ("ACK"), a negative acknowledgment ("NACK"), and a discontinuous transmission ("DTX"). ACK indicates that the TB was correctly received, while NACK (or NAK) indicates that the TB was incorrectly received. DTX indicates that the TB was not detected.

[0003] Mobile network operators (“MNOs”) are subject to mandatory SIM registration obligations as part of Know Your Customer (“KYC”) requirements, which require customers to present government-approved identity credentials before a SIM card can be activated. In most cases, these KYC rules only allow customers to present identification documents already issued by a government agency, such as a national ID card, passport, or driver's license. Summary of the Invention

[0004] A process for subscription to a network based on a digital ID is disclosed. This process can be implemented by an apparatus, system, method, and / or computer program product.

[0005] One method for a UE includes obtaining a digital identifier (“DIGIT-ID”), the digital identifier including a verifiable and secure identifier, and a digital signature generated using a private key and a timestamp. The method includes sending a first request to a mobile communication network and receiving a first response, wherein the first request includes the DIG-ID, the timestamp, and the generated digital signature, and wherein the first response includes a network access authentication success indication and the verified DIG-ID. The method also includes establishing a provisioning connection to the mobile communication network and receiving subscription credentials and / or a user subscription profile via the provisioning connection.

[0006] One method for a network function includes receiving a first request containing the UE's DIG-ID, a timestamp, and a digital signature, wherein the digital identifier includes a verifiable and secure identifier. The method includes identifying a trusted service provider based on the DIG-ID and sending a verification request to the trusted service provider. Here, the verification request includes the DIG-ID, timestamp, digital signature, minimum dataset request, and security key request. The method includes receiving the verified DIG-ID, verification result, DIG-ID lifetime, MDS information, and access key from the service provider in response to successful verification of the DIG-ID. The method includes invoking the UE's subscription provisioning based on the MDS information, wherein the subscription provisioning is secured using the access root key. Attached Figure Description

[0007] A more detailed description of the embodiments briefly described above will be presented with reference to the specific embodiments illustrated in the accompanying drawings. It should be understood that these drawings depict only a few embodiments and should therefore not be considered as limiting the scope; the embodiments will be described and explained with additional specificity and detail using the drawings, wherein:

[0008] Figure 1 This is a schematic block diagram illustrating one embodiment of a wireless communication system for subscription to the network based on a digital ID;

[0009] Figure 2 This is a diagram illustrating one embodiment of a process for digital ID verification and subscription credentials / information provision to enable subscriber onboarding in an MNO network for access to network services.

[0010] Figure 3A This is a diagram illustrating one embodiment of a network access process based on a digital ID used for network access during the registration process;

[0011] Figure 3B yes Figure 3A The continuation of the process;

[0012] Figure 4AThis is a diagram illustrating one embodiment of a network access process based on a digital ID used for network access during the network access process;

[0013] Figure 4B yes Figure 4A The continuation of the process;

[0014] Figure 5 This is a diagram illustrating one embodiment of a process for enabling digital ID-based identification, authentication, and trust services through a service enabler function.

[0015] Figure 6 This is a diagram illustrating one embodiment of a user equipment device that can be used for subscription network access based on a digital ID;

[0016] Figure 7 This is a diagram illustrating one embodiment of a network device apparatus that can be used for subscription access based on a digital ID;

[0017] Figure 8 This is a flowchart illustrating one embodiment of a method for subscription to a network based on a digital ID; and

[0018] Figure 9 This is a flowchart illustrating one embodiment of a method for subscription to the network based on a digital ID. Detailed Implementation

[0019] As those skilled in the art will understand, aspects of the embodiments can be embodied as systems, apparatus, methods, or program products. Therefore, embodiments can take the form of entirely hardware embodiments, entirely software embodiments (including firmware, resident software, microcode, etc.), or embodiments combining software and hardware aspects.

[0020] For example, the disclosed embodiments can be implemented as hardware circuitry, including custom-designed very large-scale integration (“VLSI”) circuitry or gate arrays, off-the-shelf semiconductors such as logic chips, transistors, or other discrete components. The disclosed embodiments can also be implemented in programmable hardware devices such as field-programmable gate arrays, programmable array logic, programmable logic devices, etc. As another example, the disclosed embodiments may include one or more physical or logical blocks of executable code, which may, for example, be organized as objects, processes, or functions.

[0021] Furthermore, embodiments may take the form of a program product embodied in one or more computer-readable storage devices that store machine-readable code, computer-readable code, and / or program code (hereinafter referred to as code). The storage device may be tangible, non-transitory, and / or non-transferable. The storage device may not contain signals. In one embodiment, the storage device uses only signals for accessing the code.

[0022] Any combination of one or more computer-readable media may be used. A computer-readable medium may be a computer-readable storage medium. A computer-readable storage medium may be a storage device for storing code. A storage device may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, holographic, micromechanical, or semiconductor system, apparatus, or device, or any suitable combination thereof.

[0023] More specific examples of storage devices (a non-exhaustive list) will include the following: electrical connections having one or more wires, portable computer floppy disks, hard disks, random access memory (“RAM”), read-only memory (“ROM”), erasable programmable read-only memory (“EPROM” or flash memory), portable optical disc read-only memory (“CD-ROM”), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing. In the context of this document, a computer-readable storage medium can be any tangible medium that can contain or store programs for use by or in connection with an instruction execution system, apparatus, or device.

[0024] The code used to perform the operations of the embodiments can be any number of lines and can be written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Python, Ruby, Java, Smalltalk, C++, and traditional procedural programming languages ​​such as the "C" programming language, and / or machine languages ​​such as assembly language. The code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer, partially on a remote computer, or entirely on a remote computer or server. In the latter case, the remote computer can be connected to the user's computer via any type of network, including a local area network ("LAN") or a wide area network ("WAN"), or can be made to an external computer (e.g., via the Internet using an Internet service provider).

[0025] Furthermore, the features, structures, or characteristics described in the embodiments can be combined in any suitable manner. Numerous specific details, such as examples of programming, software modules, user selection, network transactions, database queries, database structures, hardware modules, hardware circuits, hardware chips, etc., are provided in the following description to provide a thorough understanding of the embodiments. However, those skilled in the art will recognize that the embodiments can be implemented without one or more specific details or using other methods, components, materials, etc. In other instances, well-known structures, materials, or operations have not been shown or described in detail to avoid obscuring aspects of the embodiments.

[0026] Throughout this specification, references to "an embodiment," "embodiment," or similar language mean that a particular feature, structure, or characteristic described in connection with that embodiment is included in at least one embodiment. Therefore, unless expressly stated otherwise, the phrases "in an embodiment," "in an embodiment," and similar language throughout this specification may, but do not necessarily, refer to the same embodiment, but rather to "one or more, but not all, embodiments." Unless expressly stated otherwise, the terms "comprising," "including," "having," and variations thereof mean "including, but not limited to,". Unless expressly stated otherwise, the list of enumerated items does not imply that any or all items are mutually exclusive. Unless expressly stated otherwise, the terms "a / an" and "the" also mean "one or more".

[0027] As used herein, a list containing the conjunction “and / or” includes any single item in the list or a combination of items in the list. For example, a list of A, B, and / or C includes only A, only B, only C, a combination of A and B, a combination of B and C, a combination of A and C, or a combination of A, B, and C. As used herein, a list using the term “one or more” includes any single item in the list or a combination of items in the list. For example, one or more of A, B, and C includes only A, only B, only C, a combination of A and B, a combination of B and C, a combination of A and C, or a combination of A, B, and C. As used herein, a list using the term “one of” includes one and only one of any single item in the list. For example, “one of A, B, and C” includes only A, only B, or only C and excludes combinations of A, B, and C. As used herein, “selected from the group consisting of A, B, and C” includes one and only one of A, B, or C and excludes combinations of A, B, and C. As used in this article, “members of the group consisting of A, B and C and their combinations” includes only A, only B, only C, combinations of A and B, combinations of B and C, combinations of A and C, or combinations of A, B and C.

[0028] The following description of aspects of the embodiments is based on schematic flowcharts and / or schematic block diagrams of methods, apparatus, systems, and program products according to the embodiments. It should be understood that individual blocks in the flowcharts and / or schematic block diagrams, as well as combinations of blocks in the flowcharts and / or schematic block diagrams, can be implemented by code. This code can be provided to a processor of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus to produce a machine, such that instructions executed via the processor of the computer or other programmable data processing apparatus create means for implementing the functions / actions specified in the flowcharts and / or block diagrams.

[0029] The code can also be stored in a storage device that can instruct a computer, other programmable data processing device or other device to operate in a particular manner, such that the instructions stored in the storage device produce instructions that include implementing the functions / actions specified in the schematic flowchart and / or schematic block diagram.

[0030] The code can also be networked onto a computer, other programmable data processing device or other device to cause a series of operational steps to be executed on the computer, other programmable device or other device, thereby producing a computer-implemented process, such that the code executing on the computer or other programmable device provides a process for implementing the functions / actions specified in the flowchart and / or block diagram.

[0031] The flowcharts and / or block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of apparatus, systems, methods, and program products according to various embodiments. In this regard, each block in the flowcharts and / or block diagrams may represent a module, segment, or portion of code, which includes one or more executable instructions for implementing a specified logical function.

[0032] It should also be noted that in some alternative implementations, the functions marked in the boxes may not appear in the order indicated in the figures. For example, two boxes shown consecutively may actually be executed substantially simultaneously, or the boxes may sometimes be executed in reverse order, depending on the functions involved. Other steps and methods that are equivalent in function, logic, or effect to one or more boxes or portions thereof in the figures shown can be conceived.

[0033] While various arrow and line types may be used in flowcharts and / or block diagrams, they are to be understood not to limit the scope of the respective embodiments. In practice, some arrows or other connectors may be used only to indicate the logical flow of the depicted embodiment. For example, an arrow may indicate a wait or monitoring period of unspecified duration between enumeration steps in a depicted embodiment. It will also be noted that each block in a block diagram and / or flowchart, and combinations of blocks in block diagrams and / or flowcharts, may be implemented by a hardware-based dedicated system or a combination of dedicated hardware and code that performs the specified function or action.

[0034] The description of the elements in each figure can be referenced to the elements in the preceding figures. Throughout all figures, the same numbers refer to the same elements, including alternative embodiments of the same elements.

[0035] Generally, this disclosure describes systems, methods, and apparatus for subscription-based network access using digital IDs. It describes subscriber / user authentication and subscription provisioning for UEs based on digital identifiers to enable on-demand network access and services for UEs. Subscription processing based on digital identifiers is also described to mitigate identity fraud and risk. This disclosure addresses the following problems related to mobile networks.

[0036] Identity fraud and complexity inherent in the legacy Know Your Customer (“KYC”) process associated with SIM activation are critical issues. Therefore, mobile network operators are moving towards adopting digital KYC and online registration to support more on-demand services. The vertical service provider market is evolving with digital transformation, and current 3GPP mobile networks do not support on-demand user identification, authentication, and network subscription management to enable on-demand services for users (from MNOs or different service providers) in the digital market.

[0037] Fewer use cases requiring digital customer identification and subscription processing include service subscriptions to devices without USIM / UICC, pay-as-you-go models (i.e., where users purchase and use ongoing services without buying a dedicated SIM), and temporary service subscriptions (i.e., users visiting foreign countries can purchase temporary subscriptions from their local MNO during their stay). In different scenarios, such as network-as-a-service models, where 5G networks can be used / deployed for self-organized and / or temporary events in some locations to provide 5G coverage and connectivity to local users or devices (e.g., stadiums / stadiums, etc.).

[0038] However, the KYC process can be expensive, time-consuming, and potentially cumbersome for service providers, especially when MNOs are obligated to verify customers' ID credentials against government databases and charge for each verification query. In addition to the operational costs associated with customer registration, data protection, and document management, cases of identity fraud can result in hefty fines and damage to a company's brand reputation.

[0039] With the increasing number of IoT devices, embedded SIM technology is evolving and replacing physical SIM cards. Generally, USIM / UICC stores subscription information and the IMSI (International Mobile Subscription Identifier), and they are responsible for authenticating subscribers on the mobile network, accessing the network, and utilizing subscription-related services. eSIM and iSIM primarily depend on the Remote SIM Provisioning (“RSP”) scheme. The identity fraud and complexities involved in the KYC process related to SIM activation for network access pose a significant threat to mobile operators and subscribers.

[0040] As the number of IoT devices increases, devices without USIMs will have a greater chance of playing a significant role in the IoT and vertical service ecosystem. Currently, mobile operators and 3GPP networks only support traditional KYC, meaning subscribers can only obtain a SIM card and activate their subscription after legacy identity checks (such as passports) at the store. Subsequent SIM-based subscription activation and user identity authentication processes then provide network access and services. To enable on-demand subscriptions and user identity management in the evolving digital market, 3GPP networks currently lack any digital subscription and identity processing methods, as well as any standard subscription access methods.

[0041] This document describes the process of supporting digital ID verification for user authentication and, following successful digital ID verification, supplying user subscription information to the UE to enable network service access. (See Appendix) Figure 2-5 The document describes embodiments that cover scenarios in which a UE attempts network access by providing a digital ID to retrieve subscription information from the network as part of joining an MNO network (e.g., in an operator's network for service provisioning of a PLMN / NPN / content provider).

[0042] Figure 1 A wireless communication system 100 for subscription network access based on a digital ID is depicted according to embodiments of the present disclosure. In one embodiment, the wireless communication system 100 includes at least one remote unit 105, a radio access network (“RAN”) 120, a mobile core network 130, and a service provider domain 140. The RAN 120 and the mobile core network 130 form a mobile communication network. The mobile communication network is capable of providing the remote unit 105 with access to one or more services provided by the service provider domain 140. The RAN 120 may consist of a base station unit 110, with which the remote unit 105 communicates using a wireless communication link. Although in Figure 1 The document depicts a specific number of remote units 105, base station units 110, RAN 120, mobile core network 130, and service provider domains 140, but those skilled in the art will recognize that any number of remote units 105, base station units 110, RAN 120, mobile core network 130, and service provider domains 140 may be included in the wireless communication system 100.

[0043] In one implementation, RAN 120 conforms to a 5G system as defined in the 3GPP specification. In another implementation, RAN 120 conforms to an LTE system as defined in the 3GPP specification. However, more generally, the wireless communication system 100 can implement other open or proprietary communication networks, such as WiMAX, and other networks. This disclosure is not intended to limit implementation to any particular wireless communication system architecture or protocol.

[0044] In one embodiment, remote unit 105 may include computing devices such as desktop computers, laptop computers, personal digital assistants (“PDAs”), tablet computers, smartphones, smart TVs (e.g., internet-connected TVs), smart devices (e.g., internet-connected devices), set-top boxes, game consoles, security systems (including security cameras), in-vehicle computers, network devices (e.g., routers, switches, modems), etc. In some embodiments, remote unit 105 includes wearable devices such as smartwatches, fitness bands, optical head-mounted displays, etc. Furthermore, remote unit 105 may be referred to as a UE, subscriber unit, mobile device, mobile station, user, terminal, mobile terminal, fixed terminal, subscriber station, user terminal, wireless transmit / receive unit (“WTRU”), device, or by other terms used in the art.

[0045] Remote unit 105 can communicate directly with one or more base station units 121 in RAN 120 via uplink (“UL”) and downlink (“DL”) communication signals. Alternatively, the UL and DL communication signals can be carried via a wireless communication link. Here, RAN 120 is an intermediate network providing remote unit 105 with access to the mobile core network 130.

[0046] In some embodiments, remote unit 105 communicates with application server 141 via a network connection to mobile core network 130. For example, mobile application 107 (e.g., web browser, media client, telephony / VoIP application) can trigger remote unit 105 to establish a PDU session (or other data connection) with mobile core network 130 via RAN 120. Mobile core network 130 then uses the PDU session to relay services between remote unit 105 and application server 141 in service provider domain 140. The PDU session represents a logical connection between remote unit 105 and UPF 131. To establish a PDU session, remote unit 105 must register with mobile core network 130. Note that remote unit 105 can establish one or more PDU sessions (or other data connections) with mobile core network 130. Therefore, remote unit 105 can simultaneously have at least one PDU session for communicating with service provider domain 140 and at least one PDU session for communicating with another data network (e.g., packet data network 150). Other examples of mobile applications 107 include user agents, ID service applications, trust service applications, subscription profile management service applications, and blockchain / DLT wallets, as shown in the appendix below. Figures 2-5 The subject of discussion.

[0047] Base station unit 121 may be distributed across a geographical area. In some embodiments, base station unit 121 may also be referred to as an access terminal, access point, base station, base station, node B, eNB, gNB, home node B, relay node, RAN node, or any other term used in the art. Base station unit 121 is typically part of a radio access network (“RAN”) such as RAN 120, which may include one or more controllers communicatively coupled to one or more respective base station units 121. These and other elements of the radio access network are not shown, but are generally known to those skilled in the art. Base station unit 121 is connected to mobile core network 130 via RAN 120.

[0048] Base station unit 121 can serve multiple remote units 105 within a service area, such as a cell or cell sector, via wireless communication link 123. As depicted, base station unit 121 can support a specific cell 123 (i.e., PCell or PSCell) and / or SCell 125. Base station unit 121 can communicate directly with one or more remote units 105 via communication signals. Typically, base station unit 121 transmits DL communication signals to serve remote units 105 in the time, frequency, and / or spatial domains. Furthermore, DL communication signals can be carried on the wireless communication link. The wireless communication link can be any suitable carrier in the licensed or unlicensed radio spectrum. The wireless communication link facilitates communication between one or more remote units 105 and / or one or more base station units 121.

[0049] In one embodiment, the mobile core network 130 is a 5G core (“5GC”) or an evolved packet core (“EPC”), which may be coupled to a packet data network 150 (such as the Internet and private data networks), as well as other data networks. The remote unit 105 may have a subscription or other account to the mobile core network 130. Each mobile core network 130 belongs to a single Public Land Mobile Network (“PLMN”). This disclosure is not intended to limit implementation to any particular wireless communication system architecture or protocol.

[0050] Mobile core network 130 includes several network functions (“NFs”). As shown, mobile core network 130 includes one or more user plane functions (“UPFs”) 141. Mobile core network 130 also includes multiple control plane functions, including but not limited to Access and Mobility Management Functions (“AMFs”) 132 serving RAN 120, Security Anchor Function (“SEAF”) 134, Authentication Server Function (“AUSF”) 135, Policy Control Function (“PCF”) 136, Digital Identification, Authentication and Trust Service Enabler Function (“D-IDASEF”) 137, Blockchain Service Enabler Function (“BSEF”) 138, and Unified Data Management / User Data Repository Function (“UDM / UDR”) 139. In various embodiments, mobile core network 130 may also include Authentication Server Function (“AUSF”), Network Repository Function (“NRF”) (used by various NFs for discovery and communication with each other via API), Network Exposure Function (“NEF”), or other NFs defined for 5GC. In various embodiments, the AUSF 135 provides network access functionality, such as network access enabler functionality, to the mobile core network 130. In such embodiments, the AUSF 135 may be a network access enabler AUSF (“O-AUSF”).

[0051] In various embodiments, the mobile core network 130 supports different types of mobile data connections and different types of network slices, where each mobile data connection utilizes a specific network slice. Here, a "network slice" refers to a portion of the mobile core network 130 optimized for a specific service type or communication service. Each network slice includes a set of CP and / or UP network functions. Network instances can be identified by S-NSSAI, while the set of network slices authorized for use by the remote unit 105 is identified by NSSAI. In some embodiments, various network slices may include individual instances of network functions, such as SMF 133 and UPF 131. In some embodiments, different network slices may share some common network functions, such as AMF 132. Figure 1 Different network slices are not shown, but their support is assumed.

[0052] although Figure 1 The document describes a specific number and type of network functions, but those skilled in the art will recognize that any number and type of network functions can be included in the mobile core network 130. Furthermore, in the case where the mobile core network 130 is an EPC, the described network functions can be replaced by appropriate EPC entities, such as MME, S-GW, P-GW, HSS, etc. In some embodiments, the mobile core network 130 may include an AAA server.

[0053] Service provider domain 140 supports services within wireless communication system 100. Examples of services provided via service provider domain 140 may include, but are not limited to, identification services, trust services, blockchain services, and distributed ledger services. As depicted, service provider domain 140 may include application server 141, identification service provider (“IDSP”) 142, trust service provider (“TSP”) 143, and blockchain service infrastructure (“BSI”) 144. IDSP 142 and TSP 143 are described in more detail below. IDSP 142 and TSP 143 provide identification and trust services to mobile core network 130 and / or remote unit 105, respectively. BSI 144 interacts with blockchain / distributed ledger network 160 to provide blockchain (e.g., distributed ledger) services to mobile core network 130 and / or remote unit 105 to support the storage of digital IDs and verifiable credentials generated by end user (or device) 105 in a decentralized platform for end user authentication based on digital IDs via mobile core network 130.

[0054] Although Figure 1 The components of the 5G RAN and 5G core network are described, but the described embodiments for subscription access based on digital IDs are applicable to other types of communication networks and RATs, including IEEE 802.11 variants, GSM, GPRS, UMTS, LTE variants, CDMA 2000, Bluetooth, ZigBee, Sigfoxx, etc. For example, in LTE variants involving EPC, AMF 132 can be mapped to MME, SMF 133 can be mapped to the control plane portion of PGW and / or MME, UPF 131 can be mapped to the SGW and user plane portion of PGW, UDM / UDR 139 can be mapped to HSS, etc.

[0055] In the following description, the term "RAN node" is used for the base station, but it can be replaced by any other radio access node, such as gNB, eNB, BS, AP, NR, etc. Furthermore, the operation is primarily described in the context of 5G NR. However, the proposed solution / method is equally applicable to other mobile communication systems supporting mobile subscription provisioning based on digital ID authentication.

[0056] Figure 2A process 200 for a mobile subscription provisioning method (e.g., subscriber onboarding) based on digital ID authentication, according to embodiments of this disclosure, is depicted. Process 200 may be performed by a UE 205 served by a network function (“NF”) 207 and an onboarding enabler AUSF (“O-AUSF”) 209 in the serving network. Process 200 also involves a digital identifier and trust service provider (“ID / TSP”) 211, an NF (depicted as “MNO NF”) 213 storing onboarding-related user information, and a provisioning server and / or subscription manager 215. O-AUSF 209 may be a network function in the home network responsible for servicing / processing onboarding-related services. MNONF 213 may communicate with ID / TSP 211, wherein ID / TSP may belong to a third party and / or may be outside the MNO. ID / TSP 211 is an ID / TSP capable of accessing the digital identifier infrastructure and DIG-ID related documents (i.e., verifiable claims) to verify the received DIG-ID and the user / owner of the DIG-ID. In one embodiment, MNO NF 213 is located outside the MNO network. In another embodiment, MNO NF 213 is located inside the MNO network. In some embodiments, the serving network is the home network (e.g., H-PLMN). In other embodiments, the serving network is a visited / roaming network different from the home network (e.g., V-PLMN).

[0057] In various embodiments, UE 205 is an embodiment of remote unit 105, NF 207 is an embodiment of AMF 132 and / or SEAF 134, and O-AUSF 209 is an embodiment of AUSF 135. MNO NF 213 may be an embodiment of UDM / UDR 139. Procedure 200 illustrates how a user can enable UE 205 to access a mobile operator's network by providing a digital ID to the network, thereby achieving successful authentication and receiving network subscription information to enable network service access.

[0058] In various embodiments, the digital ID is a globally resolvable, cryptographically verifiable identifier (i.e., a verifiable secure user identifier or device identifier). In some embodiments, the digital ID may be directly registered on a distributed ledger (e.g., a blockchain). Here, UE 205 may be a distributed ledger technology (“DLT”) end user equipment. In some embodiments, the digital ID is generated by a user equipment that needs to obtain access to MNO services by providing the digital ID to a mobile network operator (“MNO”) for user authentication. Upon successful user authentication, the MNO (e.g., the home network) provides a temporary subscription credential or an actual subscription profile to register the user as a subscriber to the MNO network. Here, the determination of the temporary versus the actual subscription profile may be based on subscription purchase information.

[0059] A digital ID (“DIG-ID”) can contain / refer to any of the following identifiers:

[0060] • Decentralized ID (“DID”): The syntax of DID is “did:”method-name method-specificc-id. An example DID is “did:example:123456789abcdefghi”.

[0061] • Self-identified ID (“SSI”): Here, users or organizations (e.g., MNOs / service providers) control and manage their identities.

[0062] • Digital membership ID, such as the subscription unique membership ID (“SUOI”) described below.

[0063] Figure 2 The solution outlined in the diagram involves the following steps.

[0064] As a prerequisite, it is assumed that the user has purchased an MNO network subscription from a store or through online registration. However, here, the user equipment does not contain any actual subscription credentials or information (or user subscription profile) related to the purchased subscription for accessing network services. It is assumed that the MNO provides limited access within its network to provide network access services to the user equipment, while the network providing initial registration and / or access to the UE is used for UE network access.

[0065] Optionally, UE 205 can connect to an MNO network (e.g., a PLMN or NPN) and establish control plane and user plane connections without security. UE 205 can then use a mobile application or browser to generate a DIG-ID with a Trust Service Provider (“TSP”). Typically, the TSP provides trust services for electronic transactions, while the ID service provider provides identification services for electronic devices protected by end-to-end application security. Note that the ID service provider and the trust service provider can be provided by the same service provider (“SP”) and can be co-located. As used herein, TSP can refer to a single trust service provider or a combination of ID / trust service providers.

[0066] Alternatively, if the UE 205 has a wireless LAN connection (e.g., a Wi-Fi connection), it can generate a DIG-ID with a trusted service provider, either independently or when purchasing an MNO subscription online. In this scenario, the user clearly links the use of DIG-ID-related files and user information that can be shared with the MNO, as well as user-specified DIG-ID-related information.

[0067] During the online purchase of a subscription, the MNO portal or application can also provide means for linking ID / TSP-related actions, and the MNO can provide ID / TSP 211 with any subscription-related data that can define the MNO-related user subscription profile (such as subscription type, MNO information, and the address, URL, or URI of the provisioning server / subscription data management function). ID / TSP 211 stores the DIG-ID and the DIG-ID file address in storage. The DIG-ID file address can resolve to any decentralized platform or database that actually stores the DIG-ID file linked to the DIG-ID. The DIG-ID file may include a public key used to verify the DIG-ID, user information such as that configured by the user according to the MNO subscription activation requirements (i.e., any verifiable credentials), and MNO subscription-related information (if provided by the MNO).

[0068] UE 205 may locally store (in a trusted security platform, smart security platform, digital platform, memory, and / or environment) all encrypted information and the generated DIG-ID. The encrypted information may include one or more of the following: device public / private key pairs, the public key of the network and / or ID / TSP 211, encryption algorithms, or shared keys (e.g., known to the network and / or TSP 211). Similarly, ID / TSP 211 may store encrypted information, including the public / private key pair of ID / TSP 211, the public key of UE 205, encryption algorithms, or shared keys (e.g., known to UE 205). It should also be noted that UE 205 may include an ID / trust service application 217 that interacts with ID / TSP 211 and a subscription profile management service application 219 that interacts with a provisioning server / subscription manager 215.

[0069] In step 1, UE 205 generates a DIG-ID using a user agent, application, or browser associated with the ID / trust service provider. UE 205 generates a freshness parameter, such as a timestamp (or any other freshness parameter may be used). UE 205 sends the DIG-ID, timestamp, and a digital signature of the DIG-ID and timestamp in a request message to NF 207 (e.g., AMF) in the network serving the MNO (see Message Passing 221). In one example, the request is sent to the AMF in the N1 container. In some embodiments, the request may be a registration request message. Alternatively, the request may be a network access request message.

[0070] Note that if UE 205 lacks the means to generate a new DIG-ID online, UE 205 can use any of its default biometrics (such as those configured using ID / TSP 211) to generate a DIG-ID, and protect the DIG-ID using a shared secret key linked to the user's trusted service account and ID / TSP 211, appended to the public key and timestamp of ID / TSP 211. Additionally, the user can send a digital signature that can later help the TSP decrypt the DIG-ID and verify it accordingly, along with the newly created DIG-ID, TSP public key ID, and timestamp.

[0071] In step 2, based on the DIG-ID type indication in the DIG-ID, NF 207 forwards the received request, which includes the DIG-ID, timestamp, and digital signature, to an NF in the home network, such as O-AUSF 209 (see Message Passing 223). NF 207 forwards the request directly or via another NF in the serving network (e.g., via SEAF). While the depicted embodiment shows O-AUSF 209, it should be understood that O-AUSF 209 can be replaced by a different AUSF or another network function configured to handle incoming connections in the core network (e.g., a new NF or an existing 3GPP NF).

[0072] In step 3, upon receiving a request with a DIG-ID, timestamp, and digital signature, O-AUSF 209 determines, based on the domain information in the DIG-ID, to send an ID verification request to ID / TSP 211 for DIG-ID verification and related user authentication (see block 225).

[0073] In step 4, O-AUSF 209 sends an ID verification request (i.e., a service operation message) to ID / TSP 211. The ID verification request includes the received DIG-ID, timestamp, digital signature, any MNO preferred minimum dataset (MDS) request information, and security key request.

[0074] In step 5, upon receiving the DID, ID / TSP 211 can retrieve the DID-related file using a DID resolver or database. ID / TSP 211 can also verify the verifier (i.e., verify the MNO information to see if the MNO is authorized to request the verification service). Once the DID file is retrieved, ID / TSP 211 uses the user's public key associated with the DID to verify the digital signature. If the digital signature verification is successful, ID / TSP 211 retrieves user information as configured by the user, additional MNO information (if stored), and generates the network root key from the shared secret key (see block 229).

[0075] In step 6, ID / TSP 211 sends an ID verification response (i.e., a service operation message) to O-AUSF 209. The ID verification response includes the verified DIG-ID (i.e., the DIG-ID itself), the verification result, the minimum dataset (user information and MNO subscription provisioning related URIs / URLs / addresses), and the inbound root key. Note that the verified DIG-ID can be the same as the DIG-ID sent in step 4. After successful DIG-ID verification on the network side, ID / TSP 211 sends the now-verified DIG-ID along with a success indication, thus identifying which DIG-ID the verification result applies to.

[0076] In step 7, upon receiving an ID verification response with a success indication, O-AUSF 209 determines, based on the received MDS information, whether to invoke the temporary subscription credential provisioning service or the actual (i.e., non-temporary) subscription profile provisioning service (see block 233). In one embodiment, O-AUSF 209 invokes the temporary subscription credential provisioning service if only user information is provided and the user is eligible for a temporary subscription. In another embodiment, O-AUSF 209 invokes the actual subscription profile provisioning service only upon receiving a URI / URL / address related to the provisioning server / subscription management function.

[0077] In step 8a, for example, using a service operation message, O-AUSF 209 stores the received DIG-ID, verification result, minimal dataset (e.g., containing user information and MNO subscription provisioning-related URI / URL / address), and network access root key (see message passing 235) in MNO NF 213. MNO NF 213 can be any NF in the MNO that stores network access-related user information, such as UDM / UDR in the MNO.

[0078] In the first variant that supports provisioning, O-AUSF 209 can retrieve the default subscription credentials for authentication, DIG-ID, from the UDM / UDR and / or MNO NF 213. Here, the default subscription credentials may include SUPI (i.e., user subscription identifier), AKA credentials, slice information, MCC, and MNC.

[0079] In a second variant supporting provisioning, O-AUSF 209 can retrieve a user subscription profile for authentication using the DIG-ID from the provisioning server and / or subscription manager (depicted as provisioning server / subscription manager 215) by providing MNO-related information and user information received as part of a minimal dataset. In the depicted example, O-AUSF 209 retrieves the user subscription profile via MNO NF213 (i.e., UDM, see messaging 237); however, in other embodiments, O-AUSF 209 can retrieve the user subscription profile for authentication directly from provisioning server 215. The user subscription profile may include SUPI, AKA credentials, slice information, MCC, MNC, and network access-related information, which will enable UE 205 to store the subscription profile as a subscription profile in a trusted and secure location (such as eUICC or a non-UICC platform).

[0080] In the third variant that supports UP-based provisioning, after receiving the verified DIG-ID, verification result, and MDS, the MNO NF 213 can use the DIG-ID and MDS to invoke the subscription retrieval and activation process (for KYC, see Messaging 237).

[0081] In step 8b, O-AUSF 209 derives the SEAF key (Kseaf) using the received inbound root key, for example, as CK', IK' / MSK / EMSK / Kausf in KDF. O-AUSF 209 sends a response message to NF 207 in the serving network, the response message including the verified DIG-ID, Kseaf, and ID verification result (see Message Passing 239). Similar to step 2, O-AUSF 209 can communicate with NF 207 (e.g., AMF) directly or via another NF (such as SEAF) in the network.

[0082] In some embodiments, upon receiving a response message, the SEAF in the service network generates an AMF key (Kamf) from the Kseaf and forwards the response to the AMF with a DIG-ID and a verification result containing a success indication.

[0083] According to the first variant of the supported supply, O-AUSF 209 can additionally send the default subscription credentials for the DIG-ID used for authentication, along with the DIG-ID, the key derived from the network access root key, and the random number used to generate the key, to the AMF / SEAF.

[0084] According to the second variant of the support supply, O-AUSF 209 can additionally send the user subscription profile of the DIG-ID used for authentication, along with the DIG-ID, the key derived from the network access root key, and the random number used to generate the key, to the AMF / SEAF.

[0085] In step 8c, upon receiving the DID, Kamf, and success indication, NF 207 (e.g., AMF) initiates NAS and AS to set default security based on Kamf (see message 241). Control plane and user plane security can also be set based on existing mechanisms, such as using the default selection of encryption and integrity protection algorithms. Note that UE 205 and NF 207 use the inbound root key—or a key derived from it—to protect the supply. For example, the inbound root key can be used as Kausf to set NAS, AS, and UP security. After step 8c, UE 205 will have security established with the MNO.

[0086] If the NF 207 receives inbound container information with subscription credentials / user subscription profiles, it stores the inbound container information locally (e.g., at the AMF) along with the DIG-ID. The NF 207 may optionally receive a security key derived from the inbound root key. Note that NAS security is not established if the Kseaf is not received.

[0087] According to the third variant that supports UP-based provisioning, an RRC reconfiguration process can be run after the NAS and AS SMC to set up UP security. Here, PDU session establishment can be restricted to the provisioning server or subscription manager 215 (which can be located with the MNO, or alternatively, outside the MNO network) based on MDS information available in the UDM / UDR or pre-configured information.

[0088] You can trigger the provision of subscription credentials / profiles based on any of the following options.

[0089] According to the first option, control plane-based (“CP”) provisioning can be used to provide subscription credentials / user subscription profiles to the UE. With the control plane solution in place, proceed to step 9, skipping step 10.

[0090] In the first variant of the first option, the CP provisioning connection is secured with NAS. Here, the AMF (e.g., NF 207) uses a NAS key to protect subscription credentials / user subscription profiles and DIG-ID, and sends them to the UE 205 in any N1 message.

[0091] In a second variant of the first option, the CP provisioning connection is not protected by NAS security. Here, the AMF (e.g., NF207) uses a key provided by O-AUSF 209 and derived from the inbound root key to protect the subscription credentials / user subscription profile for the DID used for authentication. Alternatively, in step 8c, in step 9a...

[0092] In step 9a, the NF 207 (AMF) sends the access container with DIG-ID to the UE 205 via N1 in a response message (see message passing 245). In some embodiments, the N1 message is secured with NAS to support variant 1 of option 1. Alternatively, the NF 207 (AMF) may send a protected access container with DIG-ID to the UE in a response message to support variant 2 of option 1. The protected access container is discussed in further detail below.

[0093] According to the second option, user plane-based (“UP”) provisioning can be used to provide subscription credentials / user subscription profiles to the UE. In the case of a control plane solution, proceed to step 10, skipping step 9.

[0094] In step 10, a user subscription profile can be supplied to UE 205 via a PDU session established with the provisioning server or subscription manager 215 (see message 247). A server with authentication to provide subscription information to the UE can be defined as the subscription manager. If the DIG-ID verification is successful, the subscription manager that received the DIG-ID, verification result, lifetime, and MDS in step 8a (237) can determine to facilitate the provision of the subscription to the UE. Alternatively, if the MDS does not contain any MNO subscription-related information, the UE 205 can be prompted to purchase or scan a QR code associated with the MNO subscription.

[0095] Figures 3A-3BA DIG-ID-based subscription onboarding process 300 for network access during the registration process is illustrated according to an embodiment of this disclosure. Process 300 can be implemented using UE 205, RAN 301, AMF 303, AUSF 305, UDM 307, and Digital ID / Trust Service Platform 309. In various embodiments, RAN 301 is an embodiment of RAN 120, AMF 303 is an embodiment of AMF 132 and / or NF 207, AUSF 305 is an embodiment of O-AUSF 209 and / or AUSF 138, UDM 307 is an embodiment of UDM / UDR 139, and Digital Identifier / Trust Service Platform (“ID / TSP”) 309 is an embodiment of IDSP 142, TSP 143, and / or ID / TSP 211. Process 300 illustrates the detailed message exchange involved in DIG-ID-based subscriber onboarding and subscription provisioning during the registration process. In procedure 300, it is assumed that UE 205 does not have a valid subscription profile for network access on UICC.

[0096] In step 0, as a prerequisite, UE 205 (i.e., a device with any mobile application / user agent) purchases a network / service subscription from the MNO or service provider (see block 311). The service provider has a service level agreement with the Identification Service Framework / Identification Service Provider and Trust Service Provider 309 to enable secure subscription access via DIG-ID / DID verification. The user agent can be a program, such as a browser, mobile application, blockchain / DLT wallet, or other web client, which acts as a medium for communication between the holder (e.g., user / UE / device), the issuer (e.g., any legal entity / government / organization), and the validator (e.g., mobile operator / service provider / identity provider / trust service provider). The user agent can be an embodiment of the mobile application 107 described above.

[0097] The decentralized identification service framework / identification service provider and trust service provider can be one or different parties, which facilitates the generation, secure linking, verification, and storage of DIG-ID / DID associated with relevant verifiable credentials related to the user / device. The user / UE 205 then generates a DIG-ID / DID via a user agent based on user preferences and / or service provider requirements (e.g., having any set of attributes such as name, address, mobile number, age, institutional / legal identifier, document, biometrics, etc.) and submits the required verifiable credentials (such as passport, personal ID, government ID document, driver's license, etc.) for subscription / service activation through the user agent.

[0098] The DIG-ID / DID generated by the UE 205 through the user agent actually serves as a link / direct or indirect address to the relevant user's public key storage device (which can be used for verification of the digital signature of the digital ID created using the user's private key) and the submitted verifiable credentials. These submitted verifiable credentials can be verified by a trusted service provider / identity service provider within an identity infrastructure / framework (e.g., an autonomous network / autonomous ID framework or elDAS framework) and stored in a separate blockchain / permissioned distributed ledger (PDL). The identity / verifiable claim can be anonymously sealed on the blockchain and stored on a second permissioned and cryptographically protected distributed ledger.

[0099] DIG-ID / DID is typically associated with cryptographic materials such as user public-private key pairs, ID / trust service provider information (public key and public key identifier), and service endpoints, used to establish secure communication channels. User agents / applications can be owned by a government / network operator / service provider / trust service provider / identity service provider framework.

[0100] UE 205 stores all encrypted information, along with the generated DIG-ID / DID, locally on a trusted security platform / intelligent security platform / digital platform / memory / environment. The encrypted information can include any certificate (e.g., ECDH) / user public / private key pair, validator public key and public key ID, subscription lifetime, etc.

[0101] In step 0, UE 205 only performs successful online registration (i.e., service subscription payment, DIG-ID / DID generation, and linking to a DIG-ID / DID for service activation using verifiable credentials submitted with KYC involvement), and UE 205 has already generated a DIG-ID / DID. UE 205 has a usable DIG-ID / DID associated with the desired service, but UE 205 does not have actual subscription information for accessing the service (e.g., IMSUNAI, Authentication and Key Agreement (AKA) credentials, slicing information, etc.).

[0102] exist Figures 3A-3BIn the depicted embodiments, the solution is explained and described using DID as the DIG-ID. However, note that the same process and description apply to any DIG-ID, such as SSI or Digital Access ID, in which case, instead of DID, SSI / Access ID can be replaced in the message flow and step descriptions for any DIG-ID adaptation. Furthermore, process 300 can also be adopted in scenarios where the PLMN / NPN network operator performs DID user identification authentication via ID / trust service provider infrastructure / decentralized ID framework to trigger the MNO's PLMN / NPN / third-party service provider subscription to UE 205 for network access and provisioning.

[0103] In step 1, UE 205 (which can be any mobile user equipment or IoT device) sends a registration request message (via NAS message) to AMF 303. The registration request message contains a network access instruction and a subscription unique network access ID (SUOI) (or) a DID with a timestamp (TS) and an associated digital signature (DS) of the DID and timestamp (see Message Passing 313).

[0104] Here, UE 205 sends any of the following:

[0105] • SUOI ​​+ timestamp + signature; or

[0106] • DID + timestamp + signature; or

[0107] • Hidden SUOI.

[0108] According to the first option (Option A), UE 205 generates a digital ID (i.e., decentralized ID / autonomous ID / digital access ID) in step 0, and sends this digital ID in the registration request if the anonymity and integrity protection of the DIG-ID is sufficient. Here, in addition to the DID, a timestamp (“TS”) is added by UE 205 when it is sent in the registration request. The combination of DID and TS is indicated as “DID_TS”. The timestamp is used by UE 205 to prevent any attacker from reusing the cached DID for a replay attack.

[0109] According to the first option, UE 205 creates a digital signature for DID_TS to protect the integrity of the DID, as well as proof that the credential owner (i.e., UE / user) possesses the private key. The digital signature method can include any of the methods mentioned below in Option B (Case 1). The digital signature of the DID, timestamp, and DID_TS is sent by the UE to the network in the registration request. In the depicted embodiment, the notation “DID_TS with DS” is used to indicate a digital ID with a timestamp and digital signature generated by the identity owner (i.e., UE 205).

[0110] According to the second option (Option B), if the digital ID / DID needs to be protected for privacy by hiding it, UE 205 generates and uses a subscriber-unique access identifier (“SUOI”) in the registration request for network access. Regarding the generation and use of the SUOI, UE 205 can construct the SUOI ​​using a DID generated specific to the required service.

[0111] SUOI can have any of the following formats:

[0112] SUOI Format 1: DIG-ID type / DID type, DIG-ID (i.e., decentralized ID / autonomous ID / digital network access ID), service provider ID, and identification / trusted service provider information. Note that all of the above information can be cascaded together. The DIG-ID / DID can also contain any additional security information related to the DIG-ID / DID, such as the SUOI's MAC address / SUOI's digital signature.

[0113] SUOI Format 2: DIG-ID (i.e., Decentralized ID / Autonomous ID / Digital Network Entry ID)@Service Provider ID. Identifies / trusts service provider information. Note that the DID can also contain any additional DID-related security information, such as the SUOI's MAC address / SUOI's digital signature.

[0114] SUOI Format 3: Username = "DIG-ID type_DIG-ID (i.e., decentralized ID / autonomous ID / digital onboarding ID)"@Realm = "Service provider ID.identifier / trusted service provider information". The DIG-ID type can use indicators to specify whether it is a decentralized ID / autonomous DI / digital onboarding ID / or other digital ID types. The digital ID can also contain any additional security information related to the digital ID, such as the SUOI ​​MAC address / SUOI digital signature.

[0115] If privacy is required for the SUOI, the UE can send a protected SUOI / hidden SUOI ​​to the AMF instead of the SUOI ​​using any of the following options:

[0116] Scenario 1: Digital signatures can be used for DIG-ID integrity protection. Here, the digital signature for the DIG-ID is generated by the UE and used to prove possession of the private key used to protect the DIG-ID. The output of this scheme will contain the digital signature for the DIG-ID. Note that as a prerequisite for digital signature creation, the UE 205 and the service provider (e.g., MNO / TSP / IDP) have certificates (e.g., X.509, card-verifiable certificates, etc.) to support PKI. During online registration with the service provider (i.e., the service provider can be an MNO or a third party), the UE is provided with a certificate containing the signing public key used in the networks that allow them to connect. The TSP (Trusted Service Provider) 309 will also be provided with a certificate from a qualified UE.

[0117] In one embodiment, each service provider has a public key and private key pair (sp_PUB_Key, sp_PRI_Key). In another embodiment, the UE has a corresponding public key and private key pair (UE_PUB_Key, UE_PRI_Key). In one embodiment, each service provider shares its certified public key (sp_PUB_Key) with all UEs. In yet another embodiment, the UE shares its certified public key (UE_PUB_Key) with the service provider.

[0118] Optionally, if different network operators need to provide access to the service provider's subscribers, the same sp_PRI_Key can be provided to the network operators. In another embodiment, the UE and the service provider create a message digest by applying a hash algorithm to the SUOI. In yet another embodiment, the UE and the service provider encrypt the message digest using the core network UE_PRI_Key, which serves as the signature. In one embodiment, the signature is appended to the actual message (i.e., the SUOI).

[0119] Alternatively, the shared secret key can be used to generate the MAC tag for the DIG-ID. The scheme output will contain the MAC tag for the DIG-ID. Note that SUOI ​​can support a hidden SUOI ​​format, including: DIG-ID indication, DIG-ID, Service Provider / Identification Service Provider / TSP ID and associated public key ID, protection scheme ID, and scheme output.

[0120] Scenario 2: A shared secret key is used for DIG-ID protection, similar to SUCI protection in 5G. Here, the UE can use a shared key derived from the ID / TSP public key to encrypt the SUOI, and the corresponding ID / TSP public key ID is sent by the UE along with the hidden SUOI, enabling the ID / TSP to de-hide the hidden SUOI ​​and verify it accordingly. Note that Scenario 2 also supports the hidden SUOI ​​format, including: DIG-ID indication, service provider / identity provider / TSPID, protection scheme ID, SP / IP / TSP public key ID, and scheme output with a short-term public key.

[0121] Note that if a DID is used as a DIG-ID, the DIG-ID / DID information can include any DID-based syntax information from a W3C working draft, such as DID. Examples include: URI scheme identifier (did), identifier of the DID method, and DID method-specific identifier.

[0122] In step 2, AMF 303 sends an authentication request message with network access indication (i.e., Nausf_UEAuth_Request) to AMF 305, along with the received SUOI ​​(or hidden SUOI) / DID_TS with DS (see message passing 315).

[0123] In step 3, upon receiving an access instruction with plaintext / hidden SUOI / DID_TS with DS, AUSF 305 sends an authentication data request message (i.e., Nudm_UEAuth_Request) with the received access instruction and SUOI ​​to UDM 307, which may alternatively be a hidden SUOI ​​or a DID_TS with DS (see Message Passing 317).

[0124] In an alternative, AUSF 305—upon receiving an access indication with a plaintext / hidden SUOI / DID_TS with DS based on DID—sends an authentication / access data request message to the provisioning server containing the received access indication and the SUOI ​​(or hidden SUOI) / DID_TS with DS. An example of an authentication / access data request message is the service operation message Npserver_UEAuth_GetRequest. Another example is the service operation message Npserver_UESubscriptionProvioing_Request.

[0125] In step 4, based on the DID type and / or service provider information, UDM 307 can determine which ID service / trusted service provider manages / controls the DID and related DID files (verifiable user / device credentials) to invoke DID verification. Alternatively, based on the DID type, the provisioning server can determine which ID service / trusted service provider manages / controls the DID and related DID files (verifiable user / device credentials) to invoke DID verification.

[0126] In step 5, based on the ID service provider information and / or trusted service provider information existing in the DID or SUOI / hidden SUOI, UDM 307 selects ID / TSP 309 and sends a subscriber ID verification request message with the received SUOI / DID / hidden DID and a key request instruction to ID / TSP 309. This message may include additional information request instructions regarding the subscriber / user, such as name, address, date of birth, bank account, etc., to generate a complete subscription profile and meet KYC requirements. The ID service provider and / or trusted service provider can together form a digital identification service platform.

[0127] Alternatively, based on the ID service / trusted service provider information present in the DID or SUOI / hidden SUOI / DID_TS with DS, the provisioning server 215 sends a subscriber ID verification request message with the received SUOI / DID / hidden DID / DID_TS with DS and a key request indication to the ID / TSP 309.

[0128] Alternatively, if UDM 307 and / or provisioning server 215 receive a DID_TS with DS, they use the DID_TS with DS to invoke an ID verification request with a decentralized ID framework to verify the DID and / or retrieve ID / trust service provider information. Based on the received ID / TSP 309 address information, the UDM / provisioning server sends a subscriber ID verification request message with the received DID_TS with DS and a key request indication to ID / TSP 309.

[0129] In step 6, upon receiving the SUOI / hidden SUOI / DID_TS with DS, ID / TSP 309 verifies the DID based on information from a universal parser or local database that associates the DID with the address where the DID file is stored in the blockchain / PDL. ID / TSP 309 verifies the validity, scope (scope refers to the usage information associated with the DID, which clarifies the purpose for which the DID can be used by the user / network) and authenticity of the DID by retrieving the DID information and the user file (verifiable credentials).

[0130] If any NF from the service provider / MNO domain (here, UDM 307, or it may also be able to request any subscriber-related information for the subscription provisioning server / access server), ID / TSP 309 generates a minimal dataset with all the required subscription information about the subscriber / user (e.g., the minimal dataset may include subscriber name, location, DID validity, service payment information, service activation status, etc.).

[0131] Additionally, if the service provider / MNO domain requests any security key to protect subscription access, ID / TSP 309 derives the access root key (K) based on the security credentials available in UE 205 (e.g., public / private key pairs and shared keys). ONB_Root Using the MNO ID's root key (K) ONB_Root The example export is as follows:

[0132] K ONB_Root =KDF(Shared Secret Key, MNO ID) Equation 1 Here, KDF represents a key-derived function that takes a shared secret key and an MNO identifier as its inputs.

[0133] Using the service provider ID's root access key (K) ONB_Root The example export is as follows:

[0134] K ONB_Root =KDF(Shared Secret Key, Service Provider ID) Equation 2

[0135] Here, KDF represents a key-derived function that takes a shared secret key and a service provider identifier as its inputs.

[0136] Alternatively, if ID / TSP 309 receives a DID_TS with a DS, it retrieves the public key associated with the DID stored with the DID file to verify the digital signature received with the DID_TS. If the verification is successful, the DID authentication is considered successful, and ID / TSP 309 is able to retrieve the relevant DID information to process ID verification and key requests from the MNO / service provider.

[0137] However, if the timestamp received in DID_TS is different from the timestamp used in the creation of the digital signature, ID / TSP 309 indicates that the timestamp has been tampered with by an attacker, or if the timestamp is outdated, it is classified as a replay attack.

[0138] Alternatively, if ID / TSP 309 receives a hidden SUOI / DID instead of a plaintext SUOI, the hidden SUOI ​​is dehidden using the private key associated with the public key indicated by the public key ID. The remainder of the process involved in verifying the DID retrieved from the SUOI, generating the minimum dataset, and generating the network access key will be the same as described above.

[0139] Regarding the digital signature verification method, if the digital signature is applied to SUOI / DID_TS, then on the service provider side, the service provider should use the corresponding UE_PUB_Key to verify the SUOI / DID_TS signature. If the signature is successfully verified, the service provider can accept the message; otherwise, the message is discarded in step 7 and the verification result is set to failure.

[0140] In step 7, ID / TSP 309 sends a subscriber ID verification response message to UDM 307 (or NF in the service provider domain), which includes the verified DID, the DID verification result (success or failure), the minimum dataset with subscriber / user information, and the network access root key (K). ONB_Root (See Message Passing 325). The root key is also known as the network entry key.

[0141] Alternatively, ID / TSP 309 sends a subscriber ID verification response message to the provisioning server (or NF in the service provider domain), which includes the verified DID, the DID verification result (success or failure), a minimum dataset with user information, and the root key (K). ONB_Root ).

[0142] continue Figure 3B In step 8, if UDM 307 receives a DID verification result as "success", then UDM 307 generates subscription information and stores it in the UDR along with the received information (see block 327). The received information includes, for example, the unverified DID, the DID verification result (success or failure), the minimum dataset with user information, and the network access root key (K). ONB_Root However, if UDM 307 receives a DID verification result as "failed", UDM 307 stores the received information in UDR, such as unverified DID and DID verification result (failed).

[0143] When DID verification is successful, UDM 307 further generates a random number and uses this random number as input in key derivation to derive the network security key (K) from the received network root key. ONB_Sec ),as follows:

[0144] K ONB_Sec =KDF(KONB_Root Equation 3 (MNO / Service Provider ID, random number)

[0145] Here, KDF represents a key-derived function that takes a shared secret key and an MNO ID as its inputs.

[0146] For example, the network access encryption key (K) can be exported as follows: ONB_enc ) and network access integrity (K ONB_int Key, K ONB_Sec Used to protect the confidentiality and integrity of the network access container containing user subscription information supplied to the UE:

[0147] K ONB_enc =KDF(K ONB_Sec MNO / Service Provider ID, "Encryption Algorithm ID", "DID", keyword: "Subscription" Equation 4

[0148] K ONB_int =KDF(K ONB_Sec MNO / Service Provider ID, "Integrity Algorithm ID", "DID", keyword: "Subscription") Equation 5

[0149] The network access container may include: K, SUPVIMSI, AKA certificate, security capabilities (authentication methods, security algorithm capabilities), slice subscription information, mobile operator public key used for SUPI hiding, and any other user / service subscription information. UDM 307 either retrieves the UE subscription information from the provisioning server or generates it locally. UDM 307 further constructs the network access container using the new user subscription information (K, IMSI, AKA credentials, SUCI generation input, routing ID, slice subscription information, security information, etc.) and uses the key K... ONB_enc To encrypt the container entering the network.

[0150] UDM 307 uses the integrity key KONB_int to generate the MAC address of the access container and the access assistance information (“OAI”) information element (“IE”) to protect the subscription information and related information sent to the UE. The OAI IE contains information about the access result with a “success indication”, the security algorithm and ID used to identify the encryption and integrity protection algorithms used to protect the access container (i.e., user subscription information), and related information.

[0151] Alternatively, a new random number can be used as input from the incoming root key (K). ONB_Root Export the network access security key, which can be used to protect subscription information related to network access.

[0152] K ONB_enc =KDF(KONB_Root MNO / Service Provider ID, random number, "Integrity Algorithm ID", "DID", keyword: "Subscription") Equation 6

[0153] K ONB_int =KDF(K ONB_Root MNO / Service Provider ID, random number, "Integrity Algorithm ID", "DID", keyword: "Subscription") Equation 7

[0154] Alternatively, if the subscription process involves a provisioning server instead of UDM 307, all of the above processes specified in step 8 will be performed by the provisioning server.

[0155] Alternatively, UDM 307 stores key K in ARPF as a new root key for subscription. UDM 307 selects the authentication method based on DID / SUPI, and CK' / IK'(or)K AUSF It can be derived from key K according to the normal specification, and if UDM 307 determines to perform master authentication and subscription provision / in the next full authentication run based on the new credentials, it is supplied to AUSF along with the authentication vector (AUTN, RAND, and key).

[0156] In step 9, UDM 307 sends the protected inbound container with encrypted subscription information, along with a random number, OAI, and MAC, to AUSF 305 (see Message Passing 329). In the depicted example, the MAC is generated by hashing the string using a hash function: Inbound Container || Nonce || OAI || DID || MNO / Service Provider ID. Here, the symbol "||" is used to indicate concatenation. In some embodiments, UDM 307 sends the protected inbound container in a Nudm_UEAuth_GetResponse message.

[0157] Alternatively, the provisioning server may, for example, use the service operation messages Npserver_UEAuth_GetResponse and / or Npserver_UESubscriptionProvisiing_Response to send a protected inbound container with encrypted subscription information along with a random number, OAI, and MAC (i.e., the hash of the inbound container ||Nonce||OAI||DID||MNO / Service Provider ID).

[0158] Alternatively, the UDM 307 can send the inbound container in plaintext to AUSF, along with the "Required NAS Protection Instruction" and inbound security context included as part of the OAI. ONB_Root ) / (K ONB_enc KONB_int The UDM 307 sends the authentication vector along with the inbound container from the Nudm_UEAuth_Get response message to the AUSF, which enables the UE to continue primary authentication immediately after retrieving subscription information from the inbound container.

[0159] In step 10, AMF 305 forwards the received protected inbound container with encrypted subscription information, along with a random number, OAI, and MAC (i.e., inbound container hash ||Nonce||OAI||DID||MNO / service provider ID) to AMF 303 in a service operation message (e.g., Nudm_UEAuth_Response).

[0160] Alternatively, the AUSF 305 can transmit the received plaintext inbound container along with the "Required NAS Protection Instructions" included as part of the OAI, along with the inbound security context (K). ONB_Root ) / (K ONB_enc K ONB_int The random number is forwarded to AMF 303.

[0161] Optionally, AMF 305 can also send the authentication challenge and RAND together with the access container (protected or plaintext) to AMF 303, which enables UE 205 to continue primary authentication immediately after retrieving subscription information from the access container.

[0162] In step 11, AMF 303 sends the received protected access container with encrypted subscription information, along with a random number, OAI, and MAC (i.e., access container hash ||Nonce||OAI||DID||MNO / service provider ID) to UE 205 via the NAS transmission / message in the Auth_Response message.

[0163] Alternatively, the AMF 303 receives data with a random number and a network access security context (K). ONB_Root ) / (K ONB_enc K ONB_int The plaintext inbound container of the OAI with NAS protection indication. If the AMF 303 receives the inbound root key as the inbound security context, the AMF 303 derives K. ONB_enc and K ONB_int The key. Then, the AMF 303 uses the inbound security context (K) key. ONB_enc K ONB_int Confidentiality and integrity protection are applied to inbound containers. AMF 303 uses key K ONB_enc Encrypt the inbound container and use the integrity key K ONB_intGenerate the MAC address and OAI IE of the network entry container to protect subscription information for integrity. K can be derived from Equation 6 above. ONB_enc K can be derived from Equation 7 above. ONB_int .

[0164] Then, AMF 303 sends a protected access container with encrypted subscription information, along with a random number, OAI, and MAC (i.e., the hash of the access container || Nonce || OAI || DID || MNO / Service Provider ID) to UE 205 via a NAS transfer / message in the Auth_Response message. The OAI IE contains information about the access result with a "success indication", a security algorithm ID used to identify the encryption and integrity protection algorithms used to protect the access container (i.e., user subscription information), and a "required protection indication".

[0165] Alternatively, AMF 303 can also send the authentication challenge and RAND along with the access container to UE 205, which enables UE 205 to continue primary authentication immediately after retrieving the subscription information from the access container.

[0166] Alternatively, AMF 303 sends a registration rejection to UE 205, including a protected access container and an access / authentication success indication. The rejection message may include an indication that UE 205 will re-register using the credentials supplied in the access container.

[0167] Step 12, upon receiving the OAI with a "success indication" network access result, UE 205 can use the received random number and the locally available shared secret key associated with the DID to generate, for example, K, based on an implementation similar to UDM 307 / providing server. ONB_Root K ONB_Sec K ONB_enc K ONB_int The security context of the key for network entry. UE 205 uses K. ONB_enc To decrypt the inbound container and use K ONB_int The system generates a MAC address and verifies that the calculated MAC address is the same as the received MAC address to check the integrity of the network access container, random number, and OAI information. If the MAC verification is successful, the UE 205 stores the received subscription information locally in a trusted storage device for use in subsequent network / service access.

[0168] The subscription information received in the network access container may include one or more of the following:

[0169] K, SUPI / IMSI, AKA credentials, security capabilities (authentication methods, security algorithm capabilities), slice subscription information, and any other user / service subscription information, etc.

[0170] Alternatively, if UE 205 receives a “Required NAS Protection Instruction” as part of the OAI, UE 205 understands that the inbound container is protected at the NAS level, and UE 205 can verify integrity and decrypt the inbound container based on the received OAI information, as described in step 12.

[0171] Alternatively, if UE 205 receives a registration rejection from a protected access container with an access / access authentication success indication, UE 205 can export the access key as described above, and then decrypt and verify the access container. UE 205 generates a fresh SUCI and sends an initial registration based on the subscription profile in the received access container. UE 205 can store the subscription profile in a new USIM profile or update an existing USIM profile.

[0172] Alternatively, if UE 205 receives an authentication challenge and RAND, as well as an access container, then after successful subscription reception, UE 205 continues to exchange authentication challenge responses with the network to continue primary authentication.

[0173] In step 13, UE 205 can initiate a registration request (initial registration) to AMF 303 based on the received subscription information and can perform master authentication. If master authentication is successful, UE 205 can export the Kausf as specified in 3GPP TS 33.501. Here, the newly exported Kausf replaces the previously exported Kausf based on the network access root key.

[0174] In step 14, AMF 303 initiates NAS SMC to set NAS security, and then AMF 303 triggers the initiation of UE initial context with gNB in ​​RAN 301.

[0175] In step 15, the gNB (in RAN 301) initiates and executes AS SMC to set the AS security context.

[0176] In step 16, after successful AS security setup, a protected registration acceptance message is sent to UE 205.

[0177] Figures 4A-4BThe illustration depicts a DIG-ID-based subscription access process 400 for network access during the network access process according to an embodiment of the present disclosure. Process 400 can be implemented using UE 205, RAN 301, AMF 303, AUSF 305, UDM / UDR 307, and Digital ID / Trust Service Platform (“ID / TSP”) 309. Process 400 represents an alternative subscription access process to process 300, primarily because process 400 uses a 5G network access process / instead of a registration process.

[0178] For the sake of brevity, it is assumed that process 400 is the same as process 300, with the main difference being in the network access-related service operation messages used to carry the network access information in the 5G system. Therefore, the following description expands upon the similar steps described above, and there are changes required regarding the 5G network access process.

[0179] Step 0 (see block 311) is basically as described above. Figure 3A As stated above.

[0180] In step 1, UE 205 (which can be any mobile user equipment or IoT device) constructs a subscription-unique access ID (“SUOI”) using a DID generated specific to the desired service. The SUOI ​​can be referenced above. Figure 3A The UE 205 is constructed as described. Alternatively, the UE 205 may generate a digital signature (“DS”) of the DID, timestamp, and a combination of DID / timestamp (referred to as “DID_TS”). Here, the UE 205 sends a network access request message to the AMF 303 (via the N1 / NAS interface), which includes a subscription access instruction and a SUOI ​​(optionally, a hidden SUOI) or a DID_TS with a DS (see Message Passing 413).

[0181] In step 2, AMF 303 forwards the network access request message with a subscription access indication and the received SUOI ​​(optionally, a hidden SUOI) or DID_TS with DS (see message passing 415) to AMF 305. In some embodiments, AMF 303 uses a service operation message (i.e., Nausf_UEOnboard_Request) to forward the received network access request.

[0182] In step 3, upon receiving a subscription access instruction with a plaintext / hidden SUOI ​​based on DID or a DID_TS with DS, AUSF 305 sends an authentication / access data request message (see Message Passing 407) to UDM / UDR 307 containing the received subscription access instruction and SUOI ​​(or a hidden SUOI), or alternatively, a DID_TS with DS. In one embodiment, AUSF 305 uses the service operation message Nudm_UEOnboard_Request to send the authentication / access data request message. In another embodiment, AUSF 305 uses the service operation message Nudm_Subscription_GetRequest to send the authentication / access data request message.

[0183] Alternatively, upon receiving a subscription access instruction with a plaintext / hidden SUOI ​​based on DID or a DID_TS with DS, the AUSF 305 sends an authentication / access data request message to the provisioning server containing the received subscription access instruction and the SUOI ​​(or a hidden SUOI), or alternatively, a DID_TS with DS. In one embodiment, the AUSF 305 uses the service operation message Npserver_UEOnboard_GetRequest to send the authentication / access data request message. In another embodiment, the AUSF 305 uses the service operation message Npserver_UESubscriptionProvioing_Request to send the authentication / access data request message.

[0184] In step 4, based on the DID type and subscription access instruction, UDM / UDR 307 can determine the ID service / trust service provider 309 that invokes DID verification through the management / control of the DID and the associated DID file (verifiable user / device credentials).

[0185] Alternatively, based on the DID type and subscription access instructions, the provisioning server can determine which ID service / trusted service provider manages / controls the DID and related DID files (verifiable user / device credentials) to invoke DID verification.

[0186] Steps 5-7 are basically the same as described above. Figure 3A See (see message passing 321, block 323 and message passing 325).

[0187] continue Figure 4B Step 8 is basically the same as the above reference. Figure 4B See block 327.

[0188] In step 9, UDM / UDR 307 sends a protected access container with encrypted subscription information, along with a random number, OAI, and MAC (i.e., the hash of the access container ||Nonce||OAI||DID||MNO / Service Provider ID) to AUSF 305 in an authentication or access data response message (see message passing 429). In one embodiment, UDM / UDR 307 uses the service operation message Nudm_UEOnboard_Response to send the protected access container. Alternatively, UDM / UDR 307 uses the service operation message Nudm_Subscription_GetResponse to send the protected access container.

[0189] Alternatively, the provisioning server may send a protected access container with encrypted subscription information, along with a random number, OAI, and MAC (hash of the access container || Nonce || OAI || DID || MNO / Service Provider ID) to the AUSF 305 in an authentication or access data response message. In one embodiment, the provisioning server uses the service operation message Npserver_UEOnboard_GetResponse to send the protected access container. Alternatively, the provisioning server may use the service operation message Npserver_UESubscriptionProvisiing_Response to send the protected access container.

[0190] Alternatively, the UDM 307 and / or the provisioning server may send subscription information, along with a random number and the access security context (K) to the AUSF 305 in the authentication / access data response message (e.g., in one of the service operation messages Nudm_UEOnboard_Response, Nudm_Subscription_GetRequest, Npserver_UEOnboard_GetResponse, and / or Npserver_UESubscriptionProvioing_Response). ONB_Root ) / (K ONB_enc K ONB_int )) and OAI.

[0191] In step 10, AMF 305 forwards the received protected inbound container with encrypted subscription information, along with a random number, OAI, and MAC (i.e., the hash of the inbound container ||Nonce||OAI||DID||MNO / service provider ID) to AMF 303, for example, in a Nudm_UEOnboard_Response message (see message passing 425).

[0192] Alternatively, AUSF 305 will include the received unprotected access container with plaintext subscription information, along with the Nonce and access security context (K) in the Nudm_UEOnboard_Response message. ONB_Root ) / (K ONB_enc K ONB_int )) and OAI forwarded it to AMF 303.

[0193] In step 11, AMF 303 sends the received protected access container with encrypted subscription information and random number, OAI and MAC (i.e., hash of access container ||Nonce||OAI||DID||MNO / service provider ID) to UE 205 via NAS transmission / message in Onboard_Response message (see message passing 433).

[0194] Alternatively, AMF 303 applies confidentiality and integrity protection to the received network access container and sends encrypted subscription information, along with a random number, OAI, and MAC (i.e., network access container hash || Nonce || OAI || DID || MNO / service provider ID) to the UE via NAS transmission / message in the Onboard_Response message.

[0195] Steps 12-16 are basically as described in the reference above. Figure 3B See (see block 335, message passing 337, message passing 339, message passing 341 and message passing 343).

[0196] Note that process 400 can also be used in the following scenarios, where the PLMN / NPN network operator performs DID user identification authentication via ID / trust service provider infrastructure / decentralized ID framework to trigger the MNO's PEMN / NPN / third-party service provider subscription to UE 205 for network access and provisioning.

[0197] Figure 5 The illustration depicts a process 500 for enabling DIG-ID-based identification, authentication, and trust services via a service enabler function, according to an embodiment of the present disclosure. Process 500 represents an alternative subscription onboarding process to processes 300 and 400.

[0198] For the sake of brevity, assume process 500 is in Figure 3A Step 3 begins after this step, replacing steps 4 through 8 of process 300. Alternatively, process 500 can be... Figure 4A After step 3, the process begins and replaces steps 4 through 8 of process 400. Figure 5The DID verification and key request process shown below can be used to enable 3GPP network functions (“NF”) 501 (such as AUSF and / or UDM and / or provisioning servers) to communicate with an external identity framework 505 via the Digital Identity, Authentication and Trust Service Enabler Function (“D-IDASEF”) or Blockchain Service Enabler Function (“BSEF”) (collectively, “D-IDASEF / BSEF” 503) to perform DID-based ID verification and authentication, thereby enabling subscription provisioning to the appropriate UE. D-IDASEF / BSEF 503 is a new 3GPP network function capable of belonging to the domain of a mobile network operator or service provider. In some embodiments, D-IDASEF / BSEF 503 performs an AAA-proxy function. Note that D-IDASEF / BSEF 503 can be an embodiment of D-IDASEF 137 and / or BSEF 138.

[0199] External identity framework 505 may include identity service providers and / or trust service providers (“TSPs”), such as ID / TSP 211 and / or ID / TSP 309. As described above, ID / trust service providers can together form a digital identity service platform (“DISP”). In some embodiments, identity framework 505 includes blockchain service infrastructure (e.g., BSI 144) and / or permissioned distributed ledger (“PDL”) service infrastructure. In some embodiments, identity framework 505 includes a digital ID framework, a decentralized ID framework, and / or a self-governing ID framework.

[0200] In various embodiments, the identification framework 505 is associated with a service ID 507 provided by an identification provider and / or DID service infrastructure controlled by a PLMN or NPN operator. Alternatively, the infrastructure providing the service ID 507 may be controlled by a third-party service provider.

[0201] The identification framework 505 can reside outside the 3GPP network, for example, if the blockchain / PDL service infrastructure is managed by a third-party service provider. In such an embodiment, the DIG-ID (e.g., DID or SSI) can be stored in the blockchain or PDL (e.g., blockchain and / or distributed ledger network 160). In other embodiments, the identification framework 505 can be managed by the MNO or service provider within the 3GPP network. Note that 3GPP NF 501 and D-IDASEF / BSEF 503 reside within the 3GPP network. The AUSF / UDM can communicate directly with D-IDASEF / BSEF 503 or via a provisioning server (such as provisioning server 215).

[0202] Process 500 begins at step 4, where—based on the DID type and the ID / trust service provider ID (i.e., domain name)—3GPP NF 501 (e.g., AUSF / UDM) can determine the ID service / trust service provider that manages / controls the DID and the associated DID file (verifiable user / device credentials) to invoke DID verification (see block 509). Alternatively, based on the DID type and the ID / trust service provider ID (i.e., domain name), the provisioning server (as 3GPP NF 501) can determine the ID service / trust service provider that manages / controls the DID and the associated DID file (verifiable user / device credentials) to invoke DID verification.

[0203] In step 5a, based on the ID service / trusted service provider information present in the DID or SUO / hidden SUOI, 3GPP NF 501 (e.g., AUSF / UDM) sends a subscriber ID verification request message to D-IDASEF / BSEF 503 containing the received SUOI / DID / hidden DID / DID_TS with DS and a key request indication (see Message Passing 511). Alternatively, based on the ID service / trusted service provider information present in the DID or SUOI / hidden SUOI, the provisioning server sends a subscriber ID verification request message to D-IDASEF / BSEF 503 containing the received SUOI / DID / hidden DID / DID_TS with DS and a key request indication.

[0204] In step 5b, based on the ID service / trust service provider information present in the DID or SUOI / hidden SUOI, D-IDASEF / BSEF 503 forwards the received subscriber ID verification request message with the received SUOI / DID / hidden DID / DID_TS with DS and key request indication to the identification frame 505 (see messaging 513).

[0205] In step 6, when the identification framework 505 (e.g., ID / TSP) receives the SUOI / DID / DID_TS with DS, it verifies the DID based on a universal parser or local database information. This universal parser or local database information stores the association between the DID and the address of the DID file, along with the associated user public key storage, in the blockchain / PDL (see block 515). The identification framework 505 verifies the validity, scope, and authenticity of the DID by retrieving the DID information and the user file (verifiable credentials). If any NF (e.g., UDM, alternatively a subscription provisioning server / online server) from the service provider / MNO domain requests any subscriber-related information, the identification framework 505 generates a minimal dataset (“MDS”) containing all required subscriber verifiable credentials (e.g., the minimal dataset can include subscriber name, subscriber location, DID validity, service payment information, service activation status, etc.).

[0206] Additionally, if the service provider also requests protection for any security key requests for subscription access, the Identification Framework 505 (e.g., ID / TSP) derives the root key (K) based on the security credentials available in the UE (e.g., public-private key pairs and shared keys). ONB_Root K ONB_Root It can be derived from Equation 1 or Equation 2 above.

[0207] Alternatively, if the identification frame 505 (e.g., ID / TSP) receives a hidden SUOI / DID instead of a plaintext SUOI, the hidden SUOI ​​is dehidden using the private key associated with the public key indicated by the public key ID. The remainder of the process involved in verifying the DID retrieved from the SUOI, minimal dataset generation, and network access key generation will be the same as described above.

[0208] Alternatively, if the identification framework 505 (e.g., ID / TSP) receives a DID_TS with a DS, the DID is used to locate the DID file and public key storage information. The identification framework 505 then retrieves the user's public key to verify the digital signature of the DID and the timestamp provided as part of the DID_TS, thereby verifying that the received DID originates from an authorized user (i.e., UE 205).

[0209] In step 7a, the identification framework 505 (e.g., ID / TSP) sends a subscriber ID verification response message to D-IDASEF / BSEF 503 (or the NF in the service provider domain). The subscriber ID verification response message includes the verified DID, the DID lifetime, the DID verification result (success or failure), the minimum dataset with user information, and the network access root key (K). ONB_Root(See Message Passing 517). Identification Framework 505 determines the DID lifetime based on the lifetime of the credential / DID file associated with the UE's DID.

[0210] In step 7b, D-IDASEF / BSEF 503 forwards the received subscriber ID verification response message to AUSF / UDM (e.g., NF 501 in the service provider domain). This subscriber ID verification response message includes the verified DID, DID lifetime, DID verification result (success or failure), a minimum dataset containing user information, and the network access root key (K). ONB_Root (See Message Passing 519). Alternatively, D-IDASEF / BSEF 503 forwards the received subscriber ID verification response message to the provisioning server (e.g., NF 501 in the service provider domain). The received subscriber ID verification response message includes the verified DID, the DID verification result (success or failure), a minimum dataset with user information, and the root key (K). ONB_Root ).

[0211] In step 8, if 3GPP NF 501 (e.g., AUSF / UDM) receives a "successful" DID verification result, it will send the received information (such as the verified DID, the DID verification result (success or failure), the minimum dataset with user information, and the network access root key) to the network. ONB_Root The information is stored in the UDR (see block 521). However, if the 3GPP NF 501 receives a DID verification result as a "failure", the 3GPP NF 501 may store the received information, such as the verified DID and the DID verification result (failure), in the UDR.

[0212] 3GPP NF 501 (e.g., UDM) further generates random numbers and uses these random numbers as input in key derivation to derive the network access security key (K) from the received network access root key. ONB_Sec ), as follows. K ONB_Sec This is used to protect the confidentiality and integrity of the inbound container containing user subscription information supplied to UE205. K can be derived using Equation 3. ONB_Sec K can be derived using Equation 4. ONB_enc K can be derived using Equation 5. ONB_int .

[0213] 3GPP NF 501 (e.g., UDM) either retrieves UE subscription information from a provisioning server or generates it locally. 3GPP NF 501 (e.g., UDM) can further construct an access container using new user subscription information (K, SUPI / IMSI, AKA credentials, SUCI generation inputs such as HN public key ID, protection scheme, routing ID, slice subscription information, security information, etc.). In some embodiments, 3GPP NF 501 (e.g., UDM) utilizes key K... ONB_enc Encrypt the inbound container and use the integrity key K. ONB_int The MAC address and OAI IE of the network access container are generated and sent to the UE along with subscription information and related information for integrity protection. The OAI IE can contain information about the network access result with a "success indication", the security algorithm and ID used to identify the encryption and integrity protection algorithms used to protect the network access container (i.e., user subscription information) and related information (e.g., OAI).

[0214] Alternatively, a new random number can be used as input from the incoming root key (K). ONB_Root The network access security key is derived, and this key can be used to protect subscription information related to network access. In such an embodiment, K can be derived using Equation 6. ONB_enc K can be derived using Equation 7. ONB_int .

[0215] Alternatively, if the provisioning server, rather than the UDM, is involved in the subscription onboarding process, all of the above processing will be performed by the provisioning server. Alternatively, the UDM can generate an onboarding security key and provide it to the AMF along with a random number and an OAI with a "Required NAS Protection Indicator" to trigger the AMF to use the provided onboarding security key to protect the onboarding container.

[0216] In one embodiment, process 500 executes from Figure 3B Steps 9-16 are completed. In another embodiment, process 500 is completed by executing from Figure 4B Steps 9-16 are complete.

[0217] In alternative options, for example, to support service providers (e.g., content service providers or on-demand service providers) that provide UE subscription information to UEs via network operators (e.g., NPN / PLMN), process 500 can also be used in scenarios where network operator A provides network access to users of service provider B using credentials provided by service provider B (based on user online registration for pay-as-you-go pricing).

[0218] Here, for this scenario, service provider B will process the messages in steps 5b, 6, and 7a, and after successful DID-based ID authentication, service provider B will provide the user subscription information from the minimal dataset to network operator A in step 7a. Network operator A will then construct the complete user subscription information using the minimal dataset related to the user subscription information by adding network operator A-specific slice selection information (e.g., NSSAI) and other required network subscription information, and use... Figure 3B In the middle, alternative sites are Figure 4B The process shown provides the UE with user subscription information (the steps are applicable based on the above modifications regarding network operator A and service provider B).

[0219] Figure 6 User equipment device 600, which can be used to configure LCH mapping restrictions for SDT according to embodiments of the present disclosure, is depicted. In various embodiments, user equipment device 600 is used to implement one or more of the solutions described above. User equipment device 600 may be an embodiment of remote unit 105 and / or UE 205 described above. In addition, user equipment device 600 may include processor 605, memory 610, input device 615, output device 620, and transceiver 625.

[0220] In some embodiments, input device 615 and output device 620 are combined into a single device, such as a touchscreen. In some embodiments, user equipment device 600 may not include any input device 615 and / or output device 620. In various embodiments, user equipment device 600 may include one or more of the following: processor 605, memory 610, and transceiver 625, and may not include input device 615 and / or output device 620.

[0221] As depicted, transceiver 625 includes at least one transmitter 630 and at least one receiver 635. Here, transceiver 625 communicates with one or more serving cells supported by one or more base station elements 121. Additionally, transceiver 625 may support at least one network interface 640 and / or application interface 645. Application interface 645 may support one or more APIs. Network interface 640 may support 3GPP reference points, such as Uu and PC5. Other network interfaces 640 may be supported, as will be understood by those skilled in the art.

[0222] In one embodiment, processor 605 may include any known controller capable of executing computer-readable instructions and / or performing logical operations. For example, processor 605 may be a microcontroller, microprocessor, central processing unit (“CPU”), graphics processing unit (“GPU”), auxiliary processing unit, field-programmable gate array (“FPGA”), or similar programmable controller. In some embodiments, processor 605 executes instructions stored in memory 610 to perform the methods and routines described herein. Processor 605 is communicatively coupled to memory 610, input device 615, output device 620, and transceiver 625.

[0223] In various embodiments, processor 605 controls user equipment device 600 to implement the UE behaviors described above. For example, processor 605 controls user equipment device 600 to implement the UE behaviors described above. For example, processor 605 acquires a DIG-ID, which includes a verifiable security identifier. In some embodiments, the DIG-ID includes at least one of the following: DID, SSI, and DOID. In some embodiments, acquiring the DIG-ID includes purchasing a subscription associated with a mobile communication network and / or generating a DIG-ID at the UE.

[0224] Processor 605 uses a private key to generate a digital signature and timestamp for the DIG-ID. In some embodiments, the DIG-ID is a verifiable security identifier linked to a verifiable credential of a user stored on a trusted and decentralized platform or digital identifier infrastructure associated with a trusted service provider and / or an ID service provider. In such embodiments, the DIG-ID is used to perform user authentication during the provision of access and subscription credentials to the UE. In some embodiments, the DIG-ID is included within the username portion of the NAI, which has this form.<username@realm> In such embodiments, the NAI may include a DIG-ID and at least one of the following: a timestamp, a digital signature, key-related information, trusted service provider information, and / or identification service provider information.

[0225] via transceiver 625, processor 605 sends a first request to the mobile communication network (i.e., to the serving MNO) and receives a first response. Here, the first request includes a DIG-ID, a timestamp, and a generated digital signature, and the first response includes a network access authentication success indication and a verified DIG-ID.

[0226] In some embodiments, the first request includes a SUOI ​​containing a DIG-ID, a timestamp, and a digital signature. In some embodiments, the SUOI ​​also includes one or more of the following: DIG-ID type, service provider identifier, ID service provider domain information, and trusted service provider domain information. In such embodiments, the entire SUOI ​​is used to generate a digital signature. Note that the digital signature helps the message recipient (i.e., the service MNO) verify that the received ID and related information have not been tampered with (e.g., altered) by any attacker.

[0227] In some embodiments, a shared secret encryption key is used to protect the DIG-ID. When using a shared secret encryption key to protect the DIG-ID, the SUOI ​​further includes the SUOI's MAC, the user's public key, and a public key identifier corresponding to the ID service provider identified by the ID service provider information and / or the trust service provider identified by the trust service provider information.

[0228] Processor 605 establishes a provisioning connection to the mobile communication network and receives subscription credentials and / or user subscription profiles via the provisioning connection. In some embodiments, DIG-ID includes at least one of the following: DID, SSI, and DOID. In some embodiments, receiving subscription credentials and / or user subscription profiles includes receiving a protected access container within a NAS message or user plane message, which is protected using an encryption key and an integrity key derived from the security key based on the access root key.

[0229] In some embodiments, the first request includes a registration request to initiate a registration process with the mobile communication network. In such embodiments, following successful DIG-ID-based user authentication and / or security setup based on the network access root key, during the registration process via NAS or control plane messages, subscription credentials and / or user subscription profiles are supplied to the UE in the network access container. Here, security setup may be at least through the non-access stratum and may optionally include the access stratum and user plane.

[0230] In other embodiments, the first request includes a network access request. In such embodiments, subscription credentials and / or a user subscription profile are supplied to the UE in the network access response and / or in the user plane message following successful DIG-ID-based user authentication and / or security setup based on the network access root key during the network access and provisioning process.

[0231] In some embodiments, receiving subscription credentials and / or a user subscription profile includes receiving a protected access container within a NAS message from the AMF in the mobile communication network, wherein the NAS message includes an OAI, a random number, and a MAC. In such an embodiment, the processor 605 may derive an access root key using a shared secret key and a successfully verified DIG-ID, and use the access root key as the AUSF key. The processor 605 may further derive at least one security key using the access root key and at least one of the following: a random number, a PLMN identifier, and a network identifier.

[0232] Then, processor 605 can use a security key as the SEAF key and, either set up network security (i.e., NAS security, AS security, and / or user plane security) or use a security key to derive an access confidentiality key for decrypting the protected access container and an access integrity key for verifying the MAC of the NAS message providing the protected access container. Additionally, processor 605 can verify the MAC of the NAS message based on an OAI, where the OAI contains an access result with a "success indication" and one or more security algorithm identifiers. In response to successful MAC verification, processor 605 can decrypt and store the received subscription credentials and / or user subscription profile.

[0233] In one embodiment, memory 610 is a computer-readable storage medium. In some embodiments, memory 610 includes volatile computer storage media. For example, memory 610 may include RAM, including dynamic RAM (“DRAM”), synchronous dynamic RAM (“SDRAM”), and / or static RAM (“SRAM”). In some embodiments, memory 610 includes non-volatile computer storage media. For example, memory 610 may include a hard disk drive, flash memory, or any other suitable non-volatile computer storage device. In some embodiments, memory 610 includes both volatile and non-volatile computer storage media.

[0234] In some embodiments, memory 610 stores data related to subscription to the network based on a digital ID. For example, memory 610 may store UE identifiers, user identifiers, network function identifiers, encryption keys, security algorithms, digital signatures, message authentication codes, network resource identifiers, etc. In some embodiments, memory 610 also stores program code and related data, such as an operating system or other controller algorithms running on device 600.

[0235] In one embodiment, input device 615 may include any known computer input device, including a touch panel, buttons, keyboard, stylus, microphone, etc. In some embodiments, input device 615 may be integrated with output device 620, such as a touchscreen or similar touch-sensitive display. In some embodiments, input device 615 includes a touchscreen, enabling text input using a virtual keyboard displayed on the touchscreen and / or by handwriting on the touchscreen. In some embodiments, input device 615 includes two or more different devices, such as a keyboard and a touch panel.

[0236] In one embodiment, output device 620 is designed to output visual, auditory, and / or tactile signals. In some embodiments, output device 620 includes an electronically controllable display or display device capable of outputting visual data to a user. For example, output device 620 may include, but is not limited to, LCD displays, LED displays, OLED displays, projectors, or similar display devices capable of outputting images, text, etc., to a user. As another non-limiting example, output device 620 may include a wearable display, such as a smartwatch, smart glasses, head-up display, etc., that is separate from but communicatively coupled to the rest of user equipment device 600. Furthermore, output device 620 may be a component of a smartphone, personal digital assistant, television, desktop computer, laptop computer, personal computer, vehicle dashboard, etc.

[0237] In some embodiments, output device 620 includes one or more speakers for generating sound. For example, output device 620 may generate an audible alarm or notification (e.g., a beep or ringtone). In some embodiments, output device 620 includes one or more haptic devices for generating vibration, motion, or other haptic feedback. In some embodiments, all or part of output device 620 may be integrated with input device 615. For example, input device 615 and output device 620 may form a touchscreen or similar touch-sensitive display. In other embodiments, output device 620 may be located near input device 615.

[0238] Transceiver 625 includes at least a transmitter 630 and at least one receiver 635. One or more transmitters 630 can be used to provide UL communication signals to base station unit 121, such as the UL transmission described herein. Similarly, one or more receivers 635 can be used to receive DL communication signals from base station unit 121, as described herein. Although only one transmitter 630 and one receiver 635 are illustrated, user equipment device 600 can have any suitable number of transmitters 630 and receivers 635. Furthermore, transmitters 630 and receivers 635 can be of any suitable type. In one embodiment, transceiver 625 includes a first transmitter / receiver pair for communicating with a mobile communication network on licensed radio spectrum and a second transmitter / receiver pair for communicating with a mobile communication network on unlicensed radio spectrum.

[0239] In some embodiments, a first transmitter / receiver pair for communicating with a mobile communication network on licensed radio spectrum and a second transmitter / receiver pair for communicating with a mobile communication network on unlicensed radio spectrum may be combined into a single transceiver unit, such as a single chip performing functions for use with both licensed and unlicensed radio spectrum. In some embodiments, the first transmitter / receiver pair and the second transmitter / receiver pair may share one or more hardware components. For example, some transceivers 625, transmitters 630, and receivers 635 may be implemented as physically separate components that access shared hardware resources and / or software resources (such as, for example, network interface 640).

[0240] In various embodiments, one or more transmitters 630 and / or one or more receivers 635 may be implemented and / or integrated into a single hardware component, such as a multi-transceiver chip, a system-on-a-chip, an ASIC, or other types of hardware component. In some embodiments, one or more transmitters 630 and / or one or more receivers 635 may be implemented and / or integrated into a multi-chip module. In some embodiments, other components, such as a network interface 640 or other hardware components / circuit, may be integrated with any number of transmitters 630 and / or receivers 635 into a single chip. In such embodiments, transmitters 630 and receivers 635 may be logically configured as transceivers 625 using a plurality of common control signals, or configured as modular transmitters 630 and receivers 635 implemented in the same hardware chip or multi-chip module.

[0241] Figure 7An embodiment of a network device apparatus 700, which can be used for subscription access based on a digital ID, is depicted according to embodiments of the present disclosure. In some embodiments, the network apparatus 700 may be an embodiment for implementing network functions of any of the solutions described above. For example, the network device apparatus 700 may include hardware and / or software resources to implement one of the aforementioned network functions in a mobile communication network (i.e., PLMN, NPN, and / or MNO), such as AUSF 135, D-IDASEF 137, BSEF 138, UDM / UDR 139, O-AUSF 209, AUSF 305, UDM / UDR 307, 3GPP NF 501, and / or D-IDASEF / BSEF 503. Further, the network device apparatus 700 may include a processor 705, a memory 710, an input device 715, an output device 720, and a transceiver 725. In some embodiments, the network device apparatus 700 does not include any input device 715 and / or output device 720.

[0242] As depicted, transceiver 725 includes at least one transmitter 730 and at least one receiver 735. Here, transceiver 725 communicates with one or more remote units 105. Furthermore, transceiver 725 may support at least one network interface 740 and / or application interface 745. Application interface 745 may support one or more APIs. Network interface 740 may support 3GPP reference points, such as N1, N3, etc. Other network interfaces 740 may be supported, as will be understood by those skilled in the art.

[0243] In one embodiment, processor 705 may include any known controller capable of executing computer-readable instructions and / or performing logical operations. For example, processor 705 may be a microcontroller, microprocessor, central processing unit (“CPU”), graphics processing unit (“GPU”), auxiliary processing unit, field-programmable gate array (“FPGA”), or similar programmable controller. In some embodiments, processor 705 executes instructions stored in memory 710 to perform the methods and routines described herein. Processor 705 is communicatively coupled to memory 710, input device 715, output device 720, and transceiver 725.

[0244] In various embodiments, processor 705 controls network device apparatus 700 to implement the aforementioned network functional behaviors. For example, via network interface 740, processor 705 receives a first request containing the UE's DIG-ID, timestamp, and digital signature, wherein the digital identifier includes a verifiable security identifier. For example, DIG-ID may include at least one of the following: DID, SSI, verifiable security identifier, and DOID.

[0245] In some embodiments, the DIG-ID is a verifiable security identifier linked to a user's verifiable credentials stored on a trusted and decentralized platform or digital identifier infrastructure associated with a trusted service provider and / or an ID service provider. In such embodiments, the DIG-ID is used to perform user authentication during the provision of network access and subscription credentials to the UE. In some embodiments, the DIG-ID is included within the username portion of the NAI, which has the form<usemame@realm> In such embodiments, the NAI may include a DIG-ID and at least one of the following: a timestamp, a digital signature, key-related information, trusted service provider information, and / or identification service provider information.

[0246] In some embodiments, the first request includes a SUOI, which comprises a DIG-ID, a timestamp, and a digital signature. In some embodiments, the SUOI ​​further includes one or more of the following: DIG-ID type, service provider identifier, ID service provider domain information, and trusted service provider domain information. In such embodiments, the digital signature is generated using the entire SUOI.

[0247] In some embodiments, a shared secret encryption key is used to protect the DIG-ID. When using a shared secret encryption key to protect the DIG-ID, the SUOI ​​further includes the SUOI's MAC, the user's public key, and / or a public key identifier corresponding to the ID service provider identified by the ID service provider information and / or the trust service provider identified by the trust service provider information.

[0248] The processor 705 identifies the trusted service provider based on the DIG-ID and controls the network interface 740 to send an authentication request to the trusted service provider. This authentication request includes the DIG-ID, timestamp, digital signature, minimum dataset request, and security key request.

[0249] Processor 705 receives, in response to successful DIG-ID verification (e.g., via network interface 740), the verified DIG-ID, verification result, DIG-ID lifetime, MDS information, and network access root key from the service provider. In various embodiments, the MDS information includes user information. In some embodiments, invoking the UE's subscription provisioning based on the MDS information includes invoking a temporary subscription credential provisioning. In some embodiments, the MDS information includes at least one of the following: user information, subscription purchase information, subscription service related information, subscription validity, and network resources used for subscription provisioning (i.e., MNO subscription provisioning-related URI / URL / address). In such embodiments, invoking the subscription provisioning for the UE based on the MDS information may include invoking the actual user subscription profile provisioning.

[0250] In some embodiments, the processor stores the verified digital ID, verification result, digital ID lifetime, MDS information, and network access root key in the DMF or UDM / UDR of the mobile communication network. Specifically, the data can be stored in the UDR, where the UDM is the front end providing access to the data. Here, the UDM and UDR together form a network function, referred to as "UDM / UDR".

[0251] The processor 705 invokes the UE's subscription provisioning based on MDS information, where the subscription provisioning is protected using the network access root key.

[0252] In some embodiments, the processor generates a random number and uses the network access root key and at least one of the following to derive one or more security keys: the random number, the PLMN identifier, and the network identifier. In such embodiments, the processor uses a security key to derive one or more network access security keys (i.e., a confidentiality key and an integrity key for encrypting the network access container and protecting its integrity), and generates a plaintext or protected network access container and an OAI for the UE, wherein at least one of the derived security keys is used to protect the network access container.

[0253] In some embodiments, the processor retrieves the default subscription credentials for the DIG-ID from the DMF or UDM / UDR and exports one or more inbound security keys. In such embodiments, the default subscription credentials and one or more inbound security keys are provided as a second network function of the AMF and / or SEAF.

[0254] In some embodiments, the processor uses the received network access root key as the AUSF key and provides a security key as the SEAF key to the AMF / SEAF to establish security (i.e., NAS security, AS security, and / or user plane security) with the UE for provisioning the connection. In some embodiments, in response to receiving default subscription credentials in an unprotected network access container, the second network function (i.e., the AMF / SEAF) applies confidentiality and integrity protection to the network access container using an encryption key and an integrity key derived from the received network access security key. In such embodiments, the UE's subscription provisioning includes the second network function sending a NAS message to the UE, the NAS message being confidential and integrity protected or containing a protected network access container, network access assistance information, a random number, and a MAC address.

[0255] In some embodiments, the network access container includes a subscription credential (i.e., SUPI), a secret long-term key (denoted as 'K'), an authentication and key protocol (“AKA”) credential, and slice information (e.g., one or more S-NSSAIs). In some embodiments, the subscription credential includes a subscription-unique permanent identifier. Furthermore, the network access container may further include network access information and additional subscription information.

[0256] In some embodiments, the first request includes an authentication request to initiate an authentication process with the mobile communication network. In such embodiments, during the registration process, after successful DIG-ID-based user authentication and / or security settings based on the network access root key using the network access container via NAS or control plane messages, subscription credentials and / or a user subscription profile are supplied to the UE. Here, the security settings can be at least via NAS and may optionally include access stratum (AS) and user plane (UP) security settings. Note that the UE may send a registration request to the AMF / SEAF, and then the AMF / SEAF, upon receiving the registration request, sends an authentication request with all the information received in the registration request to the AFS.

[0257] In other embodiments, the first request includes a network access request. In such embodiments, subscription credentials and / or a user subscription profile are supplied to the UE in the network access response and / or in a user plane message after successful DIG-ID-based user authentication and / or security setup based on the network access root key during the network access and provisioning process.

[0258] In one embodiment, memory 710 is a computer-readable storage medium. In some embodiments, memory 710 includes volatile computer storage media. For example, memory 710 may include RAM, including dynamic RAM (“DRAM”), synchronous dynamic RAM (“SDRAM”), and / or static RAM (“SRAM”). In some embodiments, memory 710 includes non-volatile computer storage media. For example, memory 710 may include a hard disk drive, flash memory, or any other suitable non-volatile computer storage device. In some embodiments, memory 710 includes both volatile and non-volatile computer storage media.

[0259] In some embodiments, memory 710 stores data related to subscription to the network based on digital IDs, such as UE identifiers, user identifiers, network function identifiers, encryption keys, security algorithms, digital signatures, message authentication codes, network resource identifiers, etc. In some embodiments, memory 710 also stores program code and related data, such as an operating system (“OS”) or other controller algorithms operating on network device device 700 and one or more software applications.

[0260] In one embodiment, input device 715 may include any known computer input device, including a touch panel, buttons, keyboard, stylus, microphone, etc. In some embodiments, input device 715 may be integrated with output device 720, such as a touchscreen or similar touch-sensitive display. In some embodiments, input device 715 includes a touchscreen, enabling text input using a virtual keyboard displayed on the touchscreen and / or by handwriting on the touchscreen. In some embodiments, input device 715 includes two or more different devices, such as a keyboard and a touch panel.

[0261] In one embodiment, output device 720 may include any known electronically controllable display or display device. Output device 720 is designed to output visual, auditory, and / or tactile signals. In some embodiments, output device 720 includes an electronic display capable of outputting visual data to a user. Furthermore, output device 720 may be a component of a smartphone, personal digital assistant, television, desktop computer, laptop computer, personal computer, vehicle dashboard, etc.

[0262] In some embodiments, output device 720 includes one or more speakers for generating sound. For example, output device 720 may generate an audible alarm or notification (e.g., a beep or ringtone). In some embodiments, output device 720 includes one or more haptic devices for generating vibration, motion, or other haptic feedback. In some embodiments, all or part of output device 720 may be integrated with input device 715. For example, input device 715 and output device 720 may form a touchscreen or similar touch-sensitive display. In other embodiments, all or part of output device 720 may be located near input device 715.

[0263] As discussed above, transceiver 725 can communicate with one or more remote units and / or with one or more network functions that provide access to one or more PLMNs. Transceiver 725 operates under the control of processor 705 to transmit messages, data, and other signals, and also to receive messages, data, and other signals. For example, processor 705 can selectively activate the transceiver (or a portion thereof) at specific times to send and receive messages.

[0264] Transceiver 725 may include one or more transmitters 730 and one or more receivers 735. In some embodiments, one or more transmitters 730 and / or one or more receivers 735 may share transceiver hardware and / or circuitry. For example, one or more transmitters 730 and / or one or more receivers 735 may share antennas, antenna tuners, amplifiers, filters, oscillators, mixers, modulators / demodulators, power supplies, etc. In one embodiment, transceiver 725 implements multiple logical transceivers using different communication protocols or protocol stacks while using common physical hardware.

[0265] Figure 8 An embodiment of a method 800 for subscription to a network based on a digital ID, according to embodiments of the present disclosure, is described. In various embodiments, the method 800 is performed by a UE, such as the remote unit 105, UE 205, and / or user equipment device 600 described above. In some embodiments, the method 800 is performed by a processor, such as a microcontroller, microprocessor, CPU, GPU, auxiliary processing unit, FPGA, etc.

[0266] Method 800 begins by obtaining 805 DIG-ID, which includes a verifiable security identifier. Method 800 includes generating 810 a digital signature and timestamp for the DIG-ID using a private key. Method 800 includes sending 815 a first request to the mobile communication network (i.e., the serving MNO), the first request including the DIG-ID, timestamp, and the generated digital signature. Method 800 includes receiving 820 a successful network access authentication indication and the verified DIG-ID. Method 800 includes establishing 825 a provisioning connection to the mobile communication network. Method 800 includes receiving 830 subscription credentials and / or user subscription profiles via the provisioning connection. Method 800 ends.

[0267] Figure 9 An embodiment of a method 900 for subscription to a network based on a digital ID, according to embodiments of the present disclosure, is described. In various embodiments, the method 900 is performed by network functions such as AUSF 135, D-IDASEF 137, BSEF 138, UDM / UDR 139, O-AUSF 209, AUSF 305, UDM / UDR 307, 3GPP NF 501 and / or D-IDASEF / BSEF 503 and / or network device apparatus 700 described above. In some embodiments, the method 900 is performed by a processor, such as a microcontroller, microprocessor, CPU, GPU, auxiliary processing unit, FPGA, etc.

[0268] Method 900 begins and receives a first request (905), which includes the UE's DIG-ID, timestamp, and digital signature, wherein the digital identifier includes a verifiable security identifier. Method 900 includes identifying a trusted service provider (910) based on the DIG-ID. Method 900 includes sending a verification request (915) to the trusted service provider. Here, the verification request includes the DIG-ID, timestamp, digital signature, minimum dataset request, and security key request. Method 900 includes receiving the verified DIG-ID, verification result, DIG-ID lifetime, MDS information, and access root key (920) from the service provider in response to successful verification of the DIG-ID. Method 900 includes invoking the UE's subscription provisioning (925) based on the MDS information, wherein the access root key is used to protect the subscription provisioning. Method 900 ends.

[0269] This document discloses a first apparatus for subscription access based on a digital ID, according to embodiments of this disclosure. The first apparatus may be implemented by a UE, such as remote unit 105, UE 205, and / or user equipment apparatus 600 described above. The first apparatus includes a processor that acquires a DIG-ID, the DIG-ID including a verifiable security identifier. The processor generates a digital signature and a timestamp for the DIG-ID using a private key. The first apparatus includes a transceiver that sends a first request to a mobile communication network (i.e., to a serving MNO) and receives a first response, wherein the first request includes the DIG-ID, the timestamp, and the generated digital signature, and wherein the first response includes a successful access authentication indication and a verified DIG-ID. The processor establishes a provisioning connection to the mobile communication network and receives subscription credentials and / or user subscription profiles via the provisioning connection.

[0270] In some embodiments, the first request includes a SUOI, which comprises a DIG-ID, a timestamp, and a digital signature. In some embodiments, the SUOI ​​also includes one or more of the following: DIG-ID type, service provider identifier, ID service provider domain information, and trusted service provider domain information. In such embodiments, the digital signature is generated using the entire SUOI.

[0271] In some embodiments, a shared secret encryption key is used to protect the DIG-ID. In such embodiments, the SUOI ​​further includes the SUOI's MAC, the user's public key, and a public key identifier corresponding to the ID service provider identified by the ID service provider information and / or the trust service provider identified by the trust service provider information.

[0272] In some embodiments, the first request includes a registration request to initiate a registration process with the mobile communication network. In such embodiments, following successful user authentication based on a digital ID and / or security setup based on the network access root key, during the registration process via NAS or control plane messages, subscription credentials and / or a user subscription profile are supplied to the UE in the network access container. Here, security setup may be at least via NAS, and optionally may include AS and UP.

[0273] In other embodiments, the first request includes a network access request. In such embodiments, subscription credentials and / or a user subscription profile are supplied to the UE in the network access response and / or in the user plane message following successful DIG-ID-based user authentication and / or security setup based on the network access root key during the network access and provisioning process.

[0274] In some embodiments, receiving subscription credentials and / or user subscription profiles includes receiving a protected access container within a NAS message from the AMF in the mobile communication network, wherein the NAS message includes an OAI, a random number, and a MAC. In such embodiments, the processor may derive an access root key using a shared secret key and a successfully verified DIG-ID, and use the access root key as an AUSF key. The processor may further derive at least one security key using the access root key and at least one of the following: a random number, a PLMN identifier, and a network identifier. The processor may then use a security key as a SEAF key and set security with the network (i.e., NAS security, AS security, and / or user plane security), or use a security key to derive an access confidentiality key for decrypting the protected access container and an access integrity key for verifying the MAC of the NAS message providing the protected access container. Additionally, the processor may verify the MAC of the NAS message based on the OAI, wherein the OAI contains an access result with a "success indication" and one or more security algorithm identifiers. In response to successful MAC verification, the processor may decrypt and store the received subscription credentials and / or user subscription profile.

[0275] In some embodiments, the DIG-ID includes at least one of the following: DID, SSI, and DOID. In some embodiments, obtaining the DIG-ID includes purchasing a subscription associated with the mobile communication network and / or generating the DIG-ID at the UE. In some embodiments, receiving subscription credentials and / or a user subscription profile includes receiving a protected access container within a NAS message or user plane message, the access container being protected using an encryption key and an integrity key derived from the security key based on the access root key.

[0276] In some embodiments, the DIG-ID is a verifiable security identifier linked to a user's verifiable credentials stored on a trusted and decentralized platform or digital identifier infrastructure associated with a trusted service provider and / or an ID service provider. In such embodiments, the DIG-ID is used to perform user authentication during the provision of access and subscription credentials to the UE. In some embodiments, the DIG-ID is included within the username portion of the NAI, which has the form<usemame@realm> In such embodiments, the NAI may include a DIG-ID and at least one of the following: a timestamp, a digital signature, key-related information, trusted service provider information, and / or identification service provider information.

[0277] This document discloses a first method for subscription access based on a digital ID according to embodiments of this disclosure. The first method can be performed by a UE, such as the remote unit 105, UE 205, and / or user equipment device 600 described above. The first method includes obtaining a DIG-ID, the DIG-ID including a verifiable security identifier. The first method includes generating a digital signature and a timestamp for the DIG-ID using a private key. The first method includes sending a first request to a mobile communication network (i.e., to a serving MNO), wherein the first request includes the DIG-ID, the timestamp, and the generated digital signature. The first method includes receiving a first response from the mobile communication network, wherein the first response includes a successful access authentication indication and a verified DIG-ID. The first method includes establishing a provisioning connection to the mobile communication network. The first method includes receiving subscription credentials and / or a user subscription profile via the provisioning connection.

[0278] In some embodiments, the first request includes a SUOI, which comprises a DIG-ID, a timestamp, and a digital signature. In some embodiments, the SUOI ​​also includes one or more of the following: DIG-ID type, service provider identifier, ID service provider domain information, and trusted service provider domain information. In such embodiments, the digital signature is generated using the entire SUOI.

[0279] In some embodiments, a shared secret encryption key is used to protect the DIG-ID. In such embodiments, the SUOI ​​further includes the SUOI's MAC, the user's public key, and a public key identifier corresponding to the ID service provider identified by the ID service provider information and / or the trust service provider identified by the trust service provider information.

[0280] In some embodiments, the first request includes a registration request to initiate a registration process with the mobile communication network. In such embodiments, after successful user authentication based on a digital ID and / or security setup based on the network access root key, subscription credentials and / or a user subscription profile are supplied to the UE in the network access container during the registration process via NAS or control plane messages. Here, security setup may be at least via NAS and may optionally include AS and UP. In other embodiments, the first request includes a network access request. In such embodiments, during the network access and supply process, after successful user authentication based on a DIG-ID and / or security setup based on the network access root key, subscription credentials and / or a user subscription profile are supplied to the UE in the network access response and / or in user plane messages.

[0281] In some embodiments, receiving subscription credentials and / or user subscription profiles includes receiving a protected access container within a NAS message from an AMF in a mobile communication network, wherein the NAS message includes an OAI, a random number, and a MAC. In such an embodiment, the first method may include: deriving an access root key using a shared secret key and a successfully verified DIG-ID; using the access root key as an AUSF key; deriving at least one security key using the access root key and at least one of the following: a random number, a PLMN identifier, and a network identifier; using a security key as a SEAF key and setting security with the network (i.e., NAS security, AS security, and / or user plane security) or using a security key to derive an access confidentiality key for decrypting the protected access container and an access integrity key for verifying the MAC of the NAS message providing the protected access container; verifying the MAC of the NAS message based on an OAI containing an access result with a "success indication" and a security algorithm identifier; and decrypting and storing the received subscription credentials and / or user subscription profile in response to successful MAC verification.

[0282] In some embodiments, the DIG-ID includes at least one of the following: DID, SSI, and DOID. In some embodiments, obtaining the DIG-ID includes purchasing a subscription associated with the mobile communication network and / or generating the DIG-ID at the UE. In some embodiments, receiving subscription credentials and / or a user subscription profile includes receiving a protected access container within a NAS message or user plane message, the access container being protected using an encryption key and an integrity key derived from the security key based on the access root key.

[0283] In some embodiments, the DIG-ID is a verifiable security identifier linked to a user's verifiable credentials stored on a trusted and decentralized platform or digital identifier infrastructure associated with a trusted service provider and / or an ID service provider. In such embodiments, the DIG-ID is used to perform user authentication during the provision of access and subscription credentials to the UE. In some embodiments, the DIG-ID is included within the username portion of the NAI, which has the form<usemame@realm> In such embodiments, the NAI may include a DIG-ID and at least one of the following: a timestamp, a digital signature, key-related information, trusted service provider information, and / or identification service provider information.

[0284] This document discloses a second apparatus for subscription to a network based on a digital ID, according to embodiments of this disclosure. The second apparatus may be implemented by network functions in a mobile communication network (i.e., PLMN, NPN, and / or MNO), such as AUSF135, D-IDASEF 137, BSEF 138, UDM / UDR 139, O-AUSF 209, AUSF 305, UDM / UDR 307, 3GPP NF501, and / or D-IDASEF / BSEF 503 and / or network equipment apparatus 700 described above.

[0285] The second device includes a transceiver that receives a first request containing the UE's DIG-ID, a timestamp, and a digital signature, wherein the digital identifier includes a verifiable security identifier. The second device includes a processor that identifies a trusted service provider based on the DIG-ID and controls the transceiver to send an authentication request to the trusted service provider. Here, the authentication request includes the DIG-ID, timestamp, digital signature, minimum dataset request, and security key request. In response to successful DIG-ID authentication, the transceiver receives the verified DIG-ID, authentication result, DIG-ID lifetime, MDS information, and access root key from the service provider. The processor invokes the UE's subscription provisioning based on the MDS information, wherein the access root key is used to protect the subscription provisioning.

[0286] In various embodiments, the MDS information includes user information. In some embodiments, invoking the UE's subscription provisioning based on the MDS information includes invoking a temporary subscription credential provisioning. In some embodiments, the MDS information includes at least one of the following: user information, subscription purchase information, subscription service related information, subscription validity, and network resources used for subscription provisioning (i.e., MNO subscription provisioning-related URI / URL / address). In such embodiments, invoking the subscription provisioning for the UE based on the MDS information may include invoking the actual user subscription profile provisioning.

[0287] In some embodiments, the processor generates a random number and uses the network access root key and at least one of the following to derive one or more security keys: the random number, the PLMN identifier, and the network identifier. In such embodiments, the processor uses a security key to derive one or more network access security keys (i.e., a confidentiality key and an integrity key for encrypting the network access container and protecting its integrity), and generates a plaintext or protected network access container and an OAI for the UE, wherein at least one of the derived security keys is used to protect the network access container.

[0288] In some embodiments, the processor stores the verified DIG-ID, verification result, DIG-ID lifetime, MDS information, and access root key in the DMF or UDM / UDR of the mobile communication network. Specifically, the data may be stored in the UDR, where the UDM is the front end providing access to the data. Here, the UDM and UDR together form a network function, referred to as "UDM / UDR". In some embodiments, the processor retrieves the default subscription credential of the DIG-ID from the DMF or UDM / UDR and derives one or more access security keys. In such embodiments, the default subscription credential and one or more access security keys are provided as a second network function, the AMF and / or SEAF.

[0289] In some embodiments, the processor uses the received network access root key as the AUSF key and provides a security key as the SEAF key to the AMF / SEAF to establish security (i.e., NAS security, AS security, and / or user plane security) with the UE for provisioning the connection. In some embodiments, in response to receiving default subscription credentials in an unprotected network access container, the second network function (i.e., the AMF / SEAF) applies confidentiality and integrity protection to the network access container using an encryption key and an integrity key derived from the received network access security key. In such embodiments, the UE's subscription provisioning includes the second network function sending a NAS message to the UE, the NAS message being confidential and integrity protected or containing a protected network access container, network access assistance information, a random number, and a MAC address.

[0290] In some embodiments, the network access container includes a subscription credential (i.e., SUPI), a secret long-term key (denoted as 'K'), an authentication and key protocol (“AKA”) credential, and slice information (e.g., one or more S-NSSAIs). In some embodiments, the subscription credential includes a subscription-unique permanent identifier. Furthermore, the network access container may further include network access information and additional subscription information.

[0291] In some embodiments, the first request includes a SUOI, which comprises a DIG-ID, a timestamp, and a digital signature. In some embodiments, the SUOI ​​further includes one or more of the following: DIG-ID type, service provider identifier, ID service provider domain information, and trusted service provider domain information. In such embodiments, the digital signature is generated using the entire SUOI.

[0292] In some embodiments, a shared secret encryption key is used to protect the DIG-ID. In such embodiments, the SUOI ​​further includes the SUOI's MAC, the user's public key, and a public key identifier corresponding to the ID service provider identified by the ID service provider information and / or the trust service provider identified by the trust service provider information.

[0293] In some embodiments, the first request includes an authentication request to initiate an authentication process with the mobile communication network. In such embodiments, during the registration process, after successful DIG-ID-based user authentication and / or security settings based on the network access root key using the network access container via NAS or control plane messages, subscription credentials and / or a user subscription profile are supplied to the UE. Here, security settings may be implemented at least via NAS and may optionally include AS and UP.

[0294] In other embodiments, the first request includes a network access request. In such embodiments, subscription credentials and / or a user subscription profile are supplied to the UE in a network access response and / or user plane message after successful DIG-ID-based user authentication and / or security setup based on the network access root key during the network access and provisioning process.

[0295] In some embodiments, the DIG-ID is a verifiable security identifier linked to a user's verifiable credentials stored on a trusted and decentralized platform or digital identifier infrastructure associated with a trusted service provider and / or an ID service provider. For example, the DIG-ID includes at least one of the following: DID, SSI, verifiable security identifier, and DOID. In such embodiments, the DIG-ID is used to perform user authentication during the provision of network access and subscription credentials to the UE. In some embodiments, the DIG-ID is included within the username portion of the NAI, which has the form<username@realm> In such embodiments, the NAI may include a DIG-ID and at least one of the following: a timestamp, a digital signature, key-related information, trusted service provider information, and / or identification service provider information.

[0296] This document discloses a second method for subscription to a network based on a digital ID, according to embodiments of this disclosure. The second method can be performed by network functions in a mobile communication network (i.e., PLMN, NPN, and / or MNO), such as AUSF135, D-IDASEF 137, BSEF 138, UDM / UDR 139, O-AUSF 209, AUSF 305, UDM / UDR 307, 3GPP NF501, and / or D-IDASEF / BSEF 503 and / or network device 700 described above. The second method includes receiving a first request containing the UE's DIG-ID, a timestamp, and a digital signature, wherein the digital identifier includes a verifiable security identifier. The second method includes identifying a trusted service provider based on the DIG-ID and sending a verification request to the trusted service provider. Here, the verification request includes the DIG-ID, timestamp, digital signature, minimum dataset request, and security key request. The second method includes receiving a verified DIG-ID, verification result, DIG-ID lifetime, MDS information, and access root key from the service provider in response to successful DIG-ID verification. The second method also includes invoking the UE's subscription provisioning based on the MDS information, wherein the access root key is used to secure the subscription provisioning.

[0297] In various embodiments, the MDS information includes user information. In some embodiments, invoking the UE's subscription provisioning based on the MDS information includes invoking a temporary subscription credential provisioning. In some embodiments, the MDS information includes at least one of the following: user information, subscription purchase information, subscription service related information, subscription validity, and network resources used for subscription provisioning (i.e., MNO subscription provisioning-related URI / URL / address). In such embodiments, invoking the subscription provisioning for the UE based on the MDS information may include invoking the actual user subscription profile provisioning.

[0298] In some embodiments, the second method includes generating a random number and deriving one or more security keys using the network access root key and at least one of the following: a random number, a PLMN identifier, and a network identifier. In such embodiments, the second method further includes using a security key to derive one or more network access security keys (i.e., a confidentiality key and an integrity key for encrypting the network access container and protecting its integrity), and generating a plaintext or protected network access container and an OAI for the UE, wherein at least one of the derived security keys is used to protect the network access container.

[0299] In some embodiments, the second method includes storing the verified DIG-ID, verification result, DIG-ID lifetime, MDS information, and access root key in the DMF or UDM / UDR of the mobile communication network. Specifically, the data may be stored in the UDR, where the UDM is the front end providing access to the data. Here, the UDM and UDR together form a network function, referred to as "UDM / UDR". In some embodiments, the second method includes retrieving the default subscription credential of the DIG-ID from the DMF or UDM / UDR and deriving one or more access security keys. In such embodiments, the default subscription credential and one or more access security keys are provided as a second network function as the AMF and / or SEAF.

[0300] In some embodiments, the second method includes using the received network access root key as the AUSF key and providing a security key as the SEAF key to the AMF / SEAF to establish security (i.e., NAS security, AS security, and / or user plane security) with the UE for provisioning the connection. In some embodiments, in response to receiving default subscription credentials in an unprotected network access container, the second network function (i.e., the AMF / SEAF) applies confidentiality and integrity protection to the network access container using an encryption key and an integrity key derived from the received network access security key. In such embodiments, UE subscription provisioning includes the second network function sending a NAS message to the UE, the NAS message being confidential and integrity protected or containing a protected network access container, network access assistance information, a random number, and a MAC address.

[0301] In some embodiments, the network access container includes a subscription credential (i.e., SUPI), a secret long-term key (denoted as 'K'), an authentication and key protocol (“AKA”) credential, and slice information (e.g., one or more S-NSSAIs). In some embodiments, the subscription credential includes a subscription-unique permanent identifier. Furthermore, the network access container may further include network access information and additional subscription information.

[0302] In some embodiments, the first request includes a SUOI, which comprises a DIG-ID, a timestamp, and a digital signature. In some embodiments, the SUOI ​​further includes one or more of the following: DIG-ID type, service provider identifier, ID service provider domain information, and trusted service provider domain information. In such embodiments, the digital signature is generated using the entire SUOI.

[0303] In some embodiments, a shared secret encryption key is used to protect the DIG-ID. In such embodiments, the SUOI ​​further includes the SUOI's MAC, the user's public key, and a public key identifier corresponding to the ID service provider identified by the ID service provider information and / or the trust service provider identified by the trust service provider information.

[0304] In some embodiments, the first request includes an authentication request to initiate an authentication process with the mobile communication network. In such embodiments, during the registration process, after successful DIG-ID-based user authentication and / or security settings based on the network access root key using the network access container via NAS or control plane messages, subscription credentials and / or a user subscription profile are supplied to the UE. Here, security settings may be implemented at least via NAS and may optionally include AS and UP.

[0305] In other embodiments, the first request includes a network access request. In such embodiments, subscription credentials and / or a user subscription profile are supplied to the UE in a network access response and / or user plane message after successful DIG-ID-based user authentication and / or security setup based on the network access root key during the network access and provisioning process.

[0306] In some embodiments, the DIG-ID is a verifiable security identifier linked to a user's verifiable credentials stored on a trusted and decentralized platform or digital identifier infrastructure associated with a trusted service provider and / or an ID service provider. For example, the DIG-ID includes at least one of the following: DID, SSI, verifiable security identifier, and DOID. In such embodiments, the DIG-ID is used to perform user authentication during the provision of network access and subscription credentials to the UE. In some embodiments, the DIG-ID is included within the username portion of the NAI, which has the form<username@realm> In such embodiments, the NAI may include a DIG-ID and at least one of the following: a timestamp, a digital signature, key-related information, trusted service provider information, and / or identification service provider information.

[0307] The embodiments may be practiced in other specific forms. The described embodiments are to be considered in all respects as illustrative rather than restrictive. Therefore, the scope of the invention is indicated by the appended claims rather than by the foregoing description. All variations within the equivalent meaning and scope of the claims should be included within their scope.

Claims

1. A method for a user interface (UE), comprising: Obtain a digital identifier ("DIG-ID"), which includes a verifiable security identifier; Use the private key to generate a digital signature and timestamp for the DIG-ID; Send a first request to the mobile communication network, the first request including the DIG-ID, the timestamp and the generated digital signature, wherein the DIG-ID can be used to identify a trusted service provider for verifying the DIG-ID; Receive the network access authentication success indication and the verified DIG-ID; Establish a supply connection to the mobile communication network; as well as Receive at least one of a subscription certificate and a user subscription profile via the supply connection.

2. The method according to claim 1, in, The first request includes a Subscription Unique Access ID ("SUOI"), which includes the DIG-ID, the timestamp, and the digital signature. The SUOI ​​further includes one or more of the following: DIG-ID type, service provider identifier, identification ("ID") service provider domain information, and trusted service provider domain information. The digital signature is generated using the SUOI. If a shared secret encryption key is used to protect the DIG-ID, the SUOI ​​further includes the SUOI's message authentication code ("MAC"), the UE's public key, and a public key identifier corresponding to the ID service provider identified by the ID service provider information and / or the trust service provider identified by the trust service provider information.

3. The method according to claim 1, wherein, The first request includes initiating a registration request with the mobile communication network, wherein the UE receives the subscription credentials and / or user subscription profile in the network access container via a non-access stratum ("NAS") or control plane message after successful DIG-ID-based user authentication and / or security settings based on the network access root key during the registration process.

4. The method according to claim 1, wherein, The first request includes a network access request, wherein the UE receives the subscription credential and / or user subscription profile in a network access response and / or user plane message after successful DIG-ID-based user authentication and / or security setup based on the network access root key during the network access and provisioning process.

5. The method according to claim 1, wherein, The digital identifier includes at least one of the following: decentralized identifier ("DID"), autonomous identifier ("SSI"), and digital access identifier ("DOID"), wherein obtaining the DIG-ID includes purchasing a subscription associated with the mobile communication network and / or generating the DIG-ID at the UE.

6. The method according to claim 1, in, Receiving subscription credentials and / or user subscription profiles includes receiving a protected access container from the Access and Mobility Management Function ("AMF") in the mobile communication network. The protected network access container is received within a Non-Access Stratum ("NAS") message or a user plane message, and is protected using an encryption key and an integrity key derived from the security key based on the network access root key. The NAS message includes Network Access Assistance Information ("OAI"), a random number, and a Message Authentication Code ("MAC").

7. The method of claim 6, further comprising: Export the inbound root key using the shared secret key and the successfully verified DIG-ID; Use the aforementioned root key as the Authentication Server Function ("AUSF") key; At least one security key is derived using the network access root key and at least one of the following: the random number, the PLMN identifier, and the network identifier; Use the security key as a security anchor key and set security about the network, or use the security key to derive an inbound confidentiality key for decrypting a protected inbound container and an inbound integrity key for verifying the MAC that provides the NAS message of the protected inbound container; The MAC is used to verify the NAS message based on the OAI, which includes the network access result with a "success indication" and a security algorithm identifier; as well as In response to successful MAC verification, the received subscription credentials and / or user subscription profile are decrypted and stored.

8. A method for network functions in a mobile communication network, the method comprising: Receive a first request message, the first request message containing the UE’s digital identifier ("DIG-ID"), timestamp and digital signature, the digital identifier including a verifiable security identifier; Trust service providers are identified based on the DIG-ID identifier; Send a verification request to the trusted service provider, the verification request including the DIG-ID, the timestamp, the digital signature, a minimum dataset request, and a security key request; In response to successful verification of the DIG-ID, the verified DIG-ID, verification result, DIG-ID lifetime, minimum dataset ("MDS") information, and network access root key are received from the service provider. as well as The subscription provisioning of the UE is invoked based on the MDS information, wherein the subscription provisioning is protected using the network access root key.

9. The method according to claim 8, in, The MDS information includes at least user information. Specifically, invoking the UE's subscription provisioning based on the MDS information includes invoking temporary subscription credential provisioning in response to the MDS information containing only user information. Specifically, invoking the UE's subscription provisioning based on the MDS information includes invoking the actual user subscription profile provisioning in response to the MDS information containing user information, subscription purchase information, subscription service related information, subscription validity, and network resources for subscription provisioning.

10. The method of claim 8, further comprising: Generate random numbers; Derive one or more security keys using the network access root key and at least one of the following: the random number, the PLMN identifier, and the network identifier; Use the aforementioned security key to export the network access security key; Generate a plaintext or protected access container, and an OAI for the UE, wherein the access container is protected using at least one of the derived security keys; as well as The verified DIG-ID, verification result, DIG-ID lifetime, MDS information, and network access root key are stored in the data management function ("DMF") or unified data management and unified data repository ("UDM / UDR") of the mobile communication network.

11. The method of claim 10, further comprising: Retrieve the default subscription credential for the DIG-ID from the DMF or UDM / UDR, and export one or more access security keys, wherein the default subscription credential and the one or more access security keys are provided to a second network function, which is one of the following: Access and Mobility Management Function ("AMF") and Security Anchor Function ("SEAF").

12. The method of claim 11, further comprising using the received network access root key as an authentication server function ("AUSF") key, and providing the security key as a security anchor key to the AMF and / or SEAF to set up security for providing the connection with the UE.

13. The method according to claim 11, in, In response to receiving the default subscription credential in an unprotected inbound container, the second network function applies confidentiality and integrity protection to the inbound container using an encryption key and an integrity key derived from the received inbound security key. The subscription provisioning of the UE includes the second network function sending a non-access stratum ("NAS") message to the UE, wherein the NAS message is protected by confidentiality and integrity or contains the protected access container, access assistance information, random number and message authentication code ("MAC").

14. The method according to claim 13, in, The network access container includes subscription credentials, a secret long-term key (K), authentication and key protocol ("AKA") credentials, and slice information. The subscription credential includes a unique permanent identifier for the subscription, and the network access container further includes network access information and additional subscription information.

15. The method according to claim 8, wherein, The first request includes a Subscription Unique Access ID ("SUOI"), which includes the DIG-ID, the timestamp, and the digital signature. The SUOI ​​further includes one or more of the following: DIG-ID type, service provider identifier, identification ("ID") service provider domain information, and trusted service provider domain information. The digital signature is generated using the SUOI.

16. The method according to claim 15, wherein, If the DIG-ID is protected using a shared confidential encryption key, the SUOI ​​further includes the SUOI's Message Authentication Code ("MAC"), the UE's public key, and a public key identifier corresponding to the ID service provider identified by the ID service provider information and / or the trust service provider identified by the trust service provider information.

17. The method according to claim 8, wherein, The first request includes initiating an authentication request with the mobile communication network, wherein during the registration process, after successful DIG-ID-based user authentication and / or security setup based on the network access root key in the network access container via a non-access stratum ("NAS") or control plane message, the subscription credentials and / or user subscription profile are supplied to the UE.

18. The method according to claim 8, wherein, The first request includes a network access request, wherein, during the network access and provisioning process, in the network access response and / or in the user plane message, the UE is provided with subscription credentials and / or a user subscription profile.

19. The method according to claim 8, in, The DIG-ID is a verifiable security identifier linked to the verifiable credentials of the UE, which are stored on a trusted and decentralized platform or digital identifier infrastructure associated with the trusted service provider and / or ID service provider. The DIG-ID includes at least one of the following: Decentralized Identifier ("DID"), Self-Signing Identifier ("SSI"), Verifiable Security Identifier, and Digital Access Identifier ("DOID"). The DIG-ID is used to perform user authentication during the provision of network access and subscription credentials to the UE.

20. The method according to claim 19, wherein, The DIG-ID is included in the username portion of the Network Access Identifier ("NAI"), which includes the DIG-ID and at least one of the following: timestamp, digital signature, key-related information, trusted service provider information, and / or identification service provider information, wherein the NAI has a form<usemame@realm> .

Images