Techniques for Providing Credentials and Other Information

This document pertains generally, but not by way of limitation, to techniques for providing virtualized credentials.

Governments (or other “issuing entities”) are increasingly interested in issuing virtualized ID cards to citizens. The virtualized ID cards may be provided on mobile phones, or other similar personal computing device, and displayed using an application (or “app”) running on the device.

In some approaches, the app vendor decides on what information is used to present a document. For example, data from the document itself may be used. The issuing entity is not able to specify what information to use or not to use to present the document. In some such approaches, the app needs to know the document type in order to know which data element corresponds to which attribute. In addition, an app with a software development kit (SDK) may need to know which workflow is applicable to which document.

With some approaches, the focus for electronic wallet apps is on documents and bookmarks are typically left to the browser on the mobile device.

This disclosure describes techniques for providing more control to an issuer, e.g., governmental entity, and more particularly their backend team, which may provide citizens with a personalized virtualized experience. This may be achieved by the issuer provisioning adequate data, which is made available to a mobile App and/or verification devices. By using various techniques, the issuer may deliver such information using the same approach as for document data and even along with document data. The information may be packaged in a way that is no different from provisioning a document. In addition, because the document data is digitally signed by the issuer, it ensures authentic information for the user interface

In some aspects, this disclosure is directed to a method of providing a virtualized credential of a holder, comprising: receiving, from an issuing entity and on a device of the holder, a set of document data elements and a set of non-document data elements, wherein the document data elements at least partially define the virtualized credential, wherein the document data elements are defined in a set of document data element fields of a data structure, wherein the non-document data elements are defined in a set of non-document data element fields of the data structure, and wherein the non-document data elements are defined by the issuing entity; and displaying, on a user interface of the device of the holder, information representing the set of document data elements in a format defined by the non-document data elements, wherein the information at least partially defines the credential.

In some aspects, this disclosure is directed to at least one machine-readable medium including instructions for providing a virtualized credential of a holder, that, when executed by a machine, cause the machine to perform operations to: receive, from an issuing entity and on a device of the holder, a set of document data elements and a set of non-document data elements, wherein the document data elements at least partially define the virtualized credential, wherein the document data elements are defined in a set of document data element fields of a data structure, wherein the non-document data elements are defined in a set of non-document data element fields of the data structure, and wherein the non-document data elements are defined by the issuing entity; and display, on a user interface of the device of the holder, information representing the set of document data elements in a format defined by the non-document data elements, wherein the information at least partially defines the credential.

In some aspects, this disclosure is directed to at least one machine-readable medium including instructions for providing a virtualized credential of a holder, that, when executed by a machine, cause the machine to perform operations to: transmitting, from an issuing entity to a device of the holder, a set of document data elements and a set of non-document data elements, wherein the document data elements at least partially define the virtualized credential, wherein the document data elements are defined in a set of document data element fields of a data structure, wherein the non-document data elements are defined in a set of non-document data element fields of the data structure, wherein the non-document data elements are defined by the issuing entity, wherein the non-document data elements define a format for displaying information representing the set of document data elements on a user interface of the device of the holder, wherein the information at least partially defines the credential.

In some aspects, this disclosure is directed to at least one machine-readable medium including instructions for providing a virtualized credential of a holder, that, when executed by a machine, cause the machine to perform operations to: receive, from an issuing entity and on a device of the holder, a set of non-document data elements, wherein the non-document data elements are defined in a set of non-document data element fields of a data structure, wherein the non-document data elements are defined by the issuing entity, wherein document data elements at least partially define the virtualized credential, and wherein the document data elements are defined in a set of document data element fields of the data structure; and display, on a user interface of the device of the holder, information representing the set of non-document data elements in a format defined by the non-document data elements.

Governmental entities (or other “issuers”) are increasingly interested in issuing virtualized(or digital) documents (or credentials) to citizens. For example, a governmental entity may issue to a citizen one or more virtualized credentials, such as an identification (ID) card, a vehicle registration, various certificates (such as birth certificates and marriage certificates), various permits and licenses (such as gun licenses or fishing permits), and a voting card. Issuing virtualized credentials may have several benefits, including enhanced privacy, easier access, and mobile convenience. For example, the virtualized credentials, such as a driver's license, may be provided on a mobile phone, or other similar personal computing device, and displayed using an application (or “App”) running on the device.

The present inventors have recognized the desirability of providing more control to the issuer, e.g., governmental entity, and more particularly their backend team, which may provide citizens with a personalized virtualized experience. This may be achieved by the issuer provisioning adequate data, which is made available to the mobile App and/or verification devices. By using various techniques of this disclosure, the issuer may deliver such information using the same approach as for document data and even along with document data. The information may be packaged in a way that is no different from provisioning a document. In addition, because the document data is digitally signed by the issuer, it ensures authentic information for the user interface (UI).

The techniques of this disclosure may provide a number of benefits. For example, The issuer may control how the object is presented in the App, e.g., the text, icon and picture that may be used, and which is not dependent on the content of a document, such as the virtualized credential, e.g., driver's license. The International Organization for Standardization (ISO) standard ISO/IEC 18013-5 mDL mandates that a Latin alphabet be used for document data. However, by using techniques of this disclosure, the UI information may be separated from the document data present, and they may be provisioned at the same time.

As another example, the issuer may control the behavior of the App by indicating what actions are available to the user for a provisioned item, group of items or for the App itself, such as connecting to an issuer website, enrolling for a new document, requesting a modification to the data, deleting an item that may be associated with a document, presenting document data, etc. This may be desirable because the issuer knows what the item is about, e.g., the document type or if it is a service, and knows what is applicable to do.

As another example, the issuer may control what actions are available for a group of items. This may allow the issuer to control where that action should be presented (e.g., an issuer tab in the App). The action may be performed on multiple items at the same time or be unrelated to the items.

As another example, the issuer may deliver additional information valuable for a verification such as a web address, e.g., URL, to get an up-to-date status for that particular document. This may add information in non-document data that is not directed to the UI but instead for a verification device.

With the techniques of this disclosure, the App does not need to understand the type of document in order to present it. This may be quite valuable because each document is a set of data elements whose identifiers are specific. In addition, the App does not need to understand what any of the configured action that object specifies are about as long as the App facilitates the presentation of the information and supports the different steps of the workflow associated with the action. In short, the purpose is set by the issuer and presentation of it by the App in the UI may be sufficient for the end user to know what to do without the App needing to know anything more about it. In some examples, the mobile App where this gets provisioned to can be a browser App with extensions to support these specific features.

1 FIG. 7 FIG. 100 100 100 100 100 102 104 100 100 106 106 700 106 104 is a conceptual diagram illustrating a flow of data between an issuer and a user. A government has various issuing entities or issuersA-C for different kinds of credentials or documents. For example, a first issuing entityA may issue drivers licenses, a second issuing entityB may issue birth certificates, and a third issuing entityC may issue fishing licenses. Each issuing entity may have documents and/or servicesto offer to a user, such as a credential holder or holder, e.g., a citizen. The issuing entitiesA-C may provide a set of document data elements and a set of non-document data elements to an issuance system, e.g., a backend of the issuing entity. The issuance systemmay be similar to the machinein. The issuance systemmay mobilize any documents and prepare the data to issue the virtualized credentials to the holder.

The document data elements at least partially define a virtualized credential, e.g., a driver's license of the holder. The document data elements may be defined in a set of document data element fields of a data structure (or “container”). In some examples, the data structure may be defined by an international standard, such as the ISO/IEC 18013-5 standard (“Personal identification—ISO-compliant driving license—Part 5: Mobile driving license (mDL) application”), and ISO/IEC AWI TS 23220-4 (“Cards and security devices for personal identification—Building blocks for identity management via mobile devices—Part 4: Protocols and services for operational phase”), the entire contents of each being incorporated herein by reference.

The non-document data elements may be defined in a set of non-document data element fields of the data structure. The non-document data elements may be defined by the issuing entity. In some examples, the document data elements may include virtualized credential attributes, and the non-document data elements may be used to present the virtualize credential and present actions available to perform. As an example, a non-document data element, such as an icon associated with the virtualized credential or an image of the holder associated with the virtualized credential, may be defined or provisioned by the issuing entity.

In some examples, only some of the information is provisioned by the issuing entity. For example, a virtualized credential (or document) may be provisioned without an associated action, or an action, such as displaying a link to a website, may be provisioned without an associated document. In some examples, the document data elements and the non-document data elements may be defined under different namespaces of the data structure.

106 108 108 110 108 108 108 112 112 108 112 The issuance systemmay issue the set of document data elements and the set of non-document data elements to a software development kit (SDK). In some examples, the SDKmay be installed on the holder's mobile device, e.g., mobile phone. The SDKmay include instructions to execute various workflows specified by the issuing entity. The SDKmay handle various specificities of the documents, e.g., digital travel credentials (DTC) versus mobile document (mdoc). The SDKmay interact with an application or Appinstalled on the mobile device. The SDKmay enforce what the issuing entity made available to the Application or App, e.g., a presentation layer, in order to present the item independently of what that item is. It should be noted that the SDK is not a necessary component. However, the SDK may be desirable to include because it may bring additional benefits to the App, such as getting a new version and benefitting from new features without changing the App and its UI.

112 114 104 104 112 112 108 114 104 The Appmay receive, via a UI, user input from the holderand may act as an intermediary between the issuing entity and the holder. The Appmay display information representing the set of document data elements in a format defined by the non-document data elements, where the information at least partially defines the credential. The Appmay follow the lead from the SDKto support the workflow for the action to perform, such as to display a code, e.g., QR code, on the UI. The holdermay decide which workflow to select based on information provisioned by the issuing entity.

112 108 112 108 108 106 By using the techniques of this disclosure and having the benefit of an SDK that handles the specifics of doc type and workflows, Appdoes not need to be changed to handle new actions, services, documents, etc. Rather, an issuing entity may update the SDK, for example, with any changes. When a holder selects an action, service, document, etc. using the user interface, the Appmay call the SDK, which will execute the appropriate workflows for handling. The SDKmay communicate with the issuance system.

112 112 112 108 108 The techniques of this disclosure may allow an issuing entity to provision more than just documents to the App, such as actions and services. For example, an issuing entity pay provide a link to a website or to backend software that is ported into the Appwhen the holder selects a particular service, e.g., taxes or renewing a driver's license, provided by the issuing entity. When the user selects a service, the Appprovides an indication to the SDKrepresenting the selection. The SDKmay then retrieve the provisioned data, which is defined by the set of non-document data elements in the data structure, and execute a workflow.

In addition, these techniques allow a government or country to provision UI templates or information that designate how certain information may be displayed. For example, one government may have a different looking UI than another government. In some examples, the URL may point to a web page whose HTML title and HTML favicon may be used to provision the information for the particular tab title and icon. In some examples, the URL may point to the web page to use as a template. In some examples, the URL may point to a JSON object that contains the information used to customize the UI.

112 108 104 100 108 The Appmay control the UI template and the SDKmay be the source for the provisioned or imported item(s) and action(s) to present to the user or holder. The user understands the information from the issuing entity, e.g., issuing entityA, recognizes the item(s) and may select an action. The SDKmay execute a workflow specified by the issuing entity for the selected action.

108 112 During the workflow, the SDKmay use callbacks to deliver status updates and get support from the Appto perform elementary actions.

112 The issuing entity knows what the content is about, what kind of content it is, and what can be done with it. The Appfollows what is specified by the issuing entity to present the content and to present application actions.

the underlying document type(s), which means the UI template is independent from the underlying document type and automatically inherits from what is supported by the SDK with no change to the UI template. the workflow to execute, which means the App automatically benefits from what is supported by the SDK with no change to the UI template. The SDK API is independent from:

112 The Appmay support a set of elementary actions, each applicable to different workflows. Such a solution may ensure that new workflow may be introduced with no change to the App except for compiling a new version.

2 FIG. 2 FIG. 2 FIG. 2 FIG. 200 200 114 110 200 200 200 200 200 200 200 114 is an example of a user interface on a mobile device displaying various virtualized credentials to a holder. The example shown inis an example of a digital wallet and illustrates four virtualized credentialsA-D that may be selected by a holder using the UIfor display on the mobile device, including a driver's licenseA, a vehicle registrationB, a birth certificateC, and a vaccinationD. The information to present such credentials is delivered by the issuer as part of the non-document data and not from the document data. Each of the virtualized credentialsA-D ofonly show a portion of the available information. In addition, available actions are provided by the non-document data, such as the ability to “engage”, as seen in. By selecting a credential, e.g., vaccinationD, the holder may display additional information on the UI, such as one or more vaccination records. The issuer may have provisioned an action to show relevant information about the vaccination records. For these kinds of actions, the UI may present a template to display the data and this template may be populated with information from the document data to avoid duplication. What is provisioned is the template and the App or SDK knows what to inject when presenting the data to the user. That again allows the issuer to control what is shown to the user.

3 FIG. 3 FIG. 3 FIG. 200 114 110 200 114 is another example of a user interface on a mobile device displaying various virtualized credentials to a holder. The example shown inis another example of a digital wallet and illustrates a virtualized credentialsA, e.g., a driver's license, that may be selected by a holder using the UIfor display on the mobile device. The information to present such credentials is delivered by the issuer as part of the non-document data and not from the document data. In addition, available actions are provided by the non-document data, such as the ability to “delete”, “edit”, and “renew”, as seen in. By selecting a credential, e.g., a driver's licenseA, the holder may display additional information on the UI, such as an image of the holder, an address of the holder, a birthdate of the holder, etc.

2 FIG. 3 FIG. 114 200 300 302 114 300 114 114 114 In addition, unlike the document-centric example shown inand using various techniques of this disclosure, the example shown inmay display, on the UI, information representing the set of document data elements in a format defined by the non-document data elements, where the information at least partially defines the credential and where the non-document data elements are defined by the issuing entity. For example, the driver's licenseA depicted displays three lines of text, personal information associated with the virtualized credential in the format defined by the non-document data elements, such as a picture or an imageof the holder, and a status iconthat indicates whether the credential is active, expired, etc. The issuing entity, e.g., a department of motor vehicles, may define, via non-document data elements, the information displayed in each of the three lines of text, how that information is displayed on the UI, and a positioning of the imageon the UI, for example. With these techniques, the data is fully independent from the underlying doctype. In addition, the issuing entity may determine what is available to present in the UI. The item displayed on the UImay represent a document that may be shared, e.g., such as a driver's license, or be used by the issuer to present local actions.

114 114 304 306 308 In some examples, the UIof the device of the holder may display an icon associated with the virtualized credential in the format defined by the non-document data elements. The holder may select, using the UI, the icon and action associated with the document or virtualized credential, such as a delete icon, an edit icon, or a renew icon, which may all be provisioned by the issuing entity. In this disclosure, information that is provisioned by the issuing entity allows the mobile device to: 1) present the item, 2) know if the item is a document or service, and 3) know what workflow is associated with an action (independently from the text provisioned to present the action). This may be important in the case of an App with SDK because the App is still aware about the underlying workflow that will be started and may act accordingly. For example, the App may know that the workflow is about the “delete” action and may ask the user to confirm before sending the call to the SDK.

304 306 308 108 112 306 200 306 1 FIG. 1 FIG. The delete icon, the edit icon, and the renew iconmay be associated with non-document data elements defined by the issuing entity, such as the department of motor vehicles. In response to a selection, the SDKof(or the Appof) may execute a workflow at least partially defined by the non-document data elements. For example, a selection of the edit iconmay execute a workflow that requests a modification to at least one of the document data elements of the virtualized credential, e.g., the driver's licenseA. The edit iconmay be an elementary action that applies any form to fill, for example. The provisioned title and purpose may specify what to do with the data.

304 200 108 112 1 FIG. 1 FIG. As another example, a selection of the delete iconmay execute a workflow that requests that information associated with the document, e.g., the driver's licenseA, be deleted. In response, SDKof(or the Appof) may execute a workflow that generates and transmits, to the issuing entity, a revocation request where revocation results in deletion of the credential or document.

308 As another example, a selection of the renew iconmay execute a workflow that renews the provisioned data by checking for updates.

310 Along with the delete, edit, and renew actions, the issuing entity may provision other actions, such as “show”, “QR code”, “message”, “verify”, and “web”, which may be executable by the App or the SDK. In some examples, these actions may include a call for the SDK to execute a workflow. In other examples, these actions may be a call to the SDK to return an action for the App to execute. It should be noted that some workflows may be called without the need for the issuing entity to provision, e.g., the “engage” icon.

The ISO standard for mobile driving license application currently mandates that the Latin alphabet used for the majority of document data elements such as the first name, last name, address, etc. The Latin alphabet requirement includes the principal mandatory fields expected to be present in the document. The Latin alphabet requirement is a limitation for countries that do not use a Latin alphabet because it means the information in the ISO compliant document is not necessarily understandable by the holder of the document. The latest version of the ISO standard allows for a small number of optional non-Latin fields (such as family_name_national_character and given_name_national_character) and a domestic namespace where information in a local language may be used. However, this is still a very limited design.

104 112 112 114 112 112 In addition to presenting challenges to the holder, not provisioning UI data, such as by the issuing entity, may make the Appresponsible for deciding how to parse and present the information to the holder. As such, the Appmust decide which information to select from a document to present in the UI, which means the Appmust also understand the document type (e.g., identifiers of specific data elements). This prevents the Appfrom being truly agnostic to the underlying data structure and less likely to be able to support any document type without changes to this logic.

By using various techniques of this disclosure, the UI information may be provisioned by the issuing entity. For example, the mobile device may display on the user interface information representing the set of document data elements in the format defined by the non-document data elements (defined by the issuing entity), which may include displaying text using an alphabet different from that used by the received set of document data elements, e.g., display Chinese or Arabic instead of a Latin alphabet. Using these techniques, the alphabet is different from the document attributes and all are received within the same document data elements. Provisioning the UI information makes it independent from document type, document alphabet, etc.

In order to make it easier for an issuer and app developer, a JavaScript object notation (JSON) format may be used to store the UI data. The UI data may be stored inside the Concise Binary Object Representation (CBOR) mdoc data structure during the provisioning process and then extracted by the SDK at the time the UI data is provisioned. This technique may enable the use of a standardized JSON query technology to be used to query the data and discover the UI content (using technologies such as JMESpath).

In addition to the ability to provision information for the UI that is separate from the document data, the techniques of this disclosure also provide the ability to provision an action or information just for the UI, such as when there is no document to share. This may include a set of actions to be presented in the App, such as the option to connect to an issuer web site or perform certain functionality, such as a transaction. As an example, the provisioned action may specify that the SDK, for example, execute a workflow. In some examples, the workflow may return an elementary action for the App to execute to support the workflow, such as “show QR code”. In some examples, the action may be related to the document data, such as “show”, “edit”, and “temporarily share”, such as for a vehicle registration.

3 FIG. 114 314 Non-limiting examples of provisioned information for the UI that is separate from the document data are depicted in. For example, the UImay display the “Service home” icon. When the holder selects the icon, the SDK, for example, may execute a workflow at least partially defined by the non-document data elements that connects to a website of the issuing entity, such as a homepage. In some examples, the SDK may execute a workflow where the workflow requests one or more actions for the App to execute. In some examples, the SDK may execute a workflow that returns an action for the App to execute.

114 114 316 318 318 In some examples, the non-document data elements include information representing a service made available by the issuing entity. The UImay display the information representing the service made available by the issuing entity. For example, the UImay display a “Medicare” icon, “Taxes” icon, or the like that, when selected, connect to a website, for example. A “Documents” iconmay display a document.

In this manner, the issuing entity may provision information for the App to connect to a specific website and for a specific purpose. The action may be presented to the holder in the form of a purpose (e.g. to initiate to a government service) rather than the underlying action itself. For example, this may include a link to access a specific service that may not may not be related to the document the data has been provisioned with. For example, a link to Citizen services, not specific to document.

In addition, an issuing entity may also elect for some of the services (or bookmarks) to be deleted while others, such as service home, remain. This may provide the opportunity for the end user to only keep what is relevant while the issuing entity may ensure that important bookmarks/services cannot be removed.

In addition, the issuing entity may provision information containing data that the App should display as a code, such as a QR code. For example, the data could be a vaccination passport that may be made available for a traditional verification that may involve data from another document or be presented as is.

The issuing entity may also provision information for the document to be presented in the App. The information may already be sufficient to present to the holder (e.g., such as to ensure that the document is correct) but not be suitable for a verification. The information that is provisioned may contain a list of label-value keys for the App to present when such action is selected. This is different from a modification that is interactive and requires user input to proceed.

For the above, in some examples, a local JSON remote procedure call (RPC) request may be used that is provisioned by the issuing entity with a given action so that the App knows what process to apply and what the parameters are. The JSON RPC request format identifies the kind of action required and delivers the necessary data to execute the action. This can occur after a user has selected a specific action or even without user interaction.

The issuing entity may provision command actions, such as deletion of an item from the digital wallet. Such action may also be reported to the issuing. Another command action that the issuing entity may provision is “Delete Credential”. This action may allow a citizen to request that their credential is deleted and may initiate the delete credential workflow, such as implemented by the SDK.

The issuing entity may provision collaborative actions. For example, the issuing entity may provision an action that requires user input, such as engaging in a verification. This action may start by engaging with a verifier of a verification service then, once engaged, the process allows receiving of the request and proceeding with consented data. There may be multiple steps where the App may have to receive user input. For such an option, the issuing entity may provision the necessary information to start a particular workflow (e.g., the verification workflow) then the workflow may rely on notification for obtaining user input.

Another collaborative action includes a request to modify document data and receive an update. Although this action is related to document data to modify, the action may remain dissociated from the document itself as the issuing entity may provision only the information that is available for a change request. Once modified, the process associated with the action allows receiving the changes and delivering to the issuing entity.

Another collaborative action includes a request to transfer credential to another device. This action may request that a credential is transferred from one device to another device.

Another collaborative action includes a call for a refresh. For example, the call for refresh may renew only the keys and authenticity signature or may update the credentials as a whole. This may be transparent to the App. In other examples, an option to provision conditional actions may included, e.g., action that will show only when certain conditions are met. For example, the “renew” action may be displayed when either one of the following condition is met: the document instance is about to expire or the SDK has discovered an update is available to provision, etc.

Any of the above actions may be conditional and the issuing entity may specify the conditions for such an action in order to detail how it should be made available for use. The conditions may be delivered along with the UI information. An example of a conditional action may include applying an update-other than revocation-that has been received. For example, this may include replacing a provisioned document with a new one. As another example, only certain actions may be displayed on the UI when certain criteria are met, e.g., when it is time to renew the credential.

In some examples, the SDK, for example, may execute a workflow at least partially defined by the non-document data elements that includes permitting access to at least some of the non-document data elements by a verification service. For example, the issuing entity may communicate with a target App using an individual postbox. The data that is posted to the postbox may be encrypted and may only be opened by the target App. The postbox may be unique for a document in that App and may be used to communicate updates and revocation. Each postbox may have a unique address.

The issuing entity may provision the address of the postbox for that document. Such information may be restricted to an authorized verifier (e.g., subject to verifier authentication). A verifier may request that information like any other data element from the document and, using that information, a verifier may obtain a status about pending content in that postbox. Although the verifier is not able to see the content, the verifier will know that a pending update is present and therefore the document may not be up to date.

In some examples, the non-document data element may include a URL to check for active/revocation status of the document. The URL may be set by the issuing entity and may be the URL of the postbox to check for pending updates or a server, e.g., running OCSP, to get a status.

The issuing entity may provision an object to be delivered as a data element. This may include 1) relevant data for the object to support the applicable workflow(s); 2) information for the category the object belongs to, including icon, name and a set of actions/methods that may be started from that category; 3) as many icons and lines as provisioned by the issuing entity, where the issuing entity may customize the information for a known App; and 4) a set of actions/methods for that object that are each mapped to a workflow that can be executed by the SDK, for example.

As mentioned above, the SDK may execute various workflows. For example, a workflow may return a data element from a specified object to the App, where the data element value may 1) connect to a website, which may apply to use cases to connect to the website of the issuing entity, to start onboarding or provisioning process, etc. (an object with a document may also include a URL); and 2) show a picture, which may apply to use cases such as QR code for vaccination passport, etc.

Another example of a workflow may engage in a verification. This workflow is typically started from an action/method from a category. During a verification process, the SDK may notify the App about the request then receive the list of consented data. In some examples verification may rely on data outside of the SDK and may be delivered as device signed items.

In a non-limiting specific implementation, the App may be embedded with an SDK library that delivers all the workflow. In another example, a zero-code App for web-based UI may be used. Such an App may download the UI template from a specific backend. Then, the code of the downloaded page may call specific functions such as those API from the App with an SDK described above.

4 FIG. 4 FIG. 400 400 402 404 is a flow diagram of an example of a computer-implemented methodof providing a virtualized credential of a holder. The methodis represented as a set of blocks-that describe operations of the method. The method may be embodied in a set of instructions stored in at least one computer-readable storage device of a computing device(s). A computer-readable storage device excludes transitory signals. In contrast, a signal-bearing medium may include such transitory signals. A machine-readable medium may be a computer-readable storage device or a signal-bearing medium. The computing device(s) may have one or more processors that execute the set of instructions to configure the one or more processors to perform the operations illustrated in. The one or more processors may instruct other components of the computing device(s) to carry out the set of instructions. For example, the computing device may instruct a network device to transmit data to another computing device or the computing device may provide data over a display interface to present a user interface. In some examples, performance of the method may be split across multiple computing devices using a shared computing infrastructure.

402 400 110 104 100 1 FIG. 1 FIG. At block, the methodmay include receiving, from an issuing entity and on a device of the holder, a set of document data elements and a set of non-document data elements, wherein the document data elements at least partially define the virtualized credential, wherein the document data elements are defined in a set of document data element fields of a data structure, wherein the non-document data elements are defined in a set of non-document data element fields of the data structure, and wherein the non-document data elements are defined by the issuing entity. For example, the mobile deviceof the holderofmay receive from the first issuing entityA ofa set of document data elements and a set of non-document data elements. Regarding non-document data elements, the data structure may contain data elements whose identifiers may be organized in namespaces and, in that structure, some of the identifiers or namespace may be used for non-document data.

404 400 114 110 1 FIG. 3 FIG. At block, the methodmay include displaying, on a user interface of the device of the holder, information representing the set of document data elements in a format defined by the non-document data elements, wherein the information at least partially defines the credential. For example, the UIof mobile deviceofmay display information representing the set of document data elements in a format defined by the non-document data elements, such as shown in.

In some examples, displaying, on the user interface of the device of the holder, information representing the set of document data elements in the format defined by the non-document data elements may include displaying text using an alphabet different from that used by the received set of document data elements. In other examples, it may include displaying an icon associated with the virtualized credential in the format defined by the non-document data elements. In yet other examples, it may include displaying personal information, such as a picture, of the holder associated with the virtualized credential in the format defined by the non-document data elements.

400 108 1 FIG. In some examples, the methodmay include receiving, from the holder, a selection on the user interface, and executing a workflow, e.g., by the SDKof, at least partially defined by the non-document data elements.

In some examples, executing a workflow at least partially defined by the non-document data elements may include connecting to a website of the issuing entity. In other examples, it may include displaying a code on the user interface. In other examples, it may include requesting a modification to at least one of the document data elements. In other examples, it may include requesting that information associated with the document be deleted and, in some such examples, the method may further include generating and transmitting, to the issuing entity, a revocation request, wherein revocation results in deletion of the document.

In some examples, after requesting a modification, the requested modification may be transmitted to the issuing entity for validating and confirmation, and the mobile device may receive an updated to the document data in response to the issuing entity validating and confirming the requested modification.

In some examples, executing a workflow at least partially defined by the non-document data elements may include permitting access to at least some of the non-document data elements by a verification service.

In some examples, the non-document data elements may include information representing a service made available by the issuing entity and the method may include displaying, on the user interface of the device of the holder, the information representing the service made available by the issuing entity. For example, a link or other information related to services from the issuing entity, e.g., taxes, may be displayed.

5 FIG. 5 FIG. 500 500 502 is a flow diagram of an example of a computer-implemented methodof providing a virtualized credential of a holder. The methodis represented as a blocksthat describes operations of the method. The method may be embodied in a set of instructions stored in at least one computer-readable storage device of a computing device(s). A computer-readable storage device excludes transitory signals. In contrast, a signal-bearing medium may include such transitory signals. A machine-readable medium may be a computer-readable storage device or a signal-bearing medium. The computing device(s) may have one or more processors that execute the set of instructions to configure the one or more processors to perform the operations illustrated in. The one or more processors may instruct other components of the computing device(s) to carry out the set of instructions. For example, the computing device may instruct a network device to transmit data to another computing device or the computing device may provide data over a display interface to present a user interface. In some examples, performance of the method may be split across multiple computing devices using a shared computing infrastructure.

502 500 At block, the methodmay include transmitting, from an issuing entity to a device of the holder, a set of document data elements and a set of non-document data elements, where the document data elements at least partially define the virtualized credential, where the document data elements are defined in a set of document data element fields of a data structure, where the non-document data elements are defined in a set of non-document data element fields of the data structure, where the non-document data elements are defined by the issuing entity, where the non-document data elements define a format for displaying information representing the set of document data elements on a user interface of the device of the holder, where the information at least partially defines the credential.

500 In some examples, the methodmay include receiving, from the device of the holder, a revocation request, where revocation results in deletion of the document.

6 FIG. 6 FIG. 600 600 602 604 is a flow diagram of an example of a computer-implemented methodof providing a virtualized credential of a holder. The methodis represented as a blocks-that describes operations of the method. The method may be embodied in a set of instructions stored in at least one computer-readable storage device of a computing device(s). A computer-readable storage device excludes transitory signals. In contrast, a signal-bearing medium may include such transitory signals. A machine-readable medium may be a computer-readable storage device or a signal-bearing medium. The computing device(s) may have one or more processors that execute the set of instructions to configure the one or more processors to perform the operations illustrated in. The one or more processors may instruct other components of the computing device(s) to carry out the set of instructions. For example, the computing device may instruct a network device to transmit data to another computing device or the computing device may provide data over a display interface to present a user interface. In some examples, performance of the method may be split across multiple computing devices using a shared computing infrastructure.

602 600 4 FIG. At block, the methodmay include receiving, from an issuing entity and on a device of the holder, a set of non-document data elements, where the non-document data elements are defined in a set of non-document data element fields of a data structure, where the non-document data elements are defined by the issuing entity, where document data elements at least partially define the virtualized credential, and where the document data elements are defined in a set of document data element fields of the data structure. Here, unlike in, the device of the holder need not receive a set of document data elements.

604 At block, the method may include displaying, on a user interface of the device of the holder, information representing the set of non-document data elements in a format defined by the non-document data elements. In some examples, displaying, on a user interface of the device of the holder, information representing the set of non-document data elements in a format defined by the non-document data elements may include displaying, on the user interface of the device of the holder, information representing a service made available by the issuing entity.

600 In some examples, the methodmay include receiving, from the holder, a selection on the user interface, and executing a workflow at least partially defined by the non-document data elements. In some examples, executing a workflow at least partially defined by the non-document data elements may include connecting to a website of the issuing entity. In some examples, executing a workflow at least partially defined by the non-document data elements may include displaying a code on the user interface.

7 FIG. 700 700 700 700 700 illustrates a block diagram of an example of a machine upon which any one or more of the techniques (e.g., methodologies) discussed herein can perform. In alternative embodiments, the machinecan operate as a standalone device or are connected (e.g., networked) to other machines. In a networked deployment, the machinecan operate in the capacity of a server machine, a client machine, or both in server-client network environments. In an example, the machinecan act as a peer machine in peer-to-peer (P2P) (or other distributed) network environment. The machineis a personal computer (PC), a tablet PC, a set-top box (STB), a personal digital assistant (PDA), a mobile telephone, a smart phone, a web appliance, a network router, switch or bridge, a server computer, a database, conference room equipment, or any machine capable of executing instructions (sequential or otherwise) that specify actions to be taken by that machine. In various embodiments, machinecan perform one or more of the processes described above. 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, such as cloud computing, software as a service (Saas), other computer cluster configurations.

Examples, as described herein, can include, or can operate on, logic or a number of components, modules, or mechanisms (all referred to hereinafter as “modules”). Modules are tangible entities (e.g., hardware) capable of performing specified operations and is configured or arranged in a certain manner. In an example, circuits are arranged (e.g., internally or with respect to external entities such as other circuits) in a specified manner as a module. In an example, the whole or part of one or more computer systems (e.g., a standalone, client or server computer system) or one or more hardware processors are configured by firmware or software (e.g., instructions, an application portion, or an application) as a module that operates to perform specified operations. In an example, the software can reside on a non-transitory computer readable storage medium or other machine readable medium. In an example, the software, when executed by the underlying hardware of the module, causes the hardware to perform the specified operations.

Accordingly, the term “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. Considering examples in which modules are temporarily configured, each of the modules need not be instantiated at any one moment in time. For example, where the modules comprise a general-purpose hardware processor configured using software, the general-purpose hardware processor is configured as respective different modules at different times. Software can accordingly configure a hardware processor, for example, to constitute a particular module at one instance of time and to constitute a different module at a different instance of time.

700 702 704 706 708 700 710 712 714 710 712 714 700 716 718 720 721 700 728 Machine (e.g., computer system)can include a hardware processor(e.g., a central processing unit (CPU), a graphics processing unit (GPU), a hardware processor core, or any combination thereof), a main memory, and a static memory, some or all of which can communicate with each other via an interlink(e.g., bus). The machinecan further include a display unit, an alphanumeric input device(e.g., a keyboard), and a user interface (UI) navigation device(e.g., a mouse). In an example, the display unit, input deviceand UI navigation deviceare a touch screen display. The machinecan additionally include a storage device (e.g., drive unit), a signal generation device(e.g., a speaker), a network interface device, and one or more sensors, such as a global positioning system (GPS) sensor, compass, accelerometer, or other sensor. The machinecan include an output controller, such as a serial (e.g., universal serial bus (USB), parallel, or other wired or wireless (e.g., infrared (IR), near field communication (NFC), etc.) connection to communicate or control one or more peripheral devices (e.g., a printer, card reader, etc.).

716 722 724 724 704 706 702 700 702 704 706 716 The storage devicecan include a machine readable mediumon which is stored one or more sets of data structures or instructions(e.g., software) embodying or utilized by any one or more of the techniques or functions described herein. The instructionscan also reside, completely or at least partially, within the main memory, within static memory, or within the hardware processorduring execution thereof by the machine. In an example, one or any combination of the hardware processor, the main memory, the static memory, or the storage devicecan constitute machine readable media.

722 724 While the machine readable mediumis illustrated as a single medium, the term “machine readable medium” can include a single medium or multiple media (e.g., a centralized or distributed database, and/or associated caches and servers) configured to store the one or more instructions.

700 700 The term “machine readable medium” can include any medium that is capable of storing, encoding, or carrying instructions for execution by the machineand that cause the machineto perform any one or more of the techniques of the present disclosure, or that is capable of storing, encoding or carrying data structures used by or associated with such instructions. Non-limiting machine readable medium examples can include solid-state memories, and optical and magnetic media. Specific examples of machine readable media can include: non-volatile memory, such as 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; Random Access Memory (RAM); Solid State Drives (SSD); and CD-ROM and DVD-ROM disks. In some examples, machine readable media can include non-transitory machine readable media. In some examples, machine readable media can include machine readable media that is not a transitory propagating signal.

724 726 720 700 720 726 720 720 The instructionscan further be transmitted or received over a communications networkusing a transmission medium via the network interface device. The machinecan communicate with one or more other machines utilizing any one of a number of transfer protocols (e.g., frame relay, internet protocol (IP), transmission control protocol (TCP), user datagram protocol (UDP), hypertext transfer protocol (HTTP), etc.). Example communication networks can include a local area network (LAN), a wide area network (WAN), a packet data network (e.g., the Internet), mobile telephone networks (e.g., cellular networks), Plain Old Telephone (POTS) networks, and wireless data networks (e.g., Institute of Electrical and Electronics Engineers (IEEE) 802.11 family of standards known as Wi-Fi®, IEEE 802.16 family of standards known as WiMax®), IEEE 802.15.4 family of standards, a Long Term Evolution (LTE) family of standards, a Universal Mobile Telecommunications System (UMTS) family of standards, peer-to-peer (P2P) networks, among others. In an example, the network interface devicecan include one or more physical jacks (e.g., Ethernet, coaxial, or phone jacks) or one or more antennas to connect to the communications network. In an example, the network interface devicecan include a plurality of antennas to wirelessly communicate using at least one of single-input multiple-output (SIMO), multiple-input multiple-output (MIMO), or multiple-input single-output (MISO) techniques. In some examples, the network interface devicecan wirelessly communicate using Multiple User MIMO techniques.

Examples, as described herein, can include, or can operate on, logic or a number of components, modules, or mechanisms. Modules are tangible entities (e.g., hardware) capable of performing specified operations and are configured or arranged in a certain manner. In an example, circuits are arranged (e.g., internally or with respect to external entities such as other circuits) in a specified manner as a module. In an example, the whole or part of one or more computer systems (e.g., a standalone, client, or server computer system) or one or more hardware processors are configured by firmware or software (e.g., instructions, an application portion, or an application) as a module that operates to perform specified operations. In an example, the software can reside on a machine-readable medium. In an example, the software, when executed by the underlying hardware of the module, causes the hardware to perform the specified operations.

Accordingly, the term “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. Considering examples in which modules are temporarily configured, each of the modules need not be instantiated at any one moment in time. For example, where the modules comprise a general-purpose hardware processor configured using software, the general-purpose hardware processor is configured as respective different modules at different times. Software can accordingly configure a hardware processor, for example, to constitute a particular module at one instance of time and to constitute a different module at a different instance of time.

Various embodiments are implemented fully or partially in software and/or firmware. This software and/or firmware can take the form of instructions contained in or on a non-transitory computer-readable storage medium. Those instructions can then be read and executed by one or more processors to enable performance of the operations described herein. The instructions are in any suitable form, such as but not limited to source code, compiled code, interpreted code, executable code, static code, dynamic code, and the like. Such a computer-readable medium can include any tangible non-transitory medium for storing information in a form readable by one or more computers, such as but not limited to read only memory (ROM); random access memory (RAM); magnetic disk storage media; optical storage media; flash memory; etc.

8 FIG. 8 FIG. 1 FIG. 100 800 104 802 is another conceptual diagram illustrating a flow of data between an issuer and a user. As indicated above, an SDK is not needed.depicts an example of flow of data between an issuer and user without an SDK. An issuing entityA may have various issuer workflows to provide issuer datato the holdervia a wallet App, without an SDK and in contrast to.

Promote and keep in control of the issuer Branding including logo and written expression PII protection according to Issuer polices. No need for the App to access PII from the document Local language whereas ISO only specifies Latin alphabet (domestic is not standard) Independent from the underlying kind of document and document standard Deliver Issuer information to present the provisioned item in the Application. Deliver Issuer information to present available actions. While an action is bound to a particular workflow, the issuer can set information for the UI to present it. Express which items are grouped together Express if an action is relevant to a particular item or group of items ISO mobile document of any kinds and more in the future Bookmarks for direct access to the online services Actions to start specific workflow supported by the SDK and which will expand over time. Provision: The techniques of this disclosure may deliver more to the issuing entity than just document provisioning and revocation. These techniques may give the power to the issuing entity to:

The above detailed description includes references to the accompanying drawings, which form a part of the detailed description. The drawings show, by way of illustration, specific embodiments in which the invention can be practiced. These embodiments are also referred to herein as “examples.” Such examples can include elements in addition to those shown or described. However, the present inventors also contemplate examples in which only those elements shown or described are provided. Moreover, the present inventors also contemplate examples using any combination or permutation of those elements shown or described (or one or more aspects thereof), either with respect to a particular example (or one or more aspects thereof), or with respect to other examples (or one or more aspects thereof) shown or described herein.

The above description is intended to be illustrative, and not restrictive. For example, the above-described examples (or one or more aspects thereof) can be used in combination with each other. Other embodiments can be used, such as by one of ordinary skill in the art upon reviewing the above description. Also, in the above Detailed Description, various features can be grouped together to streamline the disclosure. This should not be interpreted as intending that an unclaimed disclosed feature is essential to any claim. Rather, inventive subject matter can lie in less than all features of a particular disclosed embodiment.