WO2020117735A1 - Système de protection de données comprenant une récupération de clé cryptographique - Google Patents

Système de protection de données comprenant une récupération de clé cryptographique Download PDF

Info

Publication number
WO2020117735A1
WO2020117735A1 PCT/US2019/064132 US2019064132W WO2020117735A1 WO 2020117735 A1 WO2020117735 A1 WO 2020117735A1 US 2019064132 W US2019064132 W US 2019064132W WO 2020117735 A1 WO2020117735 A1 WO 2020117735A1
Authority
WO
WIPO (PCT)
Prior art keywords
user
server computer
user data
cryptographic key
transaction
Prior art date
Application number
PCT/US2019/064132
Other languages
English (en)
Inventor
Michael Steven Bankston
Erik Christopher Friend
Original Assignee
Visa International Service Association
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Visa International Service Association filed Critical Visa International Service Association
Publication of WO2020117735A1 publication Critical patent/WO2020117735A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • H04L9/3239—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving non-keyed hash functions, e.g. modification detection codes [MDCs], MD5, SHA or RIPEMD
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/088—Usage controlling of secret information, e.g. techniques for restricting cryptographic keys to pre-authorized uses, different access levels, validity of crypto-period, different key- or password length, or different strong and weak cryptographic algorithms
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0894—Escrow, recovery or storing of secret information, e.g. secret key escrow or cryptographic key storage
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees

Definitions

  • a digital identity may refer to a secure set of information about an entity (e.g., a person, organization, or thing). The Dl may, in turn, be made available to another entity in a secure manner.
  • an entity In order to receive information about a Dl, an entity may request an assertion, or a statement of fact about the Dl. The assertion may be used to obtain needed information about the digital identity to perform an interaction, without the need to obtain specific information about the Dl that would not be needed to perform the interaction.
  • a Dl can be protected through the use of assertions, a Dl can be connected to a large amount of personal information. For example, a person’s credit history, bank account, location history, and social security number may all be linked to their digital identity. Thus there is a need to protect the information associated with a digital identity. It may not be desirable to provide even authorized parties with unrestricted access to a person’s Dl or any information derived from the person’s Dl (e.g., an assertion). Further, in many instances, Dl is stored in a cloud storage environment, thereby making the Dl and any information associated with it vulnerable to hacking and data breaches.
  • Embodiments of the Invention address these and other problems individually and collectively.
  • Embodiments of the invention provide for a system and method that can secure protect information such as Dl information, while also being convenient for a user and allowing requesting parties to access the information that they need to perform interactions with the user.
  • a user is desirably in control of their Dl and can determine when other entities can and cannot access their Dl, or any information associated with the Dl.
  • Embodiments also allow for the ability to continuously authenticate the user, without specifically requesting information from the user on a frequent basis.
  • One embodiment includes a method that comprises receiving, by a server computer, an indication from a user device that the user has authorized access to user data associated with a digital identity of the user by a requesting device for a time period, the user data being in encrypted form in a database coupled to the server computer.
  • the method also includes receiving, by the server computer from the requesting device, a user data request for the user data associated with the digital identity of the user and determining, by the server computer, that the user data request occurs during the time period.
  • the method also includes, in response to the determination that the user data request occurs during the time period, retrieving, by the server computer, a cryptographic key from the user device.
  • the method also includes decrypting, by the server computer, the encrypted user data using the cryptographic key to form decrypted user data and transmitting, by the server computer, the decrypted user data to the requesting device.
  • Another embodiment includes a server computer comprising a processor and a computer readable medium, coupled to the processor, for executing a method.
  • the method comprises receiving an indication from a user device that a user has authorized access to user data associated with a digital identity of the user by a requesting device for a time period, the user data being in encrypted form in a database coupled to the server computer.
  • the method also includes receiving, from the requesting device, a user data request for the user data associated with the digital identity of the user and determining that the user data request occurs during the time period.
  • the method also includes, in response to the determination that the user data request occurs during the time period, retrieving a cryptographic key from the user device.
  • the method also includes decrypting the encrypted user data using the cryptographic key to form decrypted user data and transmitting the decrypted user data to the requesting device.
  • Another embodiment includes a method that comprises authenticating, by a user device, a user and transmitting, by the user device to a server computer, an indication that the user has authorized access to user data associated with a digital identity of the user by at least a requesting device for a time period.
  • the method also includes receiving, by the user device from the server computer, a key request for a cryptographic key responsive to receiving a user data request for user data from the requesting device and providing, by the user device, the cryptographic key.
  • Another embodiment includes a user device that comprises a processor and a computer readable medium, coupled to the processor, for executing a method comprising authenticating a user and transmitting, to a server computer, an indication that the user has authorized access to user data associated with a digital identity of the user by a requesting device for a time period.
  • the method also includes receiving, from the server computer, a request for a cryptographic key responsive to receiving a user data request for user data from the requesting device and providing the cryptographic key.
  • FIG. 1 shows a block diagram of a system according to embodiments.
  • FIG. 2 shows a block diagram of an assertions platform according to embodiments.
  • FIG. 3 shows a block diagram of a user device according to
  • FIG. 4 shows a flow diagram of accessing user data according to embodiments.
  • FIG. 5 shows another flow diagram of accessing user data according to embodiments.
  • FIG. 6 shows a flow diagram of a transaction with continuous authentication according to embodiments.
  • FIG. 7 shows a flow diagram of transaction risk analysis process according to embodiments.
  • FIG. 8 shows a graphical depiction of on the grid status while on a predicted path according to some embodiments.
  • FIG. 9 shows a graphical depiction of on the grid status after a new transaction according to some embodiments.
  • FIG. 10 shows a graphical depiction of on the grid status after a suspicious transaction according to some embodiments.
  • FIGS. 11 A - 11 D are diagrams of graphical user interfaces according to some embodiments. DETAILED DESCRIPTION
  • Embodiments of the invention can provide for systems and methods for controlling access to user data.
  • a user may choose to be“on the grid.” While a user is on the grid, their data may be made available to other parties such as resource providers and financial entities. At any time, the user can choose to go“off the grid,” and make their information unavailable to such other parties.
  • assertions may be used to provide information about a user, while protecting the user’s user data.
  • assertions can be used to provide certain information that is relevant to a transaction without disclosing the underlying information in the user data. For example, an assertion such as“person X is over 21 years old” provides sufficient information to a bar owner that person X is old enough to drink alcohol, but does not disclose person X’s specific age. Person X’s specific age would be person X’s specific user data.
  • an assertions platform may authorize transactions made by the users.
  • the status of the user in the system may default to being“off the grid.”
  • the user may need to authenticate themselves to the system.
  • the user may authenticate themselves to the system with a password, a biometric, or some other authentication data.
  • the user may authenticate themselves using an application on a user device such as a mobile phone or wearable device.
  • an assertions platform may receive an indication that the user is“on the grid.” While on the grid, a user may be continuously authenticated by checking their current behavior to a predicted path based on past user behavior.
  • the user may remain“on the grid.” If the user begins behaving erratically, or if fraudulent behavior is suspected, the user may be placed“off the grid” to protect their user data until the user is able to authenticate themselves again.
  • An“identity attribute” may refer to a particular piece of information about an entity (e.g., person, organization, thing, or the like). Examples of identity attributes include a social security number, an age, a phone number, and a bank account number associated with a person.
  • A“user” may include an individual or a computational device.
  • a user may be associated with one or more personal accounts and/or mobile devices.
  • the user may be a cardholder, account holder, or consumer.
  • the user may have a digital identity.
  • a user may also be a “target entity” in some embodiments.
  • User data may include information pertaining to a user. Examples of user data may include a driver’s license number, a bank account number, a record of past transactions made at a particular merchant, and a record of visits to a particular location.
  • user data may be personal data about a user, such as a driver’s license number, a bank account number, that is provided by an authority (e.g., a bank, a government agency).
  • Identity attributes may be other examples of user data, and this user data may make up a digital identity of the user.
  • user data may be generated based on actions of the user, such as a location event when a user enters a merchant’s store.
  • user data may be stored in encrypted form in one or more databases.
  • A“target entity” may refer to an entity corresponding to an assertion
  • a target entity may be Mary Jones.
  • An assertion about Mary Jones may specify whether Mary Jones is old enough to purchase alcohol in a particular location.
  • a related identity attribute for Mary Jones may be Mary Jones’s exact age (e.g., 35 years old).
  • A“relying entity” may refer to an entity that may receive an assertion
  • the relying entity may be a bar that requests an assertion whether a target entity is old enough to be served alcohol.
  • A“requesting device” may include a device that requests data about a user.
  • requesting devices may include a resource provider computer requesting information (e.g., assertions) about a user making a transaction at the resource provider.
  • Another example may include an issuer computer requesting information (e.g., past locations and transactions) about a user in order to track purchasing habits.
  • Requesting devices may transmit a“user data request” to a computer such as an assertions platform.
  • the requesting device may be able to specify in the user data request what user data they would like to receive.
  • a bank may request data about transactions made on a particular day.
  • the user data returned in response to a user data request may be standardized. For example, any bar that sends a user data request about a user may only receive an age of the user.
  • A“digital identity” may include a secure set of information about an entity (e.g., a person, organization, or thing).
  • a Dl may comprise a plurality of identity attributes, as well as a digital identity identifier that identifies the digital identity.
  • a Dl for a user, Joe Smith may include identity attributes such as the user’s date of birth, social security number, address, and driver’s license number, as well as an identifier such as Joe_Smith_1234 which is used to identify Joe Smith’s digital identity.
  • the Dl may be made available to another entity in a secure manner. Dls may rely on agreements among stakeholders and security measures such as cryptography.
  • A“user device” may be any suitable electronic device that can process and communicate information to other electronic devices.
  • a user device may include a processor and a computer-readable medium coupled to the processor.
  • the computer-readable medium may comprise code, executable by the processor.
  • the user device may also each include an external
  • Examples of user devices may include a mobile device, a laptop or desktop computer, a wearable device, etc.
  • An“access device” may be any suitable device for providing access to an external computer system.
  • An access device may be in any suitable form.
  • Some examples of access devices include point of sale (POS) devices, cellular phones, PDAs, personal computers (PCs), tablet PCs, hand-held specialized readers, set-top boxes, electronic cash registers (ECRs), automated fuel dispensers (AFDs), automated teller machines (ATMs), virtual cash registers (VCRs), kiosks, security systems, access systems, Websites, 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 mobile device.
  • an access device may comprise a POS terminal
  • any suitable POS terminal may be used and may include a reader, a processor, and a computer-readable medium.
  • a reader may include any suitable contact or contactless mode of operation.
  • exemplary card readers can include radio frequency (RF) antennas, optical scanners, bar code readers, or magnetic stripe readers to interact with a mobile device.
  • RF radio frequency
  • A“resource provider” can be any suitable entity that provides resources (e.g., goods, services, access to secure data, access to locations, or the like) during a transaction.
  • a resource providing entity can be a merchant, a venue operator, a building owner, a governmental entity, etc.
  • a “merchant” may typically be an entity that engages in transactions and can sell goods or services, or provide access to goods or services.
  • An“acquirer” may be a financial institution associated with a merchant. Acquirers typically provide merchants with a bank account, and in some cases, transaction accepting infrastructure. Generally, after a transaction has been authorized and as part of the settlement process, funds are transferred from the issuer to merchant’s account at the acquirer. The acquirer may also communicate payment transaction status with the merchant. The acquirer may operate an acquirer computer, which may generically be a transport computer.
  • An“issuer” may be an entity that issues an account.
  • an issuer is a financial institution, such as a bank, that creates and maintains financial accounts for account holders.
  • An issuer or issuing bank may issue and maintain financial accounts for consumers. The issuer of a particular consumer account may determine whether or not to approve or deny specific transactions.
  • A“payment processing network” may include a network that processes payment data.
  • a payment processing network may be a 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 system may include VisaNetTM.
  • Payment processing systems such as VisaNetTM are able to process credit card transactions, debit card transactions, and other types of commercial transactions. Authorization, settlement, and clearing may be done at the same time (substantially
  • the payment processing network may include a server computer.
  • the payment processing network may use any suitable wired or wireless network, including the internet.
  • A“processor” may refer to 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 a CPU comprising 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).
  • 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.
  • A“server computer” may include a powerful computer or cluster of computers.
  • the server computer can be a large mainframe, a minicomputer cluster, or a group of servers functioning as a unit.
  • 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 may use any of a variety of computing structures, arrangements, and compilations for servicing the requests from one or more client computers.
  • An“assertion” may refer to a secure fact about an entity.
  • An assertion can protect information while being useful to achieve a particular goal. For example, an assertion may specify something about an entity, such as whether the entity should be allowed to purchase alcohol in a particular location. The assertion may be“Jane Doe is old enough to purchase alcohol in California.” This assertion can be used by a bar in its decision to serve alcohol to a person, instead of conveying the person’s driver’s license information to the bar. As another example, an assertion may specify whether an entity has an account which can accept deposits (e.g.,“Jane Doe has a bank account and can accept deposits.”).
  • A“type of assertion” may be a category of assertions, e.g., whether an entity has at least $100 in a bank account.
  • The“assertion” or“assertion value” associated with the type of assertion may be a corresponding answer for a particular entity, which may in the form of“yes” or“no,” or may be an affirmative statement (e.g.,“Jane Doe has $100 or more in her bank account.”).
  • An assertion may be secured cryptographically.
  • An assertion may be digitally signed by the entity of interest and/or the trusted party providing the secure facts. In some embodiments, an assertion may be digitally signed by an entity of interest and/or a trusted party providing the secure facts.
  • An“assertions model” may be a set of assertion types that may be associated with a particular entity.
  • An assertions model may specify one or more types of assertions.
  • an assertions model may include two types of assertions: whether an entity is old enough to rent a car and whether the entity has a valid driver’s license.
  • An assertions model may be tailored to a particular situation. Continuing with the previous example, whether an entity is old enough to rent a car and whether the entity has a valid driver’s license may correspond to an assertions model for the context of a prospective car renter interacting with a rental car agency.
  • An assertions model may further specify a set of identity attributes.
  • A“key” may refer to a piece of information that is used in a
  • 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.
  • a key may refer to a database index as part of a key-value pair.
  • A“public key” may include a cryptographic key that is designed to be shared (e.g., transmitted between entities) 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.
  • A“private key” may include a cryptographic key that may be used to decrypt data encrypted with a public key.
  • A“cryptogram” may refer to an encrypted representation of some information.
  • A“distributed ledger” may refer to a database that is shared among multiple nodes across a network. Entities corresponding to each node may store identical copies of the ledger at a given time. The entities may have permission to make changes or additions to the ledger. When the ledger is changed, the participating entities may receive the updated ledger. Examples of distributed ledgers include a blockchain, wherein transactions are verified before being encrypted and recorded to the ledger in a block of transactions.
  • “On the grid” may include being connected to and in communication with a computer network infrastructure.
  • being“on the grid” may include being connected to a network communication system.
  • other devices can communicate with the user device in order to access information about the user, such as a digital identity, user data, assertions and the like.
  • a device can communicate with the user device to retrieve a cryptographic key from the user device, which is then used to decrypt an assertion about the user.
  • a user may be authenticated before they go“on the grid.”
  • a user may be continuously authenticated while they are“on the grid” in order to stay“on the grid.”
  • Off the grid may include being disconnected from and not in communication with a computer network infrastructure.
  • being“off the grid” may include being disconnected from a network communication system.
  • other devices may not be able to communicate with the user device, and may not be able to obtain a cryptographic key that may be used to access information such as a digital identity, user data, assertions and the like.
  • a device may not be able to communicate with the user device to retrieve a cryptographic key, and may thus be unable to decrypt information about the user.
  • a user may choose to go off the grid in order to protect their information from other parties that may attempt to access it.
  • a user may be taken off the grid because fraudulent activity is suspected.
  • FIG. 1 shows a block diagram of a system 100 according to
  • the system 100 may comprise an access device 110, a resource provider computer 120, a transaction processor computer 130, an assertions platform 140, a user device 150, a key locker 160, and an issuer computer 170.
  • the system 100 may also comprise an assertions ledger 125 and an event log 135, which may be accessed by the assertions platform 140.
  • the entities in the system 100 may be in communication with each other, via any suitable communication network or combinations of communications networks.
  • the one or more communication networks may include 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.
  • WAP Wireless Application Protocol
  • Message between the entities, providers, networks, and devices illustrated in FIG. 1 may be transmitted using a secure communications protocols such as, but not limited to, File Transfer Protocol (FTP); HyperText Transfer Protocol (HTTP); Secure Hypertext Transfer Protocol (HTTPS), Secure Socket Layer (SSL), ISO (e.g., ISO 8583) and/or the like.
  • FTP File Transfer Protocol
  • HTTP HyperText Transfer Protocol
  • HTTPS Secure Hypertext Transfer Protocol
  • SSL Secure Socket Layer
  • ISO ISO
  • the access device 110 may be a point of sale terminal.
  • the access device 110 may be in communication with resource provider computer 120.
  • Access device 110 may receive information through one or more input devices including a card reader, a contactless interface, a key pad, etc.
  • the resource provider computer 120 may be operated by a resource provider that provides resources to the user in exchange for some value.
  • the resource provider may be assigned a resource provider identifier.
  • the resource provider identifier my include data associated with a digital signature and/or cryptographic key (e.g., a public key) of the resource provider.
  • the resource provider computer 120 may communicate with the user device 150 through access device 110.
  • the resource provider may be an example of a subscriber or a relying entity. If the resource provider is a relying entity, the resource provider may operate a resource provider computer which may be characterized as a relying entity computer.
  • the resource provider computer 120 may also have, or be in communication with, a subscriber processor that can obtain assertions from the assertions platform 140.
  • the transaction processor computer 130 may be a computer that processes transactions for resource providers. In some embodiments, transaction processor computer 130 may be operated by an acquirer of the resource provider. Transaction processor computer 130 may also be in communication with a payment processing network (not shown in FIG. 1 ).
  • the assertions platform 140 can maintain and store assertions models for making assertions about digital identities.
  • the assertions platform 140 may comprise a server computer.
  • an assertions model can be standardized such that information from various sources about digital identities can be organized into a set of assertions that is uniform regardless of the sources or the type of information coming from those sources.
  • the assertions model may also be standardized to provide for predetermined types of assertions regarding a digital identity to a resource provider, or type of resource provider.
  • assertions models can be stored in an assertions model database of the assertions platform 140.
  • the assertions model can include at least one type of assertion.
  • the assertions model can include a set of assertion types sufficient to be considered“well formed” for the relevant domain.
  • the assertions model can include data associated with additional identifiers, including but not limited to a name/identifier and current version of the assertions model and the date on which the assertions model was last updated.
  • the assertions platform 140 may also include or be in communication with an event log 135.
  • the event log 135 may be a file, a collection of files, or a database for storing event data.
  • an event may correspond to a request for information.
  • an event may correspond to a resource provider request for user data in association with an interaction.
  • the system may store event data such as the parties involved the event, the type of the event, a time and/or date associated with the event, etc.
  • each instance of event data may be encrypted using a set of cryptographic keys.
  • An event may, for example, be encrypted using a cryptographic key of the user, transaction cryptographic key of the resource provider, and/or cryptographic keys assigned to other entities, such as one or third party facilitators or technology providers (e.g., financial transaction processors).
  • the assertions ledger 125 may store assertions about users.
  • the assertions ledger 125 may be implemented as a distributed ledger such as a blockchain.
  • assertions in the assertions ledger 125 may be cryptographically secured. That is, the assertions may be signed by relevant parties to indicate that the relevant parties approved of such assertions.
  • the assertions platform 140 may only be able to retrieve assertions about the user from the assertions ledger 125 when the user is authenticated.
  • the event log 135 may be used to access event data associated with events for tasks such as dispute resolution, fraud detection, and/or analysis of user behaviors.
  • access paths to the event data may be defined via a common API structure. The access paths may be established such that limited entities may access the events with limited amounts of data.
  • the event log 135 may be stored in a database. Additionally, or alternatively, the event log 135 may be stored in a distributed ledger, including but not limited to a blockchain.
  • the event data may be encrypted in the event log 135.
  • the encrypted event data may only be accessible using an appropriate cryptographic key (e.g., a private key of a user associated with an event).
  • an appropriate cryptographic key e.g., a private key of a user associated with an event.
  • a cryptographic key held by a user device 150 may be required to access event data for an event involving the user of the user device 150. This ensures that the event data is only available to the user or others that the user may designate.
  • a cryptographic key obtained by the assertions platform 140 from the user device 150 can unlock other cryptographic keys in the key locker 160.
  • the key locker 160 may store additional cryptographic keys that can be used to encrypt user data such as assertions, event data, and transaction data.
  • a user may be associated with a plurality of additional cryptographic keys stored in the key locker.
  • a cryptographic key of the user may be used to decrypt the plurality of additional cryptographic keys.
  • the cryptographic key of the user may be used to decrypt an index associating the additional cryptographic keys to the user.
  • a user can have three encrypted events in the event log, each associated with a different transaction that the user has conducted.
  • each event may be linked together as being associated with the user, and may have unencrypted information about, for example, the resource provider involved each transaction. This may leak information about the user and their past transactions. Instead, each of the three event may be encrypted with a separate additional cryptographic key. Thus, each of the three events may appear to be separate, and cannot be linked together to glean
  • the user device 150 may be operated by a user.
  • the user device 150 may be, for example, a mobile phone or laptop, which can allow the user to interact with other devices of the system.
  • the user may be associated with a digital identity, and may have a user identifier (e.g., Joe_Smith_1234 for a user“Joe Smith ) that is stored on the user device 150.
  • the user identifier may include data associated with a digital signature and/or cryptographic key of the user.
  • the user device 150 may be able to interact with the access device 110 to send the user identifier to the transaction processor computer 130 (e.g., in an authorization request message) as part of a transaction such as a payment transaction.
  • the user device 150 can also store a cryptographic key such as a private key that can be retrieved and used by a requesting device to decrypt user data.
  • the issuer computer 170 may be operated by an issuer that may have issued an account of the user.
  • the issuer computer 170 may be in communication with the transaction processor computer 130 through a payment processing network (not shown in FIG. 1 ).
  • the issuer computer 170 may include an authentication computer that can authenticate the user of the user device 150.
  • the issuer computer 170 may then send an indication to the assertions platform 140 (e.g., via the user device 150) that the user has been authenticated.
  • FIG. 2 shows a block diagram of an assertions platform 140.
  • the assertions platform 140 may comprise a server computer comprising a processor 146 operatively coupled to a memory 144, a network interface 148, and a non- transitory computer-readable medium 142.
  • the assertions platform 140 may also include or be in communication with an assertions ledger 125, an event log 135, and a predicted path database 145.
  • the network interface 148 may be configured to connect to one or more communication networks to allow the assertions platform 140 to communicate with other entities such as a resource provider computer 120, a user device 150, etc. Communication between the assertions platform 140 and the user device 150, or any other device in the system in FIG. 1 can be direct, indirect, and/or via an API.
  • the computer-readable medium 142 may comprise one or more non- transitory media for storage and/or transmission. Suitable media include, as examples, a 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.
  • RAM random access memory
  • ROM read only memory
  • magnetic medium such as a hard-drive or a floppy disk
  • an optical medium such as a compact disk (CD) or DVD (digital versatile disk), flash memory, and the like.
  • CD compact disk
  • DVD digital versatile disk
  • flash memory and the like.
  • the computer-readable medium 142 may be any combination of such storage or transmission devices.
  • the computer-readable medium 142 may comprise software code stored as a series of instructions or commands.
  • the computer-readable medium 142 may also comprise an assertion determination module 142A, a risk analysis module 142B, a risk scoring module 142C, a pool sorting module 142D, a risk exchange module 142E, and a predicted path module 124F.
  • the assertion determination module 142A in conjunction with the processor 146, may determine an appropriate set of assertions for a particular entity such as a particular resource provider.
  • each resource provider may desire a different set of assertions.
  • the risk analysis module 142B may analyze the risk associated with a transaction, based on the assertions involved in the transaction.
  • the risk analysis module may 142B may be used as part of authorization operations.
  • the risk analysis module 142B in conjunction with the processor 146, may determine the risk for an assertion that is used in the transaction based on an update to a user’s identity data underlying the assertion, and/or a particular reference source (e.g., a driver’s license, or a statement from an individual) that forms the basis for identity data underlying the assertion.
  • a first assertion may be generated based upon only a validated email address.
  • the first assertion may be assigned a relatively “weak” score.
  • a second assertion can be generated using identity attribute data that was confirmed with a state-sponsored document such as a driver’s license, background checks of the data against several different information databases (e.g. a tax record database, property record database, etc.
  • the second assertion may be associated with a relatively“strong” score indicating confidence in the assertion.
  • the risk analysis module 142B may also analyze risk of the transaction by comparing the transaction to a predicted path of the user from the predicted path database 145. A transaction that is on the predicted path can be one that the user has completed before.
  • the user For example, if a user goes to a particular gas station to purchase gas every Tuesday around the same time, then the user’s path to that gas station can be a predicted path for that user. If the user performs a transaction that follows a similar path as a previous transaction, then the transaction has a lower risk of fraud than a different transaction that does not follow a predicted path.
  • the risk scoring module 142C in conjunction with the processor 146, may score transactions based upon an analysis provided by the risk analysis module 142B.
  • the risk score may be derived as a function of the identity data, the verifications performed, and/or confidence in the assertion.
  • Assertions that are less trusted may result in a multiplier for the risk score to increase the risk determined for the transaction.
  • the risk score may also depend on the percentage of past transactions involving the resource provider that have been completed successfully.
  • the pool sorting module 142D in conjunction with the processor 146, may sort transactions into transaction pools, or tranches, of similar transactions.
  • the transactions may be sorted by risk score. For example, transactions with risk scores that are the same may be grouped together. In another example, transactions with risk scores that fall within a certain range may be grouped together.
  • transactions may be grouped by other information, such as the resource provider and/or the transaction value.
  • the risk exchange module 142E in conjunction with the processor 146, may determine a price for a transaction. The price may be based on the risk score for the transaction. The risk exchange module 142E, in conjunction with the processor 146, may also determine a price for a transaction group that was formed by the pool sorting module 142D. The risk exchange module 142E, in conjunction with the processor 146, may then offer the transaction or group of transactions to a risk marketplace for evaluation. One party may decide to take on the risk for a transaction or a group of transactions, in exchange for a fee.
  • the predicted path module 142F in conjunction with the processor 146, may build predicted paths from user interaction data (e.g., data from past transactions).
  • a predicted path may be a graph of connected nodes, where each node is a valid event from the user’s past activity in the event log 135.
  • the predicted path module 142F, in conjunction with the processor 146 may use a machine learning algorithm to build the graph.
  • the event log 135 may store records of events associated with various users.
  • the event log 135 may be stored in a database.
  • event data in the event log 135 may be encrypted.
  • the event data may only be decrypted using private keys associated with one or more users associated with the events.
  • Events may be of any suitable type. Examples of events include transactions, requests for assertions, and the generation of new assertions. Some events may also include geofence location events.
  • a geofence can be a virtual boundary. The geo-fence can trigger an event when an entity enters or leaves a geofenced area. For example, a geofence for a user may be virtual perimeter that is around a bar. If the user crosses the geofence and enters the bar, then the user may have taken part in a geofence location event. Therefore, in some embodiments, location events may be entered into the event log 135 to indicate when the user was in a particular area.
  • the predicted path database 145 may store information about past user behavior.
  • the predicted path database 145 may store predicted paths, or patterns of user actions, as determined by the predicted path module 142F.
  • the predicted path may also include haptics and/or other information about user actions.
  • the predicted path database 145 may be periodically updated with new predicted paths as the user’s actions change and/or as new actions are included.
  • FIG. 3 shows a block diagram of a user device 150.
  • the user device 150 may comprise a processor 156.
  • the processor 156 may be coupled to a memory 154 with a secure element 154A, a network interface 158, and a non- transitory computer-readable medium 152.
  • the computer-readable medium 152 may comprise an authentication module 152A, a key storage module 152B, a transaction module 152C, and a behavior data collection module 152D.
  • the secure element 154A may be a secure data storage area that is tamper-proof. It may store a cryptographic key assocated with the user of the user device 150.
  • the cryptographic key may be a private key associated with a public key held or used by the assertions platform to encrypt data for storage.
  • the public key may encrypt user data or additional cryptographic keys of the user that may be used to encrypt user data.
  • the secure element may be accessible by the assertions platform 140.
  • the authentication module 152A may authenticate the user of the user device 150.
  • authentication module 152A and the processor 156 may receive a password or PIN from the user, and may then verify the password or PIN.
  • the authentication module 152A may capture biometric data of the user and verify the biometric data.
  • the authentication module 152A, in conjunction with the processor 156 may then compare the information to the password or PIN to a stored value, or may send the data relating to the comparison to an authorizing entity such as the issuer computer 170 or the assertions platform 140.
  • the user may enter a biometric sample such as a fingerprint or voice sample into the user device 150.
  • the authentication module 152A in conjunction with the processor 156, can send an indication to the assertions platform 140 that the user has been authenticated.
  • the key storage module 152B in conjunction with the processor 156, may store a cryptographic key of the user and may control access to the
  • key storage module 152B may store the cryptographic key in an encrypted form and may, in conjunction with the processor 156, decrypt the encrypted cryptographic key, and send the decrypted cryptographic key to the assertions platform 140. The assertions platform may then use the decrypted cryptographic key. In some embodiments, a session key may be used to establish a secure channel between the user device 150 and the assertions platform 140.
  • the transaction module 152C in conjunction with the processor 156, may enable the user device 150 to be used for transactions. In some embodiments, transaction module 152C may be a digital wallet application.
  • the transaction module 152C, in conjunction with processor 156 may also transmit a user identifier to an access device or resource provider computer in order to initiate a transaction.
  • the behavior data collection module 152D in conjunction with the processor 156, can record and collect past user behavior data for the creation of predicted paths.
  • Past user behavior data may comprise past locations, past transactions, and/or haptics.
  • a GPS unit of the user device 150 may record locations of the user device 150 as GPS coordinates.
  • an accelerometer of the user device 150 may user record movement and haptic data.
  • Behavior data collection module 152D may periodically send the behavior data to the assertions platform 140 for evaluation. For example, behavior data may be sent to the assertions platform 140 hourly, daily, or weekly.
  • FIG. 4 shows a flow diagram of a method according to an embodiment.
  • FIG. 4 shows a method for accessing user data of a user during an interaction.
  • the user is“on the grid.”
  • the user data may be associated with a digital identity of the user.
  • the user data may be one or more assertions about the user.
  • the user data may be in encrypted form, and may be stored in a database coupled to the assertions platform 140 (e.g., an event log 135, an assertions ledger 125).
  • the user may be authenticated. For example, the user may type a password into user device 150. In other words, the user may type a password into user device 150.
  • the user may not be authenticated until the interaction is initiated, such as in step S406.
  • the user device 150 may transmit an indication to the assertions platform 140 that the user has authorized access to the user data by one or more parties during a time period.
  • the access to the user data may be authorized for requesting devices (e.g., resource provider computer 120, issuer computer 170) for the next 8 hours.
  • the indication may include a time indicating when the time period begins and/or a time when the time period ends.
  • the indication may include data indicating that the user was authenticated at 8 am and a time period of 8 hours.
  • the indication may include that the user has authorized access to user data until the time period ends at 4 pm.
  • the assertions platform 140 may authenticate the user directly, and an indicator may be generated as a result of the authentication of the user by the assertions platform.
  • the user device 150 may make a cryptographic key available to the assertions platform 140 so that the assertions platform 140 can decrypt the user data using the cryptographic key.
  • the assertions platform 140 and the user device 150 can use session keys to securely pass the cryptographic key from the user device 150 to the assertions platform 140.
  • the user device 150 operated by the user may provide an identifier to an access device 1 10.
  • the identifier could be an alphanumeric string with characters (e.g., a phone number) that identifies the user or the user device 150.
  • the identifier can be a digital signature and/or a cryptographic key (e.g. , a public key) of the user.
  • the access device 1 10 e.g., a POS terminal
  • step S404 the access device 1 10 can send a user data request to the assertions platform 140, via resource provider computer 120.
  • the access device 1 10 can send a user data request to the assertions platform 140, via resource provider computer 120.
  • the user data request may be an assertions request.
  • the resource provider computer 120 may be referred to as a requesting device since it is requesting data about the user of the user device 150.
  • the user data request may include the identifier of the user and a request for one or more assertions about the user.
  • the user data request may also include a request for other user data associated with a digital identity of the user, an identifier of the resource provider, and a time stamp associated with the user data request.
  • the assertions platform 140 may also have access to one or more databases of information about digital identities associated with users.
  • the assertions platform 140 may be able to use information from the databases to generate assertions.
  • the assertions platform 140 may also store groups of one or more assertions with indexes.
  • One example of a group of assertions include a first assertion that an entity is at least 21 years old and a second assertion that the entity has a valid payment account with a financial entity. Resource providers may be able to request one or more assertions such as these from the assertions platform 140 to conduct a transaction.
  • the resource provider may be a bar owner, and may request a group of assertions include a first assertion that an entity is at least 21 years old and a second assertion that the entity has a valid payment account with a financial entity.
  • the assertions platform 140 may then provide this group of assertions to the resource provider computer 120 and/or the access device 110.
  • the assertions platform 140 can retrieve a cryptographic key (e.g., a private key) associated with the user from the user device 150.
  • the cryptographic key may be a private key of a public/private key pair.
  • the cryptographic key may be stored on a secure element of the user device 150.
  • the assertions platform 140 can determine that the user data request occurs during the time period during which the user has authorized one or more parties to access to the user’s user data. For example, the assertions platform 140 can determine that the time stamp in the user data request is within a time period authorized by the user of the user device 140. For example, after
  • the user of the user device 150 may be“on the grid” for a time period of 8 hours. Thus if the user was authenticated at 9 am on Friday, they may be“on the grid” from 9 am to 5 pm.
  • the time stamp associated with the user data request may be 10 am on Friday from Los Angeles, California.
  • a resource provider computer 120 requesting user data such as an assertion may be able to obtain such data.
  • the time period when parties are able to access the user’s user data may be dynamic and may depend on behavior of the user. For example, at 3 pm, the user may conduct a transaction that is consistent with past user behavior and the time period may be extended to 8 pm instead of 5 pm.
  • the time period may end immediately and the user may go“off the grid.”
  • parties may not be able to access the user’s user data.
  • the assertions platform 140 can retrieve the cryptographic key from the user device 150. If the user data request did not occur during the time period (e.g., the user is off the grid), the assertions platform 140 may not be able to retrieve the cryptographic key of the user from the user device 150.
  • the time period may end at 5 pm and a second requesting device (e.g., a second resource provider computer) may send a second user data request to the assertions platform 140 at 8 pm.
  • the second user data request occurs outside the time period, so the assertions platform 140 may send a decline message to the second requesting device.
  • the cryptographic key may be stored on a secure element of the user device 150.
  • the cryptographic key can be broken up and shared among several devices using any suitable key sharing algorithm. For example, key sharing, or Shamir’s secret sharing, may be used. This can allow the cryptographic key to be reconstructed if needed.
  • the assertions platform 140 may retrieve one or more additional keys associated with the user from a key locker 160.
  • the key locker 160 may store keys of the user and/or other parties (e.g., a transaction may correspond to a pairwise key set of the user and a merchant involved in the transaction).
  • the key locker 160 may be secured with the cryptographic key of the user.
  • the user may have a different identifier for each transaction. In such cases, the key locker 160 may store a record of which identifiers are associated with particular digital identities.
  • the assertions platform 140 may use the cryptographic key access one or more other cryptographic keys in the key locker 160 or to decrypt one or more other cryptographic keys in the key locker 160.
  • the assertions platform 140 may retrieve a set of one or more assertions about the user, or other requested user data.
  • the cryptographic key may be used to access an assertions ledger 125 with assertions about the user.
  • the cryptographic key may be used to decrypt an index to identify assertions about the user, or decrypt the assertions themselves.
  • one or more additional cryptographic keys from the key locker 160 may be obtained using the cryptographic key from the user device 150 and those one or more additional cryptographic keys may be used to decrypt the assertions.
  • the cryptographic key obtained from the user device 150 may be also used to access information about the user in order to generate new assertions.
  • the assertions platform 140 may automatically delete the cryptographic key obtained from the user 150 after each transaction is completed.
  • the assertions platform 140 may send a response message to the resource provider computer 120.
  • the response message may include the decrypted user data, such as the set of assertions requested by the resource provider computer 120.
  • the assertions platform 140 may write information about the interaction to an event log 135.
  • the assertions platform 140 may note that an assertion was requested and/or created.
  • Entries in the event log 135 may contain the identifiers of all entities involved in the transaction.
  • the entries and/or identifiers associated with a transaction may be encrypted.
  • the identifier of the user may be encrypted with the cryptographic key of the user.
  • FIG. 5 shows a method for retrieving user data, such as event data, about a user that is on the grid.
  • user data such as event data
  • the user may have been previously authenticated and may have authorized one or more other parties to access the user’s user data.
  • an assertions platform 140 may receive a user data request requesting information about one or more identity-based interactions associated with a particular user.
  • the access request may be received from a requesting device such as a user device 150, a resource provider computer 120, or an issuer computer 170.
  • a user may wish to see a list of all transactions that they have completed in the past week.
  • a resource provider or an issuer may wish to review information about a past transaction in order to settle a dispute.
  • the user data request may include an identifier of the user associated with the transaction, an identifier of the requesting device, and a time stamp for the prior transaction.
  • the assertions platform 140 can retrieve a cryptographic key associated with the user from a secure element on a user device 150 associated with the user. Before retrieving the cryptographic key, the assertions platform 140 can determine that the user data request occurs during the time period during which the user has authorized access to the user data. For example, the assertions platform 140 can determine that the time stamp of the access request occurs within the time period when the user has authorized access to the user data by various parties.
  • step S506 the assertions platform 140 may optionally use the cryptographic key of the user to access a key locker 160.
  • the key locker 160 may store additional cryptographic keys that have been associated with prior events involving the user.
  • step S508 the assertions platform 140 may retrieve the requested interaction information from an event log 135.
  • the identifiers may have been encrypted, so the cryptographic key may allow the assertions platform 140 to decrypt the identifiers. If one or more additional keys are obtained from the key locker 165, then those additional keys may be used to decrypted any encrypted data that can be decrypted by the additional keys.
  • the assertions platform 140 may then transmit the user data to the requesting device.
  • FIG. 6 shows a schematic diagram of a transaction that may be conducted during a continuous authentication process.
  • the transaction may be completed after the resource provider has received assertions or other user data from the assertions platform 140 (e.g., as in FIG. 4).
  • the access device 110 may send information about a transaction and an identifier of the user to a resource provider computer 120.
  • the resource provider computer 120 may then send a transaction request for the transaction to an assertions platform 140.
  • the transaction request may include the transaction information, a transaction value, and the identifier of the user.
  • the resource provider may also have an identifier.
  • the identifier may be an alphanumeric string, or may be a digital signature and/or a cryptographic key of the resource provider.
  • the resource provider may also send their identifier to the assertions platform 140.
  • the assertions platform 140 may send a key request for a cryptographic key to the user device 150.
  • the cryptographic key may be a private key of a public/private key pair.
  • the cryptographic key may be stored on a secure element of the user device 150.
  • the assertions platform 140 can determine that the transaction request occurs during the time period during which the user has authorized access to the user data by one or more parties. If the request did occur during the time period, the assertions platform 140 can retrieve the cryptographic key from the user device 150. If the request occurs outside the time period, the assertions platform may send a decline message to the resource provider computer 120.
  • the assertions platform 140 may initiate authorization processing for the transaction.
  • the assertions platform 140 may directly authorize the transaction on behalf of the issuer computer 170 using stand in processing.
  • the assertions platform 140 may determine that the transaction is consistent with the user’s past user behavior (e.g., by comparing the transaction to a predicted path) and may authorize the transaction based at least upon this information.
  • the assertions platform 140 may use the cryptographic key of the user to retrieve user data to information the authorization.
  • the assertions platform 140 may also use the authentication of the user and the on the grid status as an indication as additional inputs to the decision as to whether or not to authorize the transaction.
  • the assertions platform 140 may also calculate a risk score for the transaction based on past actions of the user and/or the resource provider.
  • the assertions platform 140 may cause initiation of authorization operations by sending an authorization request message to an issuer computer 170 or some other authorizing entity computer.
  • the authorization request message may include an indication that the user is authenticated and the transaction information.
  • the issuer computer 170 may determine whether or not to authorize the transaction, and may then send an authorization response message to the assertions platform 140.
  • the authorization response message may contain an indication as to whether the transaction was authorized or declined.
  • the assertions platform 140 may store information about the transaction in an event log 135.
  • the transaction may be considered an event and may contain information that a transaction was authorized and/or completed.
  • Entries in the event log 135 may contain the identifiers of all entities involved in the transaction.
  • the entries and/or identifiers as well as the details about the transaction may be encrypted.
  • step S614 the assertions platform 140 may send a message to the resource provider computer 120 indicating that transaction is authorized.
  • a clearing and settlement process may occur between the issuer computer 170 and an acquirer associated with the resource provider 120.
  • FIG. 7 shows the process of authorizing a transaction and performing risk analysis by an assertions platform.
  • the assertions platform 140 may receive a message with transaction information.
  • the assertions platform 140 may also receive an identifier of a user and an identifier of a resource provider that are conducting the transaction.
  • step S704 the assertions platform 140 may pass the transaction information to an assertion determination module 142A.
  • the assertion determination module 142A may determine a set of assertions about the user for the transaction.
  • the assertions platform 140 may follow step S606 of FIG. 6.
  • the assertion determination module 142A may pass the transaction information to a risk analysis module 142B.
  • the risk analysis module 142B may analyze the transaction risk (e.g., the probability that the transaction will not be settled). The risk analysis may be part of authorization processing. The transaction risk may depend on the probability that the authorized user is the entity initiating the transaction. The risk analysis module 142B may evaluate the strength of the assertions. The risk analysis module 142B may also determine whether the transaction is on a predicted path of the user, and if not, how different the transaction is from the predicted path. Flaptics may also be used to validate the identity of the user. The transaction risk may also depend in the percentage of past transactions with the resource provider that have completed successfully.
  • the risk analysis module 142B may also use information about past failed transactions to determine the level of risk.
  • the transaction risk may also depend on details of the transaction. For example, transactions with a value greater than some threshold might be considered higher risk.
  • the risk analysis module 142B may determine that the transaction has relatively low risk and can be authorized and does not need to be offered in a risk marketplace. The risk analysis module 142B may also determine that the risk for the transaction is too high and decline the
  • the risk analysis module 142B may determine that a user is authenticated for a time period, and this may cause the initiation of authorization processing for a transaction involving the user during the time period.
  • the risk analysis module 142B may pass the transaction information to a risk scoring module 142C.
  • the risk scoring module 142C may score the transaction risk based on the risk analysis performedby the risk analysis module 142B.
  • the risk scoring module 142C may pass the transaction information to a pool sorting module 142D.
  • the pool sorting module 142D may group the transaction into a pool with similar transactions.
  • the pool sorting module 142D may sort transactions into pools with similar risk scores.
  • the pool sorting module 142D may also sort transactions based on transaction details. For example, a transaction pool may consist of transactions with the same resource provider and/or with similar transaction values.
  • the pool sorting module 142D may pass the transaction pool to a risk exchange module 142E.
  • the risk exchange module 142E may determine a price for the transaction pool and offer the transaction pool in a risk marketplace.
  • entities can assume the risk for a transaction or pool of transactions. Some entities that may choose to assume the risk include resource providers, payment processing networks, issuers, and other third party entities.
  • the price, or the compensation that the entity will receive for taking on the risk may depend on the risk score.
  • a user may decide to go off the grid. Flowever, the user may also be prevented from staying on the grid indefinitely.
  • a timer may initialize when a user goes on the grid. After the timer expires, the user may be taken off the grid. For example, after authenticating and going on the grid, a user may have 8 hours before being taken off the grid. The length of timer may be a tunable system parameter. After being taken off the grid, the user may re-authenticate themselves to go back on the grid.
  • the user may be able to extend the time that they can be on the grid by completing transactions.
  • the assertions platform 140 may have a record of one or more predicted paths, or patterns of past user behavior regularly completed by the user.
  • a predicted path may be a graph of connected nodes, where each node is a valid event from the user’s past activity.
  • a predicted path may comprise records of one or more past transactions of the user, one or more past locations of the user, and/or haptic information.
  • the graph may be built by a machine learning algorithm. In some embodiments, a random walk may be used to connect the nodes and find a pattern.
  • the predicted path may also be built as a directed graph.
  • Geofences can also be used to add nodes to the predicted path.
  • a geofence can be a virtual boundary that triggers an event when an entity enters or leaves a geofenced area. Therefore, location events may be entered into the event log 135 to denote when the user was in a particular area. These location events may add data about the user’s actions even when they are not conducting transactions. Location events can help determine when a new transaction event is close to the predicted path as the transaction event may be close to (or similar to) past location events. If the user makes a transaction that is expected (i.e. , is a predicted path node), the timer may restart or more time may be added.
  • FIG. 8 are graphical illustrations illustrating the processes of extending time on the grid by conducting transactions that are on a predicted path.
  • the user may first authenticate themselves and go on the grid.
  • a timer with time left before going off the grid may then be initialized at its maximum value, such as 8 hours.
  • the user may authenticate themselves prior to or while making a transaction. For example, the user may authenticate themselves with a biometric fingerprint scan while entering a building where they work. After the authentication, the timer may begin to count down.
  • the user may conduct a transaction that corresponds to a predicted path including one or more nodes.
  • the transaction may be a lunch purchase at a restaurant that the user frequently visits.
  • the timer may reset to its maximum value and then begin to decay again. In some embodiments, the timer may reset to a value less than the maximum value.
  • the user may conduct another transaction that
  • the transaction may be reentry into a building where the user works.
  • the timer may reset to its maximum value and then begin to decay again.
  • the timer may reset to a value less than the maximum value.
  • the user may be taken off the grid at a reset time each day. This reset time may be set, for example, at 3 AM or some other time when a small number of transactions are typically completed to reduce the impact on users.
  • the user may be automatically taken off the grid because they have reached the reset time.
  • the timer may not reset, and may decrease more rapidly. This situation is shown in FIG. 9.
  • the user may first authenticate themselves and at time 902 they may conduct a transaction that is associated with a predicted path including one or more nodes as in FIG. 8.
  • the user may conduct a transaction that is not within a predicted path of one or more nodes. For example, the user may conduct a purchase from a new merchant. This may cause the timer to count down faster. Alternatively, the transaction may have no effect on the time that is left on the timer.
  • the transaction may be added to the predicted path.
  • the user may conduct another transaction after time 903 that is a predicted path node and thus reset the timer.
  • the time left may be set to its maximum value or some other value.
  • FIG. 10 shows the situation where the user makes a suspicious transaction.
  • a suspicious transaction may be one that is significantly different from any previous transactions, or where fraud is suspected.
  • the user may first authenticate themselves and at time 1002 they may conduct a transaction that is consistent with a predicted path including one or more nodes as in FIG. 8.
  • the user may conduct a suspicious transaction.
  • the user’s identifier may be used to enter a building that is hundreds of miles away from the location of the previous transaction made by the user. If the assertions platform 140 determines that the transaction is sufficiently different from the predicted path, or that the transaction is likely fraudulent, the user may be immediately taken off the grid. The assertions platform 140 may also decline the transaction.
  • An application such as a mobile application, used for going on and off the grid may have a user interface to indicate on the grid status.
  • FIGS. 1 1 A - 1 1 D diagrams of example graphical user interfaces are shown.
  • a user interface may represent that a user is on the grid in a first state 1 1 10a and that the user is off the grid in a second state 1 1 10b.
  • the user interface may include a graphical element which can represent and/or control whether the user is on the grid (1 120a) or off the grid (1 120b).
  • the graphical element can be any suitable graphical element, including but not limited to a button, a switch, a slider bar, a screen area, and/or the like.
  • the user interface may have a slider button that turns red when the user is off the grid, green when the user is on the grid, and yellow when the user will soon being put off the grid.
  • the user may be able to interact with the slider to go on and off the grid.
  • the slider may also have a timer element. After going on the grid, the timer may degrade in linear fashion towards the time limit.
  • the user interface can show the status of the timer by gradually decreasing the green slider. The slider may then turn yellow when the timer has elapsed half way and turn red when the timer has finished. Once the slider turns red, the user can know that they need to re-authenticate themselves to get back on the grid.
  • Embodiments of the invention provide several advantages. Because embodiments of the invention can retrieve a cryptographic key from a user device to decrypt encrypted user data in a database, the user data is protected until it is needed. Further, the user of assertions instead of actual digital identity data to conduct transactions also protects a user’s sensitive digital identity data. Further, the continuous“on the grid” status can be a pre-requisite allowing other parties to obtain user data from a server computer such as an assertions entity platform. This ensures that the user is active and is conducting transactions. If the user is behaving in a way that is inconsistent with the authentic user, then the sensitive user data about the user may not be distributed to any parties that might desire such information.
  • Embodiments also allow for authentication of the user the entire time they are on the grid. This can simplify the authentication and authorization processes while still maintaining the security of the user data.
  • 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++ or Perl using, for example, conventional or object-oriented techniques.
  • the software code may be stored as a series of instructions, or commands on a computer readable medium, such as a 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 CD-ROM.
  • RAM random access memory
  • ROM read only memory
  • magnetic medium such as a hard-drive or a floppy disk
  • optical medium such as a CD-ROM.
  • Any such computer readable medium may reside on or within a single computational apparatus, and may be present on or within different

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Storage Device Security (AREA)

Abstract

L'invention concerne des procédés et des systèmes de contrôle et de sécurisation d'accès à des données d'utilisateur. Un procédé consiste à recevoir par un ordinateur serveur, en provenance d'un dispositif utilisateur, une indication du fait que l'utilisateur a autorisé l'accès à des données d'utilisateur associées à une identité numérique de l'utilisateur par un dispositif demandeur pendant une certaine période de temps. Les données d'utilisateur peuvent être chiffrées et stockées dans une base de données couplée à l'ordinateur serveur. L'ordinateur serveur reçoit une demande de données d'utilisateur pour les données d'utilisateur associées à l'identité numérique de l'utilisateur en provenance du dispositif demandeur, et détermine que la demande de données d'utilisateur survient pendant la période de temps. Si la demande survient pendant la période de temps, l'ordinateur serveur récupère une clé cryptographique auprès du dispositif utilisateur. L'ordinateur serveur déchiffre ensuite, à l'aide de la clé cryptographique, les données d'utilisateur chiffrées, et transmet les données d'utilisateur déchiffrées au dispositif demandeur.
PCT/US2019/064132 2018-12-03 2019-12-03 Système de protection de données comprenant une récupération de clé cryptographique WO2020117735A1 (fr)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US201862774723P 2018-12-03 2018-12-03
US62/774,723 2018-12-03
US201862775020P 2018-12-04 2018-12-04
US62/775,020 2018-12-04

Publications (1)

Publication Number Publication Date
WO2020117735A1 true WO2020117735A1 (fr) 2020-06-11

Family

ID=70974817

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2019/064132 WO2020117735A1 (fr) 2018-12-03 2019-12-03 Système de protection de données comprenant une récupération de clé cryptographique

Country Status (1)

Country Link
WO (1) WO2020117735A1 (fr)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2006033997A2 (fr) * 2004-09-16 2006-03-30 General Instrument Corporation Systeme et procede pour fournir une autorisation d'acces a du contenu numerique
US20060123246A1 (en) * 2004-12-07 2006-06-08 Luc Vantalon Methods and apparatuses for secondary conditional access server
US20130010965A1 (en) * 2010-03-17 2013-01-10 Rainer Falk Method and device for providing at least one secure cryptographic key
WO2018129110A1 (fr) * 2017-01-06 2018-07-12 Microsoft Technology Licensing, Llc Opérations cryptographiques dans une collection isolée
US20180288031A1 (en) * 2017-03-31 2018-10-04 Ca, Inc. Collection point anchored multi-property identity based application specific token origination

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2006033997A2 (fr) * 2004-09-16 2006-03-30 General Instrument Corporation Systeme et procede pour fournir une autorisation d'acces a du contenu numerique
US20060123246A1 (en) * 2004-12-07 2006-06-08 Luc Vantalon Methods and apparatuses for secondary conditional access server
US20130010965A1 (en) * 2010-03-17 2013-01-10 Rainer Falk Method and device for providing at least one secure cryptographic key
WO2018129110A1 (fr) * 2017-01-06 2018-07-12 Microsoft Technology Licensing, Llc Opérations cryptographiques dans une collection isolée
US20180288031A1 (en) * 2017-03-31 2018-10-04 Ca, Inc. Collection point anchored multi-property identity based application specific token origination

Similar Documents

Publication Publication Date Title
US11392939B2 (en) Methods and systems for provisioning mobile devices with payment credentials
US11170379B2 (en) Peer forward authorization of digital requests
US11876911B2 (en) Blockchain based alias interaction processing
US20170270517A1 (en) Partially activated tokens with limited functionality
US12014374B2 (en) Identity-based transaction processing
JP2019507431A (ja) 位置照合を使用する認証システムおよび方法
CN112889241B (zh) 用于账户验证的核实服务
US20230062507A1 (en) User authentication at access control server using mobile device
EP4210274A1 (fr) Système et procédé de fourniture efficace de jetons
WO2019066786A1 (fr) Procédé et système d'accès aux ressources basé sur la position
WO2019125632A1 (fr) Authentification de biens
US11757638B2 (en) Account assertion
CN114788223B (zh) 令牌管理***和方法
WO2020117735A1 (fr) Système de protection de données comprenant une récupération de clé cryptographique
CN116195231A (zh) 令牌故障保护***和方法
WO2020167317A1 (fr) Traitement de transaction sur la base de l'identité
US11812260B2 (en) Secure offline mobile interactions
US20230153800A1 (en) Token processing for access interactions
WO2023055562A1 (fr) Interaction d'identité à distance

Legal Events

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

Ref document number: 19892918

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 19892918

Country of ref document: EP

Kind code of ref document: A1