WO2026002243A1 - 认证方法、装置、设备、介质及产品 - Google Patents

认证方法、装置、设备、介质及产品

Info

Publication number
WO2026002243A1
WO2026002243A1 PCT/CN2025/104764 CN2025104764W WO2026002243A1 WO 2026002243 A1 WO2026002243 A1 WO 2026002243A1 CN 2025104764 W CN2025104764 W CN 2025104764W WO 2026002243 A1 WO2026002243 A1 WO 2026002243A1
Authority
WO
WIPO (PCT)
Prior art keywords
application
mdoc
user
verification
phase
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
PCT/CN2025/104764
Other languages
English (en)
French (fr)
Inventor
果艳红
王昊
庄怀宇
董扬
巨昊
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
China Mobile Communications Group Co Ltd
China Mobile Financial Technology Co Ltd
Original Assignee
China Mobile Communications Group Co Ltd
China Mobile Financial Technology Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by China Mobile Communications Group Co Ltd, China Mobile Financial Technology Co Ltd filed Critical China Mobile Communications Group Co Ltd
Publication of WO2026002243A1 publication Critical patent/WO2026002243A1/zh
Pending legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/44—Program or device authentication
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31—User authentication
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/604—Tools and structures for managing or administering access control systems

Definitions

  • This application relates to the field of identity recognition technology, and in particular to an authentication method, apparatus, device, medium and product.
  • eID electronic IDentity, citizen network electronic identity identifier
  • eID is a citizen network electronic identity identifier issued by the "Ministry of Public Security Citizen Network Identity Recognition System" based on cryptographic technology and using a smart security chip as a carrier. It can remotely identify identities online without disclosing identity information.
  • the main purpose of this application is to provide an authentication method, apparatus, device, medium, and product, aiming to provide a universal identity authentication method and improve the universality of electronic identity applications.
  • this application provides an authentication method applied to a mobile document system, wherein the mobile document system's lifecycle includes an operational phase, and the method includes:
  • This application embodiment also provides an authentication device, which is applied to a mobile document system.
  • the life cycle stages of the mobile document system include at least one of an initialization stage, an installation stage, an issuance stage, an operation stage, and a removal stage.
  • 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.
  • This application embodiment also provides a network device, the network device including: 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 described above.
  • This application embodiment also provides a storage medium, which is a computer-readable storage medium, and stores a computer program thereon.
  • the computer program When the computer program is executed by a processor, it implements the operation of the authentication method described above.
  • This application also provides a computer program product, which includes a computer program that, when executed by a processor, implements the authentication method described above.
  • This application discloses an authentication method applied to a mobile identity document system.
  • the lifecycle of the mobile identity document system includes at least one of the following stages: initialization, installation, issuance, operation, and removal.
  • initialization in response to the activation of the mdoc application in the mobile identity document system, user identification information is transmitted to a verification application for verification.
  • verification in response to the activation of the mdoc application in the mobile identity document system, user identification information is transmitted to a verification application for verification.
  • This provides a universal identity authentication method, manages the authentication process through the mdoc application in the mobile identity document system, and is applicable to various identity authentication scenarios, improving the versatility of electronic identity applications.
  • Figure 1 is a schematic diagram of the structure of the operating device of the hardware operating environment involved in the embodiment of this application;
  • Figure 2 is a flowchart illustrating the authentication method according to the first embodiment
  • FIG. 3 is a schematic diagram of the main components of the mobile certificate system proposed in the embodiments of this application.
  • Figure 4 is a schematic diagram of the lifecycle stages of the mobile certificate system proposed in the embodiments of this application.
  • FIG. 5 is a schematic diagram of the installation architecture in an embodiment of this application.
  • Figure 6 is a schematic diagram of the general system architecture during the issuance stage in the embodiments of this application.
  • Figure 7 is a schematic diagram of the architecture for issuing local attributes and providing credentials in an embodiment of this application.
  • Figure 8 is a schematic diagram of the architecture for issuing remote attributes and providing credentials in an embodiment of this application.
  • Figure 9 is a schematic diagram of the distribution architecture with monitoring services in an embodiment of this application.
  • Figure 10 is a schematic diagram of the architecture of an on-site identity recognition system with local attribute storage in an embodiment of this application;
  • Figure 11 is a schematic diagram of the on-site identity recognition system architecture with remote attribute storage in an embodiment of this application;
  • Figure 12 is a schematic diagram of the architecture of a remote identity recognition system with local attribute storage of a mobile browser in an embodiment of this application;
  • Figure 13 is a schematic diagram of the architecture of a remote identity recognition system with local attribute storage via an external browser in an embodiment of this application;
  • Figure 14 is a schematic diagram of the architecture of a remote identity recognition system with remote attribute storage and a mobile browser in an embodiment of this application;
  • Figure 15 is a schematic diagram of the architecture of a remote identity recognition system with remote attribute storage and an external browser in an embodiment of this application;
  • Figure 16 is a schematic diagram of the architecture of a remote identity recognition system with remote user storage in an embodiment of this application;
  • Figure 17 is a schematic diagram of the architecture of an on-site identity recognition system with local attribute storage based on a SIM card, according to the fourth embodiment.
  • FIG. 18 is a schematic diagram of the SIM card application service switching process in the embodiments of this application.
  • Figure 19 is a schematic diagram of the linked list data structure in an embodiment of this application.
  • Figure 20 is a schematic diagram of an authentication process based on a SIM card with local attribute storage, according to the fifth embodiment.
  • eID Electronic IDentity
  • eID Electronic IDentity
  • mdoc applications electronic identity applications, eID-Apps
  • eID-Apps electronic identity applications
  • users can be deployed to provide many different digital ID documents. Additionally, it can reside in other eID applications on the mobile device. Furthermore, users can have multiple mobile devices with mdoc applications installed.
  • mdoc applications are used in various aspects of daily life and are a focus of different standardization activities. Because mdoc applications can reside on different types of mobile devices with varying security measures, they must be as universal as possible to be adopted by different trusted eID management variants. Therefore, it is essential to provide mechanisms and protocols that can be used with other standards to ensure interoperability and interchangeability.
  • this application provides a SIM-based identity recognition system architecture.
  • the deployment and operation of the mobile ID system are divided into different general stages.
  • an implementation scheme is provided to use the SIM as a storage medium for data assets such as user personal attributes and credentials. This fully leverages the multi-channel, multi-security algorithm, and human-computer interaction capabilities of the SIM card, providing an overall solution for the operation of the entire mobile eID identity framework.
  • mdoc application 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, regardless of whether they are stored on a mobile device, server, or external device.
  • mdoc can stand for mdoc application or mobile eID.
  • Mobile device A portable computing device that has at least the following characteristics: a) small size, 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 an independent power supply; e) includes means for interaction between the holder of the portable computing device and the device.
  • Mobile devices may also include voice communication capabilities, onboard sensors that allow the device to collect information, and/or extended computing functions and connectivity. For example, mobile communication terminals, tablet computers, and e-readers are all mobile devices.
  • Entity type characteristics or features of an entity.
  • address information e.g., phone number, permissions, MAC address, and domain name are all possible attributes.
  • Attribute statement A statement or assertion that describes a user attribute, including predicates on the attribute.
  • Authentication Providing assurance about the identity of an entity.
  • Authentication protocol A sequence of messages defined between an entity and a validator that enables the validator to authenticate the entity.
  • Credentials Data sets presented as evidence of claimed or asserted identity and/or rights. For example, user attributes signed by the issuer serve as proof of authenticity and can be verified by the service provider through a verified electronic signature.
  • Entities are an item that is related to the operation of a certain domain and has obvious identifiability within that domain. Entities can have physical or logical manifestations, such as: individuals, organizations, devices, a group of such items, telecommunications users, SIM cards, passports, network interface cards, software applications, services, or websites.
  • Discovery service A service that runs during the distribution phase and verifies the characteristics of an mdoc application through the mdoc application capability descriptor.
  • An entity that holds an mdoc application i.e., a natural person, who uses the mdoc application to implement user identification and verification applications.
  • Identification The process of distinguishing entities within a given context through a unique association of a set of descriptive parameters. For example, user attributes are descriptive parameters for the entity "holder”.
  • Identifier Data configured to distinguish an entity from other entities in a given context.
  • Identity A set of attributes associated with an entity. An entity can have multiple identities, and multiple entities can have the same identity.
  • An identity or attribute provider service receives attributes authorized by the issuer and provides these attributes to the authentication application during runtime.
  • Identity or attribute providers can be deployed as a centralized service or as a decentralized service using a holder-managed distributed ledger technology.
  • An attribute provider service provides any type of attribute, while an identity provider service makes attributes that convey identity information available.
  • ID-Provisioning Entity An entity that performs all or part of the services during the installation, distribution, and operation phases on behalf of the issuer.
  • the installation phase is the stage of the mobile credentials system, which includes loading the mdoc application and related software onto the mobile device, loading the application onto the smart mobile communication terminal, or loading the SA application (such as the Java card applet or CS card applet) into the secure area, such as the embedded secure element.
  • the mdoc application and related software onto the mobile device
  • the application onto the smart mobile communication terminal or loading the SA application (such as the Java card applet or CS card applet) into the secure area, such as the embedded secure element.
  • SA application such as the Java card applet or CS card applet
  • Issuer The entity provides available user attributes and discovery services during the issuance phase and authorizes the instantiation of the mdoc application. Note: An issuing agency can act as an issuer.
  • This phase of the mobile credentials system includes the initial issuance of user attributes or credentials, or both, into the mdoc application, and may include the reissue of qualification credentials. Note: In the literature, the issuance of user attributes and credentials is also referred to as the provision of user attributes and credentials.
  • Issuing service A service that runs during the issuance phase, providing all the data for the mobile credential, which is either stored locally in the mdoc application or in a remote identity or attribute provider service.
  • MCD attestation service A service that signs mdoc capability descriptors.
  • mdoc app provider service A web service run by the mdoc app provider during the distribution phase, controlling the distribution of mobile credentials within the mdoc app.
  • a mobile document is a set of attributes and credentials issued by one or more issuers and managed by an mdoc application.
  • a mobile document is considered a digital file.
  • An mdoc application that manages multiple mobile documents is also considered an e-wallet; the mdoc can represent the mdoc application or a mobile eID.
  • a mobile document includes an e-ID and licenses or credentials that grant the holder permissions.
  • Mobile eID System A collection of components used to manage mobile credentials and interactions.
  • the components of a mobile credential system include mdoc applications, mobile verification applications, issuance services, or verification services.
  • Monitoring service A service that operates during the distribution phase and controls all or part of the user identification service, discovery service, distribution service, or MCD authentication service.
  • On-site identification A use case for mobile authentication systems that requires local device-to-device communication between a mobile device providing an mdoc application and a authenticator device for user identification.
  • Device-to-device authentication involves a mobile device with an mdoc application and an authenticator device with an authentication application.
  • Operational phase The phase of the mobile credentials system, which includes using the mdoc application for user identification and authentication.
  • Remote identification A use case for mobile authentication systems that requires remote device-to-service communication over the internet between mobile devices and authentication applications for user identification.
  • Device-to-service authentication includes mobile devices with the mdoc application and authentication applications without an authenticator device.
  • Remote user storage service A service that manages data storage and controls data access. Authorization from the holder is required.
  • Removal phase The phase of the mobile credentials system, which includes removing the mdoc application and related software, as well as user attributes and credentials, from the mobile device.
  • SA Application An application that manages the security zone of credentials, can manage user attributes, can be configured for user identification, and can control access to user attributes.
  • SA Application Provider Service A service that installs SA applications (3.30) into the security zone via SA clients.
  • Secure memory card A non-volatile memory card format, also known as a Secure Digital (SD) card, used in portable devices with physical sizes of "raw”, “mini”, or “micro” and equipped with an encryption module.
  • SD Secure Digital
  • a secure area is an isolated internal or peripheral area of a mobile device that ensures secure data processing and storage even if the main operating system (OS) is compromised.
  • the main operating system is also known as a rich operating system or advanced operating system.
  • a secure element or trusted execution environment (TEE) serves as an internal secure area.
  • a universal integrated circuit card (UICC) is considered an additional secure area for a mobile device.
  • Server retrieval token A token that identifies the holder and moving documents, serving as an identity or attribute provider.
  • TEE Trusted Execution Environment
  • TSM Service SA application provisioning service, which allows loading and installing SA applications, such as JavaCard Applets, CS Card Applets, and Trustlets.
  • User identification service A service that operates during the issuance phase to identify the holder electronically or non-electronically, using mobile or non-mobile identification documents.
  • Validation service A service or mechanism used during runtime to determine the validity of mobile credentials. Determining validity may include checking the revocation status of the mobile credentials. For example, a credential revocation list or public key directory could be part of the validation service.
  • Verification application An application on the authenticator's device or a remote server that verifies user attributes and credentials retrieved from an mdoc application or identity or attribute provider service.
  • An mdoc application and a verification application are typically part of a mobile credentials system; an mdoc reader is defined as a device capable of retrieving mdoc data for verification purposes.
  • Verifier An entity that controls the verification application and uses it to identify users.
  • Verifier device A device that is locally connected to a mobile device that provides an mdoc application, and optionally provides a verification application.
  • a terminal connected to a mobile device is a verifier device without a verification application.
  • a mobile device that provides a verification application connected to the mobile device is a verifier device.
  • BLE Bluetooth Low Energy
  • eID Electronic Identity
  • eMRTD Electronic Machine-Readable Travel Document
  • eSE Embedded secure element
  • eUICC Embedded Universal Integrated Circuit Card
  • IDS Image Delivery Server
  • MCD Mobile Documentation Application Capability Descriptor (mdoc app capability descriptor);
  • OFL Open Firmware Loader
  • PII Personally identifiable information
  • SAAO Secure Area Attestation Object
  • TEE Trusted Execution Environment
  • FIG. 1 is a schematic diagram of the operating device structure of the hardware operating environment involved in the embodiment of this application.
  • the operating device may include: a processor 1001, such as 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 enable communication between these components.
  • the user interface 1003 may include a display screen or an input unit such as a keyboard; optionally, the user interface 1003 may also include a standard wired interface or a wireless interface.
  • the network interface 1004 may optionally include a standard wired interface or a wireless interface (such as a Wi-Fi interface).
  • the memory 1005 may be a high-speed random access memory (RAM) or a stable non-volatile memory (NVM), such as a disk drive. Alternatively, the memory 1005 may be a storage device independent of the aforementioned processor 1001.
  • FIG. 1 does not constitute a limitation on the operating equipment and may include more or fewer components than shown, or combine certain components, or have different component arrangements.
  • the memory 1005 which serves as a storage medium, may include an operating system, a data storage module, a network communication module, a user interface module, and a computer program.
  • the network interface 1004 is mainly configured for data communication with other devices;
  • the user interface 1003 is mainly configured for data interaction with the user;
  • the processor 1001 and memory 1005 in the operating device of this application can be located in the operating device, and the operating device calls the computer program stored in the memory 1005 through the processor 1001 and performs the following operations:
  • the method further includes at least one of the following:
  • 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.
  • the mdoc application is personalized.
  • the operation of loading and installing the mdoc application and related software includes:
  • the mobile document system further 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.
  • the mobile identification system further includes an application state machine configured to perform corresponding application state transitions according to the lifecycle phases of the mobile identification system.
  • the issuance phase includes a user identification sub-phase, an mdoc application discovery sub-phase, and a data issuance sub-phase.
  • the operation of the user identification sub-stage includes:
  • User attributes are retrieved through user identification services, and the binding relationship between the holder and the user attributes is verified.
  • the operation of the discovery sub-phase of the mdoc application includes:
  • the mdoc application accesses the at least one SA application and establishes a communication channel
  • the binding relationship between the holder and the mobile device and the mdoc application is verified.
  • the operations of 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 and bound with the user's identity information through the hardware identifier of the SIM card.
  • the user identification information includes at least one of the user attributes, user attribute retrieval, and server retrieval token information.
  • the operation phase includes an initialization sub-phase, a device access sub-phase, and a data transmission sub-phase.
  • the operations of the initialization sub-phase include:
  • the holder and/or validator are required to authenticate.
  • the operation of the device access sub-phase includes:
  • the transmission channel is established based on the information provided.
  • the operation of the data transmission sub-stage includes:
  • 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.
  • the operational phase includes on-site identity verification and/or remote identity verification.
  • the on-site identification includes on-site identification with local attribute storage
  • the operational phase of the on-site identification with local attribute storage includes:
  • the holder and/or verifier are required to authenticate and check whether the verification application is authorized to retrieve data.
  • the verification application 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.
  • the on-site identification includes on-site identification with remote attribute storage
  • the operational phase of the on-site identification with remote attribute storage includes:
  • the holder and/or 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.
  • the verification application 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.
  • the remote identity verification includes remote identity verification with local attribute storage
  • the operational phase of the remote identity verification with local attribute storage includes:
  • 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;
  • the verification application 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.
  • the remote identity verification includes remote identity verification with remote attribute storage
  • the operational phase of the remote identity verification with remote attribute storage includes:
  • the holder and/or verifier are required to authenticate, and a request message is received.
  • 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.
  • the verification application 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.
  • the SIM card functions include at least one of secure channel management, lifecycle control, and service function processing.
  • the business function processing includes at least one of business status synchronization, personal attribute information processing, and application remote management, wherein the business status synchronization operation includes:
  • the operations for processing personal attribute information include:
  • the user attributes and verifiable credentials are written to the SIM card;
  • the user attributes and verifiable credentials are displayed through a preset linked list data structure;
  • the updated user attributes and verifiable credentials of the issuer are written to the SIM card.
  • the operation of presenting the user attributes and verifiable credentials through a preset linked list data structure further includes:
  • 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.
  • the lifecycle phases of the mobile document system include at least one of the following: initialization phase, installation phase, issuance phase, operation phase, and removal phase.
  • the method includes:
  • the mobile identification system in this application supports one or more specified system architectures, including an mdoc application running on a mobile device for identity verification and holder authentication.
  • the verifier is an entity that provides the verification application either through a verifier device placed at a distance from the mobile device or through an online service.
  • the verifier uses issuer information and associated trustworthiness to determine the quality of the identity or authentication process.
  • the user identification information includes at least one of the user attributes, user attribute retrieval, and server retrieval token information.
  • the storage and access control of user attribute and credential data is managed by an mdoc application, an SA application, or a remote identity or attribute provider program, or a combination of these options.
  • an SA application with a hardware-supported security zone (such as one containing tamper-proof hardware components) can provide greater trust in the user identification and authentication process.
  • a mobile credentials system is an identity management system that manages identities within a specific domain.
  • the establishment of identity trust relationships across different domains allows for trust to be built during cross-domain identification and when user attributes are extrapolated from a primary domain to a secondary domain. Therefore, the processes for reissuing or updating user attributes and credentials, as well as the revocation and deletion processes and the necessary infrastructure, are all part of the mobile credentials system.
  • the mobile identification system may operate in different modes depending on the issuer's policies.
  • the main differences in architecture lie in: a) the types of user attributes bound to holders; b) the location and storage of the user attributes themselves; and c) the transmission methods 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 holder). Creating the binding is the issuer's responsibility; verifying the binding is the verifier's responsibility. A verifier running a verification application can verify this link (e.g., the verifier can compare a received electronic facial image, which is part of the user attribute, with the holder's face).
  • 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 holder's identity through their appearance during the issuance phase).
  • the verifier must have sufficient credibility in the binding established by the issuer to accept the holder as the legitimate holder of the mdoc application and the corresponding mobile identification document.
  • the modc application includes one or more SA applications.
  • the secure zone can be hardware-based, software-based, or a combination of both.
  • the mdoc application communicates with the security zone via an internal channel of the mobile device to access and process user attributes and credentials.
  • the SA application may reside on an external device (such as a contactless eID or wearable device) and communicate with the mdoc application via a local channel.
  • a physical token has electronic functionality, its physical security characteristics can be collected or interpreted by the mdoc application and can serve as additional authentication factors for the holder.
  • Issuance phase In the sub-phase user identity, they can be configured to register the holder or confirm the holder's user attributes before issuance in the sub-phase; Runtime phase: They apply to all architectures in the runtime phase to confirm the holder's identity or user attributes. They can be requested according to policies defined by the mdoc application, the issuer, or the validator running the authentication application.
  • user attributes and credentials may be managed by one or more identity or attribute provider services.
  • the mobile credentials system may include marketplace services and SA application provisioning services to install, update, or remove mdoc applications and SA applications, respectively. Any combination of the given scenarios can be designed and deployed.
  • This embodiment applies the authentication method to a mobile document system through the above scheme.
  • the life cycle of the mobile document system includes at least one of the following stages: initialization, installation, issuance, operation, and removal. Specifically, in the operation stage, 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.
  • This provides a universal identity authentication method, which manages the authentication process through the mdoc application in the mobile document system. It is applicable to various identity recognition and authentication scenarios and improves the versatility of electronic identity applications.
  • FIG 4 is a schematic diagram of the lifecycle stages of a mobile identification system proposed in this application
  • this application proposes a second embodiment based on the aforementioned first embodiment. Contents identical or similar to those in the previous embodiments in this second embodiment can be referred to the above description and will not be repeated hereafter.
  • the deployment and operation of the mobile identification system in this application based on the general system architecture of the mobile eID system, are divided into different general stages, involving different components.
  • the lifecycle of the mobile identification system includes at least one of the following: initialization stage, installation stage, issuance stage, operation stage, and removal stage.
  • the specific stages and transitions are shown in Figure 4.
  • This application addresses the general system architecture based on the mobile eID system, using a SIM card as the storage medium for user personal attributes and credentials, meeting the authentication needs of on-site or remote identity recognition between the business verification device and the user's mobile device.
  • the method further includes at least one of the following:
  • 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.
  • the mdoc application is personalized.
  • the initialization phase is a start-up phase that includes setting up one or more infrastructures required for the installation, distribution, operation, and removal phases.
  • the initialization phase implements the setup of various infrastructures required for the operation of the entire system, including the development and release of terminal apps for users to install on mobile terminals and the development and release of SIM card applications installed on the user's mobile terminal SIM card.
  • the operation of loading and installing the mdoc application and related software includes:
  • the installation phase includes all operations that prepare the mdoc application for distribution. The selection of these operations depends on the capabilities of the mdoc application. Relevant capabilities and credibility are part of the SAAO, described in the MCD, and communicated to the publisher during the distribution process.
  • the holder chooses to load and install the mdoc application through their marketplace app. The holder may learn about this mdoc application and marketplace through the publisher's portal, or the mdoc application may be pre-installed on a mobile device, with the MCD created during pre-installation or installation.
  • FIG 5 is a schematic diagram of the installation architecture in the embodiment of this application
  • the user's mobile device installs the SA application provided by the market application and the SA application provider.
  • the mdoc file is instantiated as the mobile terminal App
  • the SA application is instantiated as the SIM card application, that is, the installation of the two parts of the program, the App and the SIM card Applet, is realized.
  • the mdoc application communicates with an online MCD authentication service to initiate the binding between the mdoc application and the mobile device upon initial loading and launch of the mdoc application (see the relationship in Figure 5).
  • This binding provided by the mobile device manufacturer as part of SAAO, is based on the SA visa.
  • Information regarding further device capabilities is provided to the MCD authentication service through device functions and mdoc application functions, as shown in Figure 5.
  • the service creates an MCD, including the SAAO, and either writes the complete MCD data to the mdoc application or writes an appropriate reference to the MCD, as shown in interfaces IN-2 and IN-1 of Figure 5. In the latter case, the MCD authentication service maintains the complete MCD for online retrieval.
  • the SA application provider service allows the configuration of mdoc-specific SA applications into a security zone via an SA client application. Loading, installation, and SAAO installation are specific to the selected security zone and are outside the scope of this document; see the relationships in Figure 5. and In the initial operation, not necessarily as part of the required installation sequence, the SA application from the mdoc application provider should be provided to the SA application provider service, as shown in interface IN-3 of Figure 5.
  • the application requires the installation of its respective SA application onto the SA client already installed on the mobile device, as shown in interface IN-4 of Figure 5.
  • the SA client has administrative access to the secure zone and controls the loading and installation of the SA application.
  • the mobile eID application can begin using the SA application at the application level.
  • the mdoc application provider backend can create further authentication and provide MCD, as shown in interfaces IN-2 and IN-1 of Figure 5.
  • the mobile document system further 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.
  • the mobile identification system further includes an application state machine configured to perform corresponding application state transitions according to the lifecycle phases of the mobile identification system.
  • an SDK access interface is designed in this application embodiment.
  • the application App is authorized to access the AC channel of the SIM card, and an application state machine is added to realize the corresponding application state migration throughout the life cycle of the mobile certificate.
  • the mobile authentication system is an identity management system that includes a set of user attributes from various sources referred to as identity verification data sources. Its responsibilities in the issuance service are:
  • confidence level is determined
  • the issuance phase includes a user identification sub-phase, an mdoc application discovery sub-phase, and a data issuance sub-phase.
  • the operation of the user identification sub-stage includes:
  • User attributes are retrieved through user identification services, and the binding relationship between the holder and the user attributes is verified.
  • the operation of the discovery sub-phase of the mdoc application includes:
  • the mdoc application accesses the at least one SA application and establishes a communication channel
  • the binding relationship between the holder and the mobile device and the mdoc application is verified.
  • the operations of 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 and bound with the user's identity information through the hardware identifier of the SIM card.
  • the issuance stage has three general sub-stages: user identification sub-stage, mdoc application discovery sub-stage, and data issuance sub-stage.
  • user identification sub-stage mdoc application discovery sub-stage
  • data issuance sub-stage data issuance sub-stage.
  • a digital identity implementation framework is designed, including:
  • User identity recognition sub-stage User attribute source, user identity verification mainly determines the source of user identity writing, based on SIM card implementation method, identity attribute source is common to other methods, generally includes two parts: user personal information input and the issuing party's issuance content of personal digital identity, SIM with the operator TSM remote method implementation method has more writing methods than other methods.
  • Discovery of mdoc applications including discovery of mdoc applications, SA application inspection, release requests and verification of binding relationships.
  • the mobile terminal app program accesses the SIM Applet to obtain information about the current application, including the application version and application status, and realizes end-to-end operations for mdoc program discovery (terminal app), SA application inspection (SIM card Applet) issuance request and verification of binding relationship.
  • the attribute information required for user personal identification is written into the SIM card through a dedicated SIM secure channel method.
  • This data includes basic personal information and biometric features. Leveraging the security features of the SIM card, access rules and authentication mechanisms for attributes and credentials can be set through real-time human-machine interoperability and user-defined authorization passwords.
  • the SIM card and user identity information are associated and bound through the SIM card's unique hardware identifier (SEID), facilitating cross-terminal data migration for subsequent SIM card loss reporting, replacement, or mobile device changes.
  • SEID unique hardware identifier
  • certain stages or processes may be inapplicable during the transition period from initial issuance to updated issuance.
  • the user identification sub-phase includes the retrieval of user attributes and the verification of the holder's association with the attributes. This can be achieved through non-electronic means by the organization (e.g., by physical inspection of physical documents and by comparing facial images to verify user association) or through existing electronic identification methods, or even through mobile credentialing systems.
  • This sub-phase can also be performed after the mdoc application discovery sub-phase. Accordingly, the source of the user attributes and the issuer's policies determine the type of mdoc issued. The source of the attributes, the selection mechanism for creating credentials, and the security mechanisms used by the mdoc application together form part of the elements determining trustworthiness.
  • 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., via BLE) or remote.
  • an eligibility check should be performed to determine whether the mobile device and the mdoc application with the SA application match and meet the trustworthiness criteria of a certain policy. If the check passes, the binding between the holder and the mobile device and the mdoc application can be verified. Furthermore, the match between the holder confirmed in the user authentication sub-phase and the holder confirmed in the mdoc application discovery sub-phase can also be verified. Parts of this sub-phase can be omitted during the redistribution process. Once user authentication and mdoc application discovery are complete, user attributes and credentials are issued to the target mobile device and the mdoc application with the SA application.
  • the user identification service has identified the holder and gathered all the necessary user attributes
  • the discovery service has verified the capabilities of the mdoc application or the SA application, or both;
  • the discovery service has associated the identified holder with the mdoc application.
  • FIG 7 is a schematic diagram of the architecture of issuance with local attributes and credential provision in the embodiments of this application, as shown in Figure 7, in this stage (data issuance sub-stage): the issuance service generates credentials that are unique to each mdoc application and mobile device, as shown in interface IS-5 in Figure 7; the issuance service can directly send user attributes and credentials to the mdoc application for installation, or it can send them indirectly through the mdoc application provider service; these data are stored in the local mdoc application and security zone, as shown in interfaces IS-6 and IS-7 in Figure 7.
  • FIG 8 is a schematic diagram of the architecture for issuing remote attributes and credentials in an embodiment of this application
  • the issuer sends the data along with the mobile device and mdoc application information to the corresponding identity or attribute provider service.
  • This provider ultimately remotely stores the user attributes and credentials, and directly (see interface IS-9 in Figure 8) or indirectly through the mdoc application provider service (see interface IS-10 in Figure 8), binds the mobile device and mdoc application to the user attributes and credentials again.
  • holder identification may be required to ensure that, to a certain degree of trust, the mobile device holder is also a legitimate holder participating in the attribute issuance process, as shown in the relationship in Figures 7 and 8.
  • monitoring services can also be used to control running services.
  • the monitoring service does not interact with the mdoc application, but interacts with the user identification service, discovery service, distribution service, and MCD authentication service, as shown in Figure 9.
  • the operation phase includes an initialization sub-phase, a device access sub-phase, and a data transmission sub-phase.
  • the mdoc application and the authentication application are activated, and the holder and authenticator may be required to authenticate, respectively.
  • the mdoc application and the authentication application exchange information required to establish a secure connection. If the secure channel is successfully established, the data transmission sub-phase begins, transmitting user attributes, user attribute retrieval, and server-retrieved token information through the established transmission channel.
  • the user launches the mobile terminal app, selects the SIM card identification applet through the SIM card channel, and establishes a secure channel between the two parties through mutual authentication (such as external authentication) to enable the mobile terminal app to access user data in the SIM card.
  • mutual authentication such as external authentication
  • the operations of the initialization sub-phase include:
  • the holder and/or validator are required to authenticate.
  • the operation of the device access sub-phase includes:
  • the transmission channel is established based on the information provided.
  • the operation of the data transmission sub-stage includes:
  • 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.
  • the operational phase includes on-site identity verification and/or remote identity verification.
  • the removal phase includes deleting the mdoc application and related software, as well as user attributes and credentials, from the mobile device.
  • the removal phase is mainly responsible for deleting all related content such as the mobile terminal APP, SDK, SIM card Applet, user attributes and credentials, and reclaiming SIM card memory space.
  • This embodiment describes in detail the lifecycle of a mobile document system, including the initialization, installation, issuance, operation, and removal phases, through the above scheme. It provides a universal identity authentication method, which manages the authentication process through the mdoc application in the mobile document system. It is applicable to various identity recognition and authentication scenarios and improves the versatility of electronic identity applications.
  • This embodiment is based on any of the above embodiments and proposes a third embodiment of this application.
  • content that is the same as or similar to any of the above embodiments can be referred to the above description and will not be repeated hereafter. Based on this, this embodiment further elaborates on the on-site identity recognition and remote identity recognition scenarios during the operation phase.
  • the architecture of the on-site identification system is divided into three main sub-phases: an initialization sub-phase, a device access sub-phase, and a data transmission sub-phase.
  • the initialization sub-phase the mdoc application and the authentication application are activated, which can respectively request authentication from the holder and the authenticator.
  • the device access sub-phase the mdoc application and the authentication application exchange information required to establish a secure connection.
  • the data transmission sub-phase begins, transmitting user attributes, user attribute retrieval, and server-retrieved token information through the established transmission channel.
  • the on-site identification includes on-site identification with local attribute storage
  • the operational phase of the on-site identification with local attribute storage includes:
  • the holder and/or verifier are required to authenticate and check whether the verification application is authorized to retrieve data.
  • the verification application 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.
  • FIG 10 is a schematic diagram of the on-site identity verification system architecture with local attribute storage in an embodiment of this application, as shown in Figure 10, this embodiment adjusts the identity verification process of the physical identity card, that is, the holder presents or transfers their identity card to an official or another holder for identity verification.
  • electronic identity data is transmitted from the holder's mobile device to the verifier's verification device, and the verifier electronically proves the integrity, authenticity, and validity of the received user attributes and credentials.
  • the holder authorizes the operation and can authenticate the mdoc application, as shown in the relationship in Figure 10.
  • the mdoc application can check and verify whether the application is authorized to retrieve data.
  • a verifier e.g., a natural person or part of a verification application
  • the binary data of the holder's visual image can be considered a static identifier, which, when exposed to the verifier, allows for linking throughout the mdoc application and all uses of the identity.
  • this system architecture allows the mdoc application to run offline.
  • the system architecture also allows the verification application to run offline if it does not require real-time validity checks. Therefore, in this offline scenario, the verification service can also be part of the verification application or the verifier device.
  • the system architecture includes a verification application, a verification service, and an mdoc application, with interfaces OP-1, OP-2, and OP-3 in Figure 10.
  • the verification service of this system architecture provides the means to verify the validity of a credential and can run in a separate service or a single service.
  • the on-site identification includes on-site identification with remote attribute storage
  • the operational phase of the on-site identification with remote attribute storage includes:
  • the holder and/or 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.
  • the verification application 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.
  • FIG 11 is a schematic diagram of the on-site identity verification system architecture with remote attribute storage in an embodiment of this application
  • the system architecture shown in Figure 11 specifies a similar system architecture to that described in Figure 10, but the user attributes and credentials are managed by an identity or attribute provider service.
  • Communication can be direct, as shown in interface OP-5 in Figure 11, or indirect communication through the mdoc application, as shown in interface OP-4 in Figure 11. As shown in the architecture in Figure 11, there are many other options for this architecture.
  • the application may be authenticated by an identity or attribute provider service, which may check whether the verification application is authorized to retrieve data or has a server retrieval token before issuing data. Authentication and authorization checks may also be handled by the mdoc application before forwarding the request to the identity or attribute provider service.
  • this system architecture requires the mdoc application or authentication application to be online. When there is direct communication between the authentication application and the identity or attribute provider service, an online connection for the authentication application is required. If the authentication application does not require real-time validity checks and chooses indirect communication with the identity or attribute provider service, the system architecture allows the authentication application to run offline, but an online connection for the mdoc application is still required. In offline scenarios, the authentication service may also be part of the authentication application or the authenticator's device.
  • the system architecture includes the authentication application, the identity or attribute provider service, and the mdoc application, as shown in Figure 11.
  • the system architecture's verification service can be run by a separate service or a single service. It includes relationship OP-3 in Figure 11.
  • the remote identity verification includes remote identity verification with local attribute storage
  • the operational phase of the remote identity verification with local attribute storage includes:
  • 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;
  • the verification application 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.
  • Figure 12 is a schematic diagram of a remote identity verification system architecture with local attribute storage in a mobile browser according to an embodiment of this application
  • Figure 13 is a schematic diagram of a remote identity verification system architecture with local attribute storage in an external browser according to an embodiment of this application.
  • the verifier is a remote server that provides services to the holder and runs an 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 in Figure 12.
  • the requested user attributes, verifier information, and purpose description are provided to the mdoc application (see interface OP-6 in Figure 12) and submitted to the holder for authorization and authentication (see the relationship in Figure 12).
  • the purpose description may include a brief explanation of why the verifier is requesting user attributes.
  • holder authentication controlled by the mdoc application, verifies the binding relationship between the holder and user attributes and credentials.
  • the authentication mechanism can be handled by the mdoc application itself, the SA application, or other authentication entity factors, as shown in Figure 12.
  • the mdoc application issues the requested and authorized user attributes and credentials to the validator's verification application, as shown in interface OP-7 of Figure 12. This application verifies the received data via the verification/revocation infrastructure, as shown in interface OP-8 of Figure 12.
  • the mdoc application can authenticate and check the authorization of the validator's verification application before issuing the data. The protocol providing this attribute issuance ensures that the attributes are only issued to the requesting verification application.
  • the holder can access the remote service via a browser running on an external device (e.g., a desktop computer or other mobile device).
  • This system architecture requires binding between the external browser session and the respective holder's mdoc application via local communication, as shown in interface OP-9 of Figure 13.
  • this system architecture includes an authentication application, a browser or application, and an mdoc application, with interfaces OP-6, OP-7, OP-8, and OP-9 in Figures 12 and 13.
  • the authentication system of this system architecture can run as a separate service or within a single service, including interface OP-8 in Figures 12 and 13.
  • the remote identity verification includes remote identity verification with remote attribute storage
  • the operational phase of the remote identity verification with remote attribute storage includes:
  • the holder and/or verifier are required to authenticate, and a request message is received.
  • 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.
  • the verification application 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.
  • Figure 14 is a schematic diagram of the remote identity verification system architecture with remote attribute storage and a mobile browser in an embodiment of this application
  • Figure 15 is a schematic diagram of the remote identity verification system architecture with remote attribute storage and an external browser in an embodiment of this application
  • Figure 16 is a schematic diagram of the remote identity verification system architecture with remote user storage in an embodiment of this application.
  • the verifier is a remote server that provides services to the holder and runs the 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 relationships in Figure 14. and After the verifier's verification application makes a request and verifies the user's identity, 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 Figure 14.
  • the request is forwarded to the identity or attribute provider service, as shown in the relationship in Figure 14.
  • the service provides the requested attributes to the validator through direct communication between the validator and the identity or attribute provider service (see interface OP-10 in Figure 14) or indirect communication (see interface OP-11 in Figure 14).
  • the identity or attribute provider service in a remote identity system architecture with remote attribute storage, the identity or attribute provider service is present in every transaction; therefore, the identity or attribute provider service knows when the mdoc application is used and what data is shared (i.e., the data includes transaction data, user attributes, or credentials). If tracing is a problem, it is recommended that the identity or attribute provider service implement safeguards, etc., to ensure that the mdoc application and holder are not traced (e.g., the architecture given in Figure 16).
  • the mdoc application or identity or attribute provider service may perform authentication and authorization checks on the verifier's verification application before issuing data.
  • the holder can access the validator's service through a browser running on an external device, such as a desktop computer.
  • This system architecture shown in Figure 15, requires binding between the browser session and the corresponding holder's mdoc application via local communication, as shown in interface OP-9 of Figure 15.
  • the mobile identification system may utilize a remote user storage service instead of the identity or attribute provider service described in Figure 16.
  • the holder transmits user attributes via an mdoc application and grants permission to the authenticator to access the holder's remote user storage.
  • the authenticator can then access the holder's remote user storage and retrieve additional user attributes, as shown in interface OP-12 in Figure 16.
  • the OP-9 interface, as shown in Figure 15, can also be supported in this architecture.
  • the remote identity verification system architecture includes an authentication application, an identity or attribute provider service, and an mdoc application with interfaces OP-6, OP-8, OP-9, OP-10, OP-11, and OP-12 as shown in Figures 14, 15, and 16.
  • the authentication service of the system architecture may be run by a separate service or a single service, including interface OP-8 as shown in Figures 14 and 15.
  • This embodiment through the above scheme, specifically details the different attribute storage scenarios involved in on-site identity recognition and remote identity recognition during the operation phase, and provides a universal identity authentication method.
  • the authentication process is managed by the mdoc application in the mobile certificate system, which is applicable to various identity recognition and authentication scenarios and improves the versatility of electronic identity applications.
  • FIG 17 is a schematic diagram of the architecture of a field identity recognition system with local attribute storage based on a SIM card according to the fourth embodiment
  • this embodiment is based on any of the above embodiments and proposes the fourth embodiment of this application. Contents that are the same as or similar to any of the above embodiments in this fourth embodiment can be referred to the above description and will not be repeated hereafter.
  • this embodiment of the application designs a SIM card application functional architecture that meets the functional requirements of the entire system operation phase of the mobile eID system, including mobile terminals, identity recognition services, and user information storage. It can also support various authentication requirements such as online and offline mobile devices, and local or remote authentication on the service side.
  • the basic functional framework includes several core modules such as secure channel management, lifecycle control, and service function processing.
  • the SIM card functions include at least one of secure channel management, lifecycle control, and service function processing.
  • the SIM card's external communication methods include the SIM card channel, SMS, and BIP.
  • the SIM card application supports the service processing modes of these three methods and designs dedicated command processing structures and security algorithms for each channel.
  • two-way authentication is required when writing data externally.
  • the external authentication process of the GP is referenced. After successful external authentication, a secure channel is created, and the secure channel's security algorithm is used for data encryption and MAC calculation.
  • the lifecycle control module in order to achieve secure and efficient transition between eID service states and realize application security state management, includes the initialization phase, installation phase, issuance phase, running phase, and removal phase.
  • State transitions generally include automatic transition and service transition.
  • This scheme uses service commands for automatic switching.
  • the service switching process is shown in Figure 18.
  • Each service state can handle corresponding service commands. When a service state command is not met, the SIM card will perform exception handling and clear the security key used in the process to ensure user data security.
  • the entire business process includes issuers and verifiers.
  • the SIM card business processing module is designed with the actual identity recognition business process, including business status synchronization, personal attribute information processing and application remote management modules.
  • the business function processing includes at least one of business status synchronization, personal attribute information processing, and application remote management, wherein the business status synchronization operation includes:
  • Handle application business state machine switching performed by the issuer; and/or report the business status and business instructions executed by the business party to the issuer, and determine the security of the business status.
  • the business status synchronization module mainly handles the application business state machine switching performed by the issuer, reports the business status to the issuer, and performs business status security judgment when the business party executes business instructions.
  • the issuer uses the SIM card hardware identifier as a dispersion factor, uses the issuer's exclusive security key in SM4 CBC mode to disperse the one-time process key, encrypts all business data, and completes business processing with the help of SIM card, SMS or BIP.
  • the operations for processing personal attribute information include:
  • the user attributes and verifiable credentials are written to the SIM card;
  • the user attributes and verifiable credentials are displayed through a preset linked list data structure;
  • the updated user attributes and verifiable credentials of the issuer are written to the SIM card.
  • the operation of presenting the user attributes and verifiable credentials through a preset linked list data structure further includes:
  • 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.
  • personal attribute information processing includes three parts: the issuer writes the individual's identity information and verifiable credentials into the SIM card; the verifier reads the personal attribute information and verifiable credentials through a verifier device or other means; and the issuer updates the individual's identity information and verifiable credentials written into the SIM card. When the issuer's permissions are satisfied, the writing and updating of the user's personal attribute information can be performed.
  • a dedicated linked list data structure is designed based on the characteristics of the SIM card and using the user identity identifier as an index.
  • User verifiable credentials are associated with the service identifier to ensure that verifiable credentials are presented according to the service mode after dynamic user authorization.
  • This linked list structure ensures that all user information and verifiable credentials are stored in one copy, and the presented information can be dynamically organized according to the credential type, improving SIM space utilization, data access efficiency, and the flexibility of service data presentation.
  • the data structure is shown in Figure 19.
  • the SIM application can dynamically organize and calculate the presentation during partial presentation.
  • the SIM card supports NFC, BIP, and SMS methods to complete relevant business processing.
  • NFC NFC
  • BIP Short Streaming Protocol
  • SMS Short Streaming Protocol
  • the SIM card defines specific security measures. For example, in NFC mode, it is necessary to ensure that the device can only be read when the user is aware of it, to prevent unauthorized use.
  • BIP and SMS methods can be coordinated according to the capabilities of the mobile terminal; for example, if BIP execution fails, the SIM card automatically switches to SMS mode for business processing, thus ensuring the stability of business execution.
  • the issuer can remotely manage the application through the mobile operator's TSM platform.
  • Operators formulate different security strategies for different issuers, including authentication algorithms and secure channels. Leveraging the advantages of SIM cards over other storage media, SM2, SM3, and SM4 algorithms are used for related secure link protection.
  • This embodiment specifically provides a general architecture for a SIM-based identity recognition system.
  • it offers an implementation scheme using the SIM as a storage medium for user personal attributes and credentials, enhancing user attribute security: a dedicated linked list data structure is designed using the user's identity identifier as an index, allowing user-verifiable credentials to be associated with a business identifier; by adding the SIM as a secure carrier for the general system architecture of the eID system, security is improved compared to software or cloud-based approaches.
  • a general architecture based on SIM characteristics and fully leveraging SIM security features, full lifecycle control is achieved.
  • FIG 20 is a schematic diagram of an authentication process with local attribute storage based on a SIM card according to the fifth embodiment
  • this embodiment is based on any of the above embodiments and proposes the fifth embodiment of this application.
  • the content that is the same as or similar to any of the above embodiments can be referred to the above description and will not be repeated hereafter.
  • this embodiment takes a field identity recognition system architecture with local attribute storage as the scenario, with the initialization sub-stage, device access sub-stage, and data transmission sub-stage as the basic business flow nodes, and the SIM card as the security medium to realize the secure channel establishment, authentication data reading, and authentication implementation process.
  • the business flow diagram is shown in Figure 20.
  • the verifier is someone who electronically proves 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 and managed by the mdoc application on the holder's mobile device (SIM).
  • SIM card application is the mdoc application. Specific operations include:
  • Operation 1 The verifier establishes a service link with the SIM card application (OP-1);
  • the verifier starts the verification device to verify the application.
  • This proposal proposes that an app establishes a service connection with the SIM card application (mdoc application) via three communication interfaces: NFC, SMS, or BIP. Based on the characteristics of the SIM card, a secure channel security algorithm is implemented for these three communication methods, enabling the transmission of user attribute reading commands through the secure channel.
  • Operation 2 The SIM card application notifies the holder through a unique human-computer interaction method and obtains the holder's authorization.
  • the SIM card application will organize the user's user attribute information and send it to the authenticator device (OP-2) in a secure manner;
  • Session keyA to encrypt user attribute information: SM4 Encrypt(Device ID + Time Factor, Authentication Protection Key) to obtain secure ciphertext B;
  • Operation 3 Verify the device's attributes by applying for a connection service (OP-3);
  • the verification device sends encrypted message C to the confirmation service via HTTPS or other secure methods.
  • the confirmation service performs the following operations: 1) Device ID whitelist Query -> 2) Obtain the user's public key through the business identifier and verify the signature of ciphertext C (verification service stores personal public key) -> 3) Use the key index, device ID, and time factor to calculate Sessionkey A -> 4) Use Sessionkey A to decrypt ciphertext B and obtain user attribute information -> Compare the user attribute information with the authorized business identifier. If they match, return OK; otherwise, return FALSE and return the result to the verification device.
  • Step 4 After verifying the device and obtaining the certification result, initiate the corresponding business process based on the result.
  • This embodiment provides a "universal" architecture for a SIM-based identity recognition system through the above-described scheme. It offers an implementation scheme in each universal stage that uses the SIM as a storage medium for user personal attributes and credentials, among other data assets.
  • Each service state of the SIM card application processes corresponding service instructions. When a service state instruction is not met, the SIM card will perform exception handling and clear the security key used in the process, ensuring user data security. It also enhances the security of the connection between the verification terminal and the mobile terminal, increasing the diversity and convenience of service implementation and improving user experience.
  • this application embodiment also provides an authentication device, which is applied to a mobile document system.
  • the life cycle stages of the mobile document system include at least one of an initialization stage, an installation stage, an issuance stage, an operation stage, and a removal stage.
  • 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.
  • the authentication device provided in this application embodiment is similar in principle and beneficial effect to the technical solution shown in the corresponding method embodiment above, and will not be described again here.
  • embodiments of this application also provide a network device, the network device comprising: 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 described above.
  • this application embodiment also provides a storage medium, which is a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, it implements the operation of the authentication method described above.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • General Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • Health & Medical Sciences (AREA)
  • Automation & Control Theory (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

本申请公开了一种认证方法、装置、设备、介质及产品，涉及身份识别技术领域，所述方法应用于移动证件系统，所述移动证件系统的生存周期阶段包括运行阶段，通过在所述运行阶段，响应于所述移动证件系统中的mdoc应用程序被激活，传送用户身份识别信息至验证应用，以供所述验证应用对所述用户身份识别信息进行验证，提供了一种通用的身份认证方式，通过移动证件系统中的mdoc应用程序对认证过程进行管理，适用于各类身份识别认证场景，提高了电子身份应用程序的通用性。

Description

认证方法、装置、设备、介质及产品
相关申请的交叉引用
本申请基于2024年6月28日提交的中国专利申请202410865970.1主张其优先权，此处通过参照引入其全部的记载内容。
技术领域
本申请涉及身份识别技术领域，尤其涉及一种认证方法、装置、设备、介质及产品。
背景技术
随着互联网技术的不断发展，移动设备被广泛的应用于人们日常活动中的方方面面。在用户身份认证领域，为了减少携带各种实体身份证明给人们带来的不方便，技术人员提出了数字身份技术，eID(electronic IDentity，公民网络电子身份标识)是以密码技术为基础、智能安全芯片为载体，由“公安部公民网络身份识别系统”签发的公民网络电子身份标识，能够在不泄露身份信息的前提下在线远程识别身份。
目前，安装在用户移动设备中的电子身份应用程序(eID-Apps)可以被部署来提供许多不同的数字ID证件，但由于不同的可信eID管理变体具有多样性，导致了不同级别的安全、信任和保证，不同的软件各自采用不同的电子身份应用程序，因而缺乏一种通用的身份认证方式，以便于被不同的可信eID管理变体所采用。
上述内容仅用于辅助理解本申请的技术方案，并不代表承认上述内容是现有技术。
发明内容
本申请的主要目的在于提供一种认证方法、装置、设备、介质及产品，旨在提供一种通用的身份认证方式，提高电子身份应用程序的通用性。
为实现上述目的，本申请提供一种认证方法，所述方法应用于移动证件系统，所述移动证件系统的生存周期阶段包括运行阶段，所述方法包括：
在所述运行阶段，响应于所述移动证件系统中的mdoc应用程序被激活，传送用户身份识别信息至验证应用，以供所述验证应用对所述用户身份识别信息进行验证。
本申请实施例还提供一种认证装置，所述装置应用于移动证件系统，所述移动证件系统的生存周期阶段包括初始化阶段、安装阶段、发行阶段、运行阶段以及移除阶段中的至少一项，所述装置包括初始化模块、安装模块、发行模块、运行模块以及移除模块中的至少一项；
所述运行模块，被配置为在所述运行阶段，响应于所述移动证件系统中的mdoc应用程序被激活，传送用户身份识别信息至验证应用，以供所述验证应用对所述用户身份识别信息进行验证，并根据验证结果执行对应的业务流程。
本申请实施例还提供一种网络设备，所述网络设备包括：存储器、处理器及存储在所述存储器上并可在所述处理器上运行的计算机程序，所述计算机程序配置为实现如上所述的认证方法的操作。
本申请实施例还提供一种存储介质，所述存储介质为计算机可读存储介质，所述存储介质上存储有计算机程序，所述计算机程序被处理器执行时实现如上所述的认证方法的操作。
本申请实施例还提供一种计算机程序产品，所述计算机程序产品包括计算机程序，所述计算机程序被处理器执行时实现如上所述的认证方法的操作。
本申请实施例公开了一种认证方法，所述方法应用于移动证件系统，所述移动证件系统的生存周期阶段包括初始化阶段、安装阶段、发行阶段、运行阶段以及移除阶段中的至少一项，通过在所述运行阶段，响应于所述移动证件系统中的mdoc应用程序被激活，传送用户身份识别信息至验证应用，以供所述验证应用对所述用户身份识别信息进行验证，提供了一种通用的身份认证方式，通过移动证件系统中的mdoc应用程序对认证过程进行管理，适用于各类身份识别认证场景，提高了电子身份应用程序的通用性。
附图说明
图1为本申请实施例方案涉及的硬件运行环境的运行设备的结构示意图；
图2为根据第一实施例示出的认证方法的流程示意图；
图3为本申请实施例提出的移动证件系统的主要组件示意图；
图4为本申请实施例提出的移动证件系统的生存周期阶段示意图；
图5为本申请实施例中的安装架构示意图；
图6为本申请实施例中的发行阶段的通用系统架构示意图；
图7为本申请实施例中的发行具有本地属性和凭证提供的架构示意图；
图8为本申请实施例中的发行具有远程属性和凭证提供的架构示意图；
图9为本申请实施例中的具有监控服务的发行架构示意图；
图10为本申请实施例中的有本地属性存储的现场身份识别系统架构示意图；
图11为本申请实施例中的具有远程属性存储的现场身份识别系统架构示意图；
图12为本申请实施例中的具有移动浏览器的本地属性存储的远程身份识别系统架构示意图；
图13为本申请实施例中的具有外部浏览器的本地属性存储的远程身份识别系统架构示意图；
图14为本申请实施例中的具有远程属性存储和移动浏览器的远程身份识别系统架构示意图；
图15为本申请实施例中的具有远程属性存储和外部浏览器的远程身份识别系统架构示意图；
图16为本申请实施例中的具有远程用户存储的远程身份识别系统架构示意图；
图17为根据第四实施例示出的基于SIM卡实现有本地属性存储的现场身份识别系统架构示意图；
图18为本申请实施例中的SIM卡应用业务切换流程示意图；
图19为本申请实施例中的链表数据结构示意图；
图20为根据第五实施例示出的基于SIM卡实现有本地属性存储的认证流程示意图。
本申请目的的实现、功能特点及优点将结合实施例，参照附图做进一步说明。
具体实施方式
应当理解，此处所描述的具体实施例仅仅用以解释本申请，并不用于限定本申请。
随着互联网技术的不断发展，移动设备被广泛的应用于人们日常活动中的方方面面。在用户身份认证领域，为了减少携带各种实体身份证明给人们带来的不方便，技术人员提出了数字身份技术，eID(electronic IDentity)全称为公民网络电子身份标识，是以密码技术为基础、智能安全芯片为载体，由“公安部公民网络身份识别系统”签发的公民网络电子身份标识，能够在不泄露身份信息的前提下在线远程识别身份。
目前，安装在用户移动设备中的mdoc应用程序(电子身份应用程序，eID-Apps)可以被部署来提供许多不同的数字ID证件。另外，它还可以驻留在移动设备上的其他eID应用程序中。此外，用户还可以拥有多个安装mdoc应用程序的移动设备。
mdoc应用程序被用于日常生活的不同领域，是不同标准化活动的重点。由于mdoc应用程序可以位于具有不同安全手段的不同形式的移动设备上，它们必须尽可能地通用，以便能够被不同的可信eID管理变体所采用。因此，非常有必要提供其他标准可使用的机制和协议，以提供互操作性和互换性。
为了解决以上问题，本申请实施例中提供一种基于SIM的身份识别系统架构，移动证件系统的部署和运行分为不同的通用阶段，在每个阶段均提供了将SIM作为用户个人属性和凭证等数据资产的存储介质的实现方案，充分发挥SIM卡的多通道、多安全算法及人机交互能力，为移动eID整个身份框架的运行提供整体解决方案。
本申请实施例中涉及的术语及定义如下：
mdoc应用程序(mdoc app)：移动设备上的应用程序，管理用户属性和凭证，被配置为电子身份管理，并控制对用户属性和凭证的访问，无论用户属性和凭证是存储在移动设备、服务器还是外部设备上。mdoc可代表mdoc应用程序或移动eID。
移动设备(mobile device)：便携式计算机设备，至少具有以下特点：a)外形小巧，可由个人轻松携带；b)设计用于在没有有线连接的情况下操作、传输和接收信息c)拥有本地的、不可拆卸的或可移动的数据存储；d)包括一个独立的电源e)包括便携式计算机设备的持有者和设备之间互动的装置。移动设备还可能包括语音通信功能、允许设备采集信息的板载传感器，和/或扩展的计算机功能和连接。例如：移动通信终端、平板计算机和电子阅读器都是移动设备。
属性(attribute)、用户属性(user attribute)：实体的特征或特性，实体类型、地址信息、电话号码、权限、MAC地址、域名都是可能的属性。
属性声明(attribute statement)：描述用户属性的声明或断言，包括对属性的谓词。
鉴别(uthentication)：为实体的身份提供保证。
鉴别协议(authentication protocol)：实体和验证者之间定义的消息序列，使验证者能够对实体进行鉴别。
凭证(credential)：作为声称或断言身份和/或权利的证据而呈现的数据集。例如，由发行人签署的用户属性，作为真实性证明是通过验证电子签名可以由服务提供者验证的凭证。
实体(entity)：与某一领域运行相关的项，在这一领域内具有明显可识别性，实体可以有物理或逻辑的体现，例如：个人、组织、设备、一组这样的项目、电信用户、SIM卡、护照、网络接口卡、软件应用、服务或网站。
发现服务(discovery service)：在发行阶段运行的服务，通过mdoc应用程序能力描述符来验证mdoc应用程序的特性。
持有者(holder)：持有mdoc应用程序的实体，即自然人，使用mdoc应用程序来实现用户身份识别验证应用。
身份识别(dentification)、用户身份识别(user identification)：通过一组描述参数的唯一关联在给定上下文中区分实体的过程。例如：用户属性是实体“持有者”的描述性参数。
标识符(identifier)：在给定上下文中，被配置为标识实体与其它实体的数据。
身份(identity)：与实体相关的属性集，一个实体可以有多个身份，多个实体可以具有相同的身份。
身份或属性提供者服务(identity or attribute provider service)：接收发行者授权的属性，并将这些属性在运行阶段提供给验证应用的服务。身份或属性提供者可以作为中心服务部署，也可以通过使用持有者管理的分布式账本技术作为非中心服务部署。一个属性提供者服务提供任何类型的属性，一个身份提供者服务使传达身份信息的属性可用。
ID提供实体(D-Provisioning Entity)：代表发行者实施安装阶段、发行阶段和运行阶段的全部或部分服务的实体。
安装阶段(installation phase)：移动证件系统的阶段，包括将mdoc应用程序和相关软件加载到移动设备上，将应用程序加载到智能移动通信终端上或将SA应用程序(如Java卡小程序、CS卡小程序)加载到安全区域，如嵌入式安全元件，是安装阶段的一部分。
发行者(issuer)：实体在发行阶段提供可用的用户属性和发现服务，并且授权mdoc应用程序的实例化。注：发行机构可以充当发行者。
发行阶段(issuing phase)：移动证件系统的阶段，包括最初发行的用户属性或凭证或两者都进入mdoc应用程序，并可以包括重新发行资格凭证。注：在文献中，用户属性和凭证的发行也被称为用户属性和凭证的提供。
发行服务(issuing service)：在发行阶段运行的服务，提供移动证件的所有数据，这些数据要么储存在本地的mdoc应用程序，要么储存在远程的身份或属性提供者服务。
MCD鉴证服务(MCD attestation service)：签署mdoc能力描述符的服务。
mdoc应用程序提供者服务(mdoc app provider service)：由mdoc应用程序提供者在发行阶段运行的网络服务，控制移动证件在mdoc应用程序中的发行。
移动证件(mobile document)：由一个或多个发行者发行的属性和凭证集合，提供给mdoc应用程序进行管理。一个移动证件被认为是一个数字文件。一个管理多个移动证件的mdoc应用程序也被认为是一个电子钱包，mdoc可以代表mdoc应用程序或移动eID。例如：移动证件包括电子ID和赋予持有者权限的许可证或凭证。
移动证件系统(mobile document system)。
移动eID系统(mobile eID-System)：用来管理移动证件、交互的组件集合，例如：移动证件系统的组成部分是mdoc应用程序、移动验证应用、发行服务或验证服务。
监控服务(monitoring service)：在发行阶段运行的服务，控制用户身份识别服务、发现服务、发行服务或MCD鉴证服务的全部或部分。
现场身份识别(on-site identification)：移动证件系统的用例，要求提供mdoc应用程序的移动设备和验证者设备之间进行本地设备对设备的通信，以进行用户身份识别。设备对设备鉴别包含具有mdoc应用程序的移动设备和具有验证应用的验证者设备。
运行阶段(operational phase)：移动证件系统的阶段，包括使用mdoc应用程序来进行用户身份识别和鉴别。
远程身份识别(remote identification)：移动证件系统的用例，要求在移动设备和验证应用程序之间通过互联网进行远程设备到服务的通信，以进行用户身份识别。设备到服务的鉴别包括带有mdoc应用程序的移动设备和没有验证者设备的验证应用程序。
远程用户存储服务(remote user storage service)：管理数据存储和控制数据访问的服务。需要持有者的授权。
移除阶段(removal phase)：移动证件系统的阶段，包括从移动设备上删除mdoc应用程序和相关软件以及用户属性和凭证。
SA应用(SA-Application)：管理凭证的安全区的应用，可以管理用户属性，被配置为用户身份识别，并可以控制对用户属性的访问。
SA应用提供者服务(SA-Application provider service)：通过SA客户端将SA应用(3.30)安装到安全区域的服务。
安全存储卡(secure memory card)：非易失性存储卡格式，即安全数字(SD)卡，用于物理尺寸为"原始"、"迷你"或"微型"的便携式设备中，并配有加密模块。
安全区(secure area)：隔离的移动设备的内部或附属区域，即使在主操作系统(OS)被破坏时，也能确保数据的安全处理和存储。主操作系统也被称为富操作系统或高级操作系统。例如：安全元件或可信执行环境(TEE)作为一个内部安全区域。通用集成电路卡(UICC)被认为是移动设备的一个附加安全区域。
服务器检索令牌(server retrieval token)：识别持有者和移动证件的令牌，为身份或属性提供者服务。
可信执行环境(TEE，Trusted execution environmen)：移动设备的主处理器的安全区。
TSM服务(TSM-Service)：SA应用供应服务，允许加载和安装SA应用，例如：JavaCard Applets、CS Card Applets和Trustlets是SA应用。
用户身份识别服务(user identification service)：在发行阶段运行的服务，通过电子或非电子方式，以移动证件或不移动证件的方式识别持有者。
确认服务(validation service)：运行阶段的服务或机制，可以确定移动证件的有效性。有效性的确定可以包括移动证件的撤销状态。例如：凭证吊销列表或公钥目录可以是验证服务的一部分。
验证应用(mdoc阅读器)(verification application(mdoc reader)：验证者设备上的应用程序或远程服务器上的应用程序，验证用户属性和凭证从mdoc应用程序或身份或属性提供者服务中检索出来。mdoc应用程序和一个验证应用程序通常是移动证件系统的一部分；mdoc阅读器被定义为能够为验证目的检索mdoc数据的设备。
验证者(verifier)：实体，控制验证应用，并使用它来进行用户身份识别。
验证者设备(verifier device)：与提供mdoc应用程序的移动设备本地连接的设备，并可选择提供验证应用程序。例如：与移动设备联接的终端是没有验证应用的验证者设备。提供通过与移动设备联接的验证应用的移动设备是验证者设备。
本申请实施例中涉及的缩略语如下：
BLE：低功耗蓝牙(Bluetooth Low Energy)；
eID：电子身份(Electronic identity)；
eMRTD：电子机读旅行证件(electronic Machine-Readable Travel Document)；
eSE：嵌入式安全元件(embedded secure element)；
eUICC：嵌入式通用集成电路卡(embedded universal integrated circuit card)；
IDS：图像传递服务器(Image Delivery Server)；
MCD：移动证件应用程序能力描述符(mdoc app capability descriptor)；
mdoc：移动证件(mobile document)；
OFL：开放式固件加载器(Open Firmware Loader)；
PII：个人可识别信息(personal identifiable information)；
SA：安全区(Secure Area)；
SAAO：安全区证明对象(Secure Area Attestation Object)；
TEE：可信执行环境(Trusted Execution Environment)；
TRE：防篡改元件(Tamper Resistant Elements)。
参照图1，图1为本申请实施例方案涉及的硬件运行环境的运行设备结构示意图。
如图1所示，该运行设备可以包括：处理器1001，例如中央处理器(Central Processing Unit，CPU)，通信总线1002、用户接口1003，网络接口1004，存储器1005。其中，通信总线1002被配置为实现这些组件之间的连接通信。用户接口1003可以包括显示屏(Display)、输入单元比如键盘(Keyboard)，可选用户接口1003还可以包括标准的有线接口、无线接口。网络接口1004可选的可以包括标准的有线接口、无线接口(如无线保真(WIreless-FIdelity，WI-FI)接口)。存储器1005可以是高速的随机存取存储器(Random Access Memory，RAM)存储器，也可以是稳定的非易失性存储器(Non-Volatile Memory，NVM)，例如磁盘存储器。存储器1005可选的还可以是独立于前述处理器1001的存储装置。
本领域技术人员可以理解，图1中示出的结构并不构成对运行设备的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置。
如图1所示，作为一种存储介质的存储器1005中可以包括操作系统、数据存储模块、网络通信模块、用户接口模块以及计算机程序。
在图1所示的运行设备中，网络接口1004主要被配置为与其他设备进行数据通信；用户接口1003主要被配置为与用户进行数据交互；本申请运行设备中的处理器1001、存储器1005可以设置在运行设备中，所述运行设备通过处理器1001调用存储器1005中存储的计算机程序，并执行以下操作：
在所述运行阶段，响应于所述移动证件系统中的mdoc应用程序被激活，传送用户身份识别信息至验证应用，以供所述验证应用对所述用户身份识别信息进行验证。
在一些实施例中，所述方法还包括以下至少一项：
在所述初始化阶段，设置至少一基础设施组件，所述至少一基础设施组件用于所述安装阶段、发行阶段、运行阶段以及移除阶段中的至少一项；
在所述安装阶段，加载和安装所述mdoc应用程序及相关软件；
在所述发行阶段，对所述mdoc应用程序进行个人化处理；
在所述移除阶段，删除所述mdoc应用程序及相关软件。
在一些实施例中，所述加载和安装所述mdoc应用程序及相关软件的操作包括：
通过市场应用和/或预安装方式安装所述mdoc应用程序；
通过SA应用提供者服务在SIM卡的安全区安装至少一SA应用。
在一些实施例中，所述移动证件系统还包括SDK访问接口，所述加载和安装所述mdoc应用程序及相关软件的操作之后还包括：
通过所述SDK访问接口进行所述mdoc应用程序对所述SIM卡的AC访问通道授权。
在一些实施例中，所述移动证件系统还包括应用状态机，所述应用状态机被配置为根据所述移动证件系统的生存周期阶段执行相应的应用状态迁移。
在一些实施例中，所述发行阶段包括用户身份识别子阶段、mdoc应用程序的发现子阶段及数据发行子阶段。
在一些实施例中，所述用户身份识别子阶段的操作包括：
通过用户身份识别服务检索得到用户属性，并对持有者与所述用户属性的绑定关系进行验证。
在一些实施例中，所述mdoc应用程序的发现子阶段的操作包括：
通过所述mdoc应用程序访问所述至少一SA应用并建立通信通道；
对所述至少一SA应用进行资格检查；
在所述资格检查通过的情况下，验证所述持有者与移动设备和所述mdoc应用程序之间的绑定关系。
在一些实施例中，所述数据发行子阶段的操作包括：
将所述用户属性写入所述SIM卡，设置所述用户属性和可验证凭证的访问规则和/或鉴别机制，并通过所述SIM卡的硬件标识进行所述SIM卡与用户身份信息的关联绑定。
在一些实施例中，所述用户身份识别信息包括所述用户属性、用户属性检索和服务器检索令牌信息中的至少一项。
在一些实施例中，所述运行阶段包括初始化子阶段、设备接入子阶段及数据传输子阶段。
在一些实施例中，所述初始化子阶段的操作包括：
响应于所述mdoc应用程序被激活，要求所述持有者和/或验证者进行鉴别。
在一些实施例中，所述设备接入子阶段的操作包括：
确定所述mdoc应用程序和验证应用之间建立传输通道所需的信息；
根据所述信息建立所述传输通道。
在一些实施例中，所述数据传输子阶段的操作包括：
通过所述传输通道传送所述用户属性、用户属性检索和服务器检索令牌信息中的至少一项至所述验证应用。
在一些实施例中，所述运行阶段包括现场身份识别和/或远程身份识别。
在一些实施例中，所述现场身份识别包括具有本地属性存储的现场身份识别，在所述具有本地属性存储的现场身份识别的过程中，所述运行阶段包括：
响应于所述mdoc应用程序和验证应用被激活，要求所述持有者和/或验证者进行鉴别，检查所述验证应用是否被授权检索数据；
在所述验证应用被授权检索数据的情况下，确定所述mdoc应用程序和验证应用之间建立传输通道所需的信息，根据所述信息建立所述传输通道；
通过所述传输通道将所述mdoc应用程序管理的用户属性、用户属性检索和服务器检索令牌信息中的至少一项传送至所述验证应用，以供所述验证应用通过确认服务对所述用户属性、用户属性检索和服务器检索令牌信息中的至少一项进行验证。
在一些实施例中，所述现场身份识别包括具有远程属性存储的现场身份识别，在所述具有远程属性存储的现场身份识别的过程中，所述运行阶段包括：
响应于所述mdoc应用程序和验证应用被激活，要求所述持有者和/或验证者进行鉴别，检查所述验证应用是否被授权检索数据，以及，向身份或属性提供者服务请求所述用户属性、用户属性检索和服务器检索令牌信息中的至少一项；
在所述验证应用被授权检索数据的情况下，确定所述身份或属性提供者服务或所述mdoc应用程序与所述验证应用之间建立传输通道所需的信息，根据所述信息建立所述传输通道；
通过所述传输通道将所述身份或属性提供者服务管理的用户属性、用户属性检索和服务器检索令牌信息中的至少一项传送至所述验证应用，以供所述验证应用通过确认服务对所述用户属性、用户属性检索和服务器检索令牌信息中的至少一项进行验证。
在一些实施例中，所述远程身份识别包括具有本地属性存储的远程身份识别，在所述具有本地属性存储的远程身份识别的过程中，所述运行阶段包括：
响应于所述mdoc应用程序和验证应用被激活，要求所述持有者和/或验证者进行鉴别，以及，接收请求信息，并根据所述请求信息检查所述验证应用是否被授权检索数据，其中，所述验证者为远程服务器，所述请求信息由所述验证应用通过外部设备的浏览器或当前的移动设备中的移动应用程序或浏览器转发至所述mdoc应用程序，所述请求信息包括所请求的用户属性、验证者信息以及目的描述中的至少一项；
在所述验证应用被授权检索数据的情况下，确定所述mdoc应用程序和验证应用之间建立传输通道所需的信息，根据所述信息建立所述传输通道；
通过所述传输通道将所述mdoc应用程序管理的用户属性、用户属性检索和服务器检索令牌信息中的至少一项传送至所述验证应用，以供所述验证应用通过确认服务对所述用户属性、用户属性检索和服务器检索令牌信息中的至少一项进行验证。
在一些实施例中，所述远程身份识别包括具有远程属性存储的远程身份识别，在所述具有远程属性存储的远程身份识别的过程中，所述运行阶段包括：
响应于所述mdoc应用程序和验证应用被激活，要求所述持有者和/或验证者进行鉴别，以及，接收请求信息，并根据所述请求信息检查所述验证应用是否被授权检索数据，以及，向身份或属性提供者服务或远程用户存储服务请求所述用户属性、用户属性检索和服务器检索令牌信息中的至少一项，其中，所述验证者为远程服务器，所述请求信息由所述验证应用通过外部设备的浏览器或当前的移动设备中的移动应用程序或浏览器转发至所述mdoc应用程序，所述请求信息包括所请求的用户属性、验证者信息以及目的描述中的至少一项；
在所述验证应用被授权检索数据的情况下，确定所述身份或属性提供者服务或远程用户存储服务和验证应用之间建立传输通道所需的信息，根据所述信息建立所述传输通道；
通过所述传输通道将所述身份或属性提供者服务或远程用户存储服务管理的用户属性、用户属性检索和服务器检索令牌信息中的至少一项传送至所述验证应用，以供所述验证应用通过确认服务对所述用户属性、用户属性检索和服务器检索令牌信息中的至少一项进行验证。
在一些实施例中，所述SIM卡的功能包括安全通道管理、生命周期控制以及业务功能处理中的至少一项。
在一些实施例中，所述业务功能处理包括业务状态同步、个人属性信息处理及应用远程管理中的至少一项，所述业务状态同步的操作包括：
处理发行者进行的应用业务状态机切换；和/或，向所述发行者上报业务状态及业务方执行业务指令，并对业务状态安全进行判断；
所述个人属性信息处理的操作包括：
响应于接收到发行者的写入指令，将所述用户属性和可验证凭证写入所述SIM卡；
响应于接收到验证者的验证请求，通过预设的链表数据结构出示所述用户属性和可验证凭证；
响应于满足发行者权限，将所述发行者更新的用户属性和可验证凭证写入所述SIM卡。
在一些实施例中，所述通过预设的链表数据结构出示所述用户属性和可验证凭证的操作之前还包括：
以用户身份标识为索引，对业务标识与用户可验证凭证信息进行关联，得到所述链表数据结构；
其中，所述用户可验证凭证信息包括可验证凭证类型，所述可验证凭证类型被配置为动态组织出示信息。
第一实施例
参照图2，图2为根据第一实施例示出的认证方法的流程示意图，所述方法应用于移动证件系统，所述移动证件系统的生存周期阶段包括初始化阶段、安装阶段、发行阶段、运行阶段以及移除阶段中的至少一项，所述方法包括：
操作S10，在所述运行阶段，响应于所述移动证件系统中的mdoc应用程序被激活，传送用户身份识别信息至验证应用，以供所述验证应用对所述用户身份识别信息进行验证。
本申请实施例中的移动证件系统支持一种或多种指定的系统架构，包括在移动设备上运行的用于身份和鉴别持有者的mdoc应用程序。验证者是一个实体，它通过放置在与移动设备有一定距离的验证者设备或通过在线服务提供验证应用。验证者使用发行者信息和相关的可信度来确定身份或鉴别过程的质量。
在一些实施例中，所述用户身份识别信息包括所述用户属性、用户属性检索和服务器检索令牌信息中的至少一项。
在一些实施例中，用户属性和凭证数据的存储和访问控制由mdoc应用程序、SA应用或远程身份或属性提供者程序或这些选项的组合来管理。使用具有硬件支持的安全区的SA应用(如包含防篡改的硬件组件)，可在用户身份识别和鉴别过程中提供更高的可信度。
在一些实施例中，移动证件系统是一个身份管理系统，对某一领域进行身份管理。通过建立的身份信任关系的不同域，允许在跨域识别过程中以及在将用户属性从主域推导到次域时建立信任。因此，用户属性和凭证的重新发行或更新以及撤销和删除的过程和所需的基础设施都是移动证件系统的一部分。
在一些实施例中，移动证件系统可以根据发行者的政策采用不同的模式运行。体系架构的区别主要在以下方面：a)绑定用户属性到持有者的种类；b)用户属性本身的位置和存储；c)用户属性和凭证的传输方式。用户绑定描述了将电子数据(即用户属性)与自然人(即持有者)联系起来的方法和强度。创建绑定是发行者的责任；验证绑定是验证者的责任。运行验证应用程序的验证者可以验证这种联系(如验证者可以将收到的作为用户属性一部分的电子脸部图像与持有者的脸部进行比较)。发行者可以在电子数据和自然人之间建立强有力的联系，作为发行过程的一部分(如发行者可以在发行阶段通过个人外表验证持有者的身份)。当可信度符合验证者的要求，验证者应对发行者建立的绑定有足够的可信度，才可以接受持有者是mdoc应用程序和相应移动证件的合法持有者。
参照图3，图3为本申请实施例提出的移动证件系统的主要组件示意图，如图3所示，modc应用程序包括一个或多个SA应用，用户属性和凭证以及被配置为持有者身份鉴别的鉴别因素(如生物特征识别因素或基于知识的因素)可在安全区内管理。安全区可以是基于硬件的或基于软件的，也可以两者兼有。
在一些实施例中，mdoc应用程序通过移动设备的内部信道与安全区进行通信，访问和处理用户属性和凭证。SA应用可以驻留在外部设备上(如非接触式eID或可穿戴设备)，并通过本地信道与mdoc应用程序进行通信。此外，无论是否具有电子功能的物理令牌，其物理安全特征可以被mdoc应用程序采集或解读，可以作为持有者的其他鉴别因素，鉴别的其他物理因素可用于以下生存周期阶段：发行阶段：在子阶段的用户身份中，它们可被配置为登记持有者或在子阶段发行前确认持有者的用户属性；运行阶段：它们适用于运行阶段的所有架构，以确认持有者的身份或用户属性。它们可以根据mdoc应用程序、发行者或运行验证应用的验证者所定义的政策来请求。
在一些实施例中，用户属性和凭证可以由一个或多个身份或属性提供者服务管理，移动证件系统可以包括市场服务和SA应用供应服务，以分别安装、更新或删除mdoc应用程序和SA应用，可设计和部署上述给定方案的任何组合。
本实施例通过上述方案，将认证方法应用于移动证件系统，所述移动证件系统的生存周期阶段包括初始化阶段、安装阶段、发行阶段、运行阶段以及移除阶段中的至少一项，具体通过在所述运行阶段，响应于所述移动证件系统中的mdoc应用程序被激活，传送用户身份识别信息至验证应用，以供所述验证应用对所述用户身份识别信息进行验证，提供了一种通用的身份认证方式，通过移动证件系统中的mdoc应用程序对认证过程进行管理，适用于各类身份识别认证场景，提高了电子身份应用程序的通用性。
第二实施例
参照图4，图4为本申请实施例提出的移动证件系统的生存周期阶段示意图，本实施例在前述第一实施例的基础上，提出本申请第二实施例，在本申请第二实施例中，与上述实施例相同或相似的内容，可以参考上文介绍，后续不再赘述。在此基础上，请参照图4，本申请中基于移动eID系统的通用系统架构，移动证件系统的部署和运行被分为不同的通用阶段，涉及不同的组件。移动证件系统的生存周期包括初始化阶段、安装阶段、发行阶段、运行阶段以及移除阶段中的至少一项，具体各阶段和过渡如图4所示，本申请面向基于移动eID系统的通用系统架构，使用SIM作为用户个人属性和凭证等数据资产的存储介质，满足业务方验证设备和用户移动设备间现场身份识别或远程身份识别的认证需求。
在一些实施例中，所述方法还包括以下至少一项：
在所述初始化阶段，设置至少一基础设施组件，所述至少一基础设施组件用于所述安装阶段、发行阶段、运行阶段以及移除阶段中的至少一项；
在所述安装阶段，加载和安装所述mdoc应用程序及相关软件；
在所述发行阶段，对所述mdoc应用程序进行个人化处理；
在所述移除阶段，删除所述mdoc应用程序及相关软件。
在一些实施例中，初始化阶段是一个开始阶段，包括安装、发行、运行和移除阶段所需的一个或多个基础设施的设置。初始化阶段将实现整个系统运行所需要的各基础设施的设置，包括用于用户安装在移动终端的终端App开发及发布、安装在用户移动终端SIM卡中的SIM卡应用的开发及发布。
在一些实施例中，所述加载和安装所述mdoc应用程序及相关软件的操作包括：
通过市场应用和/或预安装方式安装所述mdoc应用程序；
通过SA应用提供者服务在SIM卡的安全区安装至少一SA应用。
在一些实施例中，安装阶段包括使mdoc应用程序准备好发行的所有操作。这些操作的选择依赖于mdoc应用程序的能力。相关能力和可信度为SAAO的一部分，在MCD中描述，并在发行过程中传达给发行者。在安装阶段，持有者选择通过其市场应用加载和安装mdoc应用程序。持有者可以通过发行者的门户网站了解这种mdoc应用程序和市场，或者，mdoc应用程序可以预先安装在移动设备上，MCD在预安装或安装时被创建。
参照图5，图5为本申请实施例中的安装架构示意图，如图5所示，基于SIM卡的实现方案，用户移动设备通过市场应用程序和SA应用提供方提供的SA应用的安装，其中mdoc文件实例化为移动终端App、SA应用实例化为SIM卡应用，即实现App和SIM卡Applet两部分程序安装。
在一些实施例中，mdoc应用程序与在线MCD鉴证服务进行通信，以便在首次加载和启动mdoc应用程序后开始建立mdoc应用程序和移动设备之间的绑定(见图5中的关系)。该绑定作为由移动设备制造商提供的作为SAAO的一部分，其是基于SA签证的。关于进一步设备能力的信息通过设备功能和mdoc应用程序功能提供给MCD鉴证服务，见图5中的关系该服务创建包括SAAO在内的MCD，并要么完整的MCD数据写入mdoc应用程序，要么给MCD写入适当引用，见图5的接口IN-2和IN-1。在后一种情况下，MCD鉴证服务会维护完整的MCD，以便在线检索。
在一些实施例中，SA应用程序提供者服务允许通过SA客户端应用程序将特定于mdoc应用程序的SA-应用程序配置到安全区域。加载、安装以及SAAO的安装是特定于所选择的安全区域的，不在本文件的范围内，见图5中的关系和在最初的操作中，不一定是必要的安装顺序的一部分，mdoc应用程序提供者的SA应用应该被提供给SA应用提供者服务，见图5中的接口IN-3。在mdoc应用程序的安装过程中，该应用要求将各自的SA应用安装到已经安装在移动设备上的SA客户端上，见图5中的接口IN-4。SA客户端有安全区域的管理访问权，并控制SA应用的加载和安装。随着SA应用和相应的SAAO的成功安装，移动eID应用程序可以开始在应用层面上使用SA应用，mdoc应用程序提供者后台可以创建进一步的鉴证并提供MCD，见图5中的接口IN-2和IN-1。
在一些实施例中，所述移动证件系统还包括SDK访问接口，所述加载和安装所述mdoc应用程序及相关软件的操作之后还包括：
通过所述SDK访问接口进行所述mdoc应用程序对所述SIM卡的AC访问通道授权。
在一些实施例中，所述移动证件系统还包括应用状态机，所述应用状态机被配置为根据所述移动证件系统的生存周期阶段执行相应的应用状态迁移。
在一些实施例中，为保证后续身份框架的认证过程，基于SIM卡特性，本申请实施例中设计了一种SDK访问接口，在mdoc应用程序安装阶段，进行应用程序App对SIM卡的AC访问通道授权，并增加设计应用状态机，实现移动证照的生命周期完成相应的应用状态迁移。
在一些实施例中，移动证件系统是一个身份管理系统，它包括了来自多种渠道被称为身份证明数据源的用户属性集。其在发行服务中承担的责任是：
a)从一个或多个源检索用户属性；
b)验证用户属性；
c)在一些实施例中，确定可信度；
将用户属性和凭证发行到mdoc应用程序中。
在一些实施例中，所述发行阶段包括用户身份识别子阶段、mdoc应用程序的发现子阶段及数据发行子阶段。
在一些实施例中，所述用户身份识别子阶段的操作包括：
通过用户身份识别服务检索得到用户属性，并对持有者与所述用户属性的绑定关系进行验证。
在一些实施例中，所述mdoc应用程序的发现子阶段的操作包括：
通过所述mdoc应用程序访问所述至少一SA应用并建立通信通道；
对所述至少一SA应用进行资格检查；
在所述资格检查通过的情况下，验证所述持有者与移动设备和所述mdoc应用程序之间的绑定关系。
在一些实施例中，所述数据发行子阶段的操作包括：
将所述用户属性写入所述SIM卡，设置所述用户属性和可验证凭证的访问规则和/或鉴别机制，并通过所述SIM卡的硬件标识进行所述SIM卡与用户身份信息的关联绑定。
参照图6，图6为本申请实施例中的发行阶段的通用系统架构示意图，如图6所示，发行阶段有以下三个通用子阶段，用户身份识别子阶段、mdoc应用程序的发现子阶段及数据发行子阶段。基于SIM卡实现方式，以用户身份识别子阶段、mdoc应用程序的发现子阶段及数据发行子阶段为基础，设计数字身份实现框架，包括：
(1)用户身份识别子阶段：用户属性来源，用户身份验证主要确定用户身份写入的来源，基于SIM卡的实现方式，身份属性来源与其他方式通用，一般包括用户个人信息输入和发行方对于个人数字身份的发行内容两部分，SIM借助运营商TSM远程方式实现方式较其他方式存在更多的写入方式。
(2)mdoc应用程序的发现：包括mdoc程序的发现、SA应用检查、发行请求及验证绑定关系。
基于SIM卡实现方式，通过手机终端app程序，访问SIM Applet获取当前应用的信息，包括应用版本、应用状态等，实现mdoc程序发现(终端app)、SA应用检查(SIM卡Applet)发行请求及验证绑定关系的端到端的操作。
(3)数据发行子阶段：发行者属性和凭证至对应mdoc应用程序和SA应用，并设置访问规则及鉴别机制。
在一些实施例中，基于SIM卡实现方式，通过SIM专用安全通道方法将用户个人身份识别所需要的属性信息,包括个人属性、发行者属性及颁发给个人的凭证等信息写入SIM，此处数据包括个人基本信息和生物特征等；并发挥SIM卡的安全特性，可以通过人机实时互操作方式，用户设置增加授权密码等方式，设置属性和凭证的访问规则和鉴别机制，同时为加固用户身份信息使用安全，通过SIM卡唯一硬件标识SEID，进行SIM卡和用户身份信息的关联绑定，以为后续用户挂失SIM、替换SIM、更换移动设备等，完成数据的跨终端迁移。
在一些实施例中，依赖用户属性和/或凭证的生存周期状态，从开始发行到更新发行这一过渡期内，有可能一些阶段或过程是不适用的。
在一些实施例中，用户身份识别子阶段包括用户属性的检索和持有者与属性绑定的验证。这可以通过组织的非电子手段(例如，通过对实体证件的物理检查和通过比较人脸图像来验证用户绑定)或通过现有的电子识别手段，甚至通过移动证件系统来实现。这个子阶段也可以在子阶段mdoc应用程序发现之后执行。相应的，用户属性的来源及发行者政策决定了所发行mdoc的种类。属性的来源以及创建凭证的选择机制和mdoc应用程序使用的安全机制一起形成确定可信度的一部分要素。
在一些实施例中，mdoc应用程序的发现子阶段要求mdoc应用程序和发现服务之间进行电子通信，并涉及设备检测。这种通信可以是本地通信(例如通过BLE)，也可以是远程通信。在这个子阶段，应进行资格检查，以确定移动设备和带有SA应用的mdoc应用程序是否匹配并符合某种策略的可信度。如果检查通过，则可以验证持有者与移动设备和mdoc应用程序之间的绑定。此外，还可以验证在用户身份鉴别子阶段确认的持有者和在mdoc应用程序发现子阶段确认的持有者之间的匹配。在重新发行过程中可以省略此子阶段的部分内容。一旦完成用户身份鉴别和mdoc应用程序发现，就会将用户属性和凭证发行给目标移动设备以及带有SA应用的mdoc应用程序。
在一些实施例中，对于数据发行子阶段而言，在前一个子阶段(用户身份识别和mdoc应用程序发现)中，已经完成了：
a)用户身份识别服务已经识别了持有者，并集合了所有需要的用户属性；
b)发现服务已经验证了mdoc应用程序或SA应用或两者的能力；
c)在一些实施例中，发现服务已经将识别的持有者与mdoc应用程序相关联。
参照图7，图7为本申请实施例中的发行具有本地属性和凭证提供的架构示意图，如图7所示，在本阶段(数据发行子阶段)：发行服务生成对各自的mdoc应用程序和移动设备来说是唯一的凭证，见图7中的界面IS-5；发行服务可以直接将用户属性和凭证发送给mdoc应用程序进行安装，也可以通过mdoc应用程序提供者服务间接发送；这些数据被存储在本地mdoc应用程序和安全区域，见图7中的接口IS-6和IS-7。
参照图8，图8为本申请实施例中的发行具有远程属性和凭证提供的架构示意图，如图8所示，如果发行服务选择了一个身份或属性提供者服务来进行远程属性存储，那么发行者将数据与移动设备和mdoc应用程序信息一起发送给相应的身份标识或属性提供者服务。该提供者最终远程存储用户属性和凭证，并直接见图8中的界面IS-9或间接通过mdoc应用程序提供者服务，见图8中的界面IS-10，再次将移动设备和mdoc应用程序与用户属性和凭证绑定。
在一些实施例中，如果子阶段的用户身份识别或mdoc应用程序发现未提供，那么可以要求持有者身份鉴别，以确保在一定的可信度下，移动设备持有者也是参与属性发行过程的合法持有者，见图7和图8的关系。
参照图9，图9为本申请实施例中的具有监控服务的发行架构示意图，除了为安装和发行阶段指定的服务外，还可以使用监控服务来控制运行服务。监控服务不与mdoc应用程序交互，而是与用户身份识别服务、发现服务、发行服务和MCD鉴证服务交互如图9所示。
在一些实施例中，运行阶段包括初始化子阶段、设备接入子阶段及数据传输子阶段。
在一些实施例中，在初始化子阶段，mdoc应用程序和验证应用被激活，可以分别要求持有者和验证者进行鉴别。在设备接入子阶段，mdoc应用程序和验证应用程序之间交换建立安全连接所需的信息。安全通道建立成功，则进入数据传输子阶段，通过已建立的传输通道传输用户属性、用户属性检索和服务器检索令牌信息。
在一些实施例中，基于SIM卡实现方式，用户拉起移动终端app通过机卡通道选择SIM卡身份识别Applet，并通过互认证(如外部认证)双方建立安全通道，实现移动终端app对SIM卡内用户数据的访问。
在一些实施例中，所述初始化子阶段的操作包括：
响应于所述mdoc应用程序被激活，要求所述持有者和/或验证者进行鉴别。
在一些实施例中，所述设备接入子阶段的操作包括：
确定所述mdoc应用程序和验证应用之间建立传输通道所需的信息；
根据所述信息建立所述传输通道。
在一些实施例中，所述数据传输子阶段的操作包括：
通过所述传输通道传送所述用户属性、用户属性检索和服务器检索令牌信息中的至少一项至所述验证应用。
在一些实施例中，所述运行阶段包括现场身份识别和/或远程身份识别。
在一些实施例中，移除阶段包括从移动设备上删除mdoc应用程序和相关软件以及用户属性和凭证。
在一些实施例中，基于SIM卡实现方式，移除阶段主要负责删除移动终端APP、SDK、SIM卡Applet及用户属性及凭证等所有相关内容的删除，并回收SIM卡内存空间。
本实施例通过上述方案，对移动证件系统的生存周期包括初始化阶段、安装阶段、发行阶段、运行阶段以及移除阶段进行了具体描述，提供了一种通用的身份认证方式，通过移动证件系统中的mdoc应用程序对认证过程进行管理，适用于各类身份识别认证场景，提高了电子身份应用程序的通用性。
第三实施例
本实施例基于上述任一实施例，提出本申请第三实施例，在本申请第三实施例中，与上述任一实施例相同或相似的内容，可以参考上文介绍，后续不再赘述。在此基础上，本实施例中对运行阶段中的现场身份识别及远程身份识别场景进行进一步阐述。
在一些实施例中，现场身份识别系统的架构分为三个主要的子阶段：初始化子阶段、设备接入子阶段和数据传输子阶段。在初始化子阶段，mdoc应用程序和验证应用被激活，可以分别要求持有者和验证者进行鉴别。在设备接入子阶段，mdoc应用程序和验证应用程序之间交换建立安全连接所需的信息。安全通道建立成功，则进入数据传输子阶段，通过已建立的传输通道传输用户属性、用户属性检索和服务器检索令牌信息。
在一些实施例中，所述现场身份识别包括具有本地属性存储的现场身份识别，在所述具有本地属性存储的现场身份识别的过程中，所述运行阶段包括：
响应于所述mdoc应用程序和验证应用被激活，要求所述持有者和/或验证者进行鉴别，检查所述验证应用是否被授权检索数据；
在所述验证应用被授权检索数据的情况下，确定所述mdoc应用程序和验证应用之间建立传输通道所需的信息，根据所述信息建立所述传输通道；
通过所述传输通道将所述mdoc应用程序管理的用户属性、用户属性检索和服务器检索令牌信息中的至少一项传送至所述验证应用，以供所述验证应用通过确认服务对所述用户属性、用户属性检索和服务器检索令牌信息中的至少一项进行验证。
参照图10，图10为本申请实施例中的有本地属性存储的现场身份识别系统架构示意图，如图10所示，本实施例中调整了实体身份卡的身份识别过程，即持有者向官员或另一持有者出示或移交其身份卡以进行身份识别。在电子情况下，电子身份数据从持有者的移动设备传输到验证者的验证设备，而验证者则以电子方式证明收到的用户属性和凭证的完整性、真实性和有效性。在传输用户属性和凭证之前，持有者授权该运行，并可对mdoc应用程序进行鉴别，见图10中的关系mdoc应用程序可检查验证应用是否被授权检索数据。
在一些实施例中，验证者(例如，自然人或验证应用的一部分)可验证持有者和传输的用户属性和凭证之间的绑定情况。示例，通过人进行视觉检查，将电子和可视化图像与持有者进行比较，或通过用指纹读取设备采集指纹，作为验证应用的一部分，见图10中的关系和在一些实施例中，持有者的可视化图像的二进制数据可被认为是静态的标识符，当该数据暴露与验证者时，允许在mdoc应用程序和身份的所有使用中进行链接。
在一些实施例中，由于用户属性和凭证完全由mdoc应用程序管理，包括SAA应用程序，该系统架构允许mdoc应用程序离线运行。如果验证应用不需要实时有效性检查，该系统架构也允许验证应用的离线运行。因此，在这种离线情况下，验证服务也可以是验证应用或验证者设备的一部分。在一些实施例中，该系统架构包括验证应用、验证服务和mdoc应用程序，接口为图10中的OP-1、OP-2和OP-3。该系统架构的验证服务提供了验证某个凭证有效性的手段，可在单独的服务中运行，也可在单一的服务中运行。
在一些实施例中，所述现场身份识别包括具有远程属性存储的现场身份识别，在所述具有远程属性存储的现场身份识别的过程中，所述运行阶段包括：
响应于所述mdoc应用程序和验证应用被激活，要求所述持有者和/或验证者进行鉴别，检查所述验证应用是否被授权检索数据，以及，向身份或属性提供者服务请求所述用户属性、用户属性检索和服务器检索令牌信息中的至少一项；
在所述验证应用被授权检索数据的情况下，确定所述身份或属性提供者服务或所述mdoc应用程序与所述验证应用之间建立传输通道所需的信息，根据所述信息建立所述传输通道；
通过所述传输通道将所述身份或属性提供者服务管理的用户属性、用户属性检索和服务器检索令牌信息中的至少一项传送至所述验证应用，以供所述验证应用通过确认服务对所述用户属性、用户属性检索和服务器检索令牌信息中的至少一项进行验证。
参照图11，图11为本申请实施例中的具有远程属性存储的现场身份识别系统架构示意图，如图11所示，图11中给出的系统架构规定了与图10中描述的类似的系统架构，但用户属性和凭证部分由身份或属性提供者服务管理。验证应用对用户属性的请求，见图11中的接口OP-1，在得到持有者的授权和鉴别后，由mdoc应用程序将请求转发给身份或属性提供者服务，该服务之后将用户属性和凭证释放给验证应用。通信可以是直接的，见图11中的接口OP-5，或通过mdoc应用程序的间接通信，见图11中的接口OP-4。如图11给出的架构，此架构还有更多的选项。
在一些实施例中，如果需要对验证应用进行鉴别，验证应用可以由身份或属性提供者服务进行认证，该服务可以在发行数据之前检查验证应用是否被授权检索数据或有服务器检索令牌。鉴别和授权检查也可由mdoc应用程序在将请求转发到身份或属性提供者服务之前处理。
在一些实施例中，该系统架构要求mdoc应用程序或验证应用在线连接。在验证应用和身份或属性提供者服务之间直接通信的情况下，需要验证应用的在线连接。如果验证应用不需要实时有效性检查，而选择与身份或属性提供者服务的间接通信，该系统架构允许验证应用的离线运行，但需要mdoc应用程序在线连接。在离线情况下，验证服务也可是验证应用程序或验证者设备的一部分。在一些实施例中，该系统架构包括验证应用、身份或属性提供者服务和mdoc应用程序，关系为图11中的在一些实施例中，该系统架构的验证服务可以由单独的服务或单一的服务来运行。它包括图11中的关系OP-3。
在一些实施例中，所述远程身份识别包括具有本地属性存储的远程身份识别，在所述具有本地属性存储的远程身份识别的过程中，所述运行阶段包括：
响应于所述mdoc应用程序和验证应用被激活，要求所述持有者和/或验证者进行鉴别，以及，接收请求信息，并根据所述请求信息检查所述验证应用是否被授权检索数据，其中，所述验证者为远程服务器，所述请求信息由所述验证应用通过外部设备的浏览器或当前的移动设备中的移动应用程序或浏览器转发至所述mdoc应用程序，所述请求信息包括所请求的用户属性、验证者信息以及目的描述中的至少一项；
在所述验证应用被授权检索数据的情况下，确定所述mdoc应用程序和验证应用之间建立传输通道所需的信息，根据所述信息建立所述传输通道；
通过所述传输通道将所述mdoc应用程序管理的用户属性、用户属性检索和服务器检索令牌信息中的至少一项传送至所述验证应用，以供所述验证应用通过确认服务对所述用户属性、用户属性检索和服务器检索令牌信息中的至少一项进行验证。
参照图12及图13，图12为本申请实施例中的具有移动浏览器的本地属性存储的远程身份识别系统架构示意图，图13为本申请实施例中的具有外部浏览器的本地属性存储的远程身份识别系统架构示意图，在图12和图13给出的系统架构中，验证者是一个远程服务器，向持有者提供服务，并运行一个验证应用。持有者通过移动浏览器或在移动设备上运行的专用移动应用程序访问该服务，见图12中的关系和在验证者的验证应用的请求和身份识别下，所请求的用户属性、验证者信息以及目的描述被提供给mdoc应用程序见图12中的界面OP-6，并提交给持有者授权和鉴别见图12的关系目的描述可以包括简要说明验证者要求用户属性的目的是什么。
在一些实施例中，持有者鉴别，即由mdoc应用程序控制，验证持有者与用户属性和凭证之间的绑定关系。鉴别机制可以由mdoc应用程序本身、SA应用或其他鉴别的实体因素来处理，见图12中的关系
在一些实施例中，mdoc应用程序将请求和授权的用户属性和凭证发行给验证者的验证应用，见图12中的界面OP-7，该应用程序通过验证/撤销基础设施，见图12中的界面OP-8，验证收到的数据。可选的是mdoc应用程序可在发行数据之前鉴别并检查验证者的验证应用的授权。提供该属性发行的协议可以确保属性只发行给提出请求的验证应用。
在一些实施例中，作为图12中系统架构的替代方案，持有者可通过在外部设备(例如台式计算机或其他移动设备)上运行的浏览器访问远程服务。在这个系统架构中见图13，需要通过本地通信在外部浏览器会话和各自持有者的mdoc应用程序之间进行绑定见图13的接口OP-9。在一些实施例中，该系统架构包括验证应用程序、浏览器或应用和mdoc应用程序，接口为图12和图13中的OP-6、OP-7、OP-8和OP-9。该系统架构的验证系统可由单独的服务运行，也可在单一的服务中运行，包括图12和图13中的接口OP-8。
在一些实施例中，所述远程身份识别包括具有远程属性存储的远程身份识别，在所述具有远程属性存储的远程身份识别的过程中，所述运行阶段包括：
响应于所述mdoc应用程序和验证应用被激活，要求所述持有者和/或验证者进行鉴别，以及，接收请求信息，并根据所述请求信息检查所述验证应用是否被授权检索数据，以及，向身份或属性提供者服务或远程用户存储服务请求所述用户属性、用户属性检索和服务器检索令牌信息中的至少一项，其中，所述验证者为远程服务器，所述请求信息由所述验证应用通过外部设备的浏览器或当前的移动设备中的移动应用程序或浏览器转发至所述mdoc应用程序，所述请求信息包括所请求的用户属性、验证者信息以及目的描述中的至少一项；
在所述验证应用被授权检索数据的情况下，确定所述身份或属性提供者服务或远程用户存储服务和验证应用之间建立传输通道所需的信息，根据所述信息建立所述传输通道；
通过所述传输通道将所述身份或属性提供者服务或远程用户存储服务管理的用户属性、用户属性检索和服务器检索令牌信息中的至少一项传送至所述验证应用，以供所述验证应用通过确认服务对所述用户属性、用户属性检索和服务器检索令牌信息中的至少一项进行验证。
参照图14、图15及图16，图14为本申请实施例中的具有远程属性存储和移动浏览器的远程身份识别系统架构示意图，图15为本申请实施例中的具有远程属性存储和外部浏览器的远程身份识别系统架构示意图，图16为本申请实施例中的具有远程用户存储的远程身份识别系统架构示意图，在图14给出的系统架构中，验证者是一个远程服务器，向持有者提供服务，并运行验证应用。持有者通过移动浏览器或在移动设备上运行的专用移动应用程序访问该服务，见图14中的关系和在验证者的验证应用提出请求并身份识别后，所请求的用户属性、验证者信息以及目的描述提供给mdoc应用程序，并提交给持有者审批和鉴别，见图14中的关系
在一些实施例中，请求被转交给到身份或属性提供者服务，见图14中的关系该服务在验证者和身份或属性提供者服务之间的直接通信见图14中的接口OP-10或间接通信，见图14中的接口OP-11，向验证者提供请求的属性。在一些实施例中，在具有远程属性存储的远程身份识别系统架构中，身份或属性提供者服务存在于每项交易中；因此，身份或属性提供者服务知道何时使用mdoc应用程序以及共享哪些数据(即数据包括交易数据、用户属性或凭证)。如果跟踪是问题，建议身份或属性提供者服务实施防护等，以确保mdoc应用程序和持有者不被跟踪(例如，图16中给出的架构)。
在一些实施例中，若需要对验证应用进行鉴别，mdoc应用程序或身份或属性提供者服务可在发行数据之前对验证者的验证应用进行鉴别和授权检查。
在一些实施例中，与图14中描述的系统架构不同，持有者可以通过在外部设备(如台式计算机)上运行的浏览器来访问验证者的服务。该系统架构见图15，需要在浏览器会话和相应持有者的mdoc应用程序之间通过本地通信进行绑定，见图15中的接口OP-9。
在一些实施例中，移动证件系统可应用远程用户存储服务，而不是图16所述的身份或属性提供者服务。在这种情况下，持有者通过mdoc应用程序传输用户属性，并向验证者提供许可，以获得对持有者的远程用户存储的访问。然后，验证者可以访问持有者的远程用户存储，并检索额外的用户属性，见图16中的界面OP-12。OP-9接口见图15也可以在这个架构中支持。
在一些实施例中，远程身份识别的系统架构包括图14、图15和图16中具有接口OP-6、OP-8、OP-9、OP-10、OP-11和OP-12的验证应用、身份或属性提供者服务和mdoc应用程序。在一些实施例中，系统架构的验证服务可以由单独的服务或单一的服务来运行，包括图14和图15中的接口OP-8。
本实施例通过上述方案，具体通过对运行阶段所包括的现场身份识别及远程身份识别涉及的不同属性存储场景进行了详细介绍，提供了一种通用的身份认证方式，通过移动证件系统中的mdoc应用程序对认证过程进行管理，适用于各类身份识别认证场景，提高了电子身份应用程序的通用性。
第四实施例
参照图17，图17为根据第四实施例示出的基于SIM卡实现有本地属性存储的现场身份识别系统架构示意图，本实施例基于上述任一实施例，提出本申请第四实施例，在本申请第四实施例中，与上述任一实施例相同或相似的内容，可以参考上文介绍，后续不再赘述。在此基础上，如图17所示，本申请实施例中针对SIM卡的安全特性，设计能够满足移动eID系统整个系统运行阶段，移动终端、身份识别业务测、用户信息存储等功能要求的SIM卡应用功能架构，同时可以支持移动设备在线、离线，业务侧本地或远程认证等多种认证需求，基本功能框架包括安全通道管理、生命周期控制、业务功能处理几个核心模块。
在一些实施例中，所述SIM卡的功能包括安全通道管理、生命周期控制以及业务功能处理中的至少一项。
在一些实施例中，对于安全通道管理模块，SIM卡对外通信方式包括机卡通道、短信和BIP常用方式，结合每种方式特点和使用场景，为提高eID身份识别业务的通用性和行业兼容性，SIM卡应用支持上述三种方式的业务处理模式，并针对各个通道设计专用的命令处理结构和安全算法。在一些实施例中，SIM卡内数据访问过程中，外部进行数据写入时均需要进行双向认证，一般参考GP的外部认证过程，外部认证成功后，将创建成功了安全通道后，使用安全通道的安全算法，进行数据的加密和MAC计算等处理。
参照图18，图18为本申请实施例中的SIM卡应用业务切换流程示意图，对于生命周期控制模块，为实现eID业务状态间的安全有效流转，实现应用安全状态管理，包括初始化阶段、安装阶段、发行阶段、运行阶段以及移除阶段。状态的转化一般包括自动流转和业务转化两种，该方案通过业务指令进行自动切换，业务切换流程如图18所示，每个业务状态可以处理相应的业务指令，当不满足业务状态指令时，SIM卡将进行异常处理，并清除过程中使用的安全密钥，保证用户数据安全。
在一些实施例中，对于业务执行模块，根据eID认证系统模型，整个业务处理包括发行者和验证者，以实际身份识别业务流程设计SIM卡业务处理模块，包括业务状态同步、个人属性信息处理及应用远程管理模块。
在一些实施例中，所述业务功能处理包括业务状态同步、个人属性信息处理及应用远程管理中的至少一项，所述业务状态同步的操作包括：
处理发行者进行的应用业务状态机切换；和/或，向所述发行者上报业务状态及业务方执行业务指令，并对业务状态安全进行判断。
在一些实施例中，业务状态同步模块主要处理发行者进行的应用业务状态机切换，向发行方上报业务状态及业务方执行业务指令时，完成业务状态安全判断等功能，其中业务处理过程中，为保证业务安全，所有业务状态的切换和上报处理中，发行者在与SIM卡建立安全通道后，采用使用SIM卡硬件标识作为分散因子，对发行者专属安全密钥使用SM4 CBC模式分散一次性过程密钥，加密所有业务数据，借助SIM卡机卡、短信或BIP方式完成业务处理。
在一些实施例中，所述个人属性信息处理的操作包括：
响应于接收到发行者的写入指令，将所述用户属性和可验证凭证写入所述SIM卡；
响应于接收到验证者的验证请求，通过预设的链表数据结构出示所述用户属性和可验证凭证；
响应于满足发行者权限，将所述发行者更新的用户属性和可验证凭证写入所述SIM卡。
在一些实施例中，所述通过预设的链表数据结构出示所述用户属性和可验证凭证的操作之前还包括：
以用户身份标识为索引，对业务标识与用户可验证凭证信息进行关联，得到所述链表数据结构；
其中，所述用户可验证凭证信息包括可验证凭证类型，所述可验证凭证类型被配置为动态组织出示信息。
在一些实施例中，个人属性信息处理包括三个部分,发行者将个人的身份信息和可验证凭证写入SIM卡；验证者通过验证者设备等方式，读取个人属性信息和可验证凭证；发行者更新个人的身份信息和可验证凭证写入SIM卡。满足发行者权限时，可以进行用户个人属性信息的写入及更新操作。
参照图19，图19为本申请实施例中的链表数据结构示意图，针对SIM卡特性，以用户身份标识为索引，设计专用的链表数据结构，用户可验证凭证通过与业务标识关联，保证在用户动态授权后，并根据业务模式进行可验证凭证的出示，此链表结构保证所有用户信息和可验证凭证均存储一份，且根据凭证类型可动态组织出示信息，提升SIM空间利用率、数据访问效率和业务出示数据的灵活性，数据结构如图19所示。当可验证凭证类型可以根据业务类型支持全部出示和部分出示，部分出示时，SIM应用可以动态进行组织并计算出示。
在一些实施例中，针对验证方的验证设备能力，SIM卡支持NFC，BIP和短信方式完成相关业务处理，针对不同模式，SIM卡对个模式安全进行专门定义，比如，NFC模式需要保证用户只有感知时才可读取，以防止盗刷盗用。BIP方式和短信方式可按照移动终端的能力，如BIP执行失败，则SIM卡自动切换短信模式进行业务处理等方式，实现两种模式的配合处理，保证业务执行稳定性。
在一些实施例中，对于应用远程管理模块，基于SIM卡作为安全载体的eID系统，发行者可以通过移动运营商TSM平台完成应用的远程管理。运营商针对不同的发行方，制定不同的安全策略，包括认证算法、安全通道等，SIM卡较其他存储介质的优势，采用SM2\SM3\SM4算法进行相关的安全链路保护。
本实施例通过上述方案，具体通过提供一种基于SIM的身份识别系统通用架构，在每个通用阶段均提供将SIM作为用户个人属性和凭证等数据资产的存储介质的实现方案，提升用户属性安全：以用户身份标识为索引，设计专用的链表数据结构，用户可验证凭证通过与业务标识关联；通过增加SIM作为eID系统的通用系统架构的安全载体，较软件或云方式提升安全。通过基于SIM特性实现通用架构，并充分挖掘SIM安全特性，完成全生命周期控制。
第五实施例
参照图20，图20为根据第五实施例示出的基于SIM卡实现有本地属性存储的认证流程示意图，本实施例基于上述任一实施例，提出本申请第五实施例，在本申请第五实施例中，与上述任一实施例相同或相似的内容，可以参考上文介绍，后续不再赘述。在此基础上，本实施例中以具有本地属性存储的现场身份识别系统架构为场景，从初始化子阶段、设备接入子阶段和数据传输子阶段为基本业务流转节点，以SIM卡为安全介质，以实现安全通道建立、认证数据读取及认证实现过程，业务流程图如图20所示。
在一些实施例中，验证者为：以电子方式证明收到的用户属性和凭证的完整性、真实性和有效性。持有者为：电子身份数据的持有者，电子身份数据存储在持有者的移动设备中(SIM)的mdoc应用程序中，并由mdoc应用程序进行管理。SIM卡应用即为mdoc应用程序。具体操作包括：
操作1：验证者与SIM卡应用建立服务链接(OP-1)；
验证者启动验证设备验证应用用app通过NFC、短信或者BIP三种通信接口方式与SIM卡应用(mdoc应用程序)建立服务连接。本提案根据SIM特性实现三种通信方式的安全通道安全算法，借助安全通道发送读取用户属性读取指令。
操作2：SIM卡应用通过特有的人机交互方式告知持有者，得到持有者授权后SIM卡应用将组织用户的用户属性信息，以安全方式发送至验证者设备(OP-2)；
特有的人机交互方式为，如输入密码验证，访问授权确认等方式。安全密文组织格式如下：
1)计算当前Session密钥：通过发送的密钥索引，获取认证保护密钥，并SM4 Encrypt(设备ID+时间因子，认证保护密钥)，得到Session keyA；
2)使用Session keyA进行用户属性信息加密：SM4 Encrypt(设备ID+时间因子，认证保护密钥)，得到安全密文B；
3)使用认证管理密钥对安全密文B进行签名：SM2 Sign(设备ID+业务标识+密钥索引+安全密文B),得到签名密文C；
4)使用操作1建立的安全通道，将密文C返回至验证设备。
操作3：验证设备申请链接服务进行属性验证(OP-3)；
验证设备将密文C，通过https等安全形式，发送至确认服务。确认服务进行以下操作：1)设备ID白名单查询->2)通过业务标识获取用户公钥，并验证密文C签名(验证服务存储个人公钥)->3)使用密钥索引使用设备ID及时间因子，计算Sessionkey A->4)使用Sessionkey A解密密文B，得出用户属性信息->将用户属性信息与授权业务标识进行比对，当一致时返回OK，否则返回FALSE，并将结果返回验证设备。
操作4：验证设备拿到认证结果后，根据结果启动后面的相应业务流程。
本实施例通过上述方案，提供了一种基于SIM的身份识别系统“通用”架构，在每个通用阶段均提供将SIM作为用户个人属性和凭证等数据资产的存储介质的实现方案；SIM卡应用的每个业务状态处理相应的业务指令，当不满足业务状态指令时，SIM卡将进行异常处理，并清除过程中使用的安全密钥，保证用户数据安全；增加验证终端与手机终端的建链安全方式，增加业务实现多样性和便捷性，提升用户体验。
此外，本申请实施例还提供一种认证装置，所述装置应用于移动证件系统，所述移动证件系统的生存周期阶段包括初始化阶段、安装阶段、发行阶段、运行阶段以及移除阶段中的至少一项，所述装置包括初始化模块、安装模块、发行模块、运行模块以及移除模块中的至少一项；
所述运行模块，被配置为在所述运行阶段，响应于所述移动证件系统中的mdoc应用程序被激活，传送用户身份识别信息至验证应用，以供所述验证应用对所述用户身份识别信息进行验证，并根据验证结果执行对应的业务流程。
本申请实施例提供的认证装置与上述对应的方法实施例所示的技术方案，其实现原理以及有益效果类似，此处不再进行赘述。
此外，本申请实施例还提供一种网络设备，所述网络设备包括：存储器、处理器及存储在所述存储器上并可在所述处理器上运行的计算机程序，所述计算机程序配置为实现如上所述的认证方法的操作。
此外，本申请实施例还提供一种存储介质，所述存储介质为计算机可读存储介质，所述存储介质上存储有计算机程序，所述计算机程序被处理器执行时实现如上所述的认证方法的操作。
需要说明的是，在本文中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者系统不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者系统所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括该要素的过程、方法、物品或者系统中还存在另外的相同要素。
通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到上述实施例方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在如上所述的一个存储介质(如ROM/RAM、磁碟、光盘)中，包括若干指令用以使得一台终端设备(可以是手机，计算机，服务器，或者网络设备等)执行本申请各个实施例所述的方法。
以上仅为本申请的部分实施例，并非因此限制本申请的专利范围，凡是利用本申请说明书及附图内容所作的等效结构或等效流程变换，或直接或间接运用在其他相关的技术领域，均同理包括在本申请的专利保护范围内。

Claims (26)

  1. 一种认证方法，其特征在于，所述方法应用于移动证件系统，所述移动证件系统的生存周期阶段包括运行阶段，所述方法包括：
    在所述运行阶段，响应于所述移动证件系统中的mdoc应用程序被激活，传送用户身份识别信息至验证应用，以供所述验证应用对所述用户身份识别信息进行验证。
  2. 如权利要求1所述的方法，其特征在于，所述移动证件系统的生存周期阶段还包括初始化阶段、安装阶段、发行阶段、以及移除阶段中的至少一项，所述方法还包括以下至少一项：
    在所述初始化阶段，设置至少一基础设施组件，所述至少一基础设施组件用于所述安装阶段、发行阶段、运行阶段以及移除阶段中的至少一项；
    在所述安装阶段，加载和安装所述mdoc应用程序及相关软件；
    在所述发行阶段，对所述mdoc应用程序进行个人化处理；
    在所述移除阶段，删除所述mdoc应用程序及相关软件。
  3. 如权利要求2所述的方法，其特征在于，所述加载和安装所述mdoc应用程序及相关软件的操作包括：
    通过市场应用和/或预安装方式安装所述mdoc应用程序；
    通过SA应用提供者服务在SIM卡的安全区安装至少一SA应用。
  4. 如权利要求3所述的方法，其特征在于，所述移动证件系统还包括SDK访问接口，所述加载和安装所述mdoc应用程序及相关软件的操作之后还包括：
    通过所述SDK访问接口进行所述mdoc应用程序对所述SIM卡的AC访问通道授权。
  5. 如权利要求3所述的方法，其特征在于，所述移动证件系统还包括应用状态机，所述应用状态机被配置为根据所述移动证件系统的生存周期阶段执行相应的应用状态迁移。
  6. 如权利要求2所述的方法，其特征在于，所述发行阶段包括用户身份识别子阶段、mdoc应用程序的发现子阶段及数据发行子阶段。
  7. 如权利要求6所述的方法，其特征在于，所述用户身份识别子阶段的操作包括：
    通过用户身份识别服务检索得到用户属性，并对持有者与所述用户属性的绑定关系进行验证。
  8. 如权利要求7所述的方法，其特征在于，所述mdoc应用程序的发现子阶段的操作包括：
    通过所述mdoc应用程序访问所述至少一SA应用并建立通信通道；
    对所述至少一SA应用进行资格检查；
    在所述资格检查通过的情况下，验证所述持有者与移动设备和所述mdoc应用程序之间的绑定关系。
  9. 如权利要求7所述的方法，其特征在于，所述数据发行子阶段的操作包括：
    将所述用户属性写入SIM卡，设置所述用户属性和可验证凭证的访问规则和/或鉴别机制，并通过所述SIM卡的硬件标识进行所述SIM卡与用户身份信息的关联绑定。
  10. 如权利要求7所述的方法，其特征在于，所述用户身份识别信息包括所述用户属性、用户属性检索和服务器检索令牌信息中的至少一项。
  11. 如权利要求10所述的方法，其特征在于，所述运行阶段包括初始化子阶段、设备接入子阶段及数据传输子阶段。
  12. 如权利要求11所述的方法，其特征在于，所述初始化子阶段的操作包括：
    响应于所述mdoc应用程序被激活，要求所述持有者和/或验证者进行鉴别。
  13. 如权利要求11所述的方法，其特征在于，所述设备接入子阶段的操作包括：
    确定所述mdoc应用程序和验证应用之间建立传输通道所需的信息；
    根据所述信息建立所述传输通道。
  14. 如权利要求13所述的方法，其特征在于，所述数据传输子阶段的操作包括：
    通过所述传输通道传送所述用户属性、用户属性检索和服务器检索令牌信息中的至少一项至所述验证应用。
  15. 如权利要求11所述的方法，其特征在于，所述运行阶段包括现场身份识别和/或远程身份识别。
  16. 如权利要求15所述的方法，其特征在于，所述现场身份识别包括具有本地属性存储的所述现场身份识别，在所述具有本地属性存储的现场身份识别的过程中，所述运行阶段包括：
    响应于所述mdoc应用程序和验证应用被激活，要求所述持有者和/或验证者进行鉴别，检查所述验证应用是否被授权检索数据；
    在所述验证应用被授权检索数据的情况下，确定所述mdoc应用程序和所述验证应用之间建立传输通道所需的信息，根据所述信息建立所述传输通道；
    通过所述传输通道将所述mdoc应用程序管理的用户属性、用户属性检索和服务器检索令牌信息中的至少一项传送至所述验证应用，以供所述验证应用通过确认服务对所述用户属性、用户属性检索和服务器检索令牌信息中的至少一项进行验证。
  17. 如权利要求15所述的方法，其特征在于，所述现场身份识别包括具有远程属性存储的所述现场身份识别，在所述具有远程属性存储的现场身份识别的过程中，所述运行阶段包括：
    响应于所述mdoc应用程序和验证应用被激活，要求所述持有者和/或验证者进行鉴别，检查所述验证应用是否被授权检索数据，以及，向身份或属性提供者服务请求所述用户属性、用户属性检索和服务器检索令牌信息中的至少一项；
    在所述验证应用被授权检索数据的情况下，确定所述身份或属性提供者服务或所述mdoc应用程序与所述验证应用之间建立传输通道所需的信息，根据所述信息建立所述传输通道；
    通过所述传输通道将所述身份或属性提供者服务管理的用户属性、用户属性检索和服务器检索令牌信息中的至少一项传送至所述验证应用，以供所述验证应用通过确认服务对所述用户属性、用户属性检索和服务器检索令牌信息中的至少一项进行验证。
  18. 如权利要求15所述的方法，其特征在于，所述远程身份识别包括具有本地属性存储的所述远程身份识别，在所述具有本地属性存储的远程身份识别的过程中，所述运行阶段包括：
    响应于所述mdoc应用程序和验证应用被激活，要求所述持有者和/或验证者进行鉴别，以及，接收请求信息，并根据所述请求信息检查所述验证应用是否被授权检索数据，其中，所述验证者为远程服务器，所述请求信息由所述验证应用通过外部设备的浏览器或当前的移动设备中的移动应用程序或浏览器转发至所述mdoc应用程序，所述请求信息包括所请求的用户属性、验证者信息以及目的描述中的至少一项；
    在所述验证应用被授权检索数据的情况下，确定所述mdoc应用程序和验证应用之间建立传输通道所需的信息，根据所述信息建立所述传输通道；
    通过所述传输通道将所述mdoc应用程序管理的用户属性、用户属性检索和服务器检索令牌信息中的至少一项传送至所述验证应用，以供所述验证应用通过确认服务对所述用户属性、用户属性检索和服务器检索令牌信息中的至少一项进行验证。
  19. 如权利要求15所述的方法，其特征在于，所述远程身份识别包括具有远程属性存储的所述远程身份识别，在所述具有远程属性存储的远程身份识别的过程中，所述运行阶段包括：
    响应于所述mdoc应用程序和验证应用被激活，要求所述持有者和/或验证者进行鉴别，以及，接收请求信息，并根据所述请求信息检查所述验证应用是否被授权检索数据，以及，向身份或属性提供者服务或远程用户存储服务请求所述用户属性、用户属性检索和服务器检索令牌信息中的至少一项，其中，所述验证者为远程服务器，所述请求信息由所述验证应用通过外部设备的浏览器或当前的移动设备中的移动应用程序或浏览器转发至所述mdoc应用程序，所述请求信息包括所请求的用户属性、验证者信息以及目的描述中的至少一项；
    在所述验证应用被授权检索数据的情况下，确定所述身份或属性提供者服务或远程用户存储服务和验证应用之间建立传输通道所需的信息，根据所述信息建立所述传输通道；
    通过所述传输通道将所述身份或属性提供者服务或远程用户存储服务管理的用户属性、用户属性检索和服务器检索令牌信息中的至少一项传送至所述验证应用，以供所述验证应用通过确认服务对所述用户属性、用户属性检索和服务器检索令牌信息中的至少一项进行验证。
  20. 如权利要求3至19中任一项所述的方法，其特征在于，所述SIM卡的功能包括安全通道管理、生命周期控制以及业务功能处理中的至少一项。
  21. 如权利要求20所述的方法，其特征在于，所述业务功能处理包括业务状态同步、个人属性信息处理及应用远程管理中的至少一项，所述业务状态同步的操作包括：
    处理发行者进行的应用业务状态机切换；和/或，向所述发行者上报业务状态及业务方执行业务指令，并对业务状态安全进行判断；
    所述个人属性信息处理的操作包括：
    响应于接收到发行者的写入指令，将所述用户属性和可验证凭证写入所述SIM卡；
    响应于接收到验证者的验证请求，通过预设的链表数据结构出示所述用户属性和可验证凭证；
    响应于满足发行者权限，将所述发行者更新的用户属性和可验证凭证写入所述SIM卡。
  22. 如权利要求21所述的方法，其特征在于，所述通过预设的链表数据结构出示所述用户属性和可验证凭证的操作之前还包括：
    以用户身份标识为索引，对业务标识与用户可验证凭证信息进行关联，得到所述链表数据结构；
    其中，所述用户可验证凭证信息包括可验证凭证类型，所述可验证凭证类型被配置为动态组织出示信息。
  23. 一种认证装置，其特征在于，所述装置应用于移动证件系统，所述移动证件系统的生存周期阶段包括初始化阶段、安装阶段、发行阶段、运行阶段以及移除阶段中的至少一项，所述装置包括初始化模块、安装模块、发行模块、运行模块以及移除模块中的至少一项；
    所述运行模块，被配置为在所述运行阶段，响应于所述移动证件系统中的mdoc应用程序被激活，传送用户身份识别信息至验证应用，以供所述验证应用对所述用户身份识别信息进行验证，并根据验证结果执行对应的业务流程。
  24. 一种认证设备，其特征在于，所述设备包括：存储器、处理器及存储在所述存储器上并可在所述处理器上运行的计算机程序，所述计算机程序配置为实现如权利要求1至22中任一项所述的认证方法的操作。
  25. 一种存储介质，其特征在于，所述存储介质为计算机可读存储介质，所述存储介质上存储有计算机程序，所述计算机程序被处理器执行时实现如权利要求1至22中任一项所述的认证方法的操作。
  26. 一种计算机程序产品，其特征在于，所述计算机程序产品包括计算机程序，所述计算机程序被处理器执行时实现如权利要求1至22中任一项所述的认证方法的操作。
PCT/CN2025/104764 2024-06-28 2025-06-27 认证方法、装置、设备、介质及产品 Pending WO2026002243A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202410865970.1 2024-06-28
CN202410865970.1A CN118673484A (zh) 2024-06-28 2024-06-28 认证方法、装置、设备、介质及产品

Publications (1)

Publication Number Publication Date
WO2026002243A1 true WO2026002243A1 (zh) 2026-01-02

Family

ID=92732567

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2025/104764 Pending WO2026002243A1 (zh) 2024-06-28 2025-06-27 认证方法、装置、设备、介质及产品

Country Status (2)

Country Link
CN (1) CN118673484A (zh)
WO (1) WO2026002243A1 (zh)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN118673484A (zh) * 2024-06-28 2024-09-20 中移动金融科技有限公司 认证方法、装置、设备、介质及产品

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111581609A (zh) * 2020-04-10 2020-08-25 杨维青 一种基于应用程序登录的用户身份认证系统
CN113946812A (zh) * 2021-09-29 2022-01-18 北京达佳互联信息技术有限公司 一种身份认证方法、装置、电子设备及存储介质
WO2022214773A1 (en) * 2021-04-07 2022-10-13 Verifiable Credentials Limited Verifiable credential
CN116886357A (zh) * 2023-07-04 2023-10-13 华南理工大学 一种移动平台分布式数字身份认证方法、装置及介质
CN118673484A (zh) * 2024-06-28 2024-09-20 中移动金融科技有限公司 认证方法、装置、设备、介质及产品

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110876144B (zh) * 2018-08-30 2023-07-11 华为技术有限公司 一种身份凭证的移动应用方法、装置及系统
CN109450872A (zh) * 2018-10-23 2019-03-08 中国联合网络通信集团有限公司 用户身份认证方法、系统、存储介质及电子设备
CN113099448B (zh) * 2019-12-20 2022-07-19 紫光同芯微电子有限公司 一种适用于大容量sim卡的终端身份认证方法
CN115689560A (zh) * 2022-08-15 2023-02-03 无锡融卡科技有限公司 智能终端、数字货币钱包认证系统及开通认证注销方法

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111581609A (zh) * 2020-04-10 2020-08-25 杨维青 一种基于应用程序登录的用户身份认证系统
WO2022214773A1 (en) * 2021-04-07 2022-10-13 Verifiable Credentials Limited Verifiable credential
CN113946812A (zh) * 2021-09-29 2022-01-18 北京达佳互联信息技术有限公司 一种身份认证方法、装置、电子设备及存储介质
CN116886357A (zh) * 2023-07-04 2023-10-13 华南理工大学 一种移动平台分布式数字身份认证方法、装置及介质
CN118673484A (zh) * 2024-06-28 2024-09-20 中移动金融科技有限公司 认证方法、装置、设备、介质及产品

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
3 February 2023 (2023-02-03), "Cards and security devices for personal identification - Building blocks for identity management via mobile devices - Part 1: Generic system architectures of mobile eID systems", XP082066810, Database accession no. ISO/IEC 23220-1:2023 *

Also Published As

Publication number Publication date
CN118673484A (zh) 2024-09-20

Similar Documents

Publication Publication Date Title
CN109951489B (zh) 一种数字身份认证方法、设备、装置、系统及存储介质
US10298568B1 (en) System integrating an identity selector and user-portable device and method of use in a user-centric identity management system
CN105429760B (zh) 一种基于tee的数字证书的身份验证方法及系统
US11556617B2 (en) Authentication translation
TW518489B (en) Data processing system for application to access by accreditation
JP2025084737A (ja) サードパーティのデジタルウォレットプロビジョニングのための認証
CN105516104B (zh) 一种基于tee的动态口令的身份验证方法及系统
US10826893B2 (en) One-time-password generated on reader device using key read from personal security device
CN113474774A (zh) 用于认可新验证器的系统和方法
US20120066501A1 (en) Multi-factor and multi-channel id authentication and transaction control
CA2914956C (en) System and method for encryption
US20170012951A1 (en) Multi-user strong authentication token
CN103812649B (zh) 机卡接口的安全访问控制方法与系统、手机终端
KR20160048203A (ko) 복수의 장치로부터 데이터에 액세스하기 위한 시스템
CN103873231A (zh) 认证服务器、移动终端和利用其来发放射频卡密钥的方法
KR102124838B1 (ko) 스마트 키를 이용한 출입관리방법 및 이를 위한 출입관리시스템
CN106063182A (zh) 电子签名方法、系统及设备
US11182777B2 (en) Systems and methods using a primary account number to represent identity attributes
WO2026002243A1 (zh) 认证方法、装置、设备、介质及产品
KR102112975B1 (ko) 하이브리드 보안환경 기반의 스마트 키를 이용한 출입관리방법 및 이를 위한 출입관리시스템
US20250356705A1 (en) Digital identification-based systems and methods
US20140150116A1 (en) Controlling release of secure data
Hölzl et al. Real-world Identification for an Extensible and Privacy-preserving Mobile eID
CN118656838B (zh) 分布式体系的数字业务系统管理方法、平台、设备及介质
WO2024095755A1 (ja) 管理サーバ、情報処理システム、及び、情報処理装置

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 25826314

Country of ref document: EP

Kind code of ref document: A1