Interaction processing using verifiable digital credentials

Abstract

A method is disclosed. The method includes obtaining, by a user device comprising a storage application, a verifiable credential comprising an attestation comprising access data. The attestation can be a network token attestation or storage application attestation. The method can further include transmitting, by the user device to a resource provider computer, the verifiable credential. The resource provider computer processes an interaction using the verifiable credential.

Description

PATENT Attorney Docket No.: 079900-1521990 Client Ref. No.: 9898WO01INTERACTION PROCESSING USING VERIFIABLE DIGITAL CREDENTIALSCROSS-REFERENCES TO RELATED APPLICATIONS

[0001] This application is a PCT application, which claims priority to U.S. Provisional Application No. 63 / 729,834, filed on December 9, 2024, which is herein incorporated by reference in its entirety.BACKGROUND

[0002] Conventional interaction systems can use proprietary methods for conducting access interactions between user devices and resource provider computers. Because such systems are often proprietary, it is difficult for some storage applications on user devices that are not traditionally used for such access interactions to interact with the resource provider computers.

[0003] Further, in one type of interaction, an access token is used instead of a sensitive access credential. In this case, an access token cryptogram is obtained by the user or the resource provider from a token service computer just prior to conducting an interaction with a resource provider computer. The access token cryptogram can encode data relating to a specific access token and an authorized interaction channel for the access token. The access token cryptogram can be used to ensure that the access token that is used in the interaction is valid and is being used in the authorized interaction channel.

[0004] The retrieval of access token cryptograms just prior to conducting resource interactions can be burdensome and can consume system resources. As such, it can be desirable to provide for some methods that would not require the retrieval of access token cryptograms just before interactions are conducted with resource provider computers are conducted.

[0005] Embodiments of the invention address these and other problems, individually and collectively.SUMMARY

[0006] One embodiment of the invention includes a method. The method comprises: obtaining, by a user device comprising a storage application, a verifiable credential comprising an attestation comprising access data, the attestation being a network token attestation or storage application attestation; and transmitting, by the user device to a resource provider computer, the verifiable credential, wherein the resource provider computer processes an interaction using the verifiable credential.

[0007] Another embodiment of the invention includes a user device comprising: a processor; and a computer readable medium comprising code, executable by the processor for performing a method comprising: obtaining, by the user device comprising a storage application, a verifiable credential comprising an attestation comprising access data, the attestation being a network token attestation or storage application attestation; and transmitting, by the user device to a resource provider computer, the verifiable credential, wherein the resource provider computer processes an interaction using the verifiable credential.

[0008] Another embodiment of the invention includes a method comprising: receiving, by a credential processing system, an authorization request message comprising a verifiable credential comprising an attestation comprising access data comprising a token or a token reference identifier, the attestation being a network token attestation or storage application attestation, a key binding proof, a resource provider identifier, and a value for an interaction; validating, by the credential processing system, the attestation; validating, by the credential processing system, the key binding proof; obtaining an access credential associated with the token or the token reference identifier; modifying, by the credential processing system, the authorization request message to include the access credential instead of the token or the token reference identifier; and transmitting, by the credential processing system, the authorization request message to an authorizing entity computer for authorization.

[0009] Another embodiment of the invention includes a token processing system comprising one or more processors, and one or more computer readable media. The one or more computer readable media comprising code, executable by the one or more processors to perform a method comprising: receiving, by thecredential processing system, an authorization request message comprising a verifiable credential comprising an attestation comprising access data comprising a token or a token reference identifier, the attestation being a network token attestation or storage application attestation, a key binding proof, a resource provider identifier, and a value for an interaction; validating, by the credential processing system, the attestation; validating, by the credential processing system, the key binding proof; obtaining an access credential associated with the token or the token reference identifier; modifying, by the credential processing system, the authorization request message to include the access credential instead of the token or the token reference identifier; and transmitting, by the credential processing system, the authorization request message to an authorizing entity computer for authorization.

[0010] A better understanding of the nature and advantages of embodiments of the invention may be gained with reference to the following Detailed description and accompanying drawings.BRIEF DESCRIPTION OF THE DRAWINGS

[0011] FIG. 1 shows a diagram illustrating a token service computer provisioning a token to a digital identity storage application.

[0012] FIG. 2 shows a diagram illustrating a flow diagram of a transaction processing method using digital verifiable credentials.

[0013] FIG. 3 illustrates a diagram illustrating a network token verifiable credential provisioning method.

[0014] FIG. 4 illustrates a diagram illustrating a method for processing a transaction using a network token verifiable credential.

[0015] FIG. 5 shows an exemplary network token verifiable credential.

[0016] FIG. 6 shows a diagram of a mobile device according to an embodiment.

[0017] FIG. 7 shows a diagram of a digital credential issuance computer according to an embodiment.DETAILED DESCRIPTION

[0018] Prior to discussing embodiments of the disclosure, some terms can be described in further detail.

[0019] A “key” may include a piece of information that is used in a cryptographic algorithm to transform input data into another representation. A cryptographic algorithm can be an encryption algorithm that transforms original data into an alternate representation, or a decryption algorithm that transforms encrypted information back to the original data. Examples of cryptographic algorithms may include triple data encryption standard (TDES), data encryption standard (DES), advanced encryption standard (AES), etc.

[0020] A “public key” may include a cryptographic key that may be shared openly and publicly. The public key may be designed to be shared and may be configured such that any information encrypted with the public key may only be decrypted using a private key associated with the public key (i.e. , a public / private key pair).

[0021] A “private key” may include any cryptographic key that may be protected and secure. A private key may be securely stored at an entity and may be used to decrypt any information that has been encrypted with an associated public key of a public / private key pair associated with the private key.

[0022] A “public / private key pair” may refer to a pair of linked cryptographic keys generated by an entity. The public key may be used for public functions such as encrypting a message to send to the entity or for verifying a digital signature which was supposedly made by the entity. The private key, on the other hand, may be used for private functions such as decrypting a received message or applying a digital signature. In some embodiments, the public key may be authorized by a body known as a certification authority (CA) which stores the public key in a database and distributes it to any other entity which requests it. The private key can typically be kept in a secure storage medium and will usually only be known to the entity. Public and private keys may be in any suitable format, including those based on Rivest- Shamir-Adleman (RSA) or elliptic curve cryptography (ECC).

[0023] A “digital signature” may include any electronic signature for a message. A digital signature may be a numeric data value, an alphanumeric datavalue, or any other type of data. In some embodiments, a digital signature may be a unique data value generated from a message (or data packet) and a private key using a cryptographic algorithm, wherein the private key is associated with a public key. In some embodiments, a validation algorithm using a public key may be used to verify the signature. A digital signature may be used to demonstrate the veracity of the authority that issued credentials (e.g., a digital license) associated with the digital signature.

[0024] The term “verification” and its derivatives may refer to a process that utilizes information to determine whether an underlying subject is valid under a given set of circumstances. Verification may include any comparison of information to ensure some data or information is correct, valid, accurate, legitimate, and / or in good standing.

[0025] A “user” may include an individual or a computational device. In some embodiments, a user may be associated with one or more personal accounts and / or user devices (e.g., mobile devices).

[0026] A “user device” may be a device that is operated by a user. Examples of user devices may include a mobile phone, a smart phone, a card, a personal digital assistant (PDA), a laptop computer, a desktop computer, a server computer, a vehicle such as an automobile, a thin-client device, a tablet PC, etc. Additionally, user devices may be any type of wearable technology device, such as a watch, earpiece, glasses, etc. The user device may include one or more processors capable of processing user input. The user device may also include one or more input sensors for receiving user input. As is known in the art, there are a variety of input sensors capable of detecting user input, such as accelerometers, cameras, microphones, etc. The user input obtained by the input sensors may be from a variety of data input types, including, but not limited to, audio data, visual data, or biometric data. The user device may comprise any electronic device that may be operated by a user, which may also provide remote communication capabilities to a network. Examples of remote communication capabilities include using a mobile phone (wireless) network, wireless data network (e.g., 3G, 4G or similar networks), Wi-Fi, Wi-Max, or any other communication medium that may provide access to a network such as the Internet or a private network.

[0027] A “server computer” is typically a powerful computer or cluster of computers. For example, the server computer can be a large mainframe, a minicomputer cluster, or a group of servers functioning as a unit, or a cloud server. In one example, the server computer may be a database server coupled to a Web server. The server computer may be coupled to a database and may include any hardware, software, other logic, or combination of the preceding for servicing the requests from one or more client computers. The server computer may comprise one or more computational apparatuses and may use any of a variety of computing structures, arrangements, and compilations for servicing the requests from one or more client computers.

[0028] A “processor” may include any suitable data computation device or devices. A processor may comprise one or more microprocessors working together to accomplish a desired function. The processor may include CPU comprises at least one high-speed data processor adequate to execute program components for executing user and / or system-generated requests. The CPU may be a microprocessor such as AMD's Athlon, Duron and / or Opteron; IBM and / or Motorola's PowerPC; IBM's and Sony's Cell processor; Intel's Celeron, Itanium, Pentium, Xeon, and / or XScale; and / or the like processor(s).

[0029] A “memory” may be any suitable device or devices that can store electronic data. A suitable memory may comprise a non-transitory computer readable medium that stores instructions that can be executed by a processor to implement a desired method. Examples of memories may comprise one or more memory chips, disk drives, etc. Such memories may operate using any suitable electrical, optical, and / or magnetic mode of operation.

[0030] An “interaction” may include a reciprocal action or influence. An interaction can include a communication, contact, or exchange between parties, devices, and / or entities. Example interactions include a transaction between two parties and a data exchange between two devices. In some embodiments, an interaction can include a user requesting access to secure data, a secure webpage, a secure location, and the like. In other embodiments, an interaction can include a transaction in which two devices can interact to facilitate a payment.

[0031] A “transaction” may be any interaction or exchange between two or more parties. For example, a transaction may include a first entity requesting resources from a second entity. In this example, the transaction is completed when the resources are either provided to the first entity, or the transaction is declined. An example transaction is a payment transaction.

[0032] An “access device” may be any suitable device that provides access to a resource. An access device may be in any suitable form. Some examples of access devices include vending machines, kiosks, POS or point of sale devices (e.g., POS terminals), cellular phones, PDAs, personal computers (PCs), tablet PCs, hand-held specialized readers, set-top boxes, electronic cash registers (ECRs), automated teller machines (ATMs), virtual cash registers (VCRs), and the like. An access device may use any suitable contact or contactless mode of operation to send or receive data from, or associated with, a user mobile communication device. In some embodiments, an access device may include a reader, a processor, and a computer-readable medium. A reader may include any suitable contact or contactless mode of operation. For example, exemplary readers can include radio frequency (RF) antennas, optical scanners, bar code readers, or magnetic stripe readers to interact with a payment device and / or mobile communication device.

[0033] 'Access data" may include any suitable data that can be used to access a resource or create data that can access a resource. In some embodiments, access data may be account information for a payment account. Account information may include a PAN, payment token, an access token reference identifier such as a token reference identifier, expiration date, card verification values (e.g., CW, CW2), dynamic card verification values (dCW, dCVV2), an identifier of an issuer with which an account is held, etc. In other embodiments, access data could include data that can be used to access a location or to access secure data. Such information may be ticket information for an event, data to access a building, transit ticket information, passwords, biometrics, or other credentials to access secure data, etc.

[0034] An “authorizing entity” may be an entity that authorizes a request. Examples of an authorizing entity may be an issuer, a governmental agency, a document repository, an access administrator, etc. An authorizing entity may operate an authorizing entity computer. An “issuer” may refer to a business entity (e.g., abank) that issues and optionally maintains an account for a user. An issuer may also issue payment credentials stored on a user device, such as a cellular telephone, smart card, tablet, or laptop to the consumer.

[0035] A “resource provider” may be an entity that can provide a resource such as goods, services, information, and / or access to a location (e.g., a parking space, a transit terminal, etc.). Examples of resource providers include merchants, governmental authorities, secure data providers, etc.

[0036] An "acquirer" may typically be a business entity (e.g., a commercial bank) that has a business relationship with a particular merchant or other entity. Some entities can perform both issuer and acquirer functions. Some embodiments may encompass such single entity issuer-acquirers. An acquirer may operate an acquirer computer, which can also be generically referred to as a “transport computer.”

[0037] A “credential” may be any suitable information that serves as reliable evidence of worth, ownership, identity, or authority. A credential may be a string of numbers, letters, or any other suitable characters that may be present or contained in any object or document that can serve as confirmation.

[0038] A “access credential” may be a credential that can be used to obtain access to a resource. Examples of access credentials include payment credentials, coupon identifiers, information needed to obtain a promotional offer, etc.

[0039] “Payment credentials” may include any suitable information associated with an account (e.g., a payment account and / or payment device associated with the account). Such information may be related to the account or may be derived from information related to the account. Examples of account information may include a PAN (primary account number or “account number”), username, expiration date, CW (card verification value), dCW (dynamic card verification value), CW2 (card verification value 2), CVC3 card verification values, etc. CVV2 is generally understood to be a static verification value associated with a payment device. CVV2 values are generally visible to a user (e.g., a consumer), whereas CW and dCW values are typically embedded in memory or authorization request messages and are not readily known to the user (although they are known to the issuer andpayment processors). Payment credentials may be any information that identifies or is associated with a payment account. Payment credentials may be provided in order to make a payment from a payment account. Payment credentials can also include a username, an expiration date, a gift card number or code, and any other suitable information.

[0040] A “verifiable credential” can be a credential that can be verified as being legitimate. In some embodiments, a verifiable credential includes a digital signature of an entity that issued or created the verifiable credential.

[0041] A “token” may be a substitute value for a credential. A token may be a string of numbers, letters, or any other suitable characters. Examples of tokens include access tokens such as payment tokens, data that can be used to access secure systems or locations, etc.

[0042] A "payment token” may include an identifier for a payment account that is a substitute for an account identifier, such as a primary account number (PAN) and / or an expiration date. For example, a token may include a series of alphanumeric characters that may be used as a substitute for an original account identifier. For example, a token “4900 0000 0000 0001” may be used in place of a PAN “4147 0900 0000 1234.” In some embodiments, a token may be “format preserving” and may have a numeric format that conforms to the account identifiers used in existing transaction processing networks (e.g., ISO 8583 financial transaction message format). In some embodiments, a token may be used in place of a PAN to initiate, authorize, settle, or resolve a payment transaction or represent the original credential in other systems where the original credential would typically be provided. In some embodiments, a token value may be generated such that the recovery of the original PAN or other account identifier from the token value may not be computationally derived. Further, in some embodiments, the token format may be configured to allow the entity receiving the token to identify it as a token and recognize the entity that issued the token.

[0043] “Tokenization” is a process by which sensitive data is replaced with substitute data. For example, a real credential (e.g., a primary account number (PAN)) may be tokenized by replacing the real account identifier with a substitute number that may be associated with the real credential. Further, tokenization can beapplied to any other information to substitute the underlying information with a token. “Token exchange” or “de-tokenization” can be a process of restoring the data that was substituted during tokenization. For example, a token exchange may include replacing a payment token with its associated primary account number (PAN). Further, de-tokenization or token exchange may be applied to any other information to retrieve the substituted information from a token. In some embodiments, token exchange can be achieved via a transactional message, such as an ISO message, an application programming interface (API), or another type of web interface (e.g., web request).

[0044] A “token service computer” can include a system that that services tokens. In some embodiments, a token service computer can facilitate requesting, determining (e.g., generating), and / or issuing tokens, as well as maintaining an established mapping of tokens to primary account numbers (PANs) in a repository (e.g., token vault). In some embodiments, the token service computer may establish a token assurance level for a given token to indicate the confidence level of the token to PAN binding. The token service computer may include or be in communication with a token vault where the generated tokens are stored. The token service computer may support token processing of payment transactions submitted using tokens by de-tokenizing the token to obtain the actual PAN.

[0045] A “token domain” may indicate an area and / or circumstance in which a token can be used. Examples of the token domain may include, but are not limited to, payment channels (e.g., e-commerce, physical point of sale, etc.), POS entry modes (e.g., contactless, magnetic stripe, etc.), and merchant identifiers to uniquely identify where the token can be used. A set of parameters (i.e., token domain restriction controls) may be established as part of token issuance by the token service computer that may allow for enforcing appropriate usage of the token in payment transactions. For example, the token domain restriction controls may restrict the use of the token with particular presentment modes, such as contactless or e-commerce presentment modes. In some embodiments, the token domain restriction controls may restrict the use of the token at a particular merchant that can be uniquely identified. Some exemplary token domain restriction controls may require the verification of the presence of a token cryptogram that is unique to agiven transaction. In some embodiments, a token domain can be associated with a token requestor.

[0046] “Token expiry date” may refer to the expiration date / time of the token. The token expiry date may be passed among the entities of the tokenization ecosystem during transaction processing to ensure interoperability. The token expiration date may be a numeric value (e.g. a 4-digit numeric value). In some embodiments, the token expiry date can be expressed as a time duration as measured from the time of issuance.

[0047] A “token request message” may be an electronic message for requesting a token. A token request message may include information usable for identifying a payment account or digital wallet, and / or information for generating a payment token. For example, a token request message may include payment credentials, mobile communication device identification information (e.g. a phone number or MSISDN), a digital wallet identifier, information identifying a tokenization service provider, a merchant identifier, a cryptogram, and / or any other suitable information. Information included in a token request message can be encrypted (e.g., with an issuer-specific key). In some embodiments, the token request message may include a flag or other indicator specifying that the message is a token request message.

[0048] A “token response message” may be a message that responds to a token request. A token response message may include an indication that a token request was approved or denied. A token response message may also include a payment token, mobile communication device identification information (e.g. a phone number or MSISDN), a digital wallet identifier, information identifying a tokenization service provider, a merchant identifier, a cryptogram, and / or any other suitable information. Information included in a token response message can be encrypted (e.g., with an issuer-specific key). In some embodiments, the token response message may include a flag or other indicator specifying that the message is a token response message.

[0049] An “authorization request message” may be a message that requests permission to conduct an interaction. For example, an authorization request message may include an electronic message that is sent to a payment processingnetwork and / or an issuer of a payment card to request authorization for a transaction. An authorization request message according to some embodiments may comply with (International Organization of Standardization) ISO 8583, which is a standard for systems that exchange electronic transaction information associated with a payment made by a consumer using a payment device or payment account. The authorization request message may include an issuer account identifier that may be associated with a payment device or payment account. An authorization request message may also comprise additional data elements corresponding to “identification information” including, by way of example only: a service code, a CVV (card verification value), a dCW (dynamic card verification value), an expiration date, etc. An authorization request message may also comprise “transaction information,” such as any information associated with a current transaction, such as the transaction amount, merchant identifier, merchant location, etc., as well as any other information that may be utilized in determining whether to identify and / or authorize a transaction.

[0050] A “storage application” can be an application which can store a virtual identity card, and other types of data. An example of a storage application can include a digital wallet or an identification application (e.g., a driver’s license application, a passport application, etc.

[0051] Embodiments of the invention enable transaction processing using digitally verifiable credentials. In some embodiments, a storage application such as a digital identity storage application (e.g., a digital identity wallet) may store and manage verifiable credentials for users. In some embodiments, the verifiable credentials can include access token reference identifiers, access tokens, and / or access token cryptograms.

[0052] Embodiments of the invention can include access token provisioning and interactions that use access tokens. In an exemplary token provisioning flow, a token service computer can provision an access token reference identifier to the digital identity storage application on a user device. When a user of the user device initiates an interaction with a resource provider computer, the digital identity storage application can use the access token reference identifier to obtain an access token and an access token cryptogram from a token service computer. The digital identitystorage application can generate a verifiable credential including the access token and the access token cryptogram. The digital identity storage application can also generate a key binding proof using dynamic data such as transaction data from the resource provider computer. The verifiable credential and the key binding proof can be passed to the resource provider computer to conduct an interaction. Details regarding such methods are described below with reference to FIG. 1 and FIG. 2.

[0053] FIG. 1 shows a system for provisioning access data to a digital identity storage application 104A on a user device 104 operated by a user 102. In some embodiments, the digital identity storage application 104A can be an Ell digital identity wallet, a digital wallet managed by the department of motor vehicles (DMV) in a state, or other storage application. The system includes a token service computer 106 that can be configured to provision access data such as an access token or an access token reference identifier to the digital identity storage application 104A. The user device 104 can be in communication with the token service computer 106. The token service computer 106 can be in communication with an authorizing entity computer 108. The authorizing entity computer 108 can manage an account such as a credit, debit, or prepaid account of the user 102.

[0054] Each of the entities in FIG. 1 (as well as FIG. 2, FIG. 3 and FIG. 4) may communicate through any suitable communication channel or communications network. A suitable communications network may be any one and / or the combination of the following: a direct interconnection; the Internet; a Local Area Network (LAN); a Metropolitan Area Network (MAN); an Operating Missions as Nodes on the Internet (OMNI); a secured custom connection; a Wide Area Network (WAN); a wireless network (e.g., employing protocols such as, but not limited to a Wireless Application Protocol (WAP), l-mode, and / or the like); and / or the like.

[0055] In some embodiments, the user device 104 may be a mobile phone, and the digital identity storage application 104A may be a digital driver’s license or passport application on the mobile phone.

[0056] In some embodiments, the digital identity storage application 104A may be a digital wallet as defined in OpenlD Connect for Verifiable Credential Issuance (OID4VCI) (or alternatively OpenlD for Verifiable Presentations (OID4VP)), which is associated with a standardized protocol stack for enabling a relying party to requestand receive verifiable credentials from an issuer through authenticated OpenlD Connect flows. The digital identity storage application 104A may store, for example, a payment card, a government issued identification card, a passport, a university certificate or other credentials.

[0057] In some embodiments, the digital identity storage application 104A may be defined in accordance with another protocol such as ISO 18013-5, which is a part of the ISO / IEC 18013 series specifying data models, presentation protocols, and security and privacy controls for mobile driving licenses (mDLs) to enable secure issuance, presentation, and verification of driver's license data via mobile devices and reader interactions. In other embodiments, the wallet may be defined in accordance with ISO 18013-7.

[0058] In embodiments of the invention, an entity that supports the digital identity storage application 104A (e.g., the authorizing entity computer 108) can issue a storage application attestation to the digital identity storage application 104A on the user device 104. The storage application attestation can be a payment wallet attestation that may serve as proof that the digital identity storage application 104A can receive an access token or access token reference identifier in a provisioning process. In some embodiments, the digital identity storage application 104A can use the payment wallet attestation as a cardholder verification method to allow the digital identity storage application 104A to request and receive an access token reference identifier or an access token from the token service computer 106. In later interaction processing (such as in payment transaction), the authorizing entity computer 108, the token service computer 106, and / or a processing network computer can accept the payment wallet attestation as a method of authentication (e.g., a cardholder verification method) for the interaction.

[0059] In some embodiments, the storage application attestation can include a digital certificate which is signed by the entity that supports the digital identity storage application 104A. It may also have details relating to the digital identity storage application 104A such as its version, an identifier for the supporting entity, validity dates, etc. The storage application attestation can be signed using an the supporting entity’s private key, so that its authenticity can be verified by verifying entities using the corresponding supporting entity public key.

[0060] The user device 104 may also have a user device public-private key pair that can be used to generate a key binding proof such as a digital signature. The public private key pair may be associated with a user device digital certificate which has been verified by a trusted authority. Data that is signed using the user device private key may be verified by a verifying entity using a corresponding user device public key. In some embodiments, the user device public-private key pair can be provided by or instantiated by the digital identity storage application 104A or an entity that supports the digital identity storage application 104A.

[0061] At step S101 , the user 102 may access the digital identity storage application 104A on the user device 104. The user 102 can authenticate with the digital identity storage application 104A using a suitable authentication method such as a password, biometric, one-time-password, etc. After authentication, the user 102 can input an access credential such as a primary account number (e.g., a credit card, debit card, or prepaid account number), IBAN, or the like into the digital identity storage application 104A, along with other associated data such as expiration dates and security codes.

[0062] At step S102, the digital identity storage application 104A submits a token provisioning request comprising the access credential to the token service computer 106.

[0063] At step S103, the token service computer 106 sends a request message to the authorizing entity computer 108 requesting supported cardholder verification methods (CVMs) from the authorizing entity computer 108. The request message may also include the access credential and may request permission from the authorizing entity computer 108 to provision the digital identity storage application 104A with an access token.

[0064] At step S104, the authorizing entity computer 108 can provide a response message to the token service computer 106 indicating that it supports storage application wallet attestations, among other methods, as a CVM method. It may also contain the permission to provision the digital identity storage application 104A with an access token.

[0065] At step S105, after receiving the response message from the authorizing entity computer 108, the token service computer 106 sends a storage application attestation request to the digital identity storage application 104A. The token service computer 106 can request that the digital identity storage application 104A provide the storage application attestation before it will provision an access token or access token reference identifier to the digital identity storage application 104A. The storage application attestation may include information such as a digital identity storage application identifier and other data signed using a private key associated with the digital identity storage application 104A. In some embodiments, a remote application server (not shown) associated with the digital identity storage application 104A may assist in performing steps associated with the creation of the storage application attestation.

[0066] At step S106 the digital identity storage application 104A retrieves the storage application attestation and transmits it to the token service computer 106.

[0067] At step S107, the token service computer 106 validates the storage application attestation and returns an access token reference identifier to the digital identity storage application 104A. For example, the token service computer 106 can validate a digital signature in the storage application attestation using a public key associated with the digital identity storage application 104A. It may also validate other data (e.g., an expiration date) associated with the digital identity storage application 104A. In some embodiments, the token service computer 106 may validate the storage application attestation via the authorizing entity computer 108.

[0068] After validating the storage application attestation, the token service computer 106 can tokenize the access credential to form an access token and can generate an access token reference identifier for the access token. The access token, the access token reference identifier, and the access credential may be stored by the token service computer 106 in database. The token service computer 106 may transmit the access token reference identifier to the digital identity storage application 104A in the user device 104 for use in subsequent transaction processing.

[0069] Since the digital identity storage application 104A stores the access token reference identifier instead of the access token or the access credential, theyare protected from man-in-the-middle or hacking attacks. If an unauthorized person were to obtain the access token reference identifier, it could not be used to directly conduct a transaction with a resource provider.

[0070] In the method 100 described above, the digital identity storage application 104A can be characterized as a token requestor. In other embodiments, a resource provider computer associated with a resource provider (e.g., a merchant) can be the token requestor. In this case, the resource provider computer can receive an access token, an access token reference identifier and other data in the same manner as the digital identity storage application 104A in user device 104.

[0071] FIG. 2 shows a diagram of a transaction processing system and an overlaid method that can use a verifiable credential to conduct a transaction. In addition to the user device 104, the digital identity storage application 104A, the user 102, the token service computer 106, and the authorizing entity computer 108, FIG. 2 also shows a resource provider computer 110, a gateway 112, and a processing network computer 114. The user device 104 may be communication with the token service computer 106 and the resource provider computer 110. The resource provider computer 110 can be in communication with the authorizing entity computer 108 via the gateway 112 and the processing network computer 114.

[0072] The resource provider computer 110 can be operated by a resource provider such as a merchant. In some embodiments, the resource provider computer 110 can be an application server, a Web server hosting a Website, an access device such as a POS terminal, etc.

[0073] The gateway 112 may provide access to the authorizing entity computer 108. In some embodiments, the gateway 112 may be a transport computer, which may be operated by an entity such as an acquirer.

[0074] The processing network computer 114 may be configured to provide authorization services, and clearing and settlement services for payment transactions. A processing network computer 114 may include data processing subsystems, networks, and operations used to support and deliver authorization services, exception file services, and clearing and settlement services. An exemplary payment processing network may include VisaNet™. Payment processing networkssuch as VisaNet™ are able to process credit card transactions, debit card transactions, and other types of commercial transactions. VisaNet™, in particular includes a Visa Integrated Payments (VIP) system which processes authorization requests and a Base II system which performs clearing and settlement services. Furthermore, the payment processing network may include a server computer and may use any suitable wired or wireless telecommunications network, including the Internet.

[0075] In a method that can be described with reference to FIG. 2, the user 102 may initiate an interaction with a resource provider computer 103 to obtain a resource such as a good, service, secure data, access to a secure location etc. The method in FIG. 2 may take place after the method 100 of FIG. 1. The digital identity storage application 104A may store the storage application attestation, which may serve as a CVM for the transaction. The digital identity storage application can also use the previously provisioned access token reference identifier (as described above with reference to FIG. 1 ) to retrieve an access token and a token cryptogram from the token service computer 106 to process the transaction.

[0076] At step S201 , the user 102 may select a resource to obtain from the resource provider operating the resource provider computer 110. The user 102 can then perform a check out process with the resource provider. For example, the user 102 may navigate a resource provider webpage on the resource provider computer 110 via a browser or resource provider application on the user device 104 to request access to a resource such as goods or services.

[0077] At step S202, the resource provider computer 103 transmits a verifiable credential request to the digital identity storage application 104A on the user device 104. For example, the transaction may be an in person transaction. The user device 104 may be a mobile phone and the resource provider computer 110 can be an access device such as a POS terminal. The user 102 may tap the user device 104 to the resource provider computer 110. The resource provider computer 110 may transmit a message to the digital identity storage application 104A in the user device 104 to request a verifiable credential. In response, the user device 104 can return the verifiable credential to the resource provider computer 110. In another example, the transaction can be a remote transaction. The user device 104 may be a laptopcomputer and the resource provider computer 110 can be a merchant server that supports a Website or merchant application. The resource provider computer 110 may transmit a message to the user device 104 to request a verifiable credential that can be used to conduct the transaction. In response, the user device 104 can later return the verifiable credential to the resource provider computer 110.

[0078] At step S203, after receiving the verifiable credential request from the resource provider computer 110, the digital identity storage application 104A may prompt the user 102 to authenticate. After the user authenticates themselves to the digital identity storage application 104A, the user 102 can then select an access credential (e.g., a primary account number such as a credit or debit card number) to use to conduct the transaction. The user 102 can also confirm other transaction details (e.g., a resource provider identifier, a transaction identifier, a transaction amount, a date and time, etc.) associated with the transaction that were received from the resource provider computer 110.

[0079] At step S204, the digital identity storage application 104A may transmit the storage application attestation, the access token reference identifier, and a key binding proof to the token service computer 106. The key binding proof may be a digital signature of the user device 104. In some embodiments, the digital identity storage application 104A may generate the user device digital signature by signing transaction data for the transaction using the private key stored on the user device. The private key is associated with a corresponding public key that can verify the user device digital signature.

[0080] At step S205, after receiving the storage application attestation, the access token reference identifier, and the key binding proof to the token service computer 106 can validate the storage application attestation and the key binding proof. They may be validated at least by using the storage application public key and the user device public key. After validating the storage application attestation and the key binding proof, the token service computer 106 may obtain the access token associated with the token reference identifier and an access token cryptogram such as a Token Authentication Verification Value or TAW associated with the access token. The token service computer 106 can then transmit the access token and theaccess token cryptogram to the digital identity storage application 104A in the user device 104.

[0081] In embodiments of the invention, the access token cryptogram may be generated by encrypting certain data including the access token, a transaction channel indicator, and other data. The use of the access token may be limited to the particular transaction channel associated with the transaction channel indicator. If the transaction is not being conducted in the transaction channel indicator, then the transaction may be declined.

[0082] At step S206, after receiving access token and the cryptogram, the digital identity storage application 104A can generate a storage application verifiable credential comprising the access token and the access token cryptogram, and can transmit it to the resource provider computer 110. The storage application verifiable credential may also contain a digital signature of the user device 104. The digital signature may be a signature on the data in the storage application verifiable credential.

[0083] In some embodiments, the storage application verifiable credential may be in the form of a JSON Web token comprising the storage application attestation, the access token, the access cryptogram, and a public key that can be used to verify the digital signature in the storage application verifiable credential.

[0084] At step S207, after receiving the storage application verifiable credential, tthe resource provider computer 103 can extract the access token and token cryptogram from the storage application verifiable credential and can generate an authorization request message. The authorization request message can comprise the access token, the token cryptogram, a resource provider identifier, a transaction amount, and other data. The resource provider computer 103 can then transmit the authorization request message to the gateway 112. In some embodiments, the gateway 112 can be a transport computer operated by an entity such as an acquirer.

[0085] At step S208, the gateway 112 can transmit the authorization request message to the processing network computer 114.

[0086] At step S209, the processing network computer 114 can send the access token and the access token cryptogram to the token service computer 106.The token service computer 106 can validate the access token cryptogram. In some embodiments, the token service computer 106 can decrypt the access token cryptogram (e.g., using a cryptographic key that is derived or shared with the user device 104) to recover its inputs. It can then compare its inputs to other data associated with the authorization request message to determine if they match. If they do, the access token cryptogram is valid. In other embodiments, the token service computer 106 can encrypt the other data associated with the authorization request message and compare the encrypted data to the access token cryptogram to validate it. Once the token cryptogram is validated, the token service computer 106 can determine the access credential associated with the token and can return the same to the processing network computer 114.

[0087] After receiving the access credential, the processing network computer 114 can modify the authorization request message to include the access credential instead of the access token.

[0088] In step S209, after modifying the authorizing request message, the processing network computer 114 can transmit the authorization request message to the authorizing entity computer 108. The authorizing entity computer 108 may then approve or decline the transaction. For example, the authorizing entity computer 108 may determine if a balance of an account associated with the access credential is sufficient to pay for the transaction and / or may conduct a fraud analysis on the transaction.

[0089] After making an authorization decision, the authorizing entity computer 108 can generate and transmit an authorization response message comprising the access credential. The authorizing entity computer 108 can then transmit the authorization response message back to the resource provider computer 110 via the processing network computer 114 and the gateway 112. In some embodiments, the processing network computer 114 can communicate with the token service computer 106 to re-tokenize the access credential and obtain the access token. The access token may replace the access credential in the authorization response message.

[0090] After a period of time, a clearing and settlement process can occur between the gateway 112, the processing network computer 114, and the authorizing entity computer.

[0091] In some embodiments, the digital identity storage application 104A contains attribute data (e.g., birthday = 1 / 1 / 18) or assertions (e.g., greater than 21 years old). Such data may be passed from the digital identity storage application 104A along with the access token and the access token cryptogram to the resource provider computer 110 in step S204. The resource provider operating the resource provider computer 110 or some other entity can use that information in processing the interaction. For example, an assertion that the user is greater than 21 years of age may be used by the resource provider in a sale of alcohol to the user 102.

[0092] Such embodiments have a number of advantages. For examle, attribute data and / or assertions can transferred with an access token and an access token cryptogram in a single interaction or a single data transmission between the user device 104 including the identity storage application 104A and the resource provider computer 110. Two separate interactions are not required to pass the attribute data and / or the assertions, the access token and the access token cryptogram to the resource provider computer 110, thereby saving computing resources and reducing the number of data transmissions.

[0093] In the above embodiments, the storage application attestation can be bound to the access token during token provisioning. The storage application attestation can additionally be bound to a cryptographic key on the user device. When the storage application attestation is presented by the digital identity storage application 104A, a proof of key binding is also generated. However, this may enable any entity in possession of the storage application verifiable credential to request an access token. To prevent replay attacks, the key binding proof can be a digital signature of dynamic data. The dynamic data can be transaction data for the transaction in which the token is being requested.

[0094] In other embodiments of the invention, the attestation can be a network token attestation. In such embodiments, the generation of the network token attestation and access token provisioning can be performed in a single step by a single entity such as the digital credential issuance computer. The digital credential issuance computer can issue the network token attestation with the access token and access token cryptogram. The digital credential issuance computer can sign the network token attestation with a digital credential issuance computer private key. Thedigital credential issuance computer may have a digital credential issuance computer private key for each authorizing entity computer (e.g., via a BIN or bank identification number) or digital identity storage application that it interacts with.

[0095] In a transaction, the resource provider computer can request the network token attestation and optionally identity claims (e.g., “age>18”) from the digital identity storage application in a transaction. The digital identity storage application can then provide the network token attestation and a key binding proof to the resource provider computer to conduct the transaction. The key binding proof can perform the function of a transaction cryptogram since it can be a signature of variable data such as a transaction data object (which may contain a resource provider identifier, a transaction amount, etc.).

[0096] FIG. 3 illustrates a system and method for provisioning a network token verifiable credential. FIG. 3 shows a user 102, a user device 104 comprising a digital identity storage application 104A, a token service computer 106, and an authorizing entity computer 108. These components are described above with respect to FIGs. 1-2 and the descriptions thereof are incorporated herein. In addition, FIG. 3 shows a digital credential issuance computer 118, which is in communication with the user 102, the user device 104 comprising the digital identity storage application 104A, the token service computer 106, and the authorizing entity computer 108.

[0097] At step S301 , the user 102 wants to use the digital identity storage application 104A on the user device 104 to conduct interactions and authenticates to the digital identity storage application 104A.

[0098] At step S302, the user 102 uses the digital identity storage application 104A to contact the digital credential issuance computer 118 to obtain a network token verifiable credential. The digital identity storage application 104A can request an authorization endpoint, which may be an authentication portal associated with the digital credential issuance computer 118.

[0099] At step S303, the digital credential issuance computer 118 can return the authorization endpoint.

[0100] At step S304, the user 102 navigates to the authorization endpoint, can be authenticated, and can then supply account details (e.g., an access credential such as a credit card number) to the digital credential issuance computer 118.

[0101] At step S305, after reviewing the account details and authenticating the user 102, the digital credential issuance computer 118 can respond to the digital identity storage application 104A with an authorization code.

[0102] At step S306, the digital identity storage application 104A can provide a request for a network token verifiable credential from the digital credential issuance computer 118. The request for network token verifiable credential for the may include the authorization code.

[0103] At step S307, after receiving the authorization code, the digital credential issuance computer 118 can send a token request message comprising the access credential to the token service computer 106. After receiving the token request message, the token service computer 106 can tokenize the access credential to form an access token (or obtain it from a pool of access tokens) and can generate or obtain an access token reference identifier for the access token. The access token, the access token reference identifier, and the access credential may be stored by the token service computer 106 in database.

[0104] At step S308 the token service computer 106 may transmit the access token reference identifier to the digital credential issuance computer 118. .

[0105] At step S309, the digital credential issuance computer 118 can generate the network token verifiable credential comprising a network token attestation comprising the access token reference identifier. The network token verifiable credential may also contain a digital signature of the digital credential issuance computer 118 and a digital credential issuance computer public key. The digital credential issuance computer public key can be used by a relying party to verify the digital signature of the digital credential issuance computer 118. In some embodiments, the network token verifiable credential may include a neetwork token attestation in the form of a Web token such as a JSON Web token. An example of a JSON Web token is illustrated in FIG. 5, and is described in further detail below.Once generated, the network token verifiable credential can be transmitted to the digital identity storage application 104A, where it can be stored.

[0106] At step S310, the digital credential issuance computer 118 can notify the authorizing entity computer 108 that the network token verifiable credential was created for the access credential that it manages.

[0107] FIG. 4 illustrates a system and a method for processing an interaction using the network token verifiable credential. In FIG. 4, the processing network computer 114, the digital credential issuance computer 118, and optionally the token service computer 106 may be part of a “credential processing system.” The digital credential issuance computer 118 can be in communication with the processing network computer 114 and the token service computer 106. In some embodiments, the functions of the digital credential issuance computer 118 and the token service computer 106 may be functional modules within the processing network computer 114.

[0108] At step S401 , the user 102 may select a resource to obtain from the resource provider operating the resource provider computer 110. The user 102 can then perform a check out process with the resource provider and initiate the transaction as described in step S201 above.

[0109] At step S402, the resource provider computer 103 sends a verifiable credential request to the digital identity storage application 104A to request the network token verifiable credential. The request may comprise transaction details such as a resource provider identifier and a transaction amount.

[0110] At step S403, the user 102 authenticates themselves to the digital identity storage application 104A, selects an access credential for use in the transaction, and confirms the transaction details.

[0111] At step S404, the digital identity storage application 104A obtains the network token verifiable credential and the key binding proof and sends them to the resource provider computer 103. The key binding proof can be a digital signature of the transaction data by a cryptographic key (e.g., a user device private key) tied to the user device 104. The key binding proof can replace a conventional transaction cryptogram that is used to prevent replay attacks.

[0112] At steps S405 and S406, the resource provider computer 103 generates an authorization request message comprising the network token verifiable credential, the key binding proof, and a transaction data object containing transaction data. The resource provider computer 103 can then transmit the authorization request message to the processing network computer 114 via the gateway 112.

[0113] At step S407, after receiving the authorization request message, the processing network computer 114 sends the network token verifiable credential, key binding proof, and the transaction data object to the digital credential issuance computer 118 for validation.

[0114] At step S408, the network verifiable credential may be validated by the digital credential issurance computer 118 at least by using the digital credential issuance computer public key. The key binding proof may be validated by the digital credential issuance computer 118 using the user device public key. The transaction data object can be validated by the digital issance computer 118 confirming that the transaction data elements match those that would be expected for the transaction. After validation, the digital credential issuance computer 118 can send a token request message comprising the access token reference identifier in the network token verifiable credential to the token service computer 106. The token servce computer 106 can then determine the access token associated with the access token reference identifier, and the access credential associated with the access token.

[0115] At step S409, the token service computer 106 can send a token response message comprising the access credential to the digital credential issuance computer 118.

[0116] At step S410, the digital credential issuance computer 118 can forward the access credential to the processing network computer 114.

[0117] At step S411 , the processing network computer 114 can transmit the access credential, the transaction data object, and optionally the network token attestation and the key binding proof, to the authorizing entity computer 108 for authorization.

[0118] The authorizing entity computer 108 may then approve or decline the transaction. For example, the authorizing entity computer 108 may determine if a balance of an account associated with the access credential is sufficient to pay for the transaction and / or may conduct a fraud analysis on the transaction. The authorizing entity computer 108 can also validate the network token attestation and / or the key binding proof if they are present in the authorization request message.

[0119] After making an authorization decision, the authorizing entity computer 108 can generate and transmit an authorization response message comprising the access credential. The authorizing entity computer 108 can then transmit the authorization response message back to the resource provider computer 110 via the processing network computer 114 and the gateway 112.

[0120] After a period of time, a clearing and settlement process can occur between the gateway 112, the processing network computer 114, and the authorizing entity computer.

[0121] FIG. 5 shows an exemplary network token verifiable credential. The network token verifiable credential may be a JSON Web token (JWT) formatted in accordance with OID4VCI. The network token verifiable credential may comprise an issuing entity endpoint, a recipient (verifier) endpoint, a subject containing an access token reference identifier, an issuance time, and expiration time, a masked credential, a user identifier, and a digital credential issuance public key.

[0122] FIG. 6 shows a block diagram of a user device 600. The user device 600 may include device hardware 608 coupled to a system memory 602.

[0123] The system memory 602 can store a digital identity storage application 604A which stores an attestation 604A-1 (a network token attestation or a storage application attestation) and digital verifiable credential 604A-2, one or more others application 604B (e.g., a browser), and a cryptography module 604C. The cryptography module 604C may comprise cryptographic keys and / or algorithms to perform cryptographic processing.

[0124] The device hardware 608 may include a processor 610, input elements 612, a short range antenna 614, a user interface 616, output elements 618, and along range antenna 620. Examples of input elements 612 may include microphones, keypads, touchscreens, sensors, and / or cameras, etc. Examples of output elements 618 may include speakers, display screens, tactile devices, and / or light emitting diodes (LEDs), etc. The processor 610 can be implemented as one or more integrated circuits (e.g., one or more single core or multicore microprocessors and / or microcontrollers), and is used to control the operation of user device 600. The processor 610 can execute a variety of programs in response to program code or computer-readable code stored in the system memory 602, and can maintain multiple concurrently executing programs or processes.

[0125] The long range antenna 620 may include one or more radio frequency (RF) transceivers and / or connectors that can be used by user device 600 to communicate with other devices and / or to connect with external networks. The input elements 612 and output elements 618 allow a user to interact with and invoke the functionalities of user device 600. The short range antenna 614 may be configured to communicate with external devices through a short range communication medium (e.g., using Bluetooth, Wi-Fi, infrared, NFC, etc.). The long range antenna 620 may be configured to communicate with a remote base station and a remote cellular or data network, over the air.

[0126] The system memory 602 can be implemented using any combination of any number of non-volatile memories (e.g., flash memory) and volatile memories (e.g., DRAM, SRAM), or any other non-transitory storage medium, or a combination thereof media. The system memory 602 may store computer code, executable by the processor 610, for performing any of the functions described herein. For example, the system memory 602 may comprise a computer readable medium comprising code, executable by the processor 610, for implementing a method for obtaining, by the user device comprising a storage application, a verifiable credential comprising an attestation comprising access data, the attestation being a network token attestation or storage application attestation; and transmitting, by the user device to a resource provider computer, the verifiable credential, wherein the resource provider computer processes an interaction using the verifiable credential.

[0127] FIG. 7 shows a block diagram of a digital credential issuance computer 700 (e.g., digital credential issuance computer 118 described above), according toan embodiment. The processing network computer 700 may include a processor 702, coupled to a network interface 704, a data store 706, and a computer readable medium 710.

[0128] The data store 706 can be implemented using any combination of any number of non-volatile memories (e.g., flash memory) and volatile memories (e.g., DRAM, SRAM), or any other non-transitory storage medium, or a combination thereof media. The data store 706 may store cryptographic keys, digital certificates, account identifying information, and / or other information.

[0129] The computer readable medium 710 may comprise a number of software modules including a communication module 712, an authentication module 714, a cryptography module 716, an authorization module 718, a validation module 722, and a tokenization module 724. The communication module 712 may comprise code, executable by the processor 702, to communicate using network interface 704 with one or more other systems. The authentication module 714 may comprise code, executable by the processor 702, to authenticate users as card holders and to issue authentication codes for subsequent access or transactions. The cryptography module 716 can perform, in conjunction with the processor 702, cryptographic processing including signature verification, digital signing, encryption, and decryption. The authorization module 718 and the processor 702 can perform authorization processing. The validation module 722 may comprise code, executable by the processor 702, to validate network verifiable credentials, digital signatures, cryptograms, and associated transaction data. The tokenization module 724 in conjunction with the processor 702 can perform tokenization and detokenization processing, as well as cryptogram generation or validation processing.

[0130] Embodiments enable tokens, passkeys, and payment wallet attestations which provide proof of strong user authentication with erifiable credentials. Embodiments also enable transaction processing in accordance with protocols such as ISO18013-5, ISO18013-7, OID4VCI, and OID4VP, while using existing rails. Embodiments also leverage the strong device binding of digital verifiable credentials for transaction processing, without the need for specific device recognition capability. Moreover, by using network token verifiable credentials, it is not necessary for the digital credential issuance computer to store a mappingbetween tokens and the users’ public keys. Rather, the digital credential issuance computer can use a key linked to the token reference to validate that it issued the network token verifiable credential. The remaining validation steps can be performed by using data present in the network token verifiable credential. For example, once it has been determined that the digital credential issuance computer issued the network token verifiable credential, the public key can be extracted and used to validate that the signature is associated with that network token verifiable credential and transaction data. The public key can be shared with authorizing entities to enable the same validation.

[0131] Embodiments enable tokenization of any suitable access credential (e.g., a card number, IBAN, crypto-wallet identifier) for transmission through existing transaction rails. The credential processing system can validate the verifiable credential and route authorization requests to the appropriate authorizing entity computer. Additionally, if the verifiable credential is in mDoc format, it may be obtained via NFC and sent over authorization rails. Therefore, embodiments are compatible with proximity and remote transactions.

[0132] Embodiments of the invention have a number of additional technical advantages. The network token verifiable credential can include information used for token retrieval and can be passed in an authorization request message. As such, a user device need not communicate with a token service computer to retrieve an access token and token cryptogram prior to initiating a transaction with the resource provider computer. Also, embodiments of the invention can use tokens and cryptographic validation processes to ensure that the transaction is secure and that sensitive access credentials are protected and not exposed to resource providers, hackers, or man-in-the-middle attacks. Still further, the verifiable credentials according to embodiments can have data structures (e.g., JSON Web tokens) that are not limited to proprietary formats so that they can be universally used.

[0133] Any of the software components or functions described in this application may be implemented as software code to be executed by a processor using any suitable computer language such as, for example, Java, C, C++, C#, Objective-C, Swift, or scripting language such as Perl or Python using, for example, conventional or object-oriented techniques. The software code may be stored as aseries of instructions or commands on a computer readable medium for storage and / or transmission, suitable media include random access memory (RAM), a read only memory (ROM), a magnetic medium such as a hard-drive or a floppy disk, or an optical medium such as a compact disk (CD) or DVD (digital versatile disk), flash memory, and the like. The computer readable medium may be any combination of such storage or transmission devices.

[0134] Such programs may also be encoded and transmitted using carrier signals adapted for transmission via wired, optical, and / or wireless networks conforming to a variety of protocols, including the Internet. As such, a computer readable medium according to an embodiment of the present invention may be created using a data signal encoded with such programs. Computer readable media encoded with the program code may be packaged with a compatible device or provided separately from other devices (e.g., via Internet download). Any such computer readable medium may reside on or within a single computer product (e.g., a hard drive, a CD, or an entire computer system), and may be present on or within different computer products within a system or network. A computer system may include a monitor, printer, or other suitable display for providing any of the results mentioned herein to a user.

[0135] The above description is illustrative and is not restrictive. Many variations of the invention will become apparent to those skilled in the art upon review of the disclosure. The scope of the invention should, therefore, be determined not with reference to the above description, but instead should be determined with reference to the pending claims along with their full scope or equivalents.

[0136] One or more features from any embodiment may be combined with one or more features of any other embodiment without departing from the scope of the invention.

[0137] As used herein, the use of "a," "an," or "the" is intended to mean "at least one," unless specifically indicated to the contrary.

Claims

WHAT IS CLAIMED IS:1 . A method comprising: obtaining, by a user device comprising a storage application, a verifiable credential comprising an attestation comprising access data, the attestation being a network token attestation or storage application attestation; and transmitting, by the user device to a resource provider computer, the verifiable credential, wherein the resource provider computer processes an interaction using the verifiable credential.

2. The method of claim 1 , wherein the attestation is the network token attestation in the form of a JSON (Javascript Object Notation) Web token.

3. The method of claim 2, wherein the access data comprises a token reference identifier.

4. The method of claim 3, further comprising: obtaining, by the user device, a key binding proof; and transmitting, by the user device to the resource provider computer, the key binding proof along with the verifiable credential to the resource provider computer.

5. The method of claim 4, wherein the resource provider computer is programmed to: generate an authorization request message comprising the network token attestation comprising the token reference identifier, the key binding proof, a resource provider identifier, and a value for the interaction; and transmit the authorization request message to a credential processing system, which is programmed to validate the network token attestation, validate the key binding proof, obtain a credential associated with the token reference identifier, replace the token reference identifier with the credential in the authorization request message, and transmit the authorization request message including the credential to an authorizing entity computer for authorization.

6. The method of claim 5, wherein the storage application is a digital identity storage application, wherein the user device transmits attributes or assertions of a user of the user device along with the verifiable credential.

7. The method of claim 1 , wherein the attestation is the network token attestation, the verifiable credential is stored in a memory of the user device, and obtaining the verifiable credential comprises obtaining the verifiable credential from the memory, and wherein the method further comprises: transmitting, by the user device to a digital credential issuance computer, a request for the verifiable credential; and receiving, by the user device from the digital credential issuance computer, the verifiable credential.

8. The method of claim 7, wherein the verifiable credential is a network token verifiable credential, and comprises a digital signature of the digital credential issuance computer and a digital credential issuer computer public key associated with the digital signature of the digital credential issuance computer.

9. The method of claim 1 , wherein the attestation is the storage application attestation comprising a digital signature of the storage application.

10. The method of claim 9, wherein the storage application attestation further comprises the token and a token cryptogram associated with the token.11 . The method of claim 10, wherein the resource provider computer is programmed to: generate an authorization request message comprising the storage application attestation comprising the digital signature of the storage application, token and the token cryptogram, a key binding proof, a resource provider identifier, and a value for the interaction; and transmit the authorization request message to a processing network computer, which is programmed to validate the storage application attestation, validate the key binding proof, validate the token cryptogram, obtain an accesscredential associated with the token, replace with the token with an access credential in the authorization request message, and transmit the authorization request message including the access credential to an authorizing entity computer for authorization.

12. A user device comprising: a processor; and a computer readable medium comprising code, executable by the processor for performing a method comprising: obtaining, by the user device comprising a storage application, a verifiable credential comprising an attestation comprising access data, the attestation being a network token attestation or storage application attestation; and transmitting, by the user device to a resource provider computer, the verifiable credential, wherein the resource provider computer processes an interaction using the verifiable credential.

13. The user device of claim 12, wherein the user device is a mobile phone.

14. The user device of claim 12, wherein the storage application is a digital identity storage application.

15. The user device of claim 12, wherein the attestation is the network token attestation in the form of a JSON (Javascript Object Notation) Web token, and the access data comprises a token, a token reference identifier, a cryptocurrency identifier, a demand account number, or a user identification number.

16. A method comprising: receiving, by a credential processing system, an authorization request message comprising a verifiable credential comprising an attestation comprising access data comprising a token or a token reference identifier, the attestation being a network token attestation or storage application attestation, a key binding proof, a resource provider identifier, and a value for an interaction; validating, by the credential processing system, the attestation;validating, by the credential processing system, the key binding proof; obtaining an access credential associated with the token or the token reference identifier; modifying, by the credential processing system, the authorization request message to include the access credential instead of the token or the token reference identifier; and transmitting, by the credential processing system, the authorization request message to an authorizing entity computer for authorization.

17. The method of claim 16, wherein the attestation is the network token attestation, and the credential processing system comprises a processing network computer in communication with a digital credential issuance system, and wherein the digital credential issuance system validates the attestation and the key binding proof.

18. The method of claim 16, wherein the credential processing system also comprises a token service computer which stores associated token reference identifiers, access tokens, and access credentials.

19. The method of claim 16, wherein the key binding proof comprises a digital signature produced using a private key of a user device used in the interaction, and the key binding proof is validated by verifying the digital signature with a public key corresponding to the private key of the user device.

20. The method of claim 16, wherein the attestation is the network token attestation in the form of a JSON (Javascript Object Notation) Web token, and the access data comprises the token, the token reference identifier, a cryptocurrency identifier, a demand account number, or a user identification number.

Images