Authentication method, apparatus and device, and medium and product
By adopting a SIM-based identity recognition system architecture, the problem of inconsistent identity authentication methods caused by different levels of trusted eID management variants is solved, realizing universal identity authentication in different devices and environments, and improving the interoperability and interchangeability of electronic identity applications.
Patent Information
- Application Number
- PCT/CN2025/104764
- Authority / Receiving Office
- WO · WO
- Patent Type
- Applications
- Current Assignee / Owner
- Priority Date
- 2024-06-28
- Filing Date
- 2025-06-27
- Publication Date
- 2026-01-02
AI Technical Summary
The lack of a universal identity authentication method due to the different levels of security, trust, and assurance in trusted eID management variants has led to different software using different electronic identity applications, resulting in a lack of interoperability and interchangeability.
This paper presents a SIM-based identity recognition system architecture. The deployment and operation of the mobile identity system are divided into different general stages. The SIM card is used as the storage medium for user personal attributes and credentials. User identity recognition information is managed through the mdoc application, and universal identity authentication is supported in different devices and environments.
It realizes a universal identity authentication method under different trusted eID management variants, improves the universality and interoperability of electronic identity applications, and is suitable for a variety of identity recognition scenarios.
Smart Images

Figure CN2025104764_02012026_PF_FP_ABST
Abstract
Description
Authentication method, device, equipment, medium and product
[0001] Cross-reference to related applications
[0002] The present application claims priority based on Chinese patent application 202410865970.1 filed on June 28, 2024, the disclosure content of which is hereby incorporated by reference in its entirety. TECHNICAL FIELD
[0003] The present application relates to the technical field of identity recognition, in particular to an authentication method, device, equipment, medium and product. BACKGROUND
[0004] With the continuous development of Internet technology, mobile devices are widely used in various aspects of people's daily activities. In the field of user identity authentication, in order to reduce the inconvenience brought by carrying various physical identity certificates, technical personnel have proposed digital identity technology. eID (electronic IDentity, citizen network electronic identity) is a citizen network electronic identity issued by the Ministry of Public Security citizen network identity recognition system based on cryptographic technology and intelligent security chip, which can identify identity online remotely without revealing identity information.
[0005] At present, the electronic identity application program (eID-Apps) installed in the user's mobile device can be deployed to provide many different digital ID certificates, but due to the diversity of different trusted eID management variants, different levels of security, trust and guarantee are caused, and different software respectively adopts different electronic identity application programs, so there is a lack of a general identity authentication method for being adopted by different trusted eID management variants.
[0006] The above content is only used to assist in understanding the technical solutions of the present application and does not represent the acknowledgement of the above content as prior art. SUMMARY
[0007] The main purpose of the present application is to provide an authentication method, device, equipment, medium and product, aiming to provide a general identity authentication method and improve the universality of the electronic identity application program.
[0008] To achieve the above purpose, the present application provides an authentication method, which is applied to a mobile certificate system, the life cycle stage of the mobile certificate system includes a running stage, and the method comprises:
[0009] In the running stage, in response to the mdoc application program in the mobile certificate system being activated, the user identity recognition information is transmitted to a verification application for the verification application to verify the user identity recognition information.
[0010] The embodiment of the present application also provides an authentication device, which is applied to a mobile certificate system, the life cycle stages of the mobile certificate system include at least one of an initialization stage, an installation stage, an issuance stage, a running stage and a removal stage, and the device includes at least one of an initialization module, an installation module, an issuance module, a running module and a removal module.
[0011] The running module is configured to, in the running stage, in response to an mdoc application program in the mobile certificate system being activated, transmit user identity identification information to a verification application, so that the verification application verifies the user identity identification information, and according to a verification result, execute a corresponding business process.
[0012] The embodiment of the present application also provides a network device, which includes a memory, a processor and a computer program stored in the memory and executable on the processor, and the computer program is configured to implement the operations of the authentication method.
[0013] The embodiment of the present application also provides a storage medium, which is a computer readable storage medium, and the storage medium stores a computer program, and the computer program is executed by a processor to implement the operations of the authentication method.
[0014] The embodiment of the present application also provides a computer program product, which includes a computer program, and the computer program is executed by a processor to implement the operations of the authentication method.
[0015] The embodiment of the present application discloses an authentication method, which is applied to a mobile certificate system, the life cycle stages of the mobile certificate system include at least one of an initialization stage, an installation stage, an issuance stage, a running stage and a removal stage, by transmitting user identity identification information to a verification application in the running stage in response to an mdoc application program in the mobile certificate system being activated, so that the verification application verifies the user identity identification information, a general identity authentication mode is provided, the authentication process is managed through the mdoc application program in the mobile certificate system, which is suitable for various identity identification and authentication scenes, and the general applicability of the electronic identity application program is improved. BRIEF DESCRIPTION OF DRAWINGS
[0016] Fig. 1 is a structural schematic diagram of a running device of a hardware running environment related to the embodiment of the present application;
[0017] Fig. 2 is a flow schematic diagram of an authentication method according to the first embodiment;
[0018] Fig. 3 is a main component schematic diagram of a mobile certificate system according to the embodiment of the present application;
[0019] Figure 4 is a diagram showing the life cycle stages of the mobile certificate system according to the embodiment of the present application;
[0020] Figure 5 is a diagram showing the installation architecture according to the embodiment of the present application;
[0021] Figure 6 is a diagram showing the general system architecture of the issuance stage according to the embodiment of the present application;
[0022] Figure 7 is a diagram showing the architecture of the issuance with local attributes and credential provision according to the embodiment of the present application;
[0023] Figure 8 is a diagram showing the architecture of the issuance with remote attributes and credential provision according to the embodiment of the present application;
[0024] Figure 9 is a diagram showing the issuance architecture with monitoring service according to the embodiment of the present application;
[0025] Figure 10 is a diagram showing the on-site identity recognition system architecture with local attribute storage according to the embodiment of the present application;
[0026] Figure 11 is a diagram showing the on-site identity recognition system architecture with remote attribute storage according to the embodiment of the present application;
[0027] Figure 12 is a diagram showing the remote identity recognition system architecture with local attribute storage and mobile browser according to the embodiment of the present application;
[0028] Figure 13 is a diagram showing the remote identity recognition system architecture with local attribute storage and external browser according to the embodiment of the present application;
[0029] Figure 14 is a diagram showing the remote identity recognition system architecture with remote attribute storage and mobile browser according to the embodiment of the present application;
[0030] Figure 15 is a diagram showing the remote identity recognition system architecture with remote attribute storage and external browser according to the embodiment of the present application;
[0031] Figure 16 is a diagram showing the remote identity recognition system architecture with remote user storage according to the embodiment of the present application;
[0032] Figure 17 is a diagram showing the on-site identity recognition system architecture with local attribute storage based on SIM card according to the fourth embodiment of the present application;
[0033] Figure 18 is a diagram showing the SIM card application service switching process according to the embodiment of the present application;
[0034] Figure 19 is a diagram showing the linked list data structure according to the embodiment of the present application;
[0035] Figure 20 is a schematic diagram of an authentication process based on a SIM card with local attribute storage according to a fifth embodiment.
[0036] The implementation, functional features and advantages of the present application will be further described with reference to the embodiments and the accompanying drawings. DETAILED DESCRIPTION
[0037] It should be understood that the specific embodiments described herein are merely exemplary and do not limit the application.
[0038] With the continuous development of Internet technology, mobile devices are widely used in all aspects of people's daily activities. In the field of user identity authentication, in order to reduce the inconvenience brought by carrying various physical identity cards, technical personnel have proposed digital identity technology. The eID (electronic IDentity) is the full name of the citizen network electronic identity, which is based on cryptographic technology and uses an intelligent security chip as a carrier. It is a citizen network electronic identity issued by the "Ministry of Public Security Citizen Network Identity Recognition System", which can identify identity online remotely without revealing identity information.
[0039] At present, the mdoc application (electronic identity application, eID-Apps) installed in the user's mobile device can be deployed to provide many different digital ID cards. In addition, it can also reside in other eID applications on the mobile device. In addition, the user can also have multiple mobile devices installed with mdoc applications.
[0040] The mdoc application is used in different fields of daily life and is the focus of different standardization activities. Since the mdoc application can be located on different forms of mobile devices with different security measures, they must be as universal as possible in order to be adopted by different trusted eID management variants. Therefore, it is necessary to provide mechanisms and protocols that can be used by other standards to provide interoperability and interchangeability.
[0041] In order to solve the above problems, the present application provides a SIM-based identity recognition system architecture. The deployment and operation of the mobile certificate system are divided into different general stages, and an implementation scheme of using SIM as a storage medium for user personal attributes and credential data assets is provided in each stage. The multi-channel, multi-security algorithm and human-computer interaction capabilities of the SIM card are fully utilized to provide an overall solution for the operation of the mobile eID identity framework.
[0042] The terms and definitions involved in the embodiments of the present application are as follows:
[0043] mdoc application (mdoc app): an application on a mobile device that manages user attributes and credentials, is configured for electronic identity management, and controls access to user attributes and credentials, whether stored on the mobile device, a server, or an external device. mdoc can stand for mdoc application or mobile eID.
[0044] mobile device: a portable computer device that has at least the following characteristics: a) small enough to be easily carried by an individual; b) designed to operate, transmit, and receive information without a wired connection; c) has local, non-removable, or removable data storage; d) includes a means of interaction between the holder of the portable computer device and the device. A mobile device can also include voice communication capabilities, on-board sensors that allow the device to gather information, and / or extended computer functionality and connectivity. For example: a mobile communication terminal, a tablet computer, and an e-reader are all mobile devices.
[0045] attribute, user attribute: a characteristic or property of an entity, an entity type, address information, a phone number, a permission, a MAC address, a domain name are all possible attributes.
[0046] attribute statement: a statement or assertion that describes a user attribute, including a predicate for the attribute.
[0047] authentication: providing assurance of the identity of an entity.
[0048] authentication protocol: a defined sequence of messages between an entity and a verifier that enables the verifier to authenticate the entity.
[0049] credential: a set of data presented as evidence of a claimed or asserted identity and / or right. For example, a user attribute signed by an issuer is a credential that can be verified by a service provider through verification of the electronic signature as proof of authenticity.
[0050] entity: an item that is relevant to the operation of a domain, and is distinctly identifiable within that domain. An entity can have a physical or logical manifestation, for example: an individual, an organization, a device, a group of such items, a telecommunications subscriber, a SIM card, a passport, a network interface card, a software application, a service, or a website.
[0051] Discovery service: Service running at the issuance phase, which validates the characteristics of the mdoc application through the mdoc application capability descriptor.
[0052] Holder: Entity, i.e. natural person, that holds the mdoc application, which is used to implement the user identification verification application.
[0053] Dentification, user identification: Process that distinguishes an entity in a given context through a unique association of a set of descriptive parameters. For example: the user attribute is a descriptive parameter of the entity "holder".
[0054] Identifier: Data configured to identify an entity from other entities in a given context.
[0055] Identity: Set of attributes related to an entity. An entity can have multiple identities and multiple entities can have the same identity.
[0056] Identity or attribute provider service: Service that receives issuer-authorized attributes and provides them to the verification application at the running phase. Identity or attribute providers can be deployed as central services or as non-central services using a holder-managed distributed ledger technology. An attribute provider service provides any type of attribute and an identity provider service makes available attributes that convey identity information.
[0057] D-Provisioning Entity: Entity that represents the issuer and implements all or part of the services of the installation phase, issuance phase and running phase.
[0058] Installation phase: Phase of the mobile certificate system that includes loading the mdoc application and related software onto the mobile device, loading the application onto a smart mobile communication terminal or loading the SA application (e.g. Java Card applet, CS applet) onto a secure area, such as an embedded secure element, which is part of the installation phase.
[0059] Issuer: Entity that provides available user attributes and discovery services at the issuance phase and authorizes the instantiation of the mdoc application. Note: An issuing authority can act as an issuer.
[0060] Issuing phase: Phase of the mobile document system that includes the initial issuance of user attributes or credentials or both into the mdoc application and can include re-issuance of entitlement credentials. Note: In literature, the issuance of user attributes and credentials is also referred to as the provisioning of user attributes and credentials.
[0061] Issuing service: Service running in the issuing phase that provides all data of the mobile document, either stored locally in the mdoc application or remotely in an identity or attribute provider service.
[0062] MCD attestation service: Service that signs the mdoc capability descriptor.
[0063] mdoc app provider service: Network service run by the mdoc application provider in the issuing phase that controls the issuance of mobile documents into the mdoc application.
[0064] Mobile document: Set of attributes and credentials issued by one or more issuers that are provided to the mdoc application for management. A mobile document is considered a digital file. An mdoc application that manages multiple mobile documents is also considered an e-wallet, and mdoc can stand for mdoc application or mobile eID. For example: Mobile documents include electronic IDs and licenses or credentials that grant the holder rights.
[0065] Mobile document system.
[0066] Mobile eID-System: Set of components used to manage mobile documents, interactions, for example: Components of the mobile document system are the mdoc application, mobile attestation application, issuing service or attestation service.
[0067] Monitoring service: Service running in the issuing phase that controls all or parts of the user identity recognition service, discovery service, issuing service or MCD attestation service.
[0068] On-site identification: Use case of the mobile credential system requiring local device-to-device communication between the mobile device with the mdoc application and the verifier device to perform user identification. Device-to-device authentication includes the mobile device with the mdoc application and the verifier device with the verification application.
[0069] Operational phase: Phase of the mobile credential system including the use of the mdoc application to perform user identification and authentication.
[0070] Remote identification: Use case of the mobile credential system requiring remote device-to-service communication over the Internet between the mobile device and the verification application to perform user identification. Device-to-service authentication includes the mobile device with the mdoc application and the verification application without a verifier device.
[0071] Remote user storage service: Service that manages data storage and controls data access. Authorization of the holder is required.
[0072] Removal phase: Phase of the mobile credential system including the deletion of the mdoc application and related software and user attributes and credentials from the mobile device.
[0073] SA application (SA-Application): Application that manages the secure zone of the credentials, can manage user attributes, is configured to perform user identification, and can control access to user attributes.
[0074] SA application provider service: Service that installs the SA application (3.30) into the secure zone via the SA client.
[0075] Secure memory card: Non-volatile memory card format, i.e. Secure Digital (SD) card, used in portable devices with physical dimensions of "original", "mini" or "micro" and equipped with an encryption module.
[0076] Secure Area: Isolated internal or attached area of a mobile device that ensures secure handling and storage of data even when the host operating system (OS) is compromised. The host operating system is also referred to as the rich operating system or advanced operating system. For example: a secure element or a trusted execution environment (TEE) as an internal secure area. A universal integrated circuit card (UICC) is considered as an attached secure area of a mobile device.
[0077] Server Retrieval Token: Token that identifies the holder and the mobile credential, serving the identity or attribute provider service.
[0078] Trusted Execution Environment (TEE): Secure area of the host processor of a mobile device.
[0079] TSM-Service: SA application provisioning service that allows loading and installation of SA applications, for example: JavaCard Applets, CS Card Applets and Trustlets are SA applications.
[0080] User Identification Service: Service that runs in the issuance phase, identifying the holder by electronic or non-electronic means, with or without mobile credentials.
[0081] Validation Service: Service or mechanism that runs in the operational phase, which can determine the validity of the mobile credential. The determination of validity can include the revocation status of the mobile credential. For example: a certificate revocation list or a public key directory can be part of the validation service.
[0082] Verification Application (mdoc Reader): Application on the verifier device or on a remote server that verifies the user attributes and the credentials retrieved from the mdoc application or the identity or attribute provider service. The mdoc application and a verification application are usually part of the mobile credential system; the mdoc reader is defined as a device that is able to retrieve mdoc data for verification purposes.
[0083] Verifier: Entity that controls the verification application and uses it for user identification.
[0084] verifier device: a device that is connected locally with the mobile device that provides the mdoc application and optionally provides the verifier application. For example, a terminal that is connected with the mobile device is a verifier device without the verifier application. A mobile device that provides the verifier application through the verifier application connected with the mobile device is a verifier device.
[0085] The abbreviations involved in the embodiments of the present application are as follows:
[0086] BLE: Bluetooth Low Energy;
[0087] eID: Electronic identity;
[0088] eMRTD: electronic Machine-Readable Travel Document;
[0089] eSE: embedded secure element;
[0090] eUICC: embedded universal integrated circuit card;
[0091] IDS: Image Delivery Server;
[0092] MCD: mdoc app capability descriptor;
[0093] mdoc: mobile document;
[0094] OFL: Open Firmware Loader;
[0095] PII: personal identifiable information;
[0096] SA: Secure Area;
[0097] SAAO: Secure Area Attestation Object;
[0098] TEE: Trusted Execution Environment
[0099] TRE: Tamper Resistant Elements.
[0100] Referring to FIG. 1, FIG. 1 is a schematic diagram of a running device structure of a hardware running environment related to an embodiment of the present application.
[0101] As shown in FIG. 1, the running device can include a processor 1001, for example, a central processing unit (CPU), a communication bus 1002, a user interface 1003, a network interface 1004, and a memory 1005. The communication bus 1002 is configured to realize the connection and communication between the components. The user interface 1003 can include a display, an input unit such as a keyboard, and can also include a standard wired interface, a wireless interface. The network interface 1004 can optionally include a standard wired interface, a wireless interface (such as a wireless fidelity (WIreless-FIdelity, WI-FI) interface). The memory 1005 can be a high-speed random access memory (RAM) memory, or a stable non-volatile memory (NVM) such as a disk memory. The memory 1005 can also be a storage device independent of the aforementioned processor 1001.
[0102] Those skilled in the art can understand that the structure shown in FIG. 1 does not constitute a limitation on the running device, and can include more or fewer components than the diagram, or combine certain components, or different component arrangements.
[0103] As shown in FIG. 1, the memory 1005 as a storage medium can include an operating system, a data storage module, a network communication module, a user interface module, and a computer program.
[0104] In the running device shown in FIG. 1, the network interface 1004 is mainly configured to communicate data with other devices; the user interface 1003 is mainly configured to interact data with the user; the processor 1001 and the memory 1005 in the running device of the present application can be arranged in the running device, and the running device calls the computer program stored in the memory 1005 through the processor 1001, and performs the following operations:
[0105] In the running phase, in response to an mdoc application in the mobile certificate system being activated, user identity information is transmitted to a verification application for verification by the verification application.
[0106] In some embodiments, the method further comprises at least one of:
[0107] In the initialization phase, at least one infrastructure component is set up, which is used in at least one of the installation phase, the distribution phase, the running phase and the removal phase;
[0108] In the installation phase, the mdoc application and related software are loaded and installed;
[0109] In the distribution phase, the mdoc application is personalized;
[0110] In the removal phase, the mdoc application and related software are deleted.
[0111] In some embodiments, the operation of loading and installing the mdoc application and related software comprises:
[0112] The mdoc application is installed through a market application and / or pre-installation;
[0113] At least one SA application is installed in a secure area of a SIM card through an SA application provider service.
[0114] In some embodiments, the mobile certificate system further comprises an SDK access interface, and the operation of loading and installing the mdoc application and related software further comprises:
[0115] The mdoc application is authorized to access an AC access channel of the SIM card through the SDK access interface.
[0116] In some embodiments, the mobile certificate system further comprises an application state machine, which is configured to perform corresponding application state migration according to the life cycle phase of the mobile certificate system.
[0117] In some embodiments, the distribution phase comprises a user identity identification sub-phase, a discovery sub-phase of the mdoc application and a data distribution sub-phase.
[0118] In some embodiments, the operation of the user identity identification sub-phase comprises:
[0119] User attributes are retrieved through a user identity identification service, and a binding relationship between a holder and the user attributes is verified.
[0120] In some embodiments, the operation of the discovery sub-phase of the mdoc application comprises:
[0121] accessing the at least one SA application through the mdoc application and establishing a communication channel;
[0122] conducting a qualification check on the at least one SA application;
[0123] verifying the binding relationship between the holder and the mobile device and the mdoc application in case the qualification check is passed.
[0124] In some embodiments, the operation of the data issuance sub-phase comprises:
[0125] writing the user attributes into the SIM card, setting the access rules and / or authentication mechanism of the user attributes and verifiable credentials, and associating the SIM card with the user identity information through the hardware identification of the SIM card.
[0126] In some embodiments, the user identity information comprises at least one of the user attributes, user attribute retrieval, and server retrieval token information.
[0127] In some embodiments, the running phase comprises an initialization sub-phase, a device access sub-phase, and a data transmission sub-phase.
[0128] In some embodiments, the operation of the initialization sub-phase comprises:
[0129] requesting the holder and / or verifier to authenticate in response to the mdoc application being activated.
[0130] In some embodiments, the operation of the device access sub-phase comprises:
[0131] determining the information required for establishing a transmission channel between the mdoc application and the verification application;
[0132] establishing the transmission channel according to the information.
[0133] In some embodiments, the operation of the data transmission sub-phase comprises:
[0134] transmitting at least one of the user attributes, user attribute retrieval, and server retrieval token information to the verification application through the transmission channel.
[0135] In some embodiments, the running phase comprises on-site identity recognition and / or remote identity recognition.
[0136] In some embodiments, the on-site identity recognition comprises on-site identity recognition with local attribute storage, in a process of the on-site identity recognition with local attribute storage, the running stage comprises:
[0137] In response to the mdoc application and the verification application being activated, requiring the holder and / or verifier to be identified, checking whether the verification application is authorized to retrieve data;
[0138] In the case that the verification application is authorized to retrieve data, determining information required for establishing a transmission channel between the mdoc application and the verification application, and establishing the transmission channel according to the information;
[0139] Transferring at least one of user attributes, user attribute retrieval and server retrieval token information managed by the mdoc application to the verification application through the transmission channel, for the verification application to verify at least one of the user attributes, the user attribute retrieval and the server retrieval token information through a confirmation service.
[0140] In some embodiments, the on-site identity recognition comprises on-site identity recognition with local attribute storage, in a process of the on-site identity recognition with local attribute storage, the running stage comprises:
[0141] In response to the mdoc application and the verification application being activated, requiring the holder and / or verifier to be identified, checking whether the verification application is authorized to retrieve data, and requesting at least one of the user attributes, the user attribute retrieval and the server retrieval token information from an identity or attribute provider service;
[0142] In the case that the verification application is authorized to retrieve data, determining information required for establishing a transmission channel between the identity or attribute provider service or the mdoc application and the verification application, and establishing the transmission channel according to the information;
[0143] Transferring at least one of user attributes, user attribute retrieval and server retrieval token information managed by the identity or attribute provider service to the verification application through the transmission channel, for the verification application to verify at least one of the user attributes, the user attribute retrieval and the server retrieval token information through a confirmation service.
[0144] In some embodiments, the remote identity recognition comprises remote identity recognition with local attribute storage, in a process of the remote identity recognition with local attribute storage, the running stage comprises:
[0145] in response to the mdoc application and the verification application being activated, requiring the holder and / or verifier to authenticate, and receiving request information and checking whether the verification application is authorized to retrieve data based on the request information, wherein the verifier is a remote server, the request information is forwarded by the verification application to the mdoc application through a browser of an external device or a mobile application or browser in the current mobile device, and the request information includes at least one of a requested user attribute, verifier information, and a purpose description;
[0146] in a case where the verification application is authorized to retrieve data, determining information required for establishing a transmission channel between the mdoc application and the verification application, and establishing the transmission channel based on the information;
[0147] transmitting at least one of a user attribute managed by the mdoc application, a user attribute retrieval, and server retrieval token information to the verification application through the transmission channel, so that the verification application verifies at least one of the user attribute, the user attribute retrieval, and the server retrieval token information through a confirmation service.
[0148] In some embodiments, the remote identity recognition includes a remote identity recognition with remote attribute storage, and in a process of the remote identity recognition with remote attribute storage, the running stage includes:
[0149] in response to the mdoc application and the verification application being activated, requiring the holder and / or verifier to authenticate, and receiving request information and checking whether the verification application is authorized to retrieve data based on the request information, and requesting at least one of the user attribute, the user attribute retrieval, and the server retrieval token information from an identity or attribute provider service or a remote user storage service, wherein the verifier is a remote server, the request information is forwarded by the verification application to the mdoc application through a browser of an external device or a mobile application or browser in the current mobile device, and the request information includes at least one of a requested user attribute, verifier information, and a purpose description;
[0150] in a case where the verification application is authorized to retrieve data, determining information required for establishing a transmission channel between the identity or attribute provider service or the remote user storage service and the verification application, and establishing the transmission channel based on the information;
[0151] transmitting, by the transport channel, at least one of the user attributes, the user attribute retrieval, and the server retrieval token information managed by the identity or attribute provider service or the remote user storage service to the authentication application for the authentication application to verify at least one of the user attributes, the user attribute retrieval, and the server retrieval token information by confirming service.
[0152] In some embodiments, the functions of the SIM card include at least one of secure channel management, life cycle control, and service function processing.
[0153] In some embodiments, the service function processing includes at least one of service state synchronization, personal attribute information processing, and application remote management, and the service state synchronization includes:
[0154] processing application service state machine switching by an issuer; and / or, reporting service state and service party execution service instructions to the issuer, and judging service state security;
[0155] The personal attribute information processing includes:
[0156] In response to receiving a write instruction of an issuer, writing the user attributes and verifiable credentials into the SIM card;
[0157] In response to receiving a verification request of a verifier, presenting the user attributes and verifiable credentials through a preset linked list data structure;
[0158] In response to satisfying an issuer permission, writing the user attributes and verifiable credentials updated by the issuer into the SIM card.
[0159] In some embodiments, the operation of presenting the user attributes and verifiable credentials through the preset linked list data structure further includes:
[0160] associating a service identifier and user verifiable credential information with a user identity identifier as an index to obtain the linked list data structure;
[0161] The user verifiable credential information includes a verifiable credential type, and the verifiable credential type is configured to dynamically organize presentation information.
[0162] First embodiment
[0163] Referring to FIG. 2, FIG. 2 is a flowchart of an authentication method according to the first embodiment, the method is applied to a mobile certificate system, a life cycle stage of the mobile certificate system includes at least one of an initialization stage, an installation stage, an issuance stage, a running stage, and a removal stage, and the method includes:
[0164] At operation S10, in the running phase, in response to an mdoc application in the mobile credential system being activated, user identity information is transmitted to a verification application for verification by the verification application.
[0165] The mobile credential system in the embodiments of the present application supports one or more specified system architectures, including mdoc applications running on mobile devices for identity and authentication of the bearer. The verifier is an entity that provides a verification application either by placing a verifier device at a certain distance from the mobile device or by an online service. The verifier uses the issuer information and related trustworthiness to determine the quality of the identity or authentication process.
[0166] In some embodiments, the user identity information includes at least one of the user attributes, user attribute retrieval, and server retrieval token information.
[0167] In some embodiments, the storage and access control of user attributes and credential data are managed by the mdoc application, the SA application, or a remote identity or attribute provider program, or a combination of these options. Using the SA application with a secure area with hardware support (such as a tamper-resistant hardware component), higher trustworthiness can be provided in the user identity recognition and authentication process.
[0168] In some embodiments, the mobile credential system is an identity management system for identity management in a certain domain. By establishing different domains of identity trust relationships, trust is allowed to be established in cross-domain identification processes and in the derivation of user attributes from a primary domain to a secondary domain. Therefore, the process and required infrastructure for re-issuance or update of user attributes and credentials, as well as revocation and deletion, are part of the mobile credential system.
[0169] In some embodiments, the mobile credential system can operate in different modes according to the policies of the issuer. The differences in the architecture are mainly in the following aspects: a) the type of binding user attributes to the bearer; b) the location and storage of user attributes themselves; c) the way of transmission of user attributes and credentials. User binding describes the method and strength of linking electronic data (i.e. user attributes) to a natural person (i.e. the bearer). Creating the binding is the responsibility of the issuer; verifying the binding is the responsibility of the verifier. The verifier running the verification application can verify this link (e.g. the verifier can compare the electronic face image received as part of the user attributes with the face of the bearer). The issuer can establish a strong link between electronic data and a natural person as part of the issuance process (e.g. the issuer can verify the identity of the bearer by personal appearance during the issuance phase). When the trustworthiness meets the requirements of the verifier, the verifier should have sufficient trust in the binding established by the issuer to accept that the bearer is the legitimate holder of the mdoc application and the corresponding mobile credential.
[0170] Referring to FIG. 3, FIG. 3 is a schematic diagram of main components of a mobile credential system according to an embodiment of the present application. As shown in FIG. 3, the mdoc application includes one or more SA applications, user attributes and credentials, and authentication factors configured for holder identity authentication (such as biometric factors or knowledge-based factors) that can be managed in a secure enclave. The secure enclave can be hardware-based or software-based, or both.
[0171] In some embodiments, the mdoc application communicates with the secure enclave through internal channels of the mobile device to access and process user attributes and credentials. The SA applications can reside on external devices (such as contactless eIDs or wearable devices) and communicate with the mdoc application through local channels. In addition, physical tokens, whether or not they have electronic functionality, can have their physical security features captured or interpreted by the mdoc application as additional authentication factors for the holder. Additional physical factors of authentication can be used in the following lifecycle stages: issuance stage: in the sub-stage of user identity, they can be configured to register the holder or confirm the user attributes of the holder before the sub-stage of issuance; running stage: they are applicable to all architectures of the running stage to confirm the identity or user attributes of the holder. They can be requested according to the policies defined by the mdoc application, the issuer, or the verifier of the running verification application.
[0172] In some embodiments, user attributes and credentials can be managed by one or more identity or attribute providers, and the mobile credential system can include a marketplace service and an SA application provisioning service to install, update, or delete mdoc applications and SA applications, respectively, and any combination of the above given solutions can be designed and deployed.
[0173] The above solutions apply the authentication method to the mobile credential system, and the lifecycle stages of the mobile credential system include at least one of the initialization stage, the installation stage, the issuance stage, the running stage, and the removal stage. Specifically, in the running stage, in response to the mdoc application in the mobile credential system being activated, the user identity identification information is transmitted to the verification application for verification by the verification application, a general identity authentication method is provided, the authentication process is managed by the mdoc application in the mobile credential system, and the general identity authentication method is suitable for various identity authentication scenarios, and the general identity authentication method improves the general identity application program.
[0174] Second Embodiment
[0175] Referring to FIG. 4, FIG. 4 is a schematic diagram of a life cycle stage of a mobile certificate system according to an embodiment of the present application. The second embodiment of the present application is based on the first embodiment described above. The same or similar contents in the second embodiment of the present application as those in the first embodiment are described above and will not be repeated hereinafter. Based on the above, referring to FIG. 4, the deployment and operation of the mobile certificate system based on the general system architecture of the mobile eID system are divided into different general stages, involving different components. The life cycle of the mobile certificate system includes at least one of an initialization stage, an installation stage, an issuance stage, an operation stage, and a removal stage. The details of each stage and transition are shown in FIG. 4. The present application is directed to the general system architecture based on the mobile eID system, uses a SIM as a storage medium for user personal attributes and credential data assets, and meets the authentication needs of on-site identity recognition or remote identity recognition between a business verification device and a user mobile device.
[0176] In some embodiments, the method further includes at least one of:
[0177] In the initialization stage, at least one infrastructure component is set, which is used for at least one of the installation stage, the issuance stage, the operation stage, and the removal stage.
[0178] In the installation stage, the mdoc application and related software are loaded and installed.
[0179] In the issuance stage, the mdoc application is personalized.
[0180] In the removal stage, the mdoc application and related software are deleted.
[0181] In some embodiments, the initialization stage is a starting stage, including the setting of one or more infrastructures required for the installation, issuance, operation, and removal stages. The initialization stage will implement the setting of various infrastructures required for the entire system operation, including the development and publication of a terminal App for user installation in a mobile terminal and the development and publication of a SIM application installed in a SIM card of a user mobile terminal.
[0182] In some embodiments, the operation of loading and installing the mdoc application and related software includes:
[0183] The mdoc application is installed through a market application and / or a pre-installation manner.
[0184] At least one SA application is installed in a secure area of the SIM card through an SA application provider service.
[0185] In some embodiments, the installation phase includes all operations to make the mdoc application ready for distribution. The selection of these operations depends on the capabilities of the mdoc application. The relevant capabilities and trustworthiness are part of the SAAO, described in the MCD and communicated to the distributor during the distribution process. During the installation phase, the holder selects the market application through which the mdoc application is loaded and installed. The holder can learn about this mdoc application and market through the distributor's portal, or the mdoc application can be pre-installed on the mobile device, and the MCD is created at pre-installation or installation.
[0186] Referring to Figure 5, which is an installation architecture diagram in embodiments of the application, in the implementation based on the SIM card, the user mobile device installs the SA application provided by the market application and the SA application provider, wherein the mdoc file is instantiated as a mobile terminal App, and the SA application is instantiated as a SIM card application, i.e. the installation of the two-part program of the App and the SIM card Applet is implemented.
[0187] In some embodiments, the mdoc application communicates with the online MCD attestation service to start the establishment of the binding between the mdoc application and the mobile device after the mdoc application is loaded and started for the first time (see the relationship between the mdoc application and the MCD attestation service in Figure 5). The binding is provided by the mobile device manufacturer as part of the SAAO, which is based on the SA attestation. Information about further device capabilities is provided to the MCD attestation service through the device functionality and the mdoc application functionality (see the relationship between the mdoc application and the MCD attestation service in Figure 5). The service creates the MCD including the SAAO and either writes the complete MCD data into the mdoc application or writes the appropriate reference to the MCD (see the interfaces IN-2 and IN-1 in Figure 5). In the latter case, the MCD attestation service maintains the complete MCD for online retrieval.
[0188] In some embodiments, the SA application provider service allows the configuration of the SA-application specific to the mdoc application into the secure area through the SA client application. The loading, installation and installation of the SAAO are specific to the selected secure area and are not within the scope of this document (see the relationship and In the initial operation, which is not necessarily part of the installation sequence, the SA application of the mdoc application provider should be provided to the SA application provider service, see interface IN-3 in Fig. 5. During the installation process of the mdoc application, the application requires the installation of the respective SA application to the SA client already installed on the mobile device, see interface IN-4 in Fig. 5. The SA client has the administrative access to the secure area and controls the loading and installation of the SA application. With the successful installation of the SA application and the corresponding SAAO, the mobile eID application can start using the SA application on the application level, the mdoc application provider backend can create further attestations and provide the MCD, see interfaces IN-2 and IN-1 in Fig. 5.
[0189] In some embodiments, the mobile credential system further comprises an SDK access interface, the loading and installation of the mdoc application and related software further comprising:
[0190] The AC access channel authorization of the mdoc application to the SIM card through the SDK access interface.
[0191] In some embodiments, the mobile credential system further comprises an application state machine, the application state machine being configured to perform corresponding application state migration according to the life cycle phase of the mobile credential system.
[0192] In some embodiments, in order to ensure the authentication process of the subsequent identity framework, based on the characteristics of the SIM card, an SDK access interface is designed in the embodiments of the application, the AC access channel authorization of the application App to the SIM card is performed during the installation phase of the mdoc application, and an application state machine is designed to realize the corresponding application state migration of the life cycle of the mobile credential.
[0193] In some embodiments, the mobile credential system is an identity management system, which includes a set of user attributes from multiple channels called identity proof data sources. Its responsibilities in the issuance service are:
[0194] a) retrieving user attributes from one or more sources;
[0195] b) verifying user attributes;
[0196] c) in some embodiments, determining trustworthiness;
[0197] issuing user attributes and credentials into the mdoc application.
[0198] In some embodiments, the issuance phase includes a user identity recognition sub-phase, a discovery sub-phase of the mdoc application, and a data issuance sub-phase.
[0199] In some embodiments, the operation of the user identity identification sub-stage includes:
[0200] Retrieving the user attribute through the user identity identification service, and verifying the binding relationship between the holder and the user attribute.
[0201] In some embodiments, the operation of the discovery sub-stage of the mdoc application includes:
[0202] Accessing the at least one SA application through the mdoc application and establishing a communication channel;
[0203] Checking the qualification of the at least one SA application;
[0204] In the case where the qualification check is passed, verifying the binding relationship between the holder and the mobile device and the mdoc application.
[0205] In some embodiments, the operation of the data issuance sub-stage includes:
[0206] Writing the user attribute into the SIM card, setting the access rule and / or authentication mechanism of the user attribute and verifiable credential, and associating the SIM card with the user identity information through the hardware identification of the SIM card.
[0207] Referring to FIG. 6, FIG. 6 is a general system architecture diagram of the issuance stage in the embodiments of the present application. As shown in FIG. 6, the issuance stage has the following three general sub-stages: the user identity identification sub-stage, the discovery sub-stage of the mdoc application, and the data issuance sub-stage. Based on the SIM card implementation mode, the digital identity implementation framework is designed based on the user identity identification sub-stage, the discovery sub-stage of the mdoc application, and the data issuance sub-stage, including:
[0208] (1) User identity identification sub-stage: user attribute source, user identity verification mainly determines the source of user identity writing. Based on the implementation mode of the SIM card, the identity attribute source is common to other modes, generally including two parts of user personal information input and issuance content of the personal digital identity by the issuer, and the SIM card has more writing modes through the remote mode of the operator TSM than other modes.
[0209] (2) Discovery of mdoc application: including discovery of mdoc program, SA application check, issuance request, and verification of binding relationship.
[0210] Based on the SIM card implementation, the current application information, including the application version and application status, is accessed through the mobile terminal app program to obtain the SIM Applet, to realize the end-to-end operation of mdoc program discovery (terminal app), SA application inspection (SIM card Applet) issuance request and verification of the binding relationship.
[0211] (3) Data issuance sub-phase: issuer attributes and credentials are issued to the corresponding mdoc application and SA application, and access rules and authentication mechanisms are set.
[0212] In some embodiments, based on the SIM card implementation, the attribute information required for user personal identification, including personal attributes, issuer attributes and credentials issued to individuals, is written into the SIM through the SIM dedicated secure channel method, where the data includes personal basic information and biometric features, etc.; and the security features of the SIM card are used, the access rules and authentication mechanisms of the attributes and credentials can be set through the real-time human-computer interaction mode, the user sets the authorized password, etc., and at the same time, in order to strengthen the security of user identity information, the association and binding of the SIM card and the user identity information are performed through the unique hardware identifier SEID of the SIM card, so as to complete the cross-terminal migration of data for subsequent user loss of SIM, replacement of SIM, replacement of mobile device, etc.
[0213] In some embodiments, depending on the life cycle state of the user attributes and / or credentials, some stages or processes may not be applicable during the transition period from the beginning of issuance to the update issuance.
[0214] In some embodiments, the user identity identification sub-phase includes retrieval of user attributes and verification of the holder and attribute binding. This can be achieved through organizational non-electronic means (for example, through physical inspection of physical certificates and verification of user binding by comparing facial images) or through existing electronic identification means, or even through a mobile certificate system. This sub-phase can also be performed after the sub-phase of mdoc application discovery. Accordingly, the source of user attributes and the issuer policy determine the type of issued mdoc. The source of attributes and the selection mechanism of creating credentials together with the security mechanism used by the mdoc application form part of the elements that determine the trustworthiness.
[0215] In some embodiments, the discovery sub-phase of the mdoc application requires electronic communication between the mdoc application and the discovery service and involves device detection. This communication can be local (e.g. through BLE) or remote. In this sub-phase, a qualification check should be performed to determine if the mobile device and the mdoc application with the SA application match and are trustworthy according to some policy. If the check passes, the binding between the holder and the mobile device and the mdoc application can be verified. In addition, the match between the holder confirmed in the user identity authentication sub-phase and the holder confirmed in the mdoc application discovery sub-phase can also be verified. Part of this sub-phase can be omitted in the re-issuance process. Once the user identity authentication and the mdoc application discovery are completed, the user attributes and credentials are issued to the target mobile device and the mdoc application with the SA application.
[0216] In some embodiments, for the data issuance sub-phase, in the previous sub-phase (user identity recognition and mdoc application discovery), the following have been completed:
[0217] a) the user identity recognition service has recognized the holder and collected all the required user attributes;
[0218] b) the discovery service has verified the capabilities of the mdoc application or the SA application or both;
[0219] c) in some embodiments, the discovery service has associated the recognized holder with the mdoc application.
[0220] Referring to FIG. 7, FIG. 7 is a schematic diagram of an architecture for issuing a local attribute and credential provision in an embodiment of the present application. As shown in FIG. 7, in this phase (the data issuance sub-phase), the issuance service generates credentials that are unique to the respective mdoc application and mobile device, see interface IS-5 in FIG. 7; the issuance service can send the user attributes and credentials directly to the mdoc application for installation, or indirectly through the mdoc application provider service; these data are stored in the local mdoc application and the secure area, see interfaces IS-6 and IS-7 in FIG. 7.
[0221] Referring to FIG. 8, FIG. 8 is a schematic diagram of an architecture for issuing a remote attribute and credential provision in an embodiment of the present application. As shown in FIG. 8, if the issuing service selects an identity or attribute provider service to store the remote attribute, the issuer sends the data to the corresponding identity or attribute provider service together with the mobile device and mdoc application information. The provider finally stores the user attribute and credential remotely and binds the mobile device and mdoc application to the user attribute and credential again, directly through interface IS-9 in FIG. 8 or indirectly through the mdoc application provider service, interface IS-10 in FIG. 8.
[0222] In some embodiments, if the user identity recognition or mdoc application discovery is not provided in the sub-phase, the holder identity authentication can be required to ensure that the mobile device holder is also the legal holder participating in the attribute issuing process under a certain level of trust, as shown in FIG. 7 and FIG. 8.
[0223] Referring to FIG. 9, FIG. 9 is a schematic diagram of an issuing architecture with a monitoring service in an embodiment of the present application. In addition to the services specified for the installation and issuing stages, a monitoring service can be used to control the running service. The monitoring service does not interact with the mdoc application, but interacts with the user identity recognition service, the discovery service, the issuing service and the MCD authentication service, as shown in FIG. 9.
[0224] In some embodiments, the running stage includes an initialization sub-phase, a device access sub-phase and a data transmission sub-phase.
[0225] In some embodiments, in the initialization sub-phase, the mdoc application and the verification application are activated, and the holder and the verifier can be required to be authenticated, respectively. In the device access sub-phase, the mdoc application and the verification application exchange information required for establishing a secure connection. If the secure channel is successfully established, the data transmission sub-phase is entered, and the user attribute, the user attribute retrieval and the server retrieval token information are transmitted through the established transmission channel.
[0226] In some embodiments, based on the SIM card implementation, the user pulls up the mobile terminal app to select the SIM card identity recognition Applet through the machine card channel, and establishes a secure channel through mutual authentication (such as external authentication) to realize the access of the mobile terminal app to the user data in the SIM card.
[0227] In some embodiments, the operation of the initialization sub-phase includes:
[0228] In response to the mdoc application being activated, the holder and / or the verifier are required to be authenticated.
[0229] In some embodiments, the operation of the device access sub-phase includes:
[0230] determining information required for establishing a transmission channel between the mdoc application and the verification application;
[0231] establishing the transmission channel according to the information.
[0232] In some embodiments, the operation of the data transmission sub-stage includes:
[0233] transmitting at least one of the user attribute, the user attribute retrieval and the server retrieval token information to the verification application through the transmission channel.
[0234] In some embodiments, the running stage includes on-site identity recognition and / or remote identity recognition.
[0235] In some embodiments, the removal stage includes deleting the mdoc application and related software and the user attribute and the credential from the mobile device.
[0236] In some embodiments, based on the SIM card implementation, the removal stage is mainly responsible for deleting the mobile terminal APP, the SDK, the SIM card Applet and the user attribute and the credential and all related contents, and recycling the memory space of the SIM card.
[0237] The embodiment above describes the life cycle of the mobile certificate system, including the initialization stage, the installation stage, the issuance stage, the running stage and the removal stage, provides a general identity authentication method, manages the authentication process through the mdoc application in the mobile certificate system, is suitable for various identity recognition and authentication scenes, and improves the universality of the electronic identity application.
[0238] Third Embodiment
[0239] The third embodiment of the present application is based on any of the above embodiments. In the third embodiment of the present application, the same or similar contents as any of the above embodiments can be referred to the above introduction, and will not be described hereinafter. On this basis, the on-site identity recognition and the remote identity recognition in the running stage are further described in the embodiment.
[0240] In some embodiments, the architecture of the on-site identity recognition system is divided into three main sub-stages: the initialization sub-stage, the device access sub-stage and the data transmission sub-stage. In the initialization sub-stage, the mdoc application and the verification application are activated, and the holder and the verifier can be respectively required to be identified. In the device access sub-stage, the mdoc application and the verification application exchange the information required for establishing a secure connection. After the secure channel is successfully established, the data transmission sub-stage is entered, and the user attribute, the user attribute retrieval and the server retrieval token information are transmitted through the established transmission channel.
[0241] In some embodiments, the live identity recognition includes live identity recognition with local attribute storage, in which the run phase includes:
[0242] In response to the mdoc application and the verification application being activated, requiring the holder and / or verifier to authenticate, checking whether the verification application is authorized to retrieve data;
[0243] In the case where the verification application is authorized to retrieve data, determining information required for establishing a transmission channel between the mdoc application and the verification application, and establishing the transmission channel according to the information;
[0244] Transferring at least one of the user attributes managed by the mdoc application, the user attribute retrieval, and the server retrieval token information to the verification application through the transmission channel, for the verification application to verify at least one of the user attributes, the user attribute retrieval, and the server retrieval token information through a confirmation service.
[0245] Referring to FIG. 10, FIG. 10 is a schematic diagram of a live identity recognition system architecture with local attribute storage in an embodiment of the present application. As shown in FIG. 10, the identity recognition process of the physical identity card is adjusted in the embodiment, i.e., the holder presents or hands over the identity card to an officer or another holder for identity recognition. In the electronic case, the electronic identity data is transmitted from the mobile device of the holder to the verification device of the verifier, and the verifier proves the integrity, authenticity, and validity of the received user attributes and credentials in an electronic manner. Before the user attributes and credentials are transmitted, the holder authorizes the run, and the mdoc application can be authenticated, as shown in the relationship The mdoc application can check whether the verification application is authorized to retrieve data.
[0246] In some embodiments, the verifier (e.g., a natural person or a part of the verification application) can verify the binding between the holder and the transmitted user attributes and credentials. For example, a visual check is performed by a person, electronic and visual images are compared with the holder, or a fingerprint is collected by a fingerprint reading device as a part of the verification application, as shown in the relationship and In some embodiments, the binary data of the visual image of the holder can be considered as a static identifier, which allows linking in all uses of the mdoc application and the identity when the data is exposed to the verifier.
[0247] In some embodiments, the system architecture allows the mdoc application to run offline since the user attributes and credentials are completely managed by the mdoc application, including the SAA application. The system architecture also allows the offline running of the verification application if real-time validity checks are not required by the verification application. Thus, in such offline cases, the verification service can also be part of the verification application or verifier device. In some embodiments, the system architecture includes the verification application, the verification service, and the mdoc application, the interfaces are OP-1, OP-2, and OP-3 in FIG. 10. The verification service of the system architecture provides the means to verify the validity of a certain credential, which can be run in a separate service or in a single service.
[0248] In some embodiments, the live identity recognition includes live identity recognition with remote attribute storage, in which the running phase includes:
[0249] In response to the mdoc application and the verification application being activated, requiring the holder and / or verifier to authenticate, checking whether the verification application is authorized to retrieve data, and requesting at least one of the user attributes, user attribute retrieval, and server retrieval token information from the identity or attribute provider service;
[0250] In the case where the verification application is authorized to retrieve data, determining information required to establish a transmission channel between the identity or attribute provider service or the mdoc application and the verification application, and establishing the transmission channel according to the information;
[0251] Transferring at least one of the user attributes, user attribute retrieval, and server retrieval token information managed by the identity or attribute provider service to the verification application through the transmission channel, so that the verification application verifies at least one of the user attributes, user attribute retrieval, and server retrieval token information through the confirmation service.
[0252] Referring to FIG. 11, FIG. 11 is a system architecture diagram of live identity recognition with remote attribute storage in embodiments of the present application. As shown in FIG. 11, the system architecture shown in FIG. 11 specifies a similar system architecture as described in FIG. 10, but the user attributes and credentials are managed by the identity or attribute provider service. The request of the verification application for user attributes, see interface OP-1 in FIG. 11, is forwarded to the identity or attribute provider service by the mdoc application after the holder's authorization and authentication, and the service then releases the user attributes and credentials to the verification application. The communication can be direct, see interface OP-5 in FIG. 11, or indirect through the mdoc application, see interface OP-4 in FIG. 11. As the architecture shown in FIG. 11, there are more options for this architecture.
[0253] In some embodiments, if the verification application needs to be authenticated, the verification application can be authenticated by an identity or attribute provider service, which can check whether the verification application is authorized to retrieve data or has a server to retrieve a token before issuing data. The authentication and authorization check can also be processed by the mdoc application before forwarding the request to the identity or attribute provider service.
[0254] In some embodiments, the system architecture requires the mdoc application or the verification application to be online. In the case of direct communication between the verification application and the identity or attribute provider service, the online connection of the verification application is required. If the verification application does not need real-time validity check and chooses indirect communication with the identity or attribute provider service, the system architecture allows offline operation of the verification application, but requires the mdoc application to be online. In the offline case, the verification service can also be part of the verification application or the verifier device. In some embodiments, the system architecture includes a verification application, an identity or attribute provider service and an mdoc application, the relationship is OP-3 in Figure 11. In some embodiments, the verification service of the system architecture can be run by a separate service or a single service. It includes the relationship OP-3 in Figure 11.
[0255] In some embodiments, the remote identity recognition includes a remote identity recognition with local attribute storage, and in the process of the remote identity recognition with local attribute storage, the running stage includes:
[0256] In response to the mdoc application and the verification application being activated, requiring the holder and / or the verifier to be authenticated, and receiving request information and checking whether the verification application is authorized to retrieve data according to the request information, wherein the verifier is a remote server, the request information is forwarded by the verification application to the mdoc application through a browser of an external device or a mobile application or a browser in a current mobile device, and the request information includes at least one of requested user attributes, verifier information and purpose description;
[0257] In the case that the verification application is authorized to retrieve data, determining the information required for establishing a transmission channel between the mdoc application and the verification application, and establishing the transmission channel according to the information;
[0258] Transmitting at least one of the user attributes managed by the mdoc application, the user attribute retrieval and the server retrieval token information to the verification application through the transmission channel, so that the verification application verifies at least one of the user attributes, the user attribute retrieval and the server retrieval token information through a confirmation service.
[0259] Referring to FIG. 12 and FIG. 13, FIG. 12 is a schematic diagram of a remote identity system architecture with local attribute storage for a mobile browser in embodiments of the application, and FIG. 13 is a schematic diagram of a remote identity system architecture with local attribute storage for an external browser in embodiments of the application. In the system architecture shown in FIG. 12 and FIG. 13, the verifier is a remote server that provides a service to the holder and runs a verification application. The holder accesses the service through a mobile browser or a dedicated mobile application running on the mobile device, see the relationship OP-1 in FIG. 12. and Upon request and identity verification by the verifier's verification application, the requested user attributes, verifier information, and purpose description are provided to the mdoc application, see interface OP-6 in FIG. 12, and submitted to the holder for authorization and attestation, see the relationship OP-2 in FIG. 12. The purpose description can include a brief explanation of what the verifier is asking for the user attributes.
[0260] In some embodiments, the holder attestation, i.e., the binding relationship between the holder and the user attributes and credentials, is controlled by the mdoc application. The attestation mechanism can be handled by the mdoc application itself, the SA application, or other attesting entity, see the relationship OP-3 in FIG. 12.
[0261] In some embodiments, the mdoc application issues the requested and authorized user attributes and credentials to the verifier's verification application, see interface OP-7 in FIG. 12. The application verifies the received data through a verification / revocation infrastructure, see interface OP-8 in FIG. 12. Optionally, the mdoc application can attest and check the authorization of the verifier's verification application before issuing the data. The protocol for providing the attribute issuance can ensure that the attributes are issued only to the requesting verification application.
[0262] In some embodiments, as an alternative to the system architecture in FIG. 12, the holder can access the remote service through a browser running on an external device, such as a desktop computer or other mobile device. In this system architecture, see FIG. 13, a binding between the external browser session and the respective holder's mdoc application is required through local communication, see interface OP-9 in FIG. 13. In some embodiments, the system architecture includes the verification application, the browser or application, and the mdoc application, with interfaces OP-6, OP-7, OP-8, and OP-9 in FIG. 12 and FIG. 13. The verification system of this system architecture can be run by a separate service or in a single service, including interface OP-8 in FIG. 12 and FIG. 13.
[0263] In some embodiments, the remote identity includes a remote identity with remote attribute storage, and the run phase includes:
[0264] In response to the mdoc application and the verification application being activated, the holder and / or verifier are required to authenticate, and request information is received and checked to determine whether the verification application is authorized to retrieve data, and at least one of the user attributes, user attribute retrieval, and server retrieval token information is requested from an identity or attribute provider service or a remote user storage service, wherein the verifier is a remote server, the request information is forwarded to the mdoc application by the verification application through a browser of an external device or a mobile application or browser in the current mobile device, and the request information includes at least one of the requested user attributes, verifier information, and purpose description;
[0265] In the case where the verification application is authorized to retrieve data, information required to establish a transmission channel between the identity or attribute provider service or remote user storage service and the verification application is determined, and the transmission channel is established according to the information;
[0266] At least one of the user attributes, user attribute retrieval, and server retrieval token information managed by the identity or attribute provider service or remote user storage service is transmitted to the verification application through the transmission channel, so that the verification application verifies at least one of the user attributes, user attribute retrieval, and server retrieval token information through the identity or attribute provider service.
[0267] Referring to FIG. 14, FIG. 15, and FIG. 16, FIG. 14 is a schematic diagram of a remote identity system architecture with remote attribute storage and a mobile browser in an embodiment of the present application, FIG. 15 is a schematic diagram of a remote identity system architecture with remote attribute storage and an external browser in an embodiment of the present application, and FIG. 16 is a schematic diagram of a remote identity system architecture with remote user storage in an embodiment of the present application. In the system architecture shown in FIG. 14, the verifier is a remote server that provides services to the holder and runs a verification application. The holder accesses the service through a mobile browser or a dedicated mobile application running on a mobile device, as shown in the relationship and After the verification application of the verifier makes a request and the identity is identified, the requested user attributes, verifier information, and purpose description are provided to the mdoc application and submitted to the holder for approval and authentication, as shown in the relationship
[0268] In some embodiments, the request is forwarded to an identity or attribute provider service, as shown in the relationship The service provides the requested attributes to the verifier in direct communication between the verifier and the identity or attribute provider service, see interface OP-10 in Figure 14, or indirect communication, see interface OP-11 in Figure 14. In some embodiments, in a remote identity system architecture with remote attribute storage, the identity or attribute provider service is present in every transaction; thus, the identity or attribute provider service knows when the mdoc application is used and which data is shared (i.e., the data includes transaction data, user attributes, or credentials). If tracking is an issue, the identity or attribute provider service is recommended to implement safeguards, etc., to ensure that the mdoc application and holder are not tracked (e.g., the architecture presented in Figure 16).
[0269] In some embodiments, if the verification application needs to be authenticated, the mdoc application or the identity or attribute provider service can perform authentication and authorization checks on the verifier’s verification application before issuing data.
[0270] In some embodiments, unlike the system architecture described in Figure 14, the holder can access the verifier’s service through a browser running on an external device, such as a desktop computer. This system architecture, see Figure 15, requires a binding between the browser session and the mdoc application of the corresponding holder through local communication, see interface OP-9 in Figure 15.
[0271] In some embodiments, the mobile credential system can apply a remote user storage service instead of the identity or attribute provider service described in Figure 16. In this case, the holder transmits the user attributes through the mdoc application and provides the verifier with permission to access the holder’s remote user storage. The verifier can then access the holder’s remote user storage and retrieve additional user attributes, see interface OP-12 in Figure 16. The OP-9 interface in Figure 15 can also be supported in this architecture.
[0272] In some embodiments, the system architecture for remote identity includes the verification application, the identity or attribute provider service, and the mdoc application with interfaces OP-6, OP-8, OP-9, OP-10, OP-11, and OP-12 in Figures 14, 15, and 16. In some embodiments, the verification service of the system architecture can be run by a separate service or a single service, including interface OP-8 in Figures 14 and 15.
[0273] The embodiment above, through the above scheme, specifically through the detailed introduction of different attribute storage scenarios involved in the on-site identity recognition and remote identity recognition in the running stage, provides a general identity authentication mode, manages the authentication process through the mdoc application program in the mobile certificate system, is suitable for various identity recognition and authentication scenarios, and improves the universality of the electronic identity application program.
[0274] A fourth embodiment
[0275] Referring to FIG. 17, which is a schematic diagram of a system architecture for implementing on-site identity recognition with local attribute storage based on a SIM card according to a fourth embodiment, the fourth embodiment is based on any of the above embodiments. In the fourth embodiment of the present application, the same or similar content as any of the above embodiments can be referred to the above introduction, and will not be described in detail. On this basis, as shown in FIG. 17, the security features of the SIM card in the embodiment of the present application are designed to meet the functional requirements of the entire system running stage of the mobile eID system, such as mobile terminal, identity recognition business, user information storage, etc. At the same time, it can support various authentication requirements such as online and offline of mobile devices, local or remote authentication of business side, etc. The basic function framework includes several core modules such as secure channel management, life cycle control and business function processing.
[0276] In some embodiments, the functions of the SIM card include at least one of secure channel management, life cycle control, and business function processing.
[0277] In some embodiments, for the secure channel management module, the external communication methods of the SIM card include the common methods of card channel, SMS and BIP. Combined with the characteristics and use scenarios of each method, in order to improve the universality and industry compatibility of eID identity recognition business, the SIM card application supports the business processing mode of the above three methods, and designs special command processing structure and security algorithm for each channel. In some embodiments, during the data access process in the SIM card, two-way authentication is required when external data is written. Generally, the external authentication process of GP is referred to. After the external authentication is successful, a secure channel is created, and the security algorithm of the secure channel is used to perform data encryption and MAC calculation and other processing.
[0278] Referring to FIG. 18, FIG. 18 is a schematic diagram of a SIM card application service switching process in an embodiment of the present application. For the life cycle control module, to achieve safe and effective flow transfer between eID service states and to achieve application security state management, the process includes an initialization stage, an installation stage, an issuance stage, a running stage, and a removal stage. State transition generally includes automatic flow transfer and service transition. The scheme automatically switches through service instructions. The service switching process is shown in FIG. 18. Each service state can process corresponding service instructions. When the service state instructions are not met, the SIM card will perform abnormal processing and clear the security keys used in the process to ensure user data security.
[0279] In some embodiments, for the service execution module, according to the eID authentication system model, the entire service processing includes issuers and verifiers. The SIM card service processing module is designed according to the actual identity recognition service process, including service state synchronization, personal attribute information processing, and application remote management module.
[0280] In some embodiments, the service function processing includes at least one of service state synchronization, personal attribute information processing, and application remote management. The operation of the service state synchronization includes:
[0281] processing application service state machine switching by the issuer; and / or, reporting service state and service party execution service instructions to the issuer and judging service state security.
[0282] In some embodiments, the service state synchronization module mainly processes application service state machine switching by the issuer, reports service state and service party execution service instructions to the issuer, and completes service state security judgment and other functions. In the service processing process, to ensure service security, in the switching and reporting processing of all service states, the issuer uses the SIM card hardware identifier as a dispersion factor after establishing a secure channel with the SIM card, uses SM4 CBC mode to disperse the one-time process key of the issuer's exclusive security key, encrypts all service data, and completes service processing by means of the SIM card machine card, short message, or BIP.
[0283] In some embodiments, the operation of the personal attribute information processing includes:
[0284] in response to receiving a write instruction of the issuer, writing the user attribute and verifiable credential into the SIM card;
[0285] in response to receiving a verification request of the verifier, presenting the user attribute and verifiable credential through a preset linked list data structure;
[0286] in response to satisfying the issuer permission, writing the user attribute and verifiable credential updated by the issuer into the SIM card.
[0287] In some embodiments, the operation of presenting the user attribute and the verifiable credential through the preset linked list data structure further comprises:
[0288] associating the service identifier with the user verifiable credential information to obtain the linked list data structure, taking the user identity as an index.
[0289] The user verifiable credential information includes a verifiable credential type, and the verifiable credential type is configured to dynamically organize presentation information.
[0290] In some embodiments, the personal attribute information processing includes three parts: the issuer writes the personal identity information and the verifiable credential into the SIM card; the verifier reads the personal attribute information and the verifiable credential through the verifier device; and the issuer updates the personal identity information and the verifiable credential written into the SIM card. When the issuer's permission is met, the writing and updating of the user's personal attribute information can be performed.
[0291] Referring to FIG. 19, FIG. 19 is a linked list data structure diagram in the embodiment of the application. A special linked list data structure is designed for the characteristics of the SIM card, taking the user identity as an index. The user verifiable credential is associated with the service identifier to ensure that the verifiable credential is presented after the user's dynamic authorization and according to the business mode. This linked list structure ensures that all user information and verifiable credentials are stored in one copy, and the presentation information can be dynamically organized according to the credential type, improving the utilization of SIM space, data access efficiency, and flexibility of business presentation data. The data structure is shown in FIG. 19. When the verifiable credential type can support full presentation and partial presentation according to the business type, the SIM application can dynamically organize and calculate the presentation.
[0292] In some embodiments, the SIM card supports NFC, BIP and SMS methods to complete related business processing according to the verification device capability of the verifier. The SIM card defines the security of each mode specially, such as NFC mode which needs to ensure that the user can only be read when he is aware to prevent fraud. The BIP method and the SMS method can be performed according to the capability of the mobile terminal, such as BIP execution failure, and the SIM card automatically switches to the SMS mode for business processing, etc. The cooperation processing of the two modes is realized to ensure the stability of business execution.
[0293] In some embodiments, for the application remote management module, based on the eID system of the SIM card as a secure carrier, the issuer can complete the remote management of the application through the mobile operator TSM platform. The operator formulates different security strategies for different issuers, including authentication algorithms, secure channels, etc. The SIM card has the advantage over other storage media, and the SM2\SM3\SM4 algorithm is used for related security link protection.
[0294] The embodiment provides a general architecture of a SIM-based identity recognition system, and provides an implementation scheme of taking a SIM as a storage medium of user personal attributes and credential data assets in each general stage, so as to improve user attribute security. A special linked list data structure is designed by taking a user identity as an index, and a user verifiable credential is associated with a business identity. The security of the general system architecture of the eID system is improved by taking a SIM as a security carrier, compared with a software or cloud mode. The general architecture is implemented based on the characteristics of the SIM, and the security characteristics of the SIM are fully tapped to complete the whole life cycle control.
[0295] Fifth embodiment
[0296] Referring to FIG. 20, which is a schematic diagram of an authentication process based on a SIM card and having local attribute storage according to the fifth embodiment, the fifth embodiment of the present application is based on any one of the above embodiments. In the fifth embodiment of the present application, the same or similar contents as those of any one of the above embodiments can be referred to the above description, and will not be described hereinafter. On this basis, in the fifth embodiment, a field identity recognition system architecture having local attribute storage is taken as a scene, and initialization, device access and data transmission are taken as basic business flow nodes, a SIM card is taken as a security medium, and a secure channel establishment, authentication data reading and authentication implementation process are implemented. The business flowchart is shown in FIG. 20.
[0297] In some embodiments, the verifier is to electronically prove the integrity, authenticity and validity of the received user attributes and credentials. The holder is the holder of the electronic identity data, which is stored in the mdoc application of the mobile device (SIM) of the holder and managed by the mdoc application. The SIM card application is the mdoc application. The specific operation includes:
[0298] Operation 1: The verifier establishes a service link with the SIM card application (OP-1);
[0299] The verifier starts the verification device verification application The app establishes a service connection with the SIM card application (mdoc application) through three communication interface modes of NFC, SMS or BIP. According to the security algorithm of the three communication modes based on the characteristics of the SIM, the SIM card application sends a user attribute reading instruction through the secure channel.
[0300] Operation 2: The SIM card application informs the holder through a special man-machine interaction mode, and obtains the authorization of the holder The SIM card application organizes the user attribute information of the user, and sends it to the verifier device in a secure manner (OP-2);
[0301] The unique human-computer interaction mode is, for example, password input verification, access authorization confirmation and the like. The security ciphertext organization format is as follows:
[0302] 1) Calculate the current Session key: obtain the authentication protection key through the sent key index, and SM4 Encrypt (device ID + time factor, authentication protection key) to obtain Session key A;
[0303] 2) Use Session key A to encrypt user attribute information: SM4 Encrypt (device ID + time factor, authentication protection key) to obtain security ciphertext B;
[0304] 3) Sign security ciphertext B using the authentication management key: SM2 Sign (device ID + business identifier + key index + security ciphertext B) to obtain signed ciphertext C;
[0305] 4) Use the secure channel established in operation 1 to return ciphertext C to the verification device.
[0306] Operation 3: The verification device applies for a link service for attribute verification (OP-3);
[0307] The verification device sends ciphertext C to the confirmation service through a secure form such as https. The confirmation service performs the following operations: 1) Device ID white list query -> 2) Obtain the user public key through the business identifier and verify the signature of ciphertext C (the verification service stores the personal public key) -> 3) Use the key index to calculate Session key A using the device ID and time factor -> 4) Use Session key A to decrypt ciphertext B to obtain user attribute information -> Compare the user attribute information with the authorized business identifier, and return OK when consistent, otherwise return FALSE, and return the result to the verification device.
[0308] Operation 4: After the verification device obtains the authentication result, the corresponding business process is started according to the result.
[0309] The above scheme provides a "universal" architecture of a SIM-based identity recognition system, which provides an implementation scheme of using SIM as a storage medium for user personal attributes and credential data assets in each universal stage. Each business state processing of the SIM card application corresponds to a business instruction. When the business state instruction is not met, the SIM card will perform abnormal processing and clear the security key used in the process to ensure the security of user data. The build chain security mode of the verification terminal and the mobile terminal is increased to increase the diversity and convenience of business implementation and improve user experience.
[0310] Further, the application also provides an authentication device, which is applied to a mobile certificate system, and a life cycle stage of the mobile certificate system includes at least one of an initialization stage, an installation stage, an issuance stage, a running stage and a removal stage, and the device includes at least one of an initialization module, an installation module, an issuance module, a running module and a removal module.
[0311] The running module is configured to, in the running stage, in response to an mdoc application in the mobile certificate system being activated, transmit user identity identification information to a verification application, so that the verification application verifies the user identity identification information, and according to a verification result, executes a corresponding business process.
[0312] The authentication device provided by the embodiments of the application has similar implementation principles and beneficial effects to the technical solutions shown in the corresponding method embodiments described above, and thus will not be described here in detail.
[0313] Further, the application also provides a network device, which includes a memory, a processor and a computer program stored in the memory and executable on the processor, and the computer program is configured to implement the operations of the authentication method described above.
[0314] Further, the application also provides a storage medium, which is a computer readable storage medium, and the storage medium stores a computer program, and the computer program is executed by a processor to implement the operations of the authentication method described above.
[0315] It should be noted that, in this document, the term "comprising" or "including" or any other variant thereof is intended to cover non-exclusive inclusion, so that a process, method, article or system including a series of elements not only includes those elements, but also includes other elements not explicitly listed, or further includes elements inherent to such a process, method, article or system. Without more limitations, the element defined by the statement "including a" does not exclude the presence of other identical elements in the process, method, article or system including the element.
[0316] Those skilled in the art can clearly understand the above-mentioned embodiment method can be realized by means of software and the necessary general hardware platform, of course, can also be through hardware, but in many cases the former is a better embodiment. Based on such understanding, the technical solutions of the present application essentially or say the part of the prior art contribution can be embodied in the form of software products, the computer software product is stored in a storage medium (such as ROM / RAM, magnetic disc, optical disc) as described above, including a number of instructions to make a terminal device (may be a mobile phone, computer, server, or network equipment, etc.) executes the method described in various embodiments of the present application.
[0317] The above is only part of the embodiments of the present application, not therefore limit the patent scope of the present application, any equivalent structure or equivalent process transformation using the contents of the present application specification and drawings, or directly or indirectly applied in other related technical fields, are also included in the patent protection scope of the present application.
Claims
1. An authentication method, characterized in that, The method is applied to a mobile document system, the mobile document system's lifecycle includes an operational phase, and the method includes: During the operation phase, in response to the activation of the mdoc application in the mobile document system, user identification information is transmitted to the verification application for verification.
2. The method as described in claim 1, characterized in that, The lifecycle phases of the mobile document system further include at least one of an initialization phase, an installation phase, an issuance phase, and a removal phase, and the method further includes at least one of the following: During the initialization phase, at least one infrastructure component is set up, which is used in at least one of the installation phase, distribution phase, operation phase, and removal phase. During the installation phase, the mdoc application and related software are loaded and installed; During the release phase, the mdoc application is personalized. During the removal phase, the mdoc application and related software are deleted.
3. The method as described in claim 2, characterized in that, The operations of loading and installing the mdoc application and related software include: Install the mdoc application through market applications and / or pre-installation methods; Install at least one SA application in the secure zone of the SIM card through the SA application provider service.
4. The method as described in claim 3, characterized in that, The mobile document system also includes an SDK access interface, and after the operation of loading and installing the mdoc application and related software, it further includes: The mdoc application authorizes the AC access channel of the SIM card through the SDK access interface.
5. The method as described in claim 3, characterized in that, The mobile document system also includes an application state machine, which is configured to perform corresponding application state transitions according to the lifecycle phases of the mobile document system.
6. The method as described in claim 2, characterized in that, The issuance phase includes a user identification sub-phase, an mdoc application discovery sub-phase, and a data issuance sub-phase.
7. The method as described in claim 6, characterized in that, The operations in the user identification sub-stage include: User attributes are retrieved through user identification services, and the binding relationship between the holder and the user attributes is verified.
8. The method as described in claim 7, characterized in that, The operations of the discovery sub-phase of the mdoc application include: The mdoc application accesses the at least one SA application and establishes a communication channel; Perform an eligibility check on at least one of the SA applications; If the eligibility check passes, the binding relationship between the holder and the mobile device and the mdoc application is verified.
9. The method as described in claim 7, characterized in that, The operations in the data issuance sub-phase include: The user attributes are written into the SIM card, access rules and / or authentication mechanisms for the user attributes and verifiable credentials are set, and the SIM card is associated with and bound to the user's identity information through the hardware identifier of the SIM card.
10. The method as described in claim 7, characterized in that, The user identification information includes at least one of the user attributes, user attribute retrieval, and server retrieval token information.
11. The method as described in claim 10, characterized in that, The operation phase includes an initialization sub-phase, a device access sub-phase, and a data transmission sub-phase.
12. The method as described in claim 11, characterized in that, The operations of the initialization sub-phase include: In response to the activation of the mdoc application, the holder and / or validator are required to authenticate.
13. The method as described in claim 11, characterized in that, The operations in the device access sub-phase include: Determine the information required to establish a transmission channel between the mdoc application and the verification application; The transmission channel is established based on the information provided.
14. The method as described in claim 13, characterized in that, The operations of the data transmission sub-stage include: At least one of the user attributes, user attribute retrieval, and server retrieval token information is transmitted to the verification application through the transmission channel.
15. The method as described in claim 11, characterized in that, The operational phase includes on-site identity verification and / or remote identity verification.
16. The method as described in claim 15, characterized in that, The on-site identification includes on-site identification with locally stored attributes. During the on-site identification process with locally stored attributes, the operational phase includes: In response to the activation of the mdoc application and the verification application, the holder and / or verifier are required to authenticate and check whether the verification application is authorized to retrieve data. When the verification application is authorized to retrieve data, determine the information required to establish a transmission channel between the mdoc application and the verification application, and establish the transmission channel based on the information; The transmission channel transmits at least one of the user attributes, user attribute retrieval, and server retrieval token information managed by the mdoc application to the verification application, so that the verification application can verify at least one of the user attributes, user attribute retrieval, and server retrieval token information through the confirmation service.
17. The method as described in claim 15, characterized in that, The on-site identification includes on-site identification with remote attribute storage, and the operation phase of the on-site identification with remote attribute storage includes: In response to the activation of the mdoc application and the verification application, the holder and / or the verifier are required to authenticate, check whether the verification application is authorized to retrieve data, and request at least one of the user attributes, user attribute retrieval, and server retrieval token information from the identity or attribute provider service. When the verification application is authorized to retrieve data, determine the information required to establish a transmission channel between the identity or attribute provider service or the mdoc application and the verification application, and establish the transmission channel based on the information; The verification application is transmitted through the transmission channel at least one of the user attributes, user attribute retrieval, and server retrieval token information managed by the identity or attribute provider service, so that the verification application can verify at least one of the user attributes, user attribute retrieval, and server retrieval token information through the confirmation service.
18. The method as described in claim 15, characterized in that, The remote identity verification includes remote identity verification with local attribute storage. During the process of remote identity verification with local attribute storage, the operational phase includes: In response to the activation of the mdoc application and the verification application, the holder and / or verifier are required to authenticate, and a request message is received, and the verification application is checked according to the request message to see if it is authorized to retrieve data, wherein the verifier is a remote server, and the request message is forwarded by the verification application to the mdoc application through a browser on an external device or a mobile application or browser on the current mobile device, and the request message includes at least one of the requested user attributes, verifier information, and purpose description; When the verification application is authorized to retrieve data, determine the information required to establish a transmission channel between the mdoc application and the verification application, and establish the transmission channel based on the information; The transmission channel transmits at least one of the user attributes, user attribute retrieval, and server retrieval token information managed by the mdoc application to the verification application, so that the verification application can verify at least one of the user attributes, user attribute retrieval, and server retrieval token information through the confirmation service.
19. The method as described in claim 15, characterized in that, The remote identity verification includes remote identity verification with remote attribute storage, and the operational phase of the remote identity verification process with remote attribute storage includes: In response to the activation of the mdoc application and the verification application, the holder and / or verifier are required to authenticate, and a request message is received. Based on the request message, the verification application is checked to see if it is authorized to retrieve data. The verification application requests at least one of the following from the identity or attribute provider service or remote user storage service: user attribute, user attribute retrieval, and server retrieval token information. The verifier is a remote server. The request message is forwarded by the verification application to the mdoc application through a browser on an external device or a mobile application or browser on the current mobile device. The request message includes at least one of the following: the requested user attribute, verifier information, and purpose description. When the verification application is authorized to retrieve data, determine the information required to establish a transmission channel between the identity or attribute provider service or remote user storage service and the verification application, and establish the transmission channel based on the information. The verification application is transmitted through the transmission channel at least one of the user attributes, user attribute retrieval, and server retrieval token information managed by the identity or attribute provider service or remote user storage service, so that the verification application can verify at least one of the user attributes, user attribute retrieval, and server retrieval token information through the confirmation service.
20. The method according to any one of claims 3 to 19, characterized in that, The SIM card has at least one of the following functions: secure channel management, lifecycle control, and service function processing.
21. The method as described in claim 20, characterized in that, The business function processing includes at least one of business status synchronization, personal attribute information processing, and remote application management. The business status synchronization operation includes: Handling application business state machine switching performed by the issuer; and / or reporting the business status and business instructions executed by the business party to the issuer, and judging the security of the business status; The operations for processing personal attribute information include: In response to receiving a write instruction from the issuer, the user attributes and verifiable credentials are written to the SIM card; In response to receiving a verification request from a verifier, the user attributes and verifiable credentials are displayed through a preset linked list data structure; In response to satisfying the issuer's permissions, the updated user attributes and verifiable credentials of the issuer are written to the SIM card.
22. The method as described in claim 21, characterized in that, The process of presenting the user attributes and verifiable credentials using a preset linked list data structure includes the following steps before proceeding: Using the user identity identifier as an index, the business identifier is associated with the user's verifiable credential information to obtain the linked list data structure; The user-verifiable credential information includes verifiable credential types, which are configured to dynamically organize and present information.
23. An authentication device, characterized in that, The device is applied to a mobile document system, the life cycle of which includes at least one of an initialization phase, an installation phase, an issuance phase, an operation phase, and a removal phase, and the device includes at least one of an initialization module, an installation module, an issuance module, an operation module, and a removal module. The running module is configured to, during the running phase, in response to the activation of the mdoc application in the mobile document system, transmit user identification information to the verification application, so that the verification application can verify the user identification information and execute the corresponding business process based on the verification result.
24. An authentication device, characterized in that, The device includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the authentication method as described in any one of claims 1 to 22.
25. A storage medium, characterized in that, The storage medium is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by a processor, it implements the operation of the authentication method as described in any one of claims 1 to 22.
26. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, implements the authentication method as described in any one of claims 1 to 22.
Citation Information
Patent Citations
User identity authentication system based on application login
CN111581609A
Identity authentication method and device, electronic equipment and storage medium
CN113946812A
Mobile platform distributed digital identity authentication method and device and medium
CN116886357A
Authentication method, device, equipment, medium and product
CN118673484A
Verifiable credential
WO2022214773A1