Patent Description:
Identity documents, such as identity cards, may have multiple pieces of information stored on them. Some countries have begun a move to national identification cards that includes a microchip or integrated circuit that electronic stores information. A national identification card may include basic information, such as a person's name, home address, date of birth, age, or gender. Additionally, a national identity card may include security mechanisms such as an electronic security certificate, anti-counterfeit printing techniques, or seals.

In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of some example embodiments. It will be evident, however, to one skilled in the art that the present disclosure may be practiced without these specific details.

Personal electronic identity cards are becoming more popular. Such cards may be issued by governments, schools, health care systems, or the like. To use a personal electronic identity card, a card reader is used to read some, or all of the information contained on the card. It may take several seconds to read the information on the card. This delay impacts the user experience and may reduce the adoption rate of identity card technology. In order to provide a better user experience and promote faster adoption of identity card use, a more powerful, scalable, and faster transmission protocol is needed. In addition, because much of the personal identity card contents may be sensitive, classified, or private, the improved transmission protocol provides a secure mechanism.

The present disclosure describes an improved credential system that provides a secure process to transmit credential information from a credential to a credential reader without impacting user experience. Additional features are discussed below.

Identity credentials (e.g., electronic documents, cards, mobile profiles, etc.) include information such as a first and last name, a date of birth, an address, etc. In the digital world, each piece of information is a data element and these data elements are combined into a package that is issued to a target user. Having a digital credential provides several advantages. Information and documentation are easy to access. The information is centralized and may be stored in a network location, providing backup and redundancy. Digital credentials may also be more immune to counterfeiting and corruption than conventional credentials.

Some terms are provided here for common reference. It is understood that these terms are non-limiting and that other terms, phrases, or descriptions of operations, components, or devices in the systems and methods described may be used.

Package - a Package is a collection of name:value pairs of data. The name of the data pair may be referred to as a Tag, Field, or Description. A Package may include metadata about the Package, such as a Package Hash, Package Signature, Package Expiration, or the like.

Credential - a Credential is an encapsulation of one or more packages. An aggregated credential includes two or more packages. A credential may include metadata describing the issuer of the credential, expiration or validity dates, or other information about the credential.

Issuer - an Issuer is a person, entity, service, or other platform that provides a Package. The Issuer may attest to the authenticity, validity, and correctness of data contained in the Package. The Issuer may sign the Package or sign individual data in the Package. The Issuer may be an Original Issuer, which is an Issuer that created the data, or a Re-Issuer, which is one that reuses the Original Issuer's data. An Issuer or Re-issuer may issue a Package as a Credential.

Data that is provided by an Issuer may have an associated Assurance Level. An Assurance Level is an indication of the trustworthiness of the data. The Assurance Level may be a numerical range, a letter grade, or other indication. Data issued by an Original Issuer may have the highest Assurance Level. As data is reused and republished by Re-Issuers in derivative Packages, the Assurance Level may decrease stepwise. By analyzing the Assurance Level of data contained in a Package, one may be able to see how many steps away the data in the current Package is from the Original Issuer.

Verifier - a Verifier is a device, person, entity, service, or other platform that verifies data in a Package or Credential. A Verifier may obtain data from a user Credential, for example a point-of-sale, and then contact one or more Issuers to validate the data. Other forms of validation may be used, such as by analyzing data signatures, analyzing a blockchain, or the like.

<FIG> is a block diagram illustrating a credential system <NUM>, according to an embodiment. The credential system <NUM> includes a first original issuer 102A and a second original issuer 102B (collectively referred to as <NUM>) that issue core packages 104A, 104B (collectively referred to as <NUM>). The core packages <NUM> include tags and values that are generated by the original issuers <NUM>. The credential system <NUM> also includes re-issuers 106A, 106B (collectively referred to as <NUM>) that compile data from one or more issuers (or re-issuers) in the credential system <NUM> and re-issues an aggregated credential with contents from two or more packages.

The re-issuer <NUM> may also add its own data to the aggregate credential by issuing its own package and consolidating the package with data from packages of other issuers <NUM>. The re-issuer <NUM> may sign its own package, portions of its own package, or the aggregated credential.

In the example illustrated in <FIG>, the first original issuer 102A is a government agency that issues birth certificates (e.g., a Public Health Office of a county). The first original issuer 102A is the place where the user's name, date of birth (DOB), and place of birth are first recorded. The second original issuer 102B is a vehicle manufacturer that produces vehicles. Each vehicle produced is uniquely identified with a vehicle identification number (VIN). The second original issuer 102B creates a package with data describing a vehicle.

The re-issuer 106A may be a government agency that produces packages for vehicle titles (e.g., a Department of Motor Vehicles (DMV)). The vehicle title is identified with a title identifier that uniquely identifies the title. Consequently, the aggregate credential produced by the re-issuer 106A may include: the vehicle title identifier, as issued by the re-issuer 106A; some or all of information from a package from first original issuer 102A describing an owner's personal information; and some or all of information from a package from the second original issuer 102B describing the vehicle.

The re-issuer 106B may be an insurance company that provides motor vehicle insurance. The re-issuer 106B may produce a policy number that identifies an insurance policy for the vehicle. The package that includes the policy number may also include, using actual values or values by reference, information about the insured party (e.g., data from package created by issuer 102A), information about the vehicle being insured (e.g., data from package created by issuer 102B), and information about the vehicle title (e.g., data from aggregate credential produced by re-issuers 106A).

A credential database <NUM> may be used to store packages and other data from one or more issuers <NUM> or re-issuers <NUM>. The credential database <NUM> may use a relational database management system (RDBMS) to organize the package information into tables. The credential database <NUM> may be queried by various entities or users, such as a re-issuer <NUM>, a verifier <NUM>, or a user at a user device <NUM>. A re-issuer <NUM> may query the credential database <NUM> to obtain original package information to populate an aggregated credential. The credential database <NUM> may be implemented on one or more servers, which may be owned or operated by a credential issuing entity. In some embodiments, credential issuing entities access the credential database <NUM> as part of a service.

The various components of the credential system <NUM> may communicate over one or more networks <NUM>, which may include any known type of network that facilitates machine-to-machine communications. The network <NUM> may use the same communication protocols or different protocols without departing from the scope of the present disclosure. The network <NUM> may include wired or wireless communication technologies. The Internet is an example of a communication network that constitutes an Internet Protocol (IP) network consisting of many computers, computing networks, and other communication devices located all over the world, which are connected through many telephone systems and other means. Other examples of a communication networks include, without limitation, a Plain Old Telephone System (POTS), an Integrated Services Digital Network (ISDN), the Public Switched Telephone Network (PSTN), a Local Area Network (LAN), a Wide Area Network (WAN), a Session Initiation Protocol (SIP) network, a Voice over Internet Protocol (VoIP) network, a cellular network, and any other type of packet-switched or circuit-switched network known in the art. In addition, it can be appreciated that the communication network <NUM> need not be limited to any one network type, and instead may be comprised of several different networks or network types. Moreover, the network <NUM> may include a number of different communication media such as coaxial cable, copper cable/wire, fiber-optic cable, antennas for transmitting/receiving wireless messages, and combinations thereof.

The user device <NUM> and verifier device <NUM> may be of any type of compute device. The user device <NUM> is typically portable in nature, and may take the form of a cellular phone, mobile device, smart phone, personal digital assistant, laptop, tablet, wearable device, portable credential card, key fob, or the like. It should be appreciated that the verifier device <NUM> does not necessarily have to correspond to a mobile device, but rather may correspond to a personal computer, desktop computer, kiosk, payment terminal, beacon, or the like.

During a transaction, a user with the user device <NUM> may be asked to present a credential <NUM> or part of a credential <NUM> to a verifier device <NUM>. The verifier device <NUM> may be a point-of-sale terminal with a beacon, for example. The beacon may periodically attempt to connect with user devices <NUM> in communication range or within some threshold proximity. The verifier device <NUM> may connect with the user device <NUM> over wireless communications (e.g., BLUETOOTH® or WI-FI), and obtain some or all of a credential <NUM> from the user device <NUM>. For instance, as the user approaches the checkout lane, the beacon may advertise a connection, which the user device <NUM> uses to connect with the beacon and construct a secure connection. The beacon may request certain credential information, such as a user's name and credit card number, and the user device <NUM> may respond with the information. The user may selectively share portions of the credential <NUM> to the verifier device <NUM> to maintain as much personal privacy as possible. The verifier device <NUM> may validate the credential <NUM> by accessing an issuer <NUM>, re-issuer <NUM>, or credential database <NUM>.

Depending on how the system is organized, the user device <NUM> may obtain one or more credentials <NUM> from one or more issuers <NUM> or re-issuers <NUM>. For instance, the user may obtain a driving license credential from a government motor vehicles agency and a health care identification card from a health insurance company. Alternatively, the user may obtain a composite credential that includes a package from the government motor vehicles agency and another package from the health insurance agency.

<FIG> is a message sequence diagram illustrating an interaction between a user device <NUM> and a verifier device <NUM>, according to an embodiment. While the various processes will be described in accordance with illustrative steps performed in a particular order, it should be appreciated that embodiments of the present disclosure are not so limited and that any of the process steps depicted and described herein can be performed in any order or in parallel with one another.

In conventional interactions, a user with a user device may form the intention to interact with a verifier device, for example, by initiating an airline check-in procedure with an airline kiosk. The user may tap the user device against the kiosk to begin a check-in procedure. After the tap, it may take several seconds (e.g., <NUM>-<NUM> seconds) for the user device to transmit the user's credential to the kiosk, which is acting as the verifier device, for verification. Once the credential is at the verifier device, the verifier device may prompt the user via the user device for consent to access one or more data elements in the credential. This delay causes annoyance and a reduced user experience.

In contrast, the improved process illustrated in <FIG> provides a quicker user interaction, which many users expect in today's electronic world. When a user device <NUM> is within wireless communication range of a verifier device <NUM>, the verifier device <NUM> may initiate a wireless connection (operation <NUM>). The wireless connection may be formed over any type of wireless communication protocol including, but not limited to BLUETOOTH®, BLUETOOTH LOW ENERGY (BLE), WI-FI, ZIGBEE, or the like.

The user device <NUM> encrypts each data element in a credential using a separate, independent encryption key (operation <NUM>). The encryption may be performed before, during, or after the wireless connection is formed in operation <NUM>. The encryption may be performed using an ephemeral key. An ephemeral key is typically a single-use key for a single session or interaction. An ephemeral key may be a symmetric key or an asymmetric key (Public Key Infrastructure (PKI)).

The user device <NUM> transmits the contents of the credential to the verifier device <NUM> as separately encrypted data elements (operation <NUM>). The advantage here is that the transmission of the data elements (i.e., credential) is performed before the user begins the interaction with the verifier device <NUM> or a human operator of the verifier device <NUM>. By transmitting the data element preemptively, the real-world delay experienced by the user is reduced or eliminated.

As such, instead of encrypting an entire credential with a key, the credential is encrypted on a part-by-part basis. Each part, which may include one or more data elements, are encrypted separately and transmitted before the user interacts with the verifying agent. By encrypting the credential piecewise, the user's information is secured better than if the credential were encrypted entirely as one unit. This is because the user may desire to consent to share only parts of a credential. If the credential is encrypted with one key, then the user's consent to share some of the credential may allow a verifier to inspect all of the credential-even though the user only wanted to share a portion of the credential. By separately encrypting the credential's parts, the user is provided a finer-grained control over the sharing.

Credentials may be of varying sizes. Encryption may increase the datafile size of a credential or of its constituent parts. The pre-sharing process described here may become cumbersome to a user device <NUM> when in an area that includes several verifier devices <NUM>. For example, in an airport, a user device <NUM> may be interrogated by verifier devices <NUM> at convenience stores (e.g., checkout terminal), terminal gates (e.g., boarding pass readers), security gates (e.g., passport controls), restaurants, newsstands, casino games, or other devices. The user device's power may be drained quickly by all of the pre-sharing to such potential verifier devices <NUM>. As such, in an embodiment, the transmission operation (operation <NUM>) may be conditioned on a triggering event.

The triggering event may be a threshold received signal strength indicator (RSSI) of a wireless signal between the user device <NUM> and the verifier device <NUM>. RSSI is a measurement of how well one device is able to receive a signal from another device. In other terms, RSSI is an estimated measurement of power level that a radio-frequency (RF) client is receiving from a transmitting device. In an IEEE <NUM> system, RSSI is the relative received signal strength in a wireless environment, in arbitrary units. Thresholds may also be based on absolute values of the received signal, such as measured in milliwatts (mW) or decibel-milliwatt (dBm). The transmitting device may be a BLUETOOTH advertiser, wireless hotspot, access point, or the like.

In another implementation, the triggering event may be based on a proximity assessment representing a distance between the verifier device and the mobile device. Other triggering events may be used. For instance, the RSSI difference between the first and a potential second verifier device, such that when one verifier device's RSSI is stronger than another's RSSI, the user device <NUM> may communicate with the device with the stronger RSSI. The rate of change or the absolute value of an increase of the RSSI value of the verifier device with the highest RSSI value may be used to identify a verifier device <NUM> to communicate with. Any combination of absolute value, relative value, and change rate of a verifier's RSSI value may be used to select a verifier device. A radio communication method (either in band as described for Bluetooth or using a separate radio communication technology such as UWB - Ultra Wide Band) allowing a distance measurement or estimation may also be used to select a verifier device from several potential verifier devices. Further, mechanisms that allow the determination of the credential position to the verifier such as angle of arrival (AoA) or time of flight (ToF) may be used to determine relative position between the user device and verifier device, and as a basis for triggering events.

It should be noted that a wireless connection used to determine a proximity assessment between the verifier device <NUM> and the user device <NUM> may be the same or different than the wireless connection used to communicate credential information or other session information. Proximity assessments may be referred to as distance measurements or ranging. Multiple types of wireless technologies may be used for ranging including but not limited to Ultra Wide Band (UWB), Bluetooth Low Energy (BLE), or the like.

In some implementations, BLE is used with AoA or triangulation (e.g., when using BLE beacons for location services). In other implementations, proximity assessment may include GPS indoor services or WLAN triangulation. Anything coming from location services or ranging (estimated or measured) may be used in the triggering event.

When a triggering event occurs, such as when the RSSI of a user device <NUM> is over a threshold amount, then the verifier device <NUM> may establish a wireless connection to interrogate the user device <NUM> for a credential. Alternatively, or in combination with such operation, the user device <NUM> may also use similar triggering events of the verifier device <NUM> to determine whether to respond to a particular credential request. This reduces the user interface queries to the user on the user device so that the user is not inundated with credential consent requests.

In the situation where there are multiple verifier devices <NUM>, then the triggering event of each may be used to determine which, if any, of the verifier devices <NUM> the user device <NUM> will interact with.

In addition, or in the alternative, the rate of change of an RSSI (or inferred distance) may be used to identify which verifier device <NUM> the user device <NUM> is to interact with. As the user approaches a verifying agent (e.g., as an airplane passenger approaches a gate attendant), the user device <NUM> may track that the verifier device <NUM> is getting closer (or vice versa) using RSSI. The rate of change may be used as a secondary indicator that the user device <NUM> it to interact with the verifier device <NUM>. For instance, a threshold RSSI may be used with a threshold rate of change.

In addition, or in the alternative, the triggering event may be an out-of-band criterium. The out-of-band criterium may be a user action (e.g., a user interaction with the user device <NUM> to select a verifier device <NUM>), a QR code scan, an NFC tap, or other activity that is used to disambiguate the verifier-user device relationship.

After receiving the parts of the credential, the verifier device <NUM> determines which data elements are needed to verify the user device <NUM> (operation <NUM>). The verifier device <NUM> may have a predetermined list of data elements to verify. Alternatively, the verifier device <NUM> may analyze the structure of the credential and determine which of the data elements to verify from those that are present in the credential. As an example, the credential may include a header field, which includes a list of the data elements or the types of data elements contained within the credential. The credential may have metadata describing the type of credential, contents, version, issuer, or other information about the credential. Based on the header field, the type of credential, metadata, or other information, the verifier device <NUM> is able to determine which data elements should be exposed for proper verification.

The verifier device <NUM> then transmits data or instructions to the user device <NUM> to initiate the user device <NUM> to prompt the user of the user device <NUM> for consent to share the needed data elements (operation <NUM>).

The user device <NUM> captures the user input consenting to share some or all of the data elements requested by the verifier device <NUM> (operation <NUM>) and transmits the decryption keys for those data elements to the verifier device <NUM> (operation <NUM>). For instance, the user may be presented with a list of items that the verifier device <NUM> is requesting, such as the user's name, driver's license number, and date of birth. The user may interact with the user device <NUM> to select one or more items, such as with a touch-sensitive display to choose a user interface control indicating selection of an item. The selection of the item and optional other user interface controls may be used then to indicate the user's consent to share the selected items with the verifier device <NUM>.

The decryption keys are transmitted to the verifier device <NUM> in operation <NUM>. The decryption keys may be one-time use keys, ephemeral keys, limited time keys, or other short-term or limited-use keys. Once the verifier device <NUM> obtains the keys for the requested data elements, the data elements are decrypted and verified (operation <NUM>).

The verifier device <NUM> may perform a variety of verification operations on the data elements, including but not limited to verifying an issuer of the data element, verifying the integrity of the data element, verifying the document type associated with the data element, and the like. Verifying the issuers of the data element may be performed by verifying a digital signature of the issuer associated with the data element. Verifying the integrity of the data element may be performed by verifying a hash of the data element, a checksum of the data element, a blockchain, or the like. Verifying the document type associated with the data element may be performed by verifying a file extension, a digital format, a header block, or the like. Verification may be performed at the verifier device <NUM> or in conjunction with a secondary device, such as a cloud service, a remote server, a companion device, or the like. Other types of verification and verification procedures are understood to be included in the scope of these verification operations.

In various embodiments, multiple thresholds may be used with each threshold initiating a separate respective triggering event. For instance, as a person approaches a verifier device, when the distance is within a first threshold, then ephemerally encrypted data may be shared. As the person continues to get closer to the verifier device, a second threshold distance is crossed, and a consent prompt may be presented to the user to share decryption keys with a verifier device within the second threshold distance range. As such, in a crowded scenario (e.g., border crossing or event venue entry), the first threshold may be set to <NUM> meters and the second threshold may be set to <NUM> meters. The thresholds may be set according to the particular scenario. As such, more or fewer thresholds with longer or shorter ranges may be used. In the interest of power saving, the ranging or location frequency may be very low while the mobile device is outside of the first threshold distance. When the mobile device is between the first and second threshold distances, the ranging/location frequency may be increased. This may be through a stepwise increase, a linear increase, or other mechanisms.

Similar to the transaction illustrated in <FIG>, the verifier device <NUM> is used to validate a credential received from the user device <NUM>. In the embodiment illustrated in <FIG>, the verifier device <NUM> uses a secondary verifier device <NUM> to perform at least part of the validation. The secondary verifier device <NUM> may be a server, cloud service, or other compute device. The secondary verifier device <NUM> may be co-located with the verifier device <NUM>, such as in a configuration where the verifier device <NUM> is in a storefront area and the secondary verifier device <NUM> is a server room. The secondary verifier device <NUM> may be more remotely located from the verifier device <NUM>, such as over a wide-area network (WAN) like the Internet. The transaction flow is as follows.

As with the embodiment illustrated in <FIG>, when a user device <NUM> is within wireless communication range of a verifier device <NUM>, the verifier device <NUM> may initiate a wireless connection (operation <NUM>). The wireless connection may be formed over any type of wireless communication protocol including, but not limited to BLUETOOTH®, BLUETOOTH LOW ENERGY (BLE), WI-FI, ZIGBEE, or the like.

The user device <NUM> transmits all of the contents of the credential to the verifier device <NUM> as separately encrypted data elements (operation <NUM>). The transmission operation (operation <NUM>) may be conditioned on a triggering event, as described above in <FIG>.

After receiving the parts of the credential, the verifier device <NUM> determines which data elements are needed to verify the user device <NUM> (operation <NUM>). This may be performed as described above in <FIG>. The verifier device <NUM> then transmits data or instructions to the user device <NUM> to initiate the user device <NUM> to prompt the user of the user device <NUM> for consent to share the needed data elements (operation <NUM>).

The user may indicate consent via the user interface presented on the user device <NUM> (operation <NUM>) and the user device <NUM> transmits the decryption keys for those data elements to the verifier device <NUM> (operation <NUM>). The decryption keys are transmitted to the verifier device <NUM> in operation <NUM>. The decryption keys may be one-time use keys, ephemeral keys, limited time keys, or other short-term or limited-use keys. Once the verifier device <NUM> obtains the keys for the requested data elements, the data elements are decrypted and verified.

In order to decrypt the data elements, the verifier device <NUM> transmits the decryption keys to a secondary verifier device <NUM> (operation <NUM>). Optionally, the verifier device <NUM> may also transmit the encrypted portions of the credential to the secondary verifier device <NUM>. The secondary verifier device <NUM> checks the status of the decryption keys and decrypts the corresponding portions of the credential (operation <NUM>). The unencrypted portions may be transmitted back to the verifier device <NUM> for verification. Alternatively, the secondary verifier device <NUM> may perform some or all of the credential verification. The results of the verification or the unencrypted data elements are transmitted to the verifier device <NUM> (operation <NUM>). Optionally the data elements may be encrypted when sent from the secondary verifier device <NUM> to the verifier device <NUM> using an encryption scheme agreed upon between the secondary verifier device <NUM> and the verifier device <NUM> to maintain security during the communication.

The secondary verifier device <NUM> may maintain a key repository that includes the operating status of various decryption keys. The keys may have expiration dates or times, operational dates or time ranges, geographical constraints, or other limitations or policies that control how or when a decryption key may be used. The secondary verifier device <NUM> is used to control how long or when a decryption key may be used. In this configuration, a user is guaranteed that a decryption key provided to a verifying agent is only available for a certain time after it is provided. In other words, encrypted data elements are made available for a limited time or for a limited number of decryptions. This is an extra layer of security to ensure that an encrypted data element is not available forever at a verifier device <NUM> because the key to decrypt the data element is expired after a certain time. Other policies may be used to secure the cleartext (e.g., unencrypted) forms of the data elements while they are being verified.

<FIG> is a message sequence diagram illustrating an interaction between a user device <NUM> and a verifier device <NUM>, according to another embodiment. While the various processes will be described in accordance with illustrative steps performed in a particular order, it should be appreciated that embodiments of the present disclosure are not so limited and that any of the process steps depicted and described herein can be performed in any order or in parallel with one another.

Similar to the transaction illustrated in <FIG> and <FIG>, the verifier device <NUM> is used to validate a credential received from the user device <NUM>. In the embodiment illustrated in <FIG>, the verifier device <NUM> uses a secondary verifier device <NUM> as part of the validation operation. The secondary verifier device <NUM> may be a server, cloud service, or other compute device. The secondary verifier device <NUM> may be co-located with the verifier device <NUM> or may be more remotely located from the verifier device <NUM>, such as over a wide-area network (WAN) like the Internet. The transaction flow is as follows.

After receiving the parts of the credential, the verifier device <NUM> determines which data elements are needed to verify the user device <NUM> (operation <NUM>). This may be performed as described above in <FIG>.

The verifier device <NUM> request an access token from the secondary verifier device <NUM> (operation <NUM>). The request provides the identification of the user device <NUM> and identifies the portions of the credential that the verifier device <NUM> has determined it needs to verify in operation <NUM>.

The secondary verifier device <NUM> transmits an access token to the user device <NUM> (operation <NUM>), in response to the request of operation <NUM>. The access token may be transmitted directly from the secondary verifier device <NUM> to the user device <NUM>, or by using the verifier device <NUM> as a communication conduit, for example, by receiving the access token from the secondary verifier device <NUM> and relaying the access token to the user device <NUM>. The access token is signed by the secondary verifier device <NUM>. In operation <NUM>, the secondary verifier device <NUM> also transmits information of which data elements are requested by the verifier device <NUM>. This information may be relayed by the verifier device <NUM> in another implementation.

At operation <NUM>, the user device <NUM> authenticates the access token. After verifying the access token, the user device <NUM> presents a user interface to prompt the user of the user device <NUM> for permission to share the requested data elements (operation <NUM>). Capturing user consent in operation <NUM> may be optionally performed in some instances.

The user may indicate consent via the user interface presented on the user device <NUM> and the user device <NUM> transmits the decryption keys for the requested data elements to the verifier device <NUM> (operation <NUM>). The decryption keys may be one-time use keys, ephemeral keys, limited time keys, or other short-term or limited-use keys. Once the verifier device <NUM> obtains the keys for the requested data elements, the data elements are decrypted and verified (operation <NUM>).

Similar to the transaction illustrated in <FIG>, the verifier device <NUM> is used to validate a credential received from the user device <NUM>. In the embodiment illustrated in <FIG>, the verifier device <NUM> uses a secondary verifier device <NUM> as part of the validation operation. The secondary verifier device <NUM> may be a server, cloud service, or other compute device. The secondary verifier device <NUM> may be co-located with the verifier device <NUM> or may be more remotely located from the verifier device <NUM>, such as over a wide-area network (WAN) like the Internet. The transaction flow is as follows.

The user device <NUM> captures the user input consenting to share some or all of the data elements requested by the verifier device <NUM> (operation <NUM>). At operation <NUM>, the user device <NUM> generates an access token. The access token may be signed by the user device <NUM> and includes a list of the data elements that the user consented to share. In an embodiment, the access token includes key derivation information (e.g., random transactional nonce) used by the secondary verifier device to generate the decryption key.

The access token is transmitted to the verifier device <NUM> (operation <NUM>). The verifier device <NUM> retransmits the access token and list of data elements to the secondary verifier device <NUM> (operation <NUM>).

At operation <NUM>, the secondary verifier device <NUM> authenticates the access token. If the access token is authenticated, then the secondary verifier device <NUM> analyzes the list of data elements and obtains the corresponding decryption keys (operation <NUM>). The decryption keys may be stored in a secure container. The decryption keys may be ephemeral keys. The decryption keys may be derived using key derivation schemes from shared master keys between the user device <NUM> and the secondary verifier device <NUM> and made ephemeral with a random transaction nonce that was previously transmitted from the user device <NUM> using the access token. The secondary verifier device <NUM> transmits the appropriate decryption keys to the verifier device <NUM> (operation <NUM>) to decrypt portions of the credential and verify the data elements (operation <NUM>).

<FIG> is a flowchart illustrating a method <NUM> of securely transmitting user credential data, according to an embodiment. The method <NUM> begins at operation <NUM>, where before the user and the verifying agent begin to interact, a verifier device having an available wireless connection is identified. The wireless connection having a wireless connection strength.

At operation <NUM>, it is determined, again before the user and the verifying agent begin to interact, that a triggering event occurs, the triggering event based on the wireless connection strength. In an embodiment, the triggering event is that the wireless connection strength is greater than a threshold amount.

At operation <NUM>, when the triggering event occurs, and before the user and the verifying agent begin to interact, the mobile device connects to the verifier device and transmits a digital credential to the verifier device. The digital credential includes a plurality of data elements, each of plurality of data elements are separately encrypted parts and, each of the plurality of data elements are encrypted using distinct encryption keys. The parts are transmitted.

In an embodiment, the triggering event comprises the wireless connection strength is greater than a threshold amount. In another embodiment, the triggering event comprises a rate of change of the wireless connection strength is greater than a threshold amount. In another embodiment, the triggering event comprises a difference between the wireless connection strength and a second wireless connection strength of a second verifier device is greater than a threshold amount.

In an embodiment, the triggering event is determined by characteristics of the wireless connection between the verifier device and the mobile device, including time of flight or angle of arrival, that allows the verifier device or the mobile device to determine spatial vicinity between the verifier device and mobile device be smaller than a threshold distance.

In an embodiment, each of the plurality of data elements is encrypted using corresponding ephemeral keys.

In an embodiment, the wireless connection strength is measured using a received signal strength indicator. In an embodiment, the available wireless connection comprises a wireless protocol from the IEEE <NUM>. <NUM> family of standards.

At operation <NUM>, after the user and the verifying agent begin to interact, a request to access a requested data element of the digital credential is received.

At operation <NUM>, a user of the mobile device is prompted for consent to share the requested data element. When the user consents sharing the requested data element, information is transmitted to the verifier device, where the information is used to decrypt only the requested data element (operation <NUM>). In a further embodiment, the verifier device is to verify the requested data element.

In an embodiment, the verifier device is to use a secondary verifier device to verify the requested data element. In a further embodiment, the verifier device is to transmit a request for an access token to the secondary verifier device, the secondary verifier device to generate and transmit the access token to the mobile device, and wherein the mobile device is to transmit the information to decrypt only the requested data element to the verifier device after authenticating the access token.

In an embodiment, the information includes a decryption key, the decryption key configured to decrypt only the requested data element.

In an embodiment, the information includes an access token generated by the mobile device, the access token used by the verifier device to access the requested data element.

In an embodiment, the verifier device is to transmit the access token to a secondary verifier device, which authenticates the access token and provides a decryption key to the verifier device to decrypt the requested data element.

A user may be issued one or more credentials. For example, the user may be issued a government-issued digital credential (e.g., a driver's license, passport, or other credential demonstrating identity). The digital credential may include various data elements about the user, such as the user's name, address, physical characteristics, photograph, date of birth, biometric information (e.g., fingerprints), where the user has traveled, or the like. Additionally, the digital credential may include information about the issuer of the credential, such as the city, state, or country that issued the credential; the department, office, or agency that issued the credential; an expiration date or valid date range; a digital signature of the issuer; or the like. The credential may be stored on a user device, such as a mobile phone.

The user may be at an airport checking luggage. To check luggage, the user is required to show a boarding pass and identification (e.g., a license or passport) to a luggage attendant. Instead of showing the luggage attendant a form of physical identification, the user may present the digital credential.

As the user approaches the luggage attendant, the credential is transmitted to a verifier device used by the luggage attendant. The credential is transmitted in parts with each part separately encrypted using distinct keys. The luggage attendant is required to check that the name on the boarding pass matches the name on the identification and also check that the identification appears to be that of the user. In order to authenticate the identification, the luggage attendant examines the name field and a photo to compare to the user. As such, the verifier device requests access to the "name" data element and the "photograph" data element from the credential. A prompt is provided to the user for consent to share the name and photo from the credential. When the user consents through interaction with the user interface, the decryption keys for only the name and photograph data elements is provided to the verifier device. As a result, the verifier device is able to decrypt these portions of the credential and present them in an unencrypted form to the luggage attendant.

Later, when the user is passing through the security gates to move from the check-in area to the concourse, a security guard may use a verifier device to check the user's name and area of origin. In this instance, the verifier device may request access to the "name" and "issuer" data elements to verify and authenticate the user's identity and credential. After consent is provided, the user device will transmit keys to decrypt the relevant data elements. As described above, the keys may be limited use keys.

Embodiments may be implemented in one or a combination of hardware, firmware, and software. Embodiments may also be implemented as instructions stored on a machine-readable storage device, which may be read and executed by at least one processor to perform the operations described herein. A machine-readable storage device may include any non-transitory mechanism for storing information in a form readable by a machine (e.g., a computer). For example, a machine-readable storage device may include read-only memory (ROM), random-access memory (RAM), magnetic disk storage media, optical storage media, flash-memory devices, and other storage devices and media.

A processor subsystem may be used to execute the instruction on the machine-readable medium. The processor subsystem may include one or more processors, each with one or more cores. Additionally, the processor subsystem may be disposed on one or more physical devices. The processor subsystem may include one or more specialized processors, such as a graphics processing unit (GPU), a digital signal processor (DSP), a field programmable gate array (FPGA), or a fixed function processor.

Modules may be hardware, software, or firmware communicatively coupled to one or more processors in order to carry out the operations described herein. Modules may be hardware modules, and as such modules may be considered tangible entities capable of performing specified operations and may be configured or arranged in a certain manner. In an example, the software may reside on a machine-readable medium. Accordingly, the term hardware module is understood to encompass a tangible entity, be that an entity that is physically constructed, specifically configured (e.g., hardwired), or temporarily (e.g., transitorily) configured (e.g., programmed) to operate in a specified manner or to perform part or all of any operation described herein. For example, where the modules comprise a general-purpose hardware processor configured using software; the general-purpose hardware processor may be configured as respective different modules at different times. Modules may also be software or firmware modules, which operate to perform the methodologies described herein.

Circuitry or circuits, as used in this document, may comprise, for example, singly or in any combination, hardwired circuitry, programmable circuitry such as computer processors comprising one or more individual instruction processing cores, state machine circuitry, and/or firmware that stores instructions executed by programmable circuitry. The circuits, circuitry, or modules may, collectively or individually, be embodied as circuitry that forms part of a larger system, for example, an integrated circuit (IC), system on-chip (SoC), desktop computers, laptop computers, tablet computers, servers, smart phones, etc..

As used in any embodiment herein, the term "logic" may refer to firmware and/or circuitry configured to perform any of the aforementioned operations. Firmware may be embodied as code, instructions or instruction sets and/or data that are hard-coded (e.g., nonvolatile) in memory devices and/or circuitry.

<FIG> is a block diagram illustrating a machine in the example form of a computer system <NUM>, within which a set or sequence of instructions may be executed to cause the machine to perform any one of the methodologies discussed herein, according to an embodiment. In alternative embodiments, the machine operates as a standalone device or may be connected (e.g., networked) to other machines. In a networked deployment, the machine may operate in the capacity of either a server or a client machine in server-client network environments, or it may act as a peer machine in peer-to-peer (or distributed) network environments. The machine may be a mobile device, a personal computer (PC), a tablet PC, a hybrid tablet, a personal digital assistant (PDA), a mobile telephone, a kiosk, a beacon, or any machine capable of executing instructions (sequential or otherwise) that specify actions to be taken by that machine. Further, while only a single machine is illustrated, the term "machine" shall also be taken to include any collection of machines that individually or jointly execute a set (or multiple sets) of instructions to perform any one or more of the methodologies discussed herein. Similarly, the term "processor-based system" shall be taken to include any set of one or more machines that are controlled by or operated by a processor (e.g., a computer) to individually or jointly execute instructions to perform any one or more of the methodologies discussed herein.

Example computer system <NUM> includes at least one processor <NUM> (e.g., a central processing unit (CPU), a graphics processing unit (GPU) or both, processor cores, compute nodes, etc.), a main memory <NUM> and a static memory <NUM>, which communicate with each other via a link <NUM> (e.g., bus). The computer system <NUM> may further include a video display unit <NUM>, an alphanumeric input device <NUM> (e.g., a keyboard), and a user interface (UI) navigation device <NUM> (e.g., a mouse). In one embodiment, the video display unit <NUM>, input device <NUM> and UI navigation device <NUM> are incorporated into a touch screen display. The computer system <NUM> may additionally include a storage device <NUM> (e.g., a drive unit), a signal generation device <NUM> (e.g., a speaker), a network interface device <NUM>, and one or more sensors (not shown), such as a global positioning system (GPS) sensor, compass, accelerometer, gyrometer, magnetometer, or other type of sensor.

The storage device <NUM> includes a machine-readable medium <NUM> on which is stored one or more sets of data structures and instructions <NUM> (e.g., software) embodying or utilized by any one or more of the methodologies or functions described herein. The instructions <NUM> may also reside, completely or at least partially, within the main memory <NUM>, static memory <NUM>, and/or within the processor <NUM> during execution thereof by the computer system <NUM>, with the main memory <NUM>, static memory <NUM>, and the processor <NUM> also constituting machine-readable media.

While the machine-readable medium <NUM> is illustrated in an example embodiment to be a single medium, the term "machine-readable medium" may include a single medium or multiple media (e.g., a centralized or distributed database, and/or associated caches and servers) that store the one or more instructions <NUM>. The term "machine-readable medium" shall also be taken to include any tangible medium that is capable of storing, encoding or carrying instructions for execution by the machine and that cause the machine to perform any one or more of the methodologies of the present disclosure or that is capable of storing, encoding or carrying data structures utilized by or associated with such instructions. The term "machine-readable medium" shall accordingly be taken to include, but not be limited to, solid-state memories, and optical and magnetic media. Specific examples of machine-readable media include nonvolatile memory, including but not limited to, by way of example, semiconductor memory devices (e.g., electrically programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM)) and flash memory devices; magnetic disks such as internal hard disks and removable disks; magneto-optical disks; and CD-ROM and DVD-ROM disks.

The instructions <NUM> may further be transmitted or received over a communications network <NUM> using a transmission medium via the network interface device <NUM> utilizing any one of a number of well-known transfer protocols (e.g., HTTP). Examples of communication networks include a local area network (LAN), a wide area network (WAN), the Internet, mobile telephone networks, plain old telephone (POTS) networks, and wireless data networks (e.g., Bluetooth, Wi-Fi, <NUM>, and <NUM> LTE/LTE-A, <NUM>, DSRC, or WiMAX networks). The term "transmission medium" shall be taken to include any intangible medium that is capable of storing, encoding, or carrying instructions for execution by the machine, and includes digital or analog communications signals or other intangible medium to facilitate communication of such software.

Claim 1:
A verifier device (<NUM>; <NUM>; <NUM>; <NUM>; <NUM>) comprising:
memory; and
at least one processor, which when configured by instructions stored on the memory, is operable to perform the operations comprising:
initiating a wireless connection with a user device (<NUM>);
receiving a digital credential from the user device (<NUM>), wherein the digital credential includes a plurality of data elements, the plurality of data elements received as a plurality of separately encrypted parts, wherein each of the plurality of separately encrypted parts are encrypted using independent encryption keys, and
each of the separately encrypted parts comprising one or more of the data elements;
determining which of the data elements are to be used to verify the user device (<NUM>);
transmitting a request to the user device (<NUM>) for consent from a user of the user device (<NUM>) for access to one or more of the data elements that are determined to be used to verify the user device (<NUM>); and
receiving one or more decryption keys
from the user device (<NUM>), the one or more decryption keys enabling decryption of one or more of
the separately encrypted parts comprising the one or more data elements for which the user provided consent.