Security mechanisms for namespaces used in electronic identification on mobile devices

Abstract

A system, mobile device, and method for managing security policies for data items stored in an electronic identification (eID) wallet on a mobile device. The security policies are associated with each of a plurality of supported namespaces on the mobile device, and a verifier terminal operates to select a namespace to access data items stored on the mobile device based on the security policies associated with the plurality of supported namespaces on the mobile device.

Description

Background Technology

[0001] This invention generally relates to mobile devices that operate electronic identity (eID) wallet applications, and more particularly to security mechanisms for accessing namespaces of data within eID wallet applications.

[0002] Mobile devices such as phones and tablets offer users numerous benefits that have allowed them to eliminate the need for other devices and cards. For example, e-wallets have allowed users to forgo carrying multiple credit cards and enabled users to load travel boarding passes and other tickets onto their mobile phones. Another emerging technology, known as electronic identification (eID), provides the ability to store identification documents such as driver's licenses, passports, national ID cards, university ID cards, and club membership cards using mobile devices.

[0003] At least one standard proposal for eID specifies the use of namespaces to access data stored in mobile driver's license applications. ISO / IEC CD2 18013-5:2019, Personal identification – ISO-compliant driver's license – Part 5: Mobile Driving License (mDL) Application Namespaces are a symbolic mechanism used to organize and identify segments of data. To access a segment of data, the requester specifies a namespace identifier and a local name (which is unique within the namespace, but does not need to be unique relative to other namespaces).

[0004] Therefore, using namespaces, within an eID wallet, one or more eID applications can each have their own namespace, which specifies the name of the data managed by the eID application.

[0005] While multiple eID applications and associated namespaces managed by mobile devices can fulfill the same identification task, such as providing a user's age, the confidence levels associated with these multiple applications and namespaces may differ. For example, a government-issued eID will typically provide a higher confidence level than one associated with a club for leisure activities.

[0006] Furthermore, before an eID application can grant access to a specific eID application and the information it manages, the eID application may have security policy requirements. Some of these security policy requirements, such as the cryptographic signature of access requests, may be considered too cumbersome by some attribute validators, or validators may be unable to meet the requirements.

[0007] In order to allow validators to determine from which namespace the request for access is made, it is desirable to have a unified communication technology that allows access from namespaces available on mobile devices and namespace security policy rules associated with such namespaces. Summary of the Invention

[0008] A technique for managing security policies for data items stored in an electronic identity (eID) wallet on a mobile device provides the following: associating security policies with each of a plurality of supported namespaces on the mobile device; operating a reader module to communicate with the mobile device; and selecting a namespace to access the data items stored on the mobile device based on the security policies associated with the plurality of supported namespaces. In one aspect, the technique for managing security policies for data items stored in an electronic identity (eID) wallet on a mobile device includes transmitting a list of supported namespaces to a validator module executed on a validator, and having the validator module select at least one candidate namespace from the list of supported namespaces based on the confidence level assigned to the namespace by the validator, a whitelist or blacklist of the namespace, or the overhead associated with satisfying the security policy of the namespace.

[0009] In another aspect, a list of supported namespaces is transmitted to the validator module, which allows the operator to select a namespace by displaying a dialog window on the validator terminal user interface to select at least one candidate namespace. In another aspect, before transmitting the list of supported namespaces to the validator terminal via the reader, the mobile device filters out any namespaces that the user chooses not to transmit, and only transmits those namespaces that the user has already tacitly agreed to be transmitted to the validator terminal.

[0010] The security policy for each of the multiple supported namespaces can be transmitted from the mobile device to the reader, for example, as a sequence of bytes containing bits identifying the required authentication protocol, bits indicating the required HASH (hash) type, bits indicating the required signature scheme, or bits indicating secure messaging options. The required authentication can be selected from one or more of digital signatures, reader authentication, certificate verification, secure messaging, role authentication, and user consent.

[0011] On one hand, the reader operates to select a namespace based on the confidence level associated with each of the multiple supported namespaces to access data items from multiple supported namespaces on the mobile device. For example, the reader selects a namespace from multiple supported namespaces on the mobile device based on a whitelist or a blacklist of namespaces. With the whitelist, the reader selects a namespace based on the namespace in the whitelist. With the blacklist, the reader does not select a namespace based on the namespace in the blacklist.

[0012] On one hand, data items stored on the mobile device are stored in hardware memory, and the association of security policies and namespaces is stored in hardware memory. The technology further includes operating the processor of the mobile device to transmit a list of supported namespaces and associated security policies to the authenticator terminal.

[0013] To achieve those and other advantages, and in accordance with the objectives of the invention as embodied and broadly described, the present invention provides a method for managing data items in an electronic identifier (eID) wallet stored on a mobile device, comprising the following steps:

[0014] Associate the security policy with each of the multiple supported namespaces on the mobile device; and

[0015] The operator executes the reader module to communicate with the mobile device and selects a namespace to access data items stored on the mobile device based on security policies associated with multiple supported namespaces on the mobile device.

[0016] On one hand, a method for managing security policies for data items in an electronic identifier (eID) wallet stored on a mobile device includes the following steps:

[0017] Transfer the list of supported namespaces to the validator module executed on the validator; and

[0018] The validator module selects at least one candidate namespace from the list of supported namespaces based on the confidence level assigned to the namespace by the validator, the whitelist or blacklist of the namespace, or the overhead associated with satisfying the security policy of the namespace.

[0019] In one aspect, a method for managing security policies for data items in an electronic identifier (eID) wallet stored on a mobile device includes the following steps:

[0020] Transmit the list of supported namespaces to the validator module; and

[0021] The validator module selects at least one candidate namespace by displaying a dialog window on the validator terminal user interface that allows the operator to select a namespace.

[0022] On one hand, the method for managing security policies for data items in an electronic identifier (eID) wallet stored on a mobile device further includes the following steps:

[0023] Before transmitting the list of supported namespaces to the validator terminal via the reader, filter out any namespaces that the user chooses not to transmit, and only transmit those namespaces that the user has already acquiesced to being transmitted to the validator terminal.

[0024] In one aspect, the method for managing security policies for data items in an eID wallet stored on a mobile device further includes the step of transmitting the security policies of each of a plurality of supported namespaces from the mobile device to a reader.

[0025] In one aspect, a method for managing security policies for data items in an electronic ID wallet stored on a mobile device, wherein the security policy is transmitted as a sequence of bytes having bits indicating a required authentication protocol, bits indicating a required HASH type, bits indicating a required signature scheme, or bits indicating secure messaging options.

[0026] On one hand, a method for managing security policies for data items in an electronic identifier (eID) wallet stored on a mobile device, wherein the required authentication can be selected from one or more of digital signatures, reader authentication, certificate verification, secure messaging, role authentication, and user consent.

[0027] In one aspect, the method for managing security policies for data items in an eID wallet stored on a mobile device further includes operating a reader to select a namespace from multiple supported namespaces on the mobile device to access the data item based on the confidence level of the validator associated with each of the multiple supported namespaces.

[0028] In one aspect, the method for managing security policies for data items in an electronic identifier (eID) wallet stored on a mobile device further includes operating a reader to access data items by selecting a namespace from multiple supported namespaces on the mobile device based on a whitelist or a blacklist of namespaces, wherein the reader selects a namespace from the whitelist of namespaces based on the namespace, and the reader selects a namespace from the blacklist of namespaces without selecting a namespace based on the namespace.

[0029] In one aspect, a method for managing security policies for data items in an electronic identifier (eID) wallet stored on a mobile device, wherein the data items stored on the mobile device are stored in hardware memory, and wherein the association between security policies and namespaces is stored in the hardware memory, the method further comprising operating a processor of the mobile device to transmit a list of supported namespaces and associated security policies to a validator terminal.

[0030] Another aspect of the present invention is a mobile device, comprising:

[0031] processor; and

[0032] A memory for storing processor-executable instructions and for storing electronic identity (eID) data, the memory including an eID wallet application having instructions that cause the processor to perform the following operations:

[0033] Receive a list of selected namespaces from the reader;

[0034] In response to receiving a list of selected namespaces from the reader, the security rules associated with each selected namespace are transmitted according to the defined byte string template.

[0035] On one hand, eID wallet applications further include instructions that cause the processor to perform the following operations:

[0036] Receive requests for supported namespaces from the reader;

[0037] The list of supported namespaces is transmitted to the reader.

[0038] On one hand, eID wallet applications further include instructions that cause the processor to perform the following operations:

[0039] Before transmitting the list of supported namespaces to the reader, filter out any namespaces that the user chooses not to transmit, and only transmit those namespaces that the user has already agreed to be transmitted to the reader.

[0040] On one hand, eID wallet applications further include instructions that cause the processor to perform the following operations:

[0041] The security policy of each of the multiple supported namespaces is transmitted to the reader connected to the validator.

[0042] On one hand, in eID wallet applications, security policies are transmitted as a sequence of bytes containing bits that identify the required authentication protocol, bits that indicate the required hash type, bits that indicate the required signature scheme, or bits that indicate secure messaging options.

[0043] In one aspect, the present invention relates to a method for managing a security policy for data items stored in an electronic identity (eID) wallet on a mobile device, comprising:

[0044] Associate the security policy with each of the multiple supported namespaces on the mobile device;

[0045] Transmit the security policy of each of the multiple supported namespaces to the reader connected to the verifier;

[0046] The reader selects at least one of the namespaces as candidate namespaces and transmits a list containing the candidate namespaces from the reader to the mobile device.

[0047] The mobile device transmits the security policy associated with each selected candidate namespace to the reader;

[0048] Operate the reader to:

[0049] Determine which candidate namespaces the reader can satisfy the security policy for that namespace; and

[0050] If the validator can satisfy the security policy of at least one candidate namespace, then one of the candidate namespaces for which the validator terminal can satisfy the security policy is selected to access the data item, and the satisfaction of the security policy is proven to the mobile device.

[0051] If the validator cannot satisfy the security policy of any candidate namespace, then access to the data item is denied; and

[0052] When the reader successfully proves to the mobile device that the security policy of the selected namespace is satisfied, the reader authorizes the mobile device to access the data item. Attached Figure Description

[0053] Figure 1 This is a schematic diagram illustrating an exemplary use case scenario.

[0054] Figure 2 It is the external representation of a mobile device.

[0055] Figure 3 This is a block diagram illustrating the main components of the hardware and software architecture of a mobile device.

[0056] Figure 4 This is a block diagram illustrating an embodiment of the reader's organization.

[0057] Figure 5 The diagram contains Figure 4 A block diagram of an embodiment of the verifier for the reader.

[0058] Figure 6 (divided into) Figure 6a and Figure 6b This is a sequence diagram illustrating the process of transferring the namespace available on the mobile device to the reader.

[0059] Figure 7 This is a table illustrating an example protocol for namespace security policy messages.

[0060] Figure 8 It is a block diagram of a namespace-secure representation containing a template and a sequence of additional information bytes.

[0061] Figure 9 This is a diagram showing a dialog box displayed on a mobile device to obtain the user's default permission to use namespaces. Detailed Implementation

[0062] In the following detailed description, reference is made to the accompanying drawings, which illustrate specific embodiments in which the invention can be practiced. These embodiments are described in sufficient detail to enable those skilled in the art to practice the invention. It will be understood that the various embodiments of the invention, though different, are not necessarily mutually exclusive. For example, a particular feature, structure, or characteristic described herein in connection with one embodiment may be implemented in other embodiments without departing from the spirit and scope of the invention. Furthermore, it will be understood that the position or arrangement of individual elements within each disclosed embodiment may be modified without departing from the spirit and scope of the invention. Therefore, the following detailed description is not to be construed in a limiting sense, and the scope of the invention is defined only by the appended claims as properly interpreted, together with the full scope of their authorized equivalents. In the drawings, similar reference numerals refer to the same or similar functions throughout several views.

[0063] The following description includes references to various methods executed by a processor of a mobile device or terminal, referred to herein as a reader or verifier. As is common in the art, phrases may be present herein indicating that these methods or method steps are performed by software instructions or software modules. As will be appreciated by those skilled in the art, such descriptions should be understood to mean that the processor actually executes the methods, software instructions, and software modules.

[0064] The technology described herein provides a mechanism for discovering security policies for electronic identification data organized in a namespace on a mobile device, utilizing a general abstraction of data structures used on mobile devices. Accordingly, this technology improves mobile devices and the overall system for electronic identification purposes by providing the following: when a mobile device is used for identity-based identification or attribute assertions, secure access rules can be assigned to the namespace used to address electronic identification data stored on the mobile device, thereby allowing electronic identification readers and verifiers to select the appropriate namespace hosted by the electronic device for verifying attribute assertions based on the electronic identification. This technology improves such devices by providing greater flexibility in allocating security policies and transmitting such security policies to readers and verifiers of electronic identification data.

[0065] First, let's consider use cases. There are many instances where individuals seek to establish an attribute that will allow them a certain privilege. This could be access to a restricted physical space, the right to participate in a program, access to private or age-restricted materials, or access to attribute-restricted benefits. Reduced fares available only to students and seniors are an example of attribute-restricted benefits.

[0066] Suppose that if the person wishing to ride the subway system is a student or a senior citizen, that person is authorized a 50% discount. A person may have several eID applications on their mobile device, which may be useful in proving that one or both of the requirements for the reduced fare are met, for example:

[0067] • Government-issued identification cards, for example, from AGENCE NATIONALE DES TITRES SÉCURISÉS (ants.gouv.fr; French National Security Documents Agency) or TEXAS DEPARTMENT OF PUBLIC SAFETY (Texas Department of Public Safety, dps.texas.gov).

[0068] • University department ID, such as University of Pau (univ-pau.fr) or University of Texas (utexas.edu)

[0069] • Recreational activity clubs, such as a philatelic club (pau-philatelie.asso.org) or a gardening club (merryweeders.org).

[0070] Each eID application can store information that can be used to prove that a person is a student or has reached a certain age; for example, a government ID typically stores a date of birth and can have an occupational status (e.g., retired or student), a university ID will of course indicate whether a person is a student, faculty member or alumnus, and even a stamp club can charge different membership fees for students and therefore have a mark set for members who are students, and a gardening club can store a date of birth so that they can celebrate the member's corresponding birthday.

[0071] When passengers intending to purchase a metro monthly pass, they present their mobile device to an automated ticket vending machine, which can be a self-service ticket terminal or an individual employee of the metro authority operating a verification terminal. If the passenger is a student or senior citizen, they provide their eID wallet as proof. The passenger or metro official then places the mobile device on the terminal.

[0072] The eID wallet transmits the desired attributes to the terminal, and the terminal decides whether to authorize the discount.

[0073] Figure 1 This is a schematic diagram illustrating the example use case scenario and alternatives described above. User 101 operates mobile device 103, such as a mobile phone. Mobile device 103 contains an eID wallet with one or more eID applications (see...). Figure 2User 101 can use the eID function of mobile device 103 to prove their identity or identity-related attributes to a authenticator. The authenticator can be a human authenticator 115 that interacts with reader 109 and authenticator computer 105 via a user interface 117 connected to reader 109. For example, if user 101 seeks access to a facility based on membership status, user 101 can present mobile device 103 to a security guard (human authenticator) 115. An authenticator module 111, executable by reader 109 or authenticator 105, provides a conversational user interface 117 to human authenticator 115 to verify the identity provided by user 101.

[0074] Alternatively, when user 101 places mobile device 103 on reader 109, a authenticator can be automatically executed. For example, reader 109 is connected to automatic authenticator 105', thereby executing software authenticator module 111' that communicates with reader 109'. Although depicted as separate units herein, reader 109' and authenticator 105' could be a single machine. An example could be an automated ticket vending machine where travelers must prove they are members of a specific age group.

[0075] In an alternative use case, mobile device 103 is used to provide identity functionality to remote server 115 via Internet 113, and authenticator module 111 is executed on remote server 115.

[0076] Figure 2 It is the external representation of the mobile device 103, and Figure 3 This is a block diagram illustrating the main components of the hardware and software architecture of mobile device 103. Mobile device 103 includes a touchscreen user interface 201 for receiving input from user 101 and providing output to user 101, and a camera 203 through which the mobile device can receive input from reader 109, such as by scanning a QR code or barcode displayed on reader 109.

[0077] like Figure 3 As illustrated, the mobile device 103 includes a processor 301, a communication interface 303, and non-volatile memory (NVM) 305. The NVM 305 includes programs including an operating system 307 and applications called "apps," which include an eID wallet app 309.

[0078] A communication interface 303, which can be used with mobile phones, NFC, Bluetooth, WiFi, etc., allows the mobile device 103 to communicate with the reader 109 or a remote server 115. Alternatively, the mobile device 103 can communicate with the reader 109 via a screen 201 and a camera 203. The reader 109 can be an optical device that reads information transmitted via the screen 201 of the mobile device 103 and outputs information that the mobile device 103 can input via the camera 203.

[0079] eID wallet app 309, for example, manages eID wallet information in eID wallet DB 311, which is organized around multiple namespaces 313a-n.

[0080] Figure 3 The architecture described is merely an example. For instance, in an alternative embodiment, there might be multiple eID wallet apps, each with its own namespace.

[0081] Each namespace provides access to multiple data elements and defines its own name for those data elements. Example namespaces can be found by referencing ISO / IEC CD2 18013-5:2019, which is incorporated herein by reference. Personal Identification — ISO-Compliant Driving License — Part 5: Mobile Driving Licence (mDL) application It can be found in section 7, “Data Model”.

[0082] However, while two namespaces may contain the same data elements, these data elements may not have the same names in the two namespaces. For example, Date of birth (Date of Birth) (from the example namespace in Appendix I) may be named in another namespace. BirthDate (Date of birth). Similarly, two different data elements can provide equivalent information segments, for example, Date of birth (Date of birth) can be used for export. age (age).

[0083] Namespaces can be addressed in different ways, such as URI, URL, URN, OID, UUID, or reverse domain namespace representation. In reverse domain representation, a namespace can be defined as... reverseDomain.domainSpecificExtensi on For example, for the French National Security Documents Agency, the reverse domain namespace identifier could be... fr.gouv.ants.id And for stamp clubs, it could be org.asso.philatelie.role .

[0084] Figure 4This is a block diagram illustrating an embodiment of the reader 109. The reader 109 includes a processor 401, a storage unit 403, an interface unit 405 for interfacing with the processor of a verifier 105, and a communication module 407 for communicating with a mobile device 103 via NFC, WiFi, or Bluetooth.

[0085] Storage unit 403 includes a software module including an operating system (OS) 409 and a reader module 411, which includes a processor 401 for implementing instructions for reader-side namespace selection as illustrated and described below.

[0086] Figure 5 This is a block diagram illustrating an embodiment of the verifier 105. The verifier includes a processor 451, a storage unit 453, an input / output interface unit 405 for interfacing with a user interface device for communication with a human operator 115 or user 101, and a communication module 457 for communication with a mobile device 103 via NFC, WiFi, or Bluetooth. The storage unit 403 contains software modules including an operating system (OS) 459 and a verifier module 111 for performing tasks related to verifying eID attribute assertions, such as tasks related to attribute-based or authentication qualifications.

[0087] Note that there are tasks for the reader module 411 and the verifier module 111 that can be performed by a human operator. For example, as discussed in conjunction with the timing diagram following Figure 6 below, the selection of a namespace based on a security level can be performed using a dialogue with a human-identity-based assertion verifier (see Figure 6 below). Figure 1 (115). Therefore, the verifier 105 may include an I / O interface 455 for connecting to a user interface device, such as a terminal for displaying a graphical user interface element 117.

[0088] Figure 6 (divided into) Figure 6a and Figure 6b This is a timing diagram illustrating the process of transferring the namespace available on mobile device 103 to verifier 105, which includes reader 109. The process performed by reader 109 can be under the control of a software module referred to herein as reader module 411. It should be noted that there is no strict boundary between reader 109 and verifier 105. Tasks described herein that are performed by one can be performed by the other. Furthermore, reader 109 and verifier 105 can be completely separated or combined into a single unit or any arrangement between these two extremes.

[0089] As a preliminary step, user 101 operating mobile device 103 seeks to make an identity-based assertion, step 501. The identity-based assertion could be a request to access the service based on verified proof of an identity attribute (such as age), or a request to prove that user 101 is a specific person. User 101 presents mobile device 103 containing and executing eID wallet app 309 to reader 109, and a communication session is established between mobile device 103 and reader 109, such as via NFC, Bluetooth, WiFi, or optical transmission.

[0090] In response to the establishment of an eID communication session, reader 109 responds by requesting a list of eID namespaces supported by mobile device 103 from mobile device 103, step 503.

[0091] Mobile device 103 responds using a list of supported eID namespaces, step 505. This list can be, for example, a juxtaposed or structured collection of namespace identifiers represented as URIs, URLs, URNs, OIDs, UUIDs, or reverse domain names. In one embodiment, mobile device 103 requests user 101's confirmation that the user tacitly consents to publishing a specific namespace to reader 109 and verifier 105. For example, if a namespace containing a birthdate is associated with a political organization, the user might be unwilling to disclose members of that organization to reader 109 and verifier 105.

[0092] For example, using reverse domain name representation, for a French citizen student at the University of Pau (who is a philatelist), mobile device 103 could return:

[0093] Nationality: fr.gouv.ants.id (French National Security Documents Bureau)

[0094] Student status: fr.edu.univ-pau.labo.profile (University of Pau)

[0095] Membership cards in the stamp club: org.asso.philatelie.role (Philatelists Club)

[0096] Depending on the request to perform an identity assertion (step 501), verifier 105 determines the level of security (LOS) that should be associated with the request, step 507. For example, a bank cashing a check may require an identity assertion associated with a national ID, while a university ID may be sufficient for proving the right to pay student fees.

[0097] Based on the required LOS, verifier 105 selects one or more namespaces that satisfy the required LOS (step 509) and sends a request to mobile device 103 to access these namespaces (step 511). Verifier 105 may have a whitelist of namespaces that can be used to satisfy LOS for identity-based assertions. For example, a major city transportation authority might accept national IDs as well as student IDs from local universities. Conversely, verifier 105 may have a blacklist of namespaces that are not allowed to be used for identity-based assertions; that is, namespaces deemed not to satisfy the required LOS.

[0098] Mobile device 103 responds using the security policy access rules associated with the namespace of each request, step 513.

[0099] In a preferred embodiment, the namespace security policy is transmitted according to a standard protocol or interoperability template. The namespace security policy protocol may consist of a series of bytes, where each bit indicates a specific security policy attribute.

[0100] Figure 7 This is a table illustrating an example of the 601 protocol for namespace security policy messages.

[0101] In Example 601, the first byte is used to transmit the version number of the template, which is used to transmit the namespace security policy.

[0102] The second byte of example template 601 contains a value indicating the required authentication protocol. The first bit (b1) indicates whether a digital signature is required. The second bit (b2) indicates whether reader verification is required. The third bit (b3) indicates whether certificate verification is required. The fourth bit (b4) indicates whether secure messaging is required. The fifth bit (b5) indicates whether role authentication is required. The sixth bit (b6) indicates whether user consent is required.

[0103] The third byte indicates the hash type to use. For example, the first to third bits indicate SHA-256, SHA-384, and SHA-512, respectively. Other bits can be used to indicate alternative hash schemes. No bits are set to indicate that a hash should not be used.

[0104] The fourth byte indicates the digital signature scheme to be used. For example, the first and second bits indicate RSA and ECDSA, respectively. Other bits can indicate other digital signature schemes. No bits are set to indicate that a digital signature is not required.

[0105] The fifth byte indicates which secure messaging option is used. The first three bits indicate AES 128-bit CMAC, AES 128-bit EMAC, and AES-GCM, respectively. Other bits can indicate other secure messaging options. No bits are set to indicate that secure messaging is not required.

[0106] It should be noted that Figure 7 The illustrations and templates described above are merely examples. Other arrangements are possible. For instance, several bytes that use only a few bits to convey information can be combined.

[0107] Returning to Figure 6, after receiving the security policy access rules (step 513), reader 109 determines whether at least one namespace has acceptable access rules (step 515). For example, if mobile device 103 requires verification of a digital signature to access a namespace for age verification of the website, verifier 105 might consider this too cumbersome. Furthermore, verifier 105 might not be able to meet highly demanding access rules and is therefore forced to request access to namespaces with less demanding access rules. Therefore, verifier 105 could have, for example, selection rules, such as not selecting namespaces requiring certificate verification or more than 128 bits of encryption.

[0108] If mobile device 103 does not provide a namespace with an acceptable level of confidence and acceptable access rules, reader 109 may refuse access to the service or benefit requested by mobile device 103, step 515, and a message refusing access to the requested service is transmitted to mobile device 103, step 515.

[0109] Otherwise, reader 109 selects a namespace with an acceptable security policy, step 519.

[0110] Using the selected namespace, the reader satisfies the access rules required by the mobile device and sends an access request message with a namespace identifier, data element name (used by the namespace to address the required data element), and required information or format, such as a certificate or hash message, according to the access rules of the namespace, step 521.

[0111] In one embodiment, the namespace security policy representation 601 further includes additional information, such as certificate routing or digital information necessary to resolve certain cryptographic references. For example, if the verifier / reader has referenced, for instance, the cryptographic key to be used, the routing to the certification authority root public key (used for certificate verification), or the object identifier (OID) of the cryptographic suite to be enforced by the verifier / reader, then verifier 105 or reader 109 can satisfy the security policy access rules. To provide this additional information, the namespace security policy template 601 transmitted in step 513 may be appended with a sequence of bytes that provides the necessary data for the defined security mechanism to allow access from mobile device 103 to eID data corresponding to each byte in the template.

[0112] Figure 8It is a block diagram of namespace security representation 701 containing template 601' and additional information byte sequences 705a-e.

[0113] Example namespace security representation 701 contains five bytes 703a-e corresponding to the five-byte template 601'. Each of these has a corresponding additional information byte sequence 705a-e. Each of these additional byte sequences 705a-e is in length-value format, that is, the first field 707a-e indicates the number of bytes in the value fields 709a-e; a value of 0 in the length fields 707a-e indicates that there is no additional information sequence corresponding to a specific byte in the template, and therefore, the value fields 709a-e will be empty sequences.

[0114] There are many different possible syntaxes for the length field. In simple cases, the length field is simply a fixed number of bytes, such as one or two bytes.

[0115] Therefore, security policy access rule communication can be:

[0116] 1st byte || 2nd byte || 3rd byte || 4th byte || 5th byte || 0x00 || 0x0C || <12-byte OID>> || 0x00 || 0x08 || <8-byte key> > || 0x00

[0117] in

[0118] • The first five bytes correspond to the combination as follows Figure 7 Described security policy access rules

[0119] • 0x00 indicates a zero-length value field, meaning there is no value, which corresponds to the first byte 703a.

[0120] • 0x0C is a length filled with a hexadecimal value, indicating that 12 bytes should follow additional information corresponding to the second byte 703b; in this example, the following 12 bytes are an OID representation, which identifies the cipher suite of the authentication protocol defined in the second byte of the security policy access rule.

[0121] • The second 0x00 indicates that there is no additional information corresponding to the third byte 703c.

[0122] • 0x08 indicates that the subsequent value field corresponding to the fourth byte 703d is 8 bytes long, and in this example, the subsequent 8 bytes are the eight-byte password key.

[0123] • The third 0x00 indicates that the fifth byte 703e does not contain an additional information byte sequence.

[0124] Other mechanisms for indicating the length of the appended value field include using escape sequences, such as 0xFF, to indicate that subsequent bytes contain the length of the length field. For example, 0xFF020216 would indicate that the length field (0x02) is two bytes long, and those two bytes would indicate that the subsequent byte sequence is 0x0216 (534) bytes long. Yet another mechanism is to have the first byte of each appended information sequence 705 indicate the length of the length field.

[0125] As noted above, user consent may be a possible access rule. Therefore, if user consent is required, mobile device 103 can display a message indicating the access request to the user on user interface 201, for example, such as... Figure 9 As instructed in the document, Figure 9 This is a diagram showing a dialog box displayed on mobile device 103. If the user cancels, access is denied. Conversely, access to the requested service is also not authorized. However, in a subsequent dialogue, user 101 may be given the opportunity to select an alternative eID namespace for the identity-based assertion required by reader 109.

[0126] Returning to Figure 6, if the reader 109 has met the requirements of the access rules for the requested namespace, the e-wallet app 309 of the mobile device 103 retrieves the required data using the provided namespace data element name, step 523, and provides an identity-based assertion to the reader 109, step 525.

[0127] Then, reader 109 or verifier 105 determines whether the identity-based assertion has been validated by the eID namespace, step 527. If the assertion has not been validated, access is denied, step 517. Otherwise, access to the requested service is granted based on the identity assertion made using the requested eID data element, which is addressed using the selected namespace and data element name (step 521), step 529.

[0128] From the above, it will be apparent that an efficient and secure mechanism is provided for associating security policy access rules with the namespaces used in eID wallets.

[0129] Although specific embodiments of the invention have been described and illustrated, the invention is not limited to the particular forms or arrangements of components described and illustrated. The invention is defined only by the claims.

Claims

1. A method for managing a security policy for data items in an electronically identified wallet stored on a mobile device, comprising: Associate the security policy with each of the multiple supported namespaces on the mobile device; and The operator executes the reader module to communicate with the mobile device and selects a namespace to access data items stored on the mobile device based on security policies associated with multiple supported namespaces on the mobile device.

2. The method for managing security policies for data items stored in an electronic identity wallet on a mobile device according to claim 1, comprising: The list of supported namespaces is transferred to the validator module that executes on the validator; and The validator module selects at least one candidate namespace from the list of supported namespaces based on the confidence level assigned to the namespace by the validator, the whitelist or blacklist of the namespace, or the overhead associated with satisfying the security policy of the namespace.

3. The method for managing security policies for data items stored in an electronic identity wallet on a mobile device according to claim 1, comprising: Transmit the list of supported namespaces to the validator module; and The validator module selects at least one candidate namespace by displaying a dialog window on the validator terminal user interface that allows the operator to select a namespace.

4. The method for managing a security policy for data items stored in an electronic identity wallet on a mobile device according to any one of claims 1-3, further comprising: Before transmitting the list of supported namespaces to the validator terminal via the reader, filter out any namespaces that the user chooses not to transmit, and only transmit those namespaces that the user has already acquiesced to being transmitted to the validator terminal.

5. A method for managing a security policy for data items stored in an electronic identity wallet on a mobile device according to any one of claims 1-3, comprising: The security policy of each of the multiple supported namespaces is transmitted from the mobile device to the reader.

6. A method for managing a security policy for data items stored in an electronically identified wallet on a mobile device according to any one of claims 1-3, wherein the security policy is transmitted as a sequence of bytes having bits indicating a required authentication protocol, bits indicating a required HASH type, bits indicating a required signature scheme, or bits indicating a secure messaging option.

7. A method for managing a security policy for data items in an electronically identified wallet stored on a mobile device, according to any one of claims 1-3, wherein the required authentication is selected from one or more of digital signatures, reader authentication, certificate verification, secure messaging, role authentication, and user consent.

8. The method for managing a security policy for data items in an electronically identified wallet stored on a mobile device according to any one of claims 1-3, further comprising operating a reader to select a namespace from the plurality of supported namespaces on the mobile device to access the data item based on the confidence level of the validator associated with each of the plurality of supported namespaces.

9. The method for managing a security policy for data items in an electronically identified wallet stored on a mobile device according to any one of claims 1-3, further comprising operating a reader to access data items by selecting a namespace from a plurality of supported namespaces on the mobile device based on a whitelist or a blacklist of namespaces, wherein the reader selects a namespace in the whitelist of namespaces based on the namespace, and the reader selects a namespace in the blacklist without selecting a namespace based on the namespace.

10. A method for managing security policies for data items in an electronically identified wallet stored on a mobile device according to any one of claims 1-3, wherein the data items stored on the mobile device are stored in hardware memory, and wherein the association between security policies and namespaces is stored in hardware memory, the method further comprising operating a processor of the mobile device to transmit a list of supported namespaces and associated security policies to a validator terminal.

11. A mobile device, comprising: processor; and A memory for storing processor-executable instructions and for storing electronic identity data, the memory including an electronic identity wallet application having instructions that cause the processor to perform the following operations: Receive a list of selected namespaces from the reader; In response to receiving a list of selected namespaces from the reader, the security rules associated with each selected namespace are transmitted according to the defined byte string template.

12. The mobile device of claim 10, wherein the electronic identity wallet application further includes instructions to cause the processor to perform the following operations: Receive requests for supported namespaces from the reader; The list of supported namespaces is transmitted to the reader.

13. The mobile device according to any one of claims 11 to 12, wherein the electronic identity wallet application further includes instructions to cause the processor to perform the following operations: Before transmitting the list of supported namespaces to the reader, filter out any namespaces that the user chooses not to transmit, and only transmit those namespaces that the user has already agreed to be transmitted to the reader.

14. The mobile device according to any one of claims 11 to 12, wherein the electronic identity wallet application further includes instructions to cause the processor to perform the following operations: The security policy of each of the multiple supported namespaces is transmitted to a reader connected to the validator.

15. The mobile device according to any one of claims 11 to 12, wherein the electronic identification wallet application, wherein the security policy is transmitted as a byte sequence, the byte sequence having bits identifying the required authentication protocol, bits indicating the required HASH type, bits indicating the required signature scheme, or bits indicating secure messaging options.

16. A method for managing a security policy for data items in an electronically identified wallet stored on a mobile device, comprising: Associate the security policy with each of the multiple supported namespaces on the mobile device; The security policy of each of the multiple supported namespaces is transmitted to a reader connected to the verifier; The reader selects at least one of the namespaces as candidate namespaces and transmits a list containing the candidate namespaces from the reader to the mobile device. The mobile device transmits the security policy associated with each selected candidate namespace to the reader; Operate the reader to: Determine which candidate namespaces the reader can satisfy the namespace's security policy; and If the validator can satisfy the security policy of at least one candidate namespace, then one of the candidate namespaces for which the validator terminal can satisfy the security policy is selected to access the data item, and the satisfaction of the security policy is proven to the mobile device. If the validator cannot satisfy the security policy of any candidate namespace, access to the data item is denied; and When the reader successfully proves to the mobile device that the security policy of the selected namespace is satisfied, the reader authorizes the mobile device to access the data item.

Images