User authentication in a network environment

Abstract

A method and system for authenticating and / or authorizing a user in a network environment, wherein the method comprises the following steps: a trusted issuer issues a user identifier (ID) as a decentralized identifier (DID 44) and a DID-bound verifiable credential (VC, 45) to a user equipment (UE 100); a SIM or eSIM issues network registration data of a 3GPP network provider to a 3GPP network access module (110); the network access module (110) sends a network access registration message (62, 31b) to a core network (CN), wherein the network access registration message comprises the network registration data of the 3GPP network provider; the core network (CN) registers the network access module (110) in the network of the network operator; the DID (44) and the DID-bound VC (45) are transmitted from the UE (100) to the network access module (110); the network access module (110) sends a user authentication message comprising the DID (44) and the DID-bound VC (45) to the 3GPP core network; the core network issues the DID (44) and the DID-bound VC (45) to a verification unit (120, 120a) performing an authentication and / or authorization process; after successful authentication, the verification unit transmits the result to the UE (100), thereby granting the user access to the requested service.

Description

[0001] This invention relates to a method, communication system, user equipment, and / or network access module for authenticating and / or authorizing users in a network environment.

[0002] Currently, 3GPP-based networks use credentials stored on the SIM card to authenticate the SIM card to the network. The problem with this method is that it actually authenticates the SIM card (IMSI), and therefore authenticates the subscribed user, not the actual user behind the SIM card who actually uses the user equipment to access the service.

[0003] For example, if a SIM card is used in a mobile WLAN router, the SIM card is used to access the mobile network, and the contract associated with the SIM card identifies the contract holder. However, it is not possible to identify, for example, the actual user browsing the internet through that specific WLAN router.

[0004] Therefore, since the user cannot be identified and authorization cannot be verified, it is impossible to determine whether the user is authorized to use the specific service.

[0005] WO 2022 / 96125 A1 defines a mechanism for replacing the user-hidden identifier SUCI with another identifier DIG-ID (digital identifier), wherein a component of DIG-ID is a DID.

[0006] However, this concept is only intended to enable UE access using DIG-ID, not to identify the actual end user. Therefore, this method simply replaces one parameter with another in a different format, without directly identifying the user. Replacing the User Hidden Identifier (SUCI) with a DID does not change the fact that the parameter on the SIM card only identifies a specific contract and the contract holder, and it does not help identify the actual user using the connection established through that SIM card.

[0007] WO 2021 / 173265 A1 is titled "Decentralized Authentication Anchored by a Decentralized Identifier". This document describes a general method for providing both a DID (Decentralized Identifier) ​​and a VC (Verifiable Credential) to the end user using a mobile phone, but does not describe how the transmission of the VC is implemented in a 3GPP system.

[0008] WO 2022 / 258180 A1 discloses various aspects of authentication using DID and VC and their transmission to the network, but does not disclose them in conjunction with the 3GPP registration and authentication process.

[0009] In view of the above, the object of the present invention is to provide a technology that can verify and / or authenticate users in a network environment.

[0010] This objective is achieved through the features of the independent claims.

[0011] Features or various embodiments of the invention described below can be combined with each other unless this is explicitly excluded or technically impossible.

[0012] Furthermore, the terms first, second, third, etc., used in the specification and claims are used to distinguish between similar elements and are not necessarily used to describe order or chronological sequence. It should be understood that such terms are interchangeable where appropriate, and the embodiments of the invention described herein can operate in orders other than those described or illustrated herein.

[0013] The entire disclosure of European patent application No. 23205428.8 is incorporated herein by reference.

[0014] For example, technically, the present invention may be based on 3GPP version 18 (e.g., the November 2023 version) or version 19, which is effective as of the filing date.

[0015] According to a first aspect of the present invention, a method for authenticating and / or authorizing a user in a network environment is disclosed, particularly for authenticating and / or authorizing after a service request, which may be forcibly initiated by the user or automatically initiated by the UE upon power-on, wherein the method includes the following steps:

[0016] The trusted issuer provides the user equipment (UE) with a user identifier (ID) as a decentralized identifier (DID) and a verifiable credential (VC) bound to the DID;

[0017] o DID and the VC bound to DID are data types that can be clearly associated with a specific user, rather than a specific device or a specific contractual relationship; UE can be a tablet, smartphone, general computing device or IoT device, and may or may not have an (e)SIM card;

[0018] o DID and VC bound to DID can be stored on UE;

[0019] The SIM (Subscriber Identification Module) or eSIM (Embedded SIM) provides the 3GPP network access module with network registration data from the 3GPP network provider, which is in particular a part of the UE;

[0020] Network registration data can be data contained in the (e)SIM and typically includes IMSI, SUCI, and / or SUPI. This network registration data is associated with the subscriber under the network access contract. However, this subscriber is not necessarily the actual user of the UE. By providing this data to the network access module, it can be sent to the network operator.

[0021] The network access module sends a network access registration message to the network provider's core network (CN), wherein the network access registration message includes network registration data from the 3GPP network provider. The network access module registers within the network operator's network.

[0022] This step is used to establish actual communication between the network access module and / or the UE and the 3GPP network operator;

[0023] The DID and the VC bound to the DID are transmitted from the UE to the network access module;

[0024] This step enables the network access module to transmit the DID and the VC associated with the DID to the network operator.

[0025] The network access module (110) sends a user authentication message, including the DID and the VC bound to the DID, to the 3GPP core network of the network operator;

[0026] o User authentication messages can be used to perform user authentication and / or authorization;

[0027] o User authentication messages may also include service requests. User authentication messages provide information identifying the actual user of the UE, who may be different from the subscribed user of (e)SIM;

[0028] Specifically, the 3GPP core network or network operator provides the DID and the VC bound to the DID to the authentication unit, which performs the authentication and / or authorization process. Upon successful authentication, the authentication unit transmits the result to the UE (100), thereby granting the user access to the requested service.

[0029] The authentication unit may be located in or associated with the network operator's core network; the authentication unit may also provide the requested service and the UE with the results of the authentication and / or authorization process, wherein the service may be initiated after successful authentication and / or authorization.

[0030] Therefore, this invention, for the first time, enables the verification and / or authentication of the actual user of the UE, who may be different from the (e)SIM's subscribed user. This significantly improves security when operating services in a network environment.

[0031] Compared to the "Contract Owner" ID (IMSI; SUCI; SUPI) stored on the SIM / eSIM and identifying only a specific contract, this invention introduces new possibilities implemented by DID and / or VC. Therefore, DID and / or VC can be described as genuine user ID credentials. Contract Owner IDs are primarily designed for 3GPP-based processes and scenarios and are not intended for use outside the telecommunications domain; in particular, IMSI / SUPI are intentionally highly protected and not intended to be shared with anyone. However, user ID credentials can be shared with other network operators and / or service providers, thus providing greater flexibility in authentication and / or authorization processes. Therefore, access to services can be based on the actual user.

[0032] In this embodiment, the verification unit is assigned to a 3GPP network operator, or the 3GPP network operator may assign it to a 3GPP network operator. The DID and the VC bound to the DID are transmitted to the external verification unit.

[0033] If the authentication unit is assigned to a 3GPP network operator, the authentication process can be performed efficiently, and the network operator can generally be trusted. Using an external authentication unit can provide greater flexibility in the authentication and / or authorization process, but it is less efficient because the network operator needs to transmit the user ID credentials to the external authentication unit.

[0034] In this embodiment, the DID and the VC bound to the DID are stored in the UE's secure memory, and authentication must be performed before the DID and the VC bound to the DID can be transmitted from the UE to the network access module. In this case, the UE can be a computing device that establishes a data connection with the network access module.

[0035] This offers the following advantages: only users with user ID credentials can open the secure storage and trigger the transmission of the user ID credentials to the network access module, and then from the network access module to the network operator. User ID credentials can be protected using the following technologies: code protection; fingerprint protection, audio protection, and / or facial ID protection, or any other protection mechanism that can be used to protect the contents of the digital secure storage.

[0036] In this embodiment, at least the DID and the associated VC bound to the DID are transmitted to the verification unit.

[0037] In this embodiment, the user authentication message is associated with the network access registration message.

[0038] This offers the following advantages: the subscription relationship used by the UE to obtain network access can also be related to user data. For example, it can be stipulated that only specific users are allowed to use this subscription relationship.

[0039] Linking these messages also provides the following advantages: i) Synchronization: Linking these two messages synchronizes the processing of user authentication details and their network access credentials. This reduces the risk of inconsistencies between user profiles and their access permissions. ii) Efficiency: Combining these messages simplifies the user registration process. Users do not need to register for network access separately after completing user registration, saving time and effort. iii) Security: Linking user registration with network access registration enhances security by ensuring that only authorized users can access the network. This helps prevent unauthorized access attempts or fraudulent registrations. iv) User Experience: A seamless registration process improves the overall user experience. Users are less likely to experience confusion or frustration when registering for user accounts and network access simultaneously or separately.

[0040] In this embodiment, the network access registration message includes a user authentication message.

[0041] This offers the following advantages: user authentication and / or authorization can be performed more efficiently without further signaling, especially at a very early stage of the communication process. This is particularly advantageous if only specific users are allowed to use the service under a contract with the network operator.

[0042] In this embodiment, the 3GPP network access module and the user equipment are two different devices connected to each other via a communication channel.

[0043] This offers the following advantages: it allows for highly flexible authorization and / or authentication. This authentication and / or authorization can be performed even if the UE is a non-3GPP device.

[0044] In this embodiment, the UE's user authentication message is converted into a 3GPP-compatible data type. Specifically, the 3GPP network access module performs this conversion.

[0045] The advantage provided by this is that even non-3GPP devices can be used within the scope of this invention. Performing this conversion at the 3GPP network access module is particularly advantageous because user authentication and / or authorization can be provided from non-3GPP devices connected to the network access module.

[0046] In this embodiment, the user equipment (UE) includes a 3GPP network access module.

[0047] The advantage of this is that if a user wishes to accept user authentication and / or authorization to use the UE to gain access to services, an external network access module is not required.

[0048] According to a second aspect of the present invention, the above method is disclosed to be used in the following use cases:

[0049] Operators and / or third parties may perform the user verification process;

[0050] For end users: enhanced security protocols and / or direct payment options; and / or

[0051] Protection issues when accessing services;

[0052] For enterprise customers, network operators can provide access management for enterprise infrastructure or networks. Operators can authenticate VCs on behalf of enterprise customers, thereby granting access to customer services or customer networks.

[0053] For (end) users, there are several possible scenarios, such as enhancing the security of different service access scenarios; roaming customers can use their payment credentials to directly pay for a certain number of minutes or bits, just like in a voucher system; customers accessing visitor-facing WLAN hotspots can use credentials for access management; or, access to the service ecosystem can be achieved by verifying credentials.

[0054] For operators, this fosters the development of new business opportunities. It strengthens the relationship between customers and the network, and operators gain more transparent information across mobile / fixed networks, as well as private and public WLANs, about who actually uses their networks and the applications they employ. Furthermore, operators only need to implement this highly flexible mechanism to support a large number of diverse use cases catering to different customer needs.

[0055] Once credentials are available online, multiple use cases can be supported by using the same technical mechanisms for multiple use cases. Currently, a wide range of government agencies are adopting the approach and features of Personal DID / VC to drive the digitalization of relationship management.

[0056] According to a third embodiment of the present invention, a network access module is disclosed, which is adapted to transmit user authentication messages including VCs bound to a user's DID, wherein the network access module is adapted to convert user authentication messages of user terminals into 3GPP-compatible data types.

[0057] The network access module of the present invention provides the advantages described above within the scope of the method.

[0058] According to a fourth aspect of the present invention, a UE designed for authenticating and / or authorizing users in a network environment is disclosed, wherein the UE is configured to

[0059] Store the user ID as the DID and the VC bound to the DID;

[0060] The network access module sends user authentication messages, including the DID and the VC bound to the DID, to the 3GPP network operator.

[0061] In a preferred embodiment, the UE can be configured to perform the above-described UE-related method steps.

[0062] This UE provides the advantages described above in the context of this method.

[0063] In this embodiment, the UE includes a network access module. For example, the UE may be a smartphone, smartwatch, tablet, etc. The UE may also be configured to retrieve and process a response from an authentication unit, indicating whether the authentication of the user was successful.

[0064] According to a fifth aspect of the present invention, a communication system is disclosed, wherein the communication system is configured to perform the above-described method.

[0065] This communication system provides the advantages described above in the context of this method.

[0066] In this embodiment, the network layer of the 3GPP network provider that supports the transmission of DID and DID-bound VC is configured to act as an authentication and / or authorization proxy.

[0067] This provides the advantage of achieving a clear distinction between the application / service layer and / or the network layer.

[0068] In the following explanation, preferred embodiments of the invention are described with reference to the accompanying drawings:

[0069] Figure 1 This illustrates the trust triangle used by the VC to verify DID bindings.

[0070] Figure 2 This illustration shows an architecture overview according to a first embodiment of the present invention;

[0071] Figure 3 : Shows according to Figure 2 A flowchart of the combined registration process for UE registration and user authentication / authorization, wherein the registration is based on IMSI / SUPI for devices and on DID-bound VC for human users;

[0072] Figure 4Registration request message as explained in the embodiments of the present invention;

[0073] Figure 5 This illustration shows an architecture overview according to a second embodiment of the present invention;

[0074] Figure 6 : Shows according to Figure 5 A flowchart of the separate registration process for UE registration and user authentication / authorization, wherein the registration is based on IMSI / SUPI for devices and on DID-bound VC for human users;

[0075] The numerous features of the invention are explained in detail below with reference to preferred embodiments. This disclosure is not limited to specifically named combinations of features. Rather, the features mentioned herein can be combined arbitrarily in embodiments of the invention unless explicitly excluded below. In particular, the invention covers a variety of use cases employing the same mechanism.

[0076] Decentralized Identifiers (DIDs) can be used to manage identities in a decentralized manner without the need for centralized identity databases and Certificate Authorities (CAs). The decentralized aspect of DIDs has the inherent potential to unify cross-domain access management processes, for example, in 6G by using a distributed ledger (DL) among all relevant participants in the PLMN ecosystem as a single source of truth for non-privacy-sensitive access management data. DID infrastructure also enables the storage of DIDs in a privacy-preserving manner in a VDR (Verifiable Data Registry), such as a database, distributed ledger, or any other storage solution, based on the principle of Sovereign Identity (SSI). Applying DIDs to achieve IDM decentralization in communication systems not only reduces the risk of single points of failure or single point of attack by removing CAs, but also allows MNOs (Mobile Network Operators) to leverage SSIs and adhere to privacy-preserving design principles.

[0077] A DID is a unique identifier that may include an alphanumeric string pointing to an IS (Identity Subject) (referred to herein as a DID Subject) and resolves to a DID document. A DID Subject can be a person or any type of network element, such as a signed user, MNO, or NF. Among other information, a DID document may also include verification material, such as the DID Subject's public key used for authentication, authorization, and other purposes. Therefore, a DID binds a DID Subject to its DID document, just as an X.509 certificate binds an identity to a public key. Neither the DID nor the DID document discloses or contains any personal data. The basic idea of ​​the DID concept is to manage and share non-privacy-sensitive verification material in the form of DID documents among interacting stakeholders, such as via a DL (Data Provider), while keeping the DID Subject's privacy-sensitive personal data local rather than stored on the DL, ideally at the location of the respective DID Subject or stakeholder. Therefore, a DL can be used to persistently store and share identity-related data in a fully synchronized and tamper-proof manner among all participants in a multi-stakeholder network.

[0078] The primary goal behind the latest SSI paradigm is to maintain autonomy over any information describing an entity. Ideally, all digital information associated with an identified or identifiable subject, such as a Social Security number, should be held and managed solely by the IS (Independent Token). In SSI, whether to disclose personal data (credentials), to whom to disclose it, and to what extent is entirely determined by the credential holder. To establish trust between two ISs that have not yet interacted, it is advantageous for the ISs to exchange credentials approved by a third party trusted equally by both ISs. Therefore, to establish trust using SSI, one IS (role: holder) can disclose its own credentials to another IS (role: verifier), in the form of a verifiable credential (VC), which has previously been approved, digitally signed, and delivered to the holder by a third IS (role: issuer). For example, to enter into a mobile phone contract, a potential customer (holder) discloses a Social Security number issued by a government agency (issuer) as a VC to the MNO (verifier). Only when the party using the credential (verifier) ​​can cryptographically verify the issuer's approval of the disclosed statement can trust be established. Figure 1 The trust triangle shown in SSI is necessary for its feasibility. Therefore, SSI not only advocates that privacy-sensitive credentials should be held and managed solely by the IS, but also that credentials can be approved by a trusted third party and verified by other parties. This makes SSI a new foundational concept for implementing privacy protections and enabling trust to be established between participants in different trust domains.

[0079] Network elements can be provided with a DID and a DID-bound VC. These DIDs and VCs can be used by the network elements to authenticate themselves and / or authorize themselves in a decentralized manner. The communication system can be an intranet, a 4G communication system, a 5G communication system, a 6G communication system, and / or a combination of these different communication systems, or any other type of communication network, such as a fixed network or a WLAN network. Decentralized identity management of network elements is preferred to reduce the risk of a "single point of failure." The digital identity of a network element includes the identity attributes (AuthN VC) and authorization (AuthZ VC) required for authentication and authorization. Decentralized key management via VDR is preferably disclosed to simplify cross-network key exchange required for decentralized identity, or to make such cross-network key exchange easier or more efficient to manage, and is typically also used independently for cross-network authentication and authorization.

[0080] The issuer can be a trusted institution that all participants in the communication system rely on, such as a government agency.

[0081] A DID-bound VC includes attributes of network elements and / or network functions that can be used to prove its identity. A DID-bound VC can be used to prove identity attributes such as name (for authentication) or permissions (for authorization), and also to prove ownership of the DID bound to that VC. Therefore, the holder uses the DID-bound VC to simultaneously provide two proofs to the verifier: DID ownership and a claim of ownership. The VC according to the invention can be configured to provide authentication and / or authorization information, may contain digitally signed credentials, and may also contain other information about the issuer. The VC can be stored in the holder's secure wallet.

[0082] In short, this innovation describes how to transmit a user's DID and attached verifiable credentials (VC), particularly the VC bound to the DID, from the user's device to the 3GPP-based core network to authenticate and authorize the end user in response to subsequent service requests to another network and / or service.

[0083] In this embodiment, the VC bound to a user's DID is not intended to replace pre-existing network registration data or IDs, such as IMSI, SUCI, and / or TMSI, or any other pre-existing and transmitted identifiers. The VC bound to the DID may also be transmitted as additional content in the same process.

[0084] To realize this concept, the 3GPP specifications need to be modified so that they can transmit not only the SUCI, IMSI, and / or TMSI used for SIM identification, but also the VC bound to the current user's DID associated with the established call.

[0085] In one embodiment, the VC bound to the end user's DID may already be part of the UE registration message. In other cases, the VC bound to the DID will be transmitted from the SIM sub-subscriber (the device holding the SIM) to the 3GPP core network in a new 3GPP-based message. Such a device can be a router, particularly a WLAN router, or any other networking device.

[0086] DID or VC can be stored in a database within the network or in another external database.

[0087] Figure 2 An architecture overview of a communication system 50 according to a first embodiment of the present invention is shown, the communication system 50 being configured to transmit the VC of a user’s DID binding according to the present invention.

[0088] Communication system 50 includes:

[0089] User Equipment (UE) 100. Figure 2 UE 100 is an entity that includes the 3GPP network access module 110. Therefore, UE 100 can be a smartphone or tablet. Furthermore, the UE has a secure storage 105, such as a digital wallet 105, where the DID and VC, particularly the VC bound to the DID, are securely stored. UE 100 may have a new feature that allows the user to decide whether to use the terminal as usual (simply using it as a network connection device), or to register using their personal credentials (DID / VC) to begin using a specific service, or to gain access to a service platform or service controller that requires user authorization and / or authentication. UE 100 supports the "new parameters" for UE registration messages as shown below.

[0090] Radio access network 115 (RAN) is configured to provide a communication link from UE 100 to 3GPP core network 120 (CN).

[0091] In this scenario, CN 120 can act as the authenticator. In addition to performing known IMSI / SUPI authentication according to the standard procedures using Unified Data Management Node (UDM / UDR) 125, CN 120 (i.e., AMF 120a) also authenticates the VC bound to the DID to allow or deny access to the service network 140, service platform 140, or service controller 140.

[0092] Verifiable Data Registry (VDR): VDR 130 is a trusted entity that stores DID documents (containing DIDs and public keys) and is used to retrieve these DID documents to allow pseudonymous authentication of DID owners. Depending on the specific use case, VDR 130 can be part of the operator's own network infrastructure or an external network entity.

[0093] One reason for providing the end user's DID and / or the VC bound to the DID in the registration message is to enable combined registration and authorization processes for mobile networks and access to service networks, service ecosystems, or service controllers (SCs), or to provide any type of payment information to the AMF so that charges can be applied to certain access / services. This avoids the additional signaling and reduces latency.

[0094] Service Ecosystem 140 or Service Controller 140 (SC) is the platform the user wishes to access. The VC bound to the DID is verified to authenticate the end customer and confirm authorization to access the specific (service) endpoint. Upon successful verification, the successful registration result is forwarded to the user's UE and Service Ecosystem / SSC.

[0095] Figure 3 A flowchart is shown for the combined registration process for UE registration and user authentication / authorization, where the registration is based on IMSI / SUPI for devices and on VC based on DID binding for human users.

[0096] Step 30: The user has a contract with a network operator who provides the user with an (e)SIM card. The (e)SIM provides network registration information such as IMSI, SUCI, or SUPI. The SIM card identifies the contract and the connectivity features purchased by the contract holder. The SIM card is associated with UE 100, wherein, in this embodiment, UE 100 also includes a secure memory 105 that stores the end user's ID, specifically the VC bound to the DID. The DID and / or VC may be based on W3C definitions to allow interoperability with other network operators. The contracted user associated with the (e)SIM card may be the same as or different from the user using UE 100 who wishes to access services.

[0097] Step 31: Registration trigger conditions: The registration trigger conditions for registering with the operator's network can be UE 100 powering on, manual triggering, current network loss, or any other method specified in the standard.

[0098] Step 31a: Registration with or without user authentication:

[0099] Once the network registration procedure is triggered, UE 100 should initiate the decision-making process by asking the user whether they should still use the DID and / or the VC bound to the DID to perform "user authentication and authorization".

[0100] If not, then the 3GPP-based "normal" registration procedure should be performed according to step 31b. If yes, the procedure continues to step 32.

[0101] Step 32, Obtain DID and DID-bound VC: The network access module 110 of UE 100 requests credentials such as DID and DID-bound VC from the digital wallet 105 stored on UE 100. The digital wallet 105 provides these credentials as requested based on the prior authorization of the corresponding user, such as based on the use of Face ID, fingerprint, password, etc.

[0102] Step 33, by sending a user authorization message, or by sending such as Figure 4 The network access registration message 40 shown, which includes user authorization information, is used to send a user verification request.

[0103] In addition to the parameters standardized in the 3GPP specifications, such as message type 41 and IMSI / SUPI 42, this new type of network access registration message 40 should also include the following additional parameters:

[0104] - The user authentication data field 43 in this registration message, based on DID / VC, particularly DID 44 and DID-bound VC 45, indicates: Yes / No. If Yes: The message displays additional user identification information elements. If No: Standard UE registration message. The registration request message may also include identification information for the requested service.

[0105] - DID: At least a decentralized identifier for the user must be provided, and a DID method must be provided;

[0106] - VC, especially DID-bound VC: shows the corresponding presentation content of the verifiable credentials associated with the DID.

[0107] Step 34: Interact with UDM / UDR 125 to perform IMSI / SUPI verification and contractual relationship check:

[0108] CN 120 first verifies IMSI / TMSI / SUPI / SUCI based on the content provided by UE 100 and according to standard 3GPP procedures. This message exchange takes place between AMF 120a and UDM / UDR 125.

[0109] Step 35: CN 120, especially AMF 120a, makes a determination regarding IMSI / SUPI verification:

[0110] If the IMSI / SUPI verification fails (for example, possibly due to the revocation of the contractual relationship), the result is transmitted to the UE (step 35a), and the procedure is terminated.

[0111] If the verification is successful, the positive result is transmitted to UE 100 (step 35), and the verification of DID and the VC bound to DID continues in step 36.

[0112] Step 36: Verify the DID and the VC bound to the DID:

[0113] CN 120, and especially AMF 120a, begins verifying the "personal" credentials received from the user. First, in step 36a, it requests a DID document from VDR 130. If the user does indeed possess the key belonging to DID 44, this allows pseudonymous authentication. If the public key contained in the retrieved document does not match the private key used to encrypt the VC, the entity is immediately aware of the problem and can reject the request.

[0114] Step 36a: Retrieve DID document message:

[0115] A request is sent from AMF 120a to VDR to retrieve the user's DID document. The corresponding response shows the user's DID. This response is sent from VDR to AMF and includes: i) a DID document showing the user's DID and public key, where the DID is a decentralized identifier, and the public key contains the user's public key if decryption or encryption of messages from the client is required. Depending on the use case, the DID document may contain additional non-personal data.

[0116] Step 36b: AMF 120a verifies the received DID-bound VC by checking the VC signature (issuer verification). Verifiable credentials (VCs) may include: i) the user's DID, ii) information about the issuer, iii) information about the service to which the user verification is targeted, and / or iv) any limiting characteristics (e.g., time, location, etc.).

[0117] If user authentication fails, a "Authentication Rejected" message is sent from CN 120 to UE 100 in step 36c.

[0118] If the DID and the VC bound to the DID have been successfully verified, the result is transmitted to the UE in step 36d. This message may include i) a verification success message, ii) the DID and DID document of service 140, and / or the service endpoint address (URI; IP address; ...) for using and accessing the requested service.

[0119] Optionally, the positive verification result can also be transmitted to the requested service ecosystem 140 according to step 36e, which can also be listed in VC. Optionally, the positive verification result for a specific service or fund flow can be transmitted to and stored in any relevant backend system (UDM / UDR, billing system, service, etc.).

[0120] Optional step 37: After successfully verifying the user's credentials, allow the user to access the service ecosystem or service 140; if necessary, an encrypted connection can be established between UE 100 and service ecosystem 140 or SC 140 based on DID / VC.

[0121] Optional step 38: After successfully establishing an encrypted connection, UE 100 can send a service request for a specific service to Service Ecosystem 140 or SC 140.

[0122] Figure 3 The order of the steps shown can be varied according to the actual implementation needs. In particular, the messages based on steps 35a and 36c and the messages based on steps 35b and 36d can be merged into a single message.

[0123] Figure 5 An architecture overview according to a second embodiment of the present invention is shown.

[0124] This embodiment introduces new messages for user authentication and / or authorization based on DID / VC after successful 3GPP registration, particularly applicable when the network access module 110 differs from the UE 100 and the UE 100 is a non-3GPP device. This embodiment allows for implementation of the invention in a very flexible manner. Figure 5 An embodiment is shown in which the network access module 110 and the UE 100, including the secure memory 105, are separate devices.

[0125] Figure 5 It is shown that:

[0126] UE 100, used by the user to access the service.

[0127] Secure storage 105: Secure storage 105 can reside on any type of UE 100 capable of connecting to a network. In this case, the storage device is physically separate from the network access module 110 that provides connectivity to the 3GPP-based network. For example, the UE 100 may be a tablet computer without SIM card information, which connects to the WLAN router 110 using WLAN. The UE may have its own (e)SIM, but does not use it, instead connecting to the WLAN network.

[0128] Network Access Module 110: Network Access Module 110 is a router that provides UE 110 with a WLAN interface and a 3GPP-based mobile interface for connecting to the Internet via a 3GPP-based mobile network. Compared to existing devices, Network Access Module 110 requires additional functionality to allow the transmission of DID / VC to the core network via a message separate from the IMSI registration message. UE 100 and Network Access Module 110 can be connected via communication channel 116, which can be a WLAN channel. Furthermore, new functionality may be required to transmit credentials from UE 100 to Network Access Module 110.

[0129] CN 120: In this embodiment, the core network 120 acts as the authenticator. In addition to performing known authentication of IMSI / SUPI (which conforms to standards) together with the UDM / UDR, CN 120 (i.e., AMF 120a) also authenticates additional received credentials, such as the DID and the VC bound to the DID, to allow or deny access to the service network 140, service platform 140, or service controller 140.

[0130] UDM / UDR 125: Standard-compliant IMSI / SUPI verification requires a unified data management node 125, and the unified data management node 125 can store additional credentials (DID / VC) via a specific contractual relationship (IMSI).

[0131] VDR 130: Verifiable Data Registry 130 is a trusted entity that stores DID documents (containing DIDs and public keys) and is used to retrieve these DID documents to allow pseudonymous authentication of DID owners. Depending on the specific use case, VDR 130 can be part of the operator's own network infrastructure or an entity outside the network.

[0132] When the mobile WLAN router 110 connects to a 3GPP-based network via its SIM card, any user of the WLAN can authenticate to the 3GPP network and be authorized based on their own Personal ID (DID / VC) to access the Dedicated Service Ecosystem 140 or request any other type of license based on the VC used.

[0133] Figure 6 The timing diagram illustrates the message flow between different entities.

[0134] Step 60: The user of the managed network access module has entered into a contract (prepaid or postpaid) with the network operator and has a valid (e)SIM containing relevant credentials (IMSI / SUPI).

[0135] Step 61: The user using UE 100 has a DID and a VC bound to the DID stored in the UE. Network access module 110 has a valid active connection to the 3GPP network. The user may or may not be a holder of a contract with a network operator.

[0136] Step 62: The network access module 110 including (e)SIM has active registration and active connection to the 3GPP network.

[0137] Step 63: The user or the application that wants to use the service triggers authentication and / or authorization of the user's DID and the VC bound to the DID.

[0138] Step 64: As a user authentication and / or authorization request, the DID and the VC bound to the DID are transmitted from UE 100 to network access module 110, wherein network access module 110 triggers a user authentication and / or authorization request to CN 120. The interaction with the wallet is similar to the interaction described above.

[0139] In step 64a, the network access module 110 can convert user authentication and / or authorization requests into 3GPP format, especially when the UE is a non-3GPP device.

[0140] Step 65: Send a 3GPP-compliant user authentication and / or authorization request, including the DID and the VC bound to the DID, from network access module 110 to CN 120. Step 65 may include sending a network registration message. This message may be as follows: Figure 4 As shown, it includes at least the DID 44 data field and the VC 45 data field.

[0141] Step 66: CN 120, and in particular AMF 120a, retrieves the user's DID document from VDR 130 to verify DID 44.

[0142] Step 67a: CN 120 verifies the DID using the DID document received from the VDR and verifies the VC bound to the received DID by checking the signature.

[0143] Step 67b: If the DID or the VC bound to the DID cannot be successfully verified, AMF 120a refuses to verify, and the process is interrupted at this stage.

[0144] Step 67c: If the DID and the VC bound to the DID can be successfully verified, AMF 120a returns a success response to UE 100, which may include the DID and / or DID document of service 140. Furthermore, in step 67d, CN 120 may provide service 140 with information indicating successful user verification.

[0145] Steps 68 and 69: After successful authentication and / or verification, the user can connect to service 140. Furthermore, service 140 may again execute more specific authorization procedures (for certain services) or trigger encryption of data exchange.

Claims

1. A method for authenticating and / or authorizing users in a network environment, characterized in that, The method includes the following steps: The trusted issuer provides the user equipment (UE 100) with a user identifier (ID) as a decentralized identifier (DID 44) and a verifiable credential (VC, 45) bound to the DID; The SIM or eSIM provides the 3GPP network provider's network registration data to the 3GPP network access module (110); The network access module (110) sends a network access registration message (62, 31b) to the core network (CN), wherein the network access registration message includes network registration data of the 3GPP network provider; The core network (CN) registers the network access module (110) in the network provider's network; The DID (44) and the VC (45) bound to the DID are transmitted from the UE (100) to the network access module (110); The network access module (110) sends a user authentication message to the 3GPP core network, including the DID (44) and the VC (45) bound to the DID; The core network provides the DID (44) and the VC (45) bound to the DID to the verification unit (120, 120a) that performs the authentication and / or authorization process; After successful authentication, the verification unit transmits the result to the UE (100), thereby granting the user access to the requested service.

2. The method according to claim 1, characterized in that, The verification unit (120, 120a) is assigned to the 3GPP network operator, or the 3GPP network operator transmits the DID (44) and the VC (45) bound to the DID to the external verification unit.

3. The method according to any one of the preceding claims, characterized in that, The DID (44) and the VC (45) bound to the DID are stored in the secure memory (105) of the UE (100), and authentication for opening and releasing the DID (44) and the VC (45) bound to the DID is performed before the DID (44) and the VC (45) bound to the DID are transmitted from the UE (100) to the network access module (110).

4. The method according to any one of the preceding claims, characterized in that, At least the DID (44) and the VC (45) bound to the DID are transmitted to the verification unit.

5. The method according to any one of the preceding claims, characterized in that, The network access registration message includes the user authorization message.

6. The method according to any one of the preceding claims, characterized in that, The 3GPP network access module (110) and the UE (100) are two different devices connected to each other via a communication channel (116).

7. The method according to any one of the preceding claims, characterized in that, The UE (100) includes the 3GPP network access module.

8. A UE (100) designed for authenticating and / or authorizing users in a network environment, characterized in that, The UE is configured to Store the user identifier ("ID") as a decentralized identifier ("DID", 44) and the VC ("verifiable credential") bound to the DID ("verifiable credential", 45); The network access module (110) sends a user authorization message, including the DID and the VC bound to the DID, to the 3GPP network operator.

9. The UE as described in claim 8, characterized in that, The UE includes the network access module (110).

Images