WO2026030384A1 - Procédé et système d'authentification cryptographique sécurisée - Google Patents

Procédé et système d'authentification cryptographique sécurisée

Info

Publication number
WO2026030384A1
WO2026030384A1 PCT/US2025/039758 US2025039758W WO2026030384A1 WO 2026030384 A1 WO2026030384 A1 WO 2026030384A1 US 2025039758 W US2025039758 W US 2025039758W WO 2026030384 A1 WO2026030384 A1 WO 2026030384A1
Authority
WO
WIPO (PCT)
Prior art keywords
user device
user
server computer
computer
server
Prior art date
Legal status (The legal status 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 status listed.)
Pending
Application number
PCT/US2025/039758
Other languages
English (en)
Inventor
Jason LIGHTMAN
Jose Luis RIOS TREVINO
Christopher BOHATKA
Tabitha ODOM
Mustaq M. LIAQATH
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Visa International Service Association
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 WO2026030384A1 publication Critical patent/WO2026030384A1/fr
Pending legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L51/00—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
    • H04L51/21—Monitoring or handling of messages
    • H04L51/212—Monitoring or handling of messages using filtering or selective blocking
    • 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/3226—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 a predetermined code, e.g. password, passphrase or PIN
    • H04L9/3231—Biological data, e.g. fingerprint, voice or retina
    • 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/3247—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 involving digital signatures
    • 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/3271—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 challenge-response
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L51/00—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
    • H04L51/42—Mailbox-related aspects, e.g. synchronisation of mailboxes

Definitions

  • Various processes, activities, or other interactions involve the authentication of entities or devices, e.g., involving determining whether an entity or device is who or what they proport to be.
  • entities or devices e.g., involving determining whether an entity or device is who or what they proport to be.
  • a user might provide a username and password. Under the assumption that the password is only known to the authentic user, presentation of a correct username and password is sufficient to authenticate the user.
  • a computer system associated with the email hosting service can verify that the password is correct (e.g., based on the provided username), thereby authenticating the user, and then allow the user to access their emails.
  • Many authentication methods can be generally categorized based on the concepts of “something they know”, “something they have”, and “something they are”.
  • a user can be authenticated based on some knowledge, e.g., a password, that is known to the user but presumably not known to users at large (“something they know”), an object, such as a smartphone, that is known to be possessed by the user (“something they have”), or some generally immutable property of the user, e.g., a biometric, such as a fingerprint, that is largely unique to the user (“something they are”). Demonstrating such knowledge, possession, or characteristic may be sufficient for a user to generally verify their identity.
  • Multi-factor authentication has seen increasing use in authentication processes due to its security benefits. Rather than authenticating based on a single factor, such as a password, a user can be authenticated using multiple factors. For example, after a user inputs a password into a login form, a server computer may automatically transmit a text message to a phone number associated with the user. The text message may contain a one-time password (OTP) that the user may be instructed to provide to the login form. If the user is able to provide the OTP, it demonstrates that the user both knows the password and is possession of the phone (satisfying “something they have”).
  • OTP one-time password
  • MFA multi-factor authentication
  • a hacker or other malicious user Under the assumption that it is more difficult for a hacker or other malicious user to both steal a phone and a password (rather than steal either one individually), such an MFA process is more secure than a similar single-factor authentication process.
  • authentication using MFA is either strongly recommended or required, e.g., for sensitive information or in particular jurisdictions.
  • a device manufacturer may require that a user has a single account across all their devices, e.g., the user has a single account that they can use to access their smartphone or their tablet, and can e.g., check messages sent to their smartphone using their tablet. While this may be convenient to the user, it may “violate” some of the principles of MFA described above.
  • This weaker form of authentication can lead to various security concerns.
  • a user’s live-in partner could use a “shared” tablet (but tied to an account of the user) in order to access the user’s private emails, medical records, etc., e.g., by authenticating as the user using an OTP sent to the user’s smartphone but shared via a synced account.
  • a user’s child could use a shared tablet in order to make unauthorized purchases in an application store, e.g., by authenticating as the user using an OTP sent to the user’s smartphone but shared via a synced account.
  • the variety and number of authentication systems that users now regularly interact with can create a frustrating user experience.
  • Embodiments address these and other problems, individually and collectively.
  • Embodiments of the present disclosure are directed to various methods and systems for performing authentication using cryptography, particularly for the authentication of users of user devices (e.g., users of smartphones, laptop computers, desktop computers, other personal electronic devices, etc.).
  • Embodiments of the present disclosure can enable highly accurate and secure authentication of users in a manner that is friction-free, requires little action on the part of users, and can be achieved using authentication factors that are already familiar to users.
  • Some embodiments involve establishing “one-to-one” device bindings between user devices and passkeys (including, e.g., Fast Identity Online or “FIDO” passkeys).
  • passkeys including, e.g., Fast Identity Online or “FIDO” passkeys.
  • a user device can only use a passkey to perform authentication provided there is an established binding between that passkey and device information that can be used to identify that device (e.g., as established or recorded by a “passkey server”, described in more detail below).
  • passkey server described in more detail below.
  • the passkey can only be accessed or used provided that the user provides some other form of authentication (e.g., either by inputting a password or providing a biometric sample such as a fingerprint scan), methods according to embodiments naturally provide a convenient form of two-factor authentication.
  • embodiments of the present disclosure can be used in networks and systems which involve multiple parties and computer systems, which may have more complex authentication processes or requirements.
  • a user operating a user device
  • a resource provider operating a resource provider computer
  • the resource provider may rely on another party or computer system (e.g., a processing network operating a passkey server, as described in more detail further below) to authenticate the user, rather than performing authentication itself.
  • any number of additional parties may want proof or some attestation that the user was authenticated, e.g., in order to authorize the interaction between the user and the resource provider.
  • Methods according to embodiments can be used to securely authenticate users in a friction-free manner, while also informing any other relevant entities or computer systems (e.g., resource provider computers, authorizing entity computers, etc.) that those users have been authenticated.
  • a passkey server can identify and recognize user devices across many interactions with different resource providers, thus enabling a user to register a passkey once, then use it with any resource provider. This reduces the need for users to perform tedious authentications or authentication enrollment steps with individual resource providers or authorizing entities.
  • a user device could generate a passkey as part of a registration process, which the user could subsequently use to interact with another resource provider (e.g., an email service provider that the user must authenticate with in order to access their email address).
  • a passkey as part of a registration process, which the user could subsequently use to interact with another resource provider (e.g., an email service provider that the user must authenticate with in order to access their email address).
  • one embodiment is directed to a method performed by a server computer.
  • the server computer can receive an initialization request message from a user device interacting with a resource provider computer to conduct an interaction.
  • the initialization request message can comprise device data associated with the user device.
  • the server computer can determine a device identifier based on the device data.
  • the server computer can additionally determine a session identifier and determine that the user device is capable of performing an authentication process using a digital signature.
  • the server computer can transmit the session identifier (e.g., to the resource provider computer or the user device).
  • the server computer can receive the session identifier and interaction data associated with the interaction.
  • the interaction data can comprise a credential.
  • the server computer can identify a database record from a database.
  • the database record can indicate that the credential is associated with the device identifier and a public key of a public-private key pair.
  • the server computer can transmit a challenge message to the user device.
  • the user device can sign the challenge message using a private key of a public-private key pair to produce the digital signature.
  • the server computer can receive the digital signature.
  • the server computer can validate the digital signature using the public key of the public-private key pair.
  • the server computer can provide a message indicating that the user device is authenticated.
  • Another embodiment is directed to a method performed by a user device interacting with a resource provider website operated by a resource provider computer to conduct an interaction.
  • the user device can transmit an initialization request message comprising device data associated with the user device to a server computer.
  • the server computer can determine a device identifier based on the device data, determine a session identifier, and can determine that the user device is capable of performing an authentication process using a digital signature.
  • the user device can receive the session identifier.
  • the user device can transmit the session identifier and interaction data associated with the interaction to the server computer.
  • the interaction data can comprise a credential.
  • the server computer can identify a database record in a database, which can indicate that the credential is associated with the device identifier and a public key of a public-private key pair.
  • the user device can receive a challenge message from the server computer.
  • the user device can sign the challenge message using a private key of the public-private key pair, thereby producing a digital signature.
  • the user device can transmit the digital signature to the server computer.
  • the server computer can validate the digital signature using the public key of the public-private key pair and provide a message indicating that the user device is authenticated.
  • some embodiments are directed to computer systems or other devices that can be configured to perform the methods described above or other methods.
  • a computer system e.g., a server computer or a user device
  • the non-transitory computer-readable medium can comprise code executable by the processor for performing the methods described above (or other methods described in the detailed description below).
  • a “user” may include an individual or a machine that operates something.
  • a user may be associated with one or more personal accounts and/or mobile devices.
  • the user may also be referred to as a cardholder, account holder, or consumer in some embodiments.
  • a “user device” may be a device that is operated by a user.
  • user devices may include a mobile phone, a smartphone, 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.
  • 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.
  • a “resource provider” may be an entity that can provide a resource such as goods, services, information, and/or access.
  • resource providers include merchants, data providers, transit agencies, governmental entities, venue, and dwelling operators, etc.
  • a “merchant” may typically be an entity that engages in transactions and can sell goods and services or otherwise provide access to goods or services.
  • a “transporter” or "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.
  • a transporter may operate a “transport computer” (also referred to as an “acquirer computer”).
  • 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 “issuer” may typically refer to a business entity (e.g., a bank) that maintains an account for a user.
  • An issuer may also issue payment credentials stored on a user device, such as a cellular telephone, smartcard, tablet, or laptop to the consumer.
  • 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, as well as any object or document that can serve as confirmation. Examples of credentials include value credentials, identification cards, certified documents, access cards, passcodes, and other login information, etc.
  • 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 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.
  • a “cryptogram” may include encrypted information.
  • a cryptogram can be a set of text encrypted with an encryption key.
  • a “user device identifier” can include a sequence of characters used to identify or refer to a user device.
  • a user device identifier can be associated with a particular user device.
  • a user device identifier can include alphanumeric characters that may refer to a user device.
  • An “authorization request message” may be an electronic message that requests authorization for a transaction. In some embodiments, it is sent to a transaction processing computer 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 ISO 8583, which is a standard for systems that exchange electronic transaction information associated with a payment made by a user 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 CW (card verification value), a dCW (dynamic card verification value), a PAN (primary account number or “account number”), a payment token, a username, 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, acquirer bank identification number (BIN), card acceptor ID, information identifying items being purchased, etc., as well as any other information that may be utilized in determining whether to identify and/or authorize a transaction.
  • An “authorization response message” may be a message that responds to an authorization request. In some cases, it may be an electronic message reply to an authorization request message generated by an issuing financial institution or a transaction processing computer.
  • the authorization response message may include, by way of example only, one or more of the following status indicators: Approval -- transaction was approved; Decline -- transaction was not approved; or Call Center -- response pending more information, merchant must call the toll-free authorization phone number.
  • the authorization response message may also include an authorization code, which may be a code that a credit card issuing bank returns in response to an authorization request message in an electronic message (either directly or through the transaction processing computer) to the merchant's access device (e.g., PCS equipment) that indicates approval of the transaction. The code may serve as proof of authorization.
  • An “interaction” may refer to a reciprocal action, effect or influence.
  • an interaction could be an exchange or transaction between two or more parties.
  • FIG. 1 shows a four-party network in which an interaction between a resource provider and a user can be authorized and performed.
  • FIG. 2 shows a diagram of credentials and their association with user identity data, authentication devices, and passkeys.
  • FIG. 3 shows a sequence diagram of a process for performing an interaction and enrolling a user in a passkey-based authentication system according to embodiments.
  • FIGs. 4A-4G show several exemplary user device views that a user could see when performing an interaction and enrolling in a passkey-based authentication system according to embodiments.
  • FIG. 5 shows a sequence diagram of a process for authenticating a user during an interaction using a passkey-based authentication system according to embodiments.
  • FIGs. 6A-6D shows several exemplary user device views that a user could see when performing an interaction and authenticating using a passkey-based authentication system according to embodiments.
  • FIG. 7 shows a system block diagram of a user device according to some embodiments.
  • FIG. 8 shows a system block diagram of a passkey server according to some embodiments.
  • Embodiments of the present disclosure are directed to various methods and systems for authenticating users of user devices using passkeys (including FIDO passkeys or other similar passkeys) securely stored on those user devices. These can include methods and systems for registering or otherwise enrolling users in such authentication systems, e.g., enabling those users to authenticate using passkeys instead of (or in addition to) other authentication methods.
  • passkeys can be “device bound”, e.g., a passkey can only be used for authentication if there is an established binding between that passkey and a corresponding user device, e.g., as recorded by a passkey server.
  • Embodiments of the present disclosure can be used in contexts that involve interactions between resource providers and users of user devices, e.g., interactions in which a user may be provided access to a resource (e.g., a video stream from a streaming service resource provider) provided that they are successfully authenticated (and in some cases also authorized).
  • a resource e.g., a video stream from a streaming service resource provider
  • one advantage of the embodiments is that such passkeys can be used by users to securely authenticate with various resource providers without requiring specific registration with those resource providers.
  • a user could, e.g., use the same passkey to access a streaming service provided by one resource provider and an online banking account associated with another resource provider, thus providing a much more convenient and “frictionless” user experience.
  • Such users and resource providers can exist in four-party networks, networks in which interactions between e.g., four parties (and any number of applicable computing systems) are mediated (at least in part) by a processing network.
  • a processing network in order to better orient the reader, an exemplary four-party network 100 is described below with reference to FIG. 1 is illustrative and not limiting.
  • the exemplary four-party network 100 can comprise a resource provider 102, a user 104, a transporter 106 (also referred to as an “acquirer”) and an authorizing entity 108 (also referred to as an “issuer”).
  • a four-party network can be used to authorize interactions between resource providers (such as resource provider 102) and users (such as user 104). Such an interaction could comprise, e.g., user 104 attempting to access a video streaming service or an email hosting service provided by resource provider 102, or e.g., a transaction between a merchant resource provider 102 and a customer user 104.
  • interoperability domain 116 can include processing network 110 (and any number of applicable processing network servers) as well as, e.g., a directory server and any number of other applicable computer systems that enable the processing network 110 to perform its functions (as described in more detail further below).
  • the authorizing entity domain 114 can include an authorizing entity computer, e.g., a computer system associated with authorizing entity 108 that performs function associated with authorizing interactions between resource providers and users, as well as e.g., an access control server that verifies the identities of users and performs risk assessment in the context of interactions between resource providers and users.
  • the resource provider domain 112 can include a resource provider computer (associated with the resource provider) that can provide resources to user 104, e.g., a server computer associated with a video streaming service that can stream video to a user device operated by user 104, as well as various other applicable computer systems, such as an “authentication server computer”, which can perform various steps associated with authenticating users.
  • the user 104 and any applicable user device can be considered part of the resource provider domain.
  • Some interactions may be “authorized” prior to the interaction taking place.
  • an interaction may be authorized based (in part) on a credential (e.g., a payment account number or “PAN”) issued to the user 104 by authorizing entity 108 (e.g., an issuing bank).
  • a credential e.g., a payment account number or “PAN”
  • PAN payment account number
  • a payment transaction may be authorized provided that the user 104 has a valid credential corresponding to a payment account with enough funds (or a sufficient line of credit) to pay for any resources provided by the resource provider 102 to the user 104 as part of the transaction.
  • the user 104 can show or otherwise provide their credential to the resource provider 102 during an interaction.
  • the authorizing entity 108 (having issued the credential to the user 104) will authorize the interaction.
  • the resource provider 102 may have an established relationship with transporter 106 (e.g., as transporter 106 may comprise an acquiring bank that maintains a payment account on behalf of resource provider 102).
  • authorizing entity 108 may be one of a large number of authorizing entities (e.g., an issuing bank of a large number of issuing banks).
  • the processing network 110 can provide various services related to interactions, including services related to routing authorization request messages (e.g., requesting authorizations for interactions corresponding to provided credentials) and authorization response messages (e.g., indicating whether such interactions are authorized or are not authorized).
  • the resource provider 102 can generate an authorization request message and transmit it to transporter 106, e.g., via an access terminal (e.g., a point-of-sale terminal) to a transporter computer.
  • Transporter 106 can then transmit the authorization request message to processing network 110, which can identify authorizing entity 108 and route the authorization request message to authorizing entity 108.
  • Authorizing entity 108 can then perform any applicable analysis in order to determine whether to authorize the interaction or not (e.g., via an authorizing entity computer).
  • Authorizing entity 108 can generate an authorization response message, indicating whether the interaction has been authorized or not.
  • Authorizing entity 108 can transmit the authorization response message back to processing network 110, which can then route the authorization response message to transporter 106.
  • Transporter 106 can then transmit the authorization response message to resource provider 102, which can then complete or terminate the interaction based on the authorization response message, e.g., completing the interaction if the authorization response message indicates the interaction is “approved” and terminating the interaction if the authorization is “declined”.
  • One related aspect of authorization is “authentication”, which can involve authenticating the user 104 prior to authorizing the interaction.
  • a thief could steal the user’s 104 credential, then pose as the user 104 and attempt to perform an interaction with resource provider 102, e.g., attempt to purchase goods or services using the user’s 104 money or credit. For this reason, it is generally prudent to authenticate user 104 prior to, or as part of, the authorization process.
  • Methods and systems according to embodiments can be used to authenticate users in four-party networks (or other situation), thus enabling users and resources providers to securely and safely perform interactions.
  • FIG. 2 generally depicts exemplary associations between user identity data, credentials, authentication devices, and passkeys, which may be helpful for understanding authentication methods and systems according to embodiments.
  • authorizing an interaction between a resource provider and a user may involve the use of a credential, e.g., an interaction may be approved by an authorizing entity computer if a valid credential has been presented (in addition to any number of additional considerations, e.g., if the user is successfully authenticated) and denied if a valid credential has not been presented.
  • FIG. 2 shows a first credential 214 and a second credential 216.
  • a credential may be considered a sensitive form of data, depending in part on the types of interactions (e.g., access to sensitive medical records, transactions, etc.) that the credential can be used to authorize. As such, credentials that are stolen or leaked may need to be reissued.
  • a PAN may be associated with a physical payment card, and reissuing a PAN (e.g., if the original PAN was stolen) may involve manufacturing and shipping a new credit card to a user.
  • the tokenized credential could be used to authorize interactions in place of the underlying credential.
  • the advantage of using tokenized credentials is that if a tokenized credential is stolen or leaked, it can quickly be deactivated and a new tokenized credential can quickly be generated from the underlying credential, e.g., by generating a new pseudorandom number. Because the underlying credential cannot be determined from inspection of the tokenized credential, the underlying credential remains secure, and a new underlying credential (and e.g., a physical object such as a payment card) does not need to be issued to a user.
  • various user identity data 202 can be associated with credentials or corresponding tokenized credentials. Such user identity data 202 can be used to identify users (or associated user devices) corresponding to credentials, e.g., by a passkey server, e.g., for the purpose of determining whether a user device is registered to perform passkeybased authentication, as described in more detail further below with reference to FIGs. 3 and 5.
  • FIG. 2 shows various examples of user identity data 202, including a user’s name 204, address 206, phone number 208, email address 210, embedded identity document (EID) number 212 (e.g., associated with an eSIM of a smartphone user device owned by a user), or various other user identity data 202.
  • EID embedded identity document
  • First credential 214 and second credential 216 can be associated with various authentication devices, which can comprise user devices that can be used in order to authenticate users in some methods according to embodiments.
  • FIG. 2 shows a first user device 226, a second user device 228, a third user device 230, a fourth user device 232, and a fifth user device 234.
  • the first credential 214 can be associated with the first user device 226, the second user device 228, and the third user device 230.
  • the second credential 216 can be associated with the third user device 230, the fourth user device 232, and the fifth user device 234.
  • such credentials can be stored in their corresponding user device in any applicable manner, e.g., in encrypted format, in a “digital wallet”, “hardware wallet” (e.g., implemented using a secure chip or trusted platform module), “vault”, “keychain”, etc.
  • a user could use a corresponding user device to provide a credential to a resource provider computer in order to be authorized to perform the interaction.
  • a user could use a web browser on their user device to navigate to a website hosted by the resource provider computer and provide their credential to that resource provider via a web form (see e.g., FIG. 4A, view 402, in which a credential 430 is provided to a resource provider via a field on a web form).
  • the credential could be forwarded to an authorizing entity computer in an authorization request message via a transporter computer and a processing network, e.g., as discussed above with reference to FIG. 1 .
  • the authorizing entity computer could generate an authorization response message (e.g., approving or declining the interaction) and transmit the authorization response message back to the resource provider computer.
  • an authorization response message e.g., approving or declining the interaction
  • the user may first need to be authenticated, e.g., using authentication methods and systems according to embodiments.
  • passkeys can be used to authenticate users of user devices.
  • FIG. 2 shows a first passkey 236, a second passkey 238, a third passkey 240, and a fourth passkey 242, which can be associated with various user devices 226-234.
  • passkeys can be used to perform authentication without needing to be shared or transmitted. As such, passkeys are resistant to fishing, brute force attacks, man-in-the-middle attacks, and various other methods used to commit identity theft and fraud.
  • a passkey can generally comprise or relate to these public and private keys.
  • An authentication device e.g., a user device
  • can securely store a private key e.g., in encrypted format, in a “digital wallet”, “hardware wallet” (e.g., implemented using a secure chip or trusted platform module), “vault”, “keychain”, etc.
  • the public key can be stored at a passkey server.
  • the passkey server can transmit a “challenge message” (also referred to as an “assertion challenge”) to a user device possessed by the user.
  • the user device can then sign the challenge message using the private key and send the resulting digital signature back to the passkey server.
  • the passkey server can verify the digital signature using the public key, thereby authenticating the user.
  • a registration process can generally involve the generation of such a public-private key pair, secure storage of the private key on a user device, transmission of the public key to the passkey server, etc.
  • the user could use their user device (e.g., first user device 226) to provide a credential (e.g., first credential 214) to a resource provider computer.
  • This process can trigger further authentication of the user via passkeys.
  • a passkey server can then transmit a challenge message to the user device, which the user device can then sign using the private key corresponding to the user’s passkey (e.g., first passkey 236).
  • the user device can then return the resulting digital signature to the passkey server, which can then verify the digital signature using the corresponding public key.
  • the passkey server can then forward the digital signature and any other relevant information (e.g., interaction details (e.g., an amount spent, a merchant identifier, a timestamp, etc.), an assertion that the passkey server verified the digital signature, etc.) to an authorizing entity computer, which can then authorize the interaction (or not) based on the passkey-based authentication of the user.
  • the user device may only sign the challenge message if the user “unlocks” the passkey by providing a biometric (e.g., a fingerprint or thumbprint scan, facial identification, an iris scan, etc.) or by providing a personal identification number (PIN) or password, thus providing a form of two-factor authentication.
  • a biometric e.g., a fingerprint or thumbprint scan, facial identification, an iris scan, etc.
  • PIN personal identification number
  • synchronized devices e.g., different devices that may correspond to the same manufacturer and share the same account (e.g., a smartphone and tablet manufactured by the same device manufacturer and owned by the same user) may weaken some forms of multi-factor authentication, including passkey-based authentication.
  • FIG. 2 shows a scenario in which fourth passkey 242 is shared between third user device 230, fourth user device 232, and fifth user device 234.
  • using fourth passkey during authentication does not necessarily verify that the user is in possession of a specific user device (e.g., third user device 230), as such a passkey could instead be used by fourth user device 232 or fifth user device 234.
  • methods and systems according to embodiments can provide for a form of “device-binding” between passkeys and user devices, such that a passkey can only be used to authenticate a user when it is used in conjunction with its corresponding user device during authentication.
  • passkey-based authentication methods guarantee that a user is in possession of their corresponding user device during authentication, thus providing a stronger form of multi-factor authentication security, particularly if biometric scans performed on user devices are required to “unlock” passkeys for passkey-based authentication.
  • a passkey server can record a binding between credentials, corresponding passkeys, and various user identity data 202, particularly device-related data (such as Embedded Identity Document numbers, International Mobile Equipment Identity Numbers, etc.). Using such a binding, during an authentication process, the passkey server can use the device-related data to identify the user device and determine whether the user device has an associated and uniquely-bound passkey. If the user device has an associated passkey, the passkey server can generate a challenge message and send it to the user device as part of the authentication process. If the user device does not have an associated passkey, the user can be authenticated through other means (e.g., the use of “3-D Secure”, as described in more detail with reference to FIG. 3) and the user can later be offered an opportunity to enroll in passkey-based authentication, e.g., via an enrollment message sent to the user device and displayed to the user.
  • device-related data such as Embedded Identity Document numbers, International Mobile Equipment Identity Numbers, etc.
  • a passkey-based authentication registration process can be integrated into existing interaction processing and authentication methods, creating a convenient and user-friendly experience. For example, after being authenticated with an email service provider by providing login details, a user could be prompted to register with a passkey-based registration service according to embodiments. For subsequent login attempts, rather than having to input their login details, the user’s passkey could be used to authenticate the user. As another example, after being authenticated (e.g., using a 3-D Secure authentication process) as part of performing an online transaction with an e- commerce merchant, a user could be prompted to create a passkey that is associated with a user device and a payment credential (e.g., a payment account number or PAN). For subsequent transactions, the user could be authenticated using their passkey rather than through other authentication processes.
  • a payment credential e.g., a payment account number or PAN
  • FIG. 3 shows a sequence diagram corresponding to an interaction between a user 350 and a resource provider.
  • the user 350 has not yet registered with a passkey-based authentication system according to embodiments.
  • the user 350 can enroll in passkey-based authentication (steps S316-S328). Afterwards, the user 350 can then use their passkey to authenticate with the same resource provider or other resource providers in subsequent authentications, e.g., as described in more detail below with reference to FIG. 5.
  • the computers, devices, and entities in FIG. 3 can generally be divided into a resource provider domain 368 (including user 350, user device 352, resource provider computer 354, and authentication server computer 356 (e.g., a 3-D Secure authentication server)), interoperability domain 370 (including directory server 358, passkey server 360, and processing network 362), and authorizing entity domain 372 (including access control server 364 and authorizing entity computer 366).
  • resource provider domain 368 including user 350, user device 352, resource provider computer 354, and authentication server computer 356 (e.g., a 3-D Secure authentication server)
  • interoperability domain 370 including directory server 358, passkey server 360, and processing network 362
  • authorizing entity domain 372 including access control server 364 and authorizing entity computer 366.
  • an authorizing entity may have issued a credential (e.g., a PAN) to user 350.
  • a credential e.g., a PAN
  • Such a credential may be used in order to authorize an interaction (e.g., a transaction) between the user 350 and a resource provider (e.g., a merchant), e.g., an interaction carried out via user device 352 and resource provider computer 354.
  • a resource provider e.g., a merchant
  • Such an interaction could comprise an ecommerce transaction carried out by the user 350 by accessing a resource provider website (associated with the resource provider computer 354) via user device 352.
  • an authorization request message may be generated (e.g., by resource provider computer 354, which may contain interaction details (e.g., a transaction amount, an identifier associated with the resource provider, a timestamp, the credential used as part of the interaction, etc.).
  • Such an authorization request message may be transmitted to the authorizing entity computer 366 via processing network 362 (e.g., a processing network such as VisaNet).
  • the authorizing entity computer 366 can approve or decline the interaction based on the authorization request message, generate an authorization response message to that effect, and e.g., transmit the authorization response message back to the resource provider computer 354 (e.g., via processing network 362).
  • the resource provider computer 354 can then complete or terminate the interaction based on the authorization response message and e.g., display a status message to the user 350 via a display on user device 352.
  • a user 350 operating a user device 352 can conduct an interaction with a resource provider via resource provider computer 354.
  • User device 352 may be interacting with a resource provider website (e.g., a “first resource provider website”) operated by resource provider computer 354 in order to conduct the interaction. “Conducting” an interaction can take various forms depending on the nature of the resource provider and any resources provided by that resource provider.
  • FIG. 4A shows a view 402 of a smartphone user device displaying a resource provider website (e.g., hosted by resource provider computer 354) corresponding to a resource provider URL 428 via a browser application.
  • a credential 430 e.g., a credit card number
  • the user can signal their intent to make a purchase using the provided credential by selecting a checkout button 438.
  • an initialization request message (e.g., a first initialization request message) can be transmitted to passkey server 360 (sometimes more generically referred to as a “server computer”).
  • the passkey server 360 can receive the initialization request message from the user device 352, e.g., via resource provider computer 354 and/or authentication server computer 356 or from the resource provider computer 354 itself.
  • the initialization request message can comprise device data associated with the user device 352.
  • an HTML “iframe” embedded in the resource provider website can be used to transmit the device data from the user device 352 to the passkey server 360, e.g., via a user device SDK (e.g., accessible by a browser application) that enables device data to be read from the user device 352.
  • a user device SDK e.g., accessible by a browser application
  • the device data can include any suitable data that can be used to identify the user device 352, e.g., via “device fingerprinting” processes.
  • the device data can include a numerical or alphanumerical code that can be used to identify the user device 352 (e.g., a phone number, an international mobile equipment identity (IMEI) number, an embedded identity document (EID) number, etc.).
  • IMEI international mobile equipment identity
  • EID embedded identity document
  • the device data can also include, as examples, an IP address, geolocation data, a browser type or browser version number, processor data (e.g., identifying a processor or microprocessor type or model number), a model number, a manufacturer name, an operating system identifier, device component data (e.g., identifying any types of components in the user device such as a biometric reader, an NFC antenna, etc.), etc.
  • processor data e.g., identifying a processor or microprocessor type or model number
  • model number e.g., identifying a processor or microprocessor type or model number
  • a manufacturer name e.g., identifying any types of components in the user device
  • device component data e.g., identifying any types of components in the user device such as a biometric reader, an NFC antenna, etc.
  • the passkey server 360 can determine a device identifier based on the device data.
  • the device identifier can uniquely identify the user device 352 based on its associated device data.
  • the passkey server 360 can determine a device identifier based on the device data.
  • the passkey server 360 could rely on an external authentication provider or device intelligence provider, which could generate the device identifier based on the provided device data and return the device identifier to the passkey server 360.
  • the passkey server 360 could hash the device data (or some subset of the device data), thereby generating a device hash.
  • the device identifier can comprise the device hash.
  • the device identifier can be used by the passkey server 360 to look up a database record corresponding to user device 352.
  • a database record can indicate whether user device 352 is enrolled in a passkey-based authentication system according to embodiments, e.g., if a passkey (or a component of a passkey, e.g., a related public key) is recorded in the database record and is associated with the user device 352 and any applicable credential (e.g., the credential provided at step S302, e.g., a PAN).
  • a passkey or a component of a passkey, e.g., a related public key
  • the passkey server 360 can also determine a session identifier (e.g, a “first session identifier”).
  • the session identifier can generally identify the interaction between the user 350 and the resource provider, or e.g., a “session” associated with the interaction, e.g., a particular “authentication session” taking place in order to authenticate the user 350.
  • a session identifier can be determined in any appropriate manner, e.g., a session identifier could comprise the next sequential number in a sequence of numbers used as session identifiers.
  • the passkey server 360 can determine that the user device 352 is capable of performing an authentication process using a digital signature, e.g., is capable of performing passkey-based authentication methods according to embodiments.
  • the passkey server 360 can make this determination based on the received device data. For example, in some embodiments, in which the user 350 and user device 352 are authenticated via FIDO passkeys, the passkey server 360 can determine that the user device is capable of performing the authentication process using the digital signature by determining that the user device is FIDO compatible.
  • the passkey server 360 could determine, based on the device data, whether the user device 352 has any appropriate APIs for performing authentication using a digital signature, e.g., a universal second factor (U2F) API, a “WebAuthn” API, etc.), and whether the user device can support any appropriate authentication protocols (e.g., the client to authenticator protocol CTAP1 or CTAP2).
  • a digital signature e.g., a universal second factor (U2F) API, a “WebAuthn” API, etc.
  • the passkey server 360 can also determine whether the user device 352 has any form of secure memory that can be used to securely store a private key for authentication (e.g., a private key that can be used to generate the digital signature), such as a “digital wallet”, “hardware wallet” (e.g., implemented using a secure chip or trusted platform module), a “vault”, “keychain”, etc.
  • the passkey server 360 can further determine whether the user device 352 possesses any hardware or components that may be used for user authentication, e.g., a biometric interface (such as a fingerprint scanner or a camera for performing an iris scan or facial recognition) as part of determining whether the user device 352 is capable of performing an authentication process using a digital signature.
  • a biometric interface such as a fingerprint scanner or a camera for performing an iris scan or facial recognition
  • the passkey server 360 can transmit the session identifier to the resource provider computer 354. Alternatively or additionally, the passkey server 360 can transmit the session identifier to user device 352. The passkey server 360 can additionally transmit a flag indicating that the user device 352 is capable of performing an authentication process using a digital signature, e.g., that the user device 352 is capable of performing a FIDO authentication process. In some embodiments, the passkey server 360 can transmit the session identifier and the flag via the authentication server computer 356 (which can comprise a 3-D Secure server).
  • the passkey server 360 can receive the session identifier (e.g., a “first session identifier”) and interaction data associated with the interaction (also referred to as a “first interaction”).
  • the interaction data can comprise a credential (e.g., a PAN), as well as various other data, such as a resource provider identifier (e.g., a merchant identifier), an interaction amount (e.g., a transaction amount), a currency, a transaction UUID (unique universal identifier), etc.
  • the passkey server 360 can receive the session identifier and the interaction data from the resource provider computer 354, e.g., via authentication server computer 356. Alternatively, the passkey server 360 can receive the session identifier and interaction data from the user device 352 instead of the resource provider computer 354.
  • the passkey server 360 can determine that the credential is not associated with the device identifier, e.g., that there is no database record corresponding to the credential and the device identifier.
  • the passkey server 360 can further determine that the credential is not associated with a public key of a public-private key pair, i.e. , a public key corresponding to a passkey (e.g., a FIDO passkey).
  • a passkey e.g., a FIDO passkey
  • the passkey server 360 can determine that the user device 352 is not enrolled into a passkey-based authentication system according to embodiments.
  • the passkey server 360 can store the device data in association with the device identifier in a database record, e.g., for later use during enrollment.
  • Steps S304-S310 generally do not require any input on behalf of the user.
  • the user 350 could be displayed a brief “loading” or “working” screen on user device 352, e.g., as depicted in view 404 of FIG. 4A.
  • the passkey server 360 can initiate an alternative authentication process.
  • the user device 352 can be authenticated via the alternative authentication process.
  • the authentication process can be performed by the user device 352 and the authorizing entity computer 366 or access control server 364. This may be useful as an authorizing entity (e.g., an issuing bank) associated with the authorizing entity computer 366 or access control server 364 may have initially issued the credential to the user 350, and consequently the authorizing entity may be better suited to authenticate the user 350 and the user device 352.
  • an authorizing entity e.g., an issuing bank
  • the passkey server 360 can provide a message (e.g., a “first message”) indicating that the user device 352 is authenticated, e.g., to any device, entity, or system depicted in FIG. 3. Such a message can contain a cryptogram indicating that the user 350 has been verified or authenticated.
  • a message e.g., a “first message”
  • Such a message can contain a cryptogram indicating that the user 350 has been verified or authenticated.
  • the alternative authentication process can comprise a 3-D secure authentication process performed by the user device 352 and the authorizing entity computer 366.
  • a 3-D secure authentication process can involve the use of a “3-D Secure Protocol”, such as the “EMV® 3-D Secure Protocol”.
  • a 3-D Secure Protocol process flow will not be described in detail herein. More specific details about 3-D Secure Protocols can be found in the “EMV® 3-D Secure Protocol and Core Functions Specification” (e.g., version 2.2.0 updated June 2023).
  • 3-D Secure Protocols enables authentication steps to be performed in order to authorize an interaction, usually by an authorizing entity.
  • 3-D Secure Protocols can support various different authentication methods, which may be set based on the preferences of authorizing entities, assessments of risk or security requirements, etc.
  • a 3-D Secure Protocol could involve an authorizing entity computer 366 transmitting a one-time password (OTP) or a verification link to the user device 352 (e.g., via a text message) and requesting that the user 350 either input the one-time password into a form (e.g., via a web browser running on user device 352) or click the verification link.
  • OTP one-time password
  • a verification link to the user device 352 (e.g., via a text message) and requesting that the user 350 either input the one-time password into a form (e.g., via a web browser running on user device 352) or click the verification link.
  • the user 350 can subsequently be offered an opportunity to enroll in a passkey-based authentication system according to embodiments (e.g., in steps S316-S328), which may provide user 350 with a more streamlined authentication process for future interactions using their credential.
  • This enrollment process can benefit from the alternative authentication process, i.e. , the user 350 can be enrolled in the passkeybased authentication system given that they have successfully been authenticated via the alternative authentication process (e.g., given that they have been authenticated via 3-D Secure).
  • Step S312 generally corresponds to views 406-412 of FIG. 4B-4C.
  • a message can be displayed to the user via the user device, e.g., in an iframe or via any other suitable means. Such a message can indicate that the user may need to perform additional authentication steps before the interaction can be authorized.
  • interaction details can be displayed to the user via the message, e.g., indicating an interaction amount (e.g., a transaction amount), a resource provider identifier (e.g., the name of a merchant), etc., enabling the user to review and confirm the interaction details before submitting to the alternative authentication process.
  • an interaction amount e.g., a transaction amount
  • a resource provider identifier e.g., the name of a merchant
  • the user may be prompted to perform a biometric authentication (e.g., in displayed message 432).
  • a biometric authentication e.g., in displayed message 432.
  • the user may be prompted to approve or cancel the interaction (view 410), which may additionally involve displaying interaction details to the user.
  • the user can be shown a verification screen (view 412).
  • Various other 3-D Secure Challenge steps can be performed, as described in more detail in the EMV® 3-D Secure Protocol and Core Functions Specification, which may not be visible to the user.
  • an authorization process can be performed for the interaction.
  • An authorization request message (e.g., comprising an ECI 05 authentication indicator) can be sent to authorizing entity computer 366 from resource provider computer 354, e.g., via processing network 362 (e.g., a payment processing network such as VisaNet).
  • the authorizing entity computer 366 can review the authorization request message and any relevant data therein.
  • the authorization request message may contain a cryptogram indicating that the user 350 has been authenticated via the alternative authentication process, as well as various interaction details associated with the interaction.
  • the authorizing entity computer 366 can approve or decline the interaction (e.g., approving the interaction provided that user 350 has been successfully authenticated and declining otherwise) and generate an authorization response message, which can be relayed back to the resource provider computer 354 (e.g., via processing network 362).
  • the resource provider computer 354 can then complete or terminate the interaction based on the authorization response message, e.g., completing the interaction by providing some resource (e.g., access to an email account, access to a streaming service, etc.) to the user 350, e.g., via user device 352.
  • user 350 can be offered to enroll in a passkey-based authentication system according to embodiments.
  • the passkey server 360 can transmit an enrollment request message to the user device 352.
  • the passkey server 360 can transmit the enrollment request message to the user device 352 responsive to successful authentication of the user device 352 via the alternative authentication process.
  • View 414 of FIG. 4D shows a prompt or message being shown to the user, which may be displayed to the user via an iframe in a resource provider website (or via some other display element, e.g., a pop-up).
  • the user can use III elements such as a button 434 in order to enroll in the passkey-based authentication service.
  • Such a button could open another interface (view 416), e.g., by redirecting the user to a website associated with a processing network and a passkey server.
  • the interface can indicate to the user that the passkey will be associated with the user device and with the provided credential (e.g., the PAN).
  • This enrollment process generally corresponds to steps S316-S328 of FIG. 3.
  • a registration message can be sent to the passkey server 360, e.g., from resource provider computer 354 via authentication server computer 356, from user device 352 via authentication server computer 356, from user device 352 via resource provider computer 354 and authentication server computer 356, etc.
  • the registration message can comprise the session identifier and an alternative authentication identifier (e.g., a 3-D Secure transaction identifier) corresponding to the interaction.
  • the alternative authentication identifier can confirm that the user 350 was authenticated (i.e. , via the alternative authentication process), and thus can safely be enrolled in passkey-based authentication systems according to embodiments.
  • the passkey server 360 can use the session identifier to identify any relevant data collected during steps S304-S310, e.g., relevant user device data, confirmation that the user device 352 is capable of performing authentication using digital signatures and passkeys (e.g., confirming that user device 352 is FIDO compatible), confirmation that user 350 and user device 352 are not already enrolled in passkey-based authentication systems according to embodiments, etc.
  • the registration message can also confirm the intent by the user 350 to enroll in passkey-based authentication systems according to embodiments.
  • an authentication request object can be sent to the user device 352, enabling the user device 352 to continue the enrollment process.
  • the authentication request object can be sent to the user device 352 via authentication server computer 356, via the resource provider computer 354 (e.g., via a resource provider website displayed to user 350 via user device 352), etc.
  • the authentication request object can be sent back to the passkey server 360 from user device 352, e.g., via resource provider computer 354 and authentication server computer 356.
  • the user device 352 can generate a passkey that can be used for later authentication.
  • the passkey can comprise a public private-key pair.
  • the user device 352 can generate a public key and a private key of a public-private key pair.
  • the user device 352 can generate the public key and the private key of the public-private key pair responsive to an enrollment request message received by the user device 352 from the passkey server 360.
  • the user device 352 can securely store the private key, e.g., in encrypted format, in a “digital wallet”, “hardware wallet” (e.g., implemented using a secure chip or trusted platform module), “vault”, “keychain”, etc.
  • the user device 352 can generate an enrollment response message and transmit the enrollment response message to the passkey server 360.
  • the enrollment response message can include authentication data (e.g., FIDO authentication data) including the public key.
  • the passkey server 360 can store the public key in association with other information related to the user, e.g., the user device identifier, the credential, the device data, and any other applicable information. In some embodiments, the passkey server 360 can store such data by generating a database record indicating that the credential is associated with the device identifier and the public key of the public-private key pair.
  • the user device 352 may perform additional authentication prior to generating the public-private keypair, e.g., biometric authentication, e.g., as shown in views 418 and 420 of FIG. 4E, in which the user is provided a message 436 asking the user whether they would like to use facial recognition in order to sign in to their user device as part of the passkey generation process. Afterwards, the user can be displayed a brief “loading” or “working” screen (view 422) while the public-private key pair is generated and various other steps are performed (e.g., steps S234-S238).
  • biometric authentication e.g., as shown in views 418 and 420 of FIG. 4E
  • the user is provided a message 436 asking the user whether they would like to use facial recognition in order to sign in to their user device as part of the passkey generation process.
  • the user can be displayed a brief “loading” or “working” screen (view 422) while the public-private key pair is generated and various other steps are performed (e.g
  • the passkey server 360 can transmit a passkey payload (e.g., a FIDO payload) to the authentication server computer 356, effectively informing the authentication server computer 356 (e.g., a 3-D Secure server) that the user 350 and user device 352 have been enrolled in passkey-based authentication systems according to embodiments.
  • a passkey payload e.g., a FIDO payload
  • the authentication server computer 356 e.g., a 3-D Secure server
  • the authentication server computer 356 can transmit the passkey payload to the access control server 364, e.g., via directory server 358 (which may identify an access control server relevant to the passkey payload using its directory, e.g., an access control server corresponding to an issuer that issued a payment credential to user 350).
  • the passkey payload can indicate to the authorizing entity that the user was enrolled in a passkey-based authentication system according to embodiments (in other words that a passkey, e.g., a FIDO or FIDO2 passkey, was created) and did so by authenticating the user 350 through an alternative authentication process (e.g., 3-D Secure, ID&V, etc.)
  • the access control server 364 can transmit a success response to authentication server computer 356 (e.g., via directory server 358), thereby notifying the authentication server computer 356 that the authorizing entity has received the passkey payload and is aware that user 350 and user device 352 have been enrolled in passkey-based authentication systems according to embodiments.
  • the user may be displayed various other views via the user device, e.g., a view requesting the user to input an email address so that a passkey creation confirmation email can be sent to the user (view 424) and a view showing an exemplary passkey creation confirmation email (view 426).
  • FIG. 5 shows a sequence diagram corresponding to an interaction between a user 550 and a resource provider.
  • the user 550 has already registered with a passkey-based authentication system according to embodiments (e.g., as described above with reference to FIG. 3).
  • the user 550 can be authenticated using passkey-based authentication methods according to embodiments and does not need to be authenticated using an alternative authentication process (e.g., 3-D Secure).
  • an alternative authentication process e.g., 3-D Secure
  • the computers, devices, and entities in FIG. 5 can generally be divided into a resource provider domain 568 (including user 550, user device 552, resource provider computer 554, and authentication server computer 556 (e.g., a 3-D Secure authentication server)), interoperability domain 570 (including directory server 558, passkey server 560, and processing network 562), and authorizing entity domain 572 (including access control server 564 and authorizing entity computer 566).
  • resource provider domain 568 including user 550, user device 552, resource provider computer 554, and authentication server computer 556 (e.g., a 3-D Secure authentication server)
  • interoperability domain 570 including directory server 558, passkey server 560, and processing network 562
  • authorizing entity domain 572 including access control server 564 and authorizing entity computer 566.
  • a user 550 operating a user device 552 can conduct an interaction with a resource provider via resource provider computer 554.
  • User device 352 may be interacting with a resource provider website operated by resource provider computer 354 in order to conduct the interaction.
  • “conducting” an interaction can take various forms depending on the nature of the resource provider and any resources provided by that resource provider.
  • user 550 could conduct an interaction by providing a credential (e.g., a password) to a web form associated with an email hosting service and clicking or otherwise selecting a “login” button.
  • FIG. 6A shows a view 602 of a smartphone user device displaying a resource provider website (e.g., hosted by resource provider computer 354) via a browser application.
  • a credential 616 e.g., a credit card number
  • the user can signal their intent to make a purchase using the provided credential by selecting a checkout button 620.
  • the resource provider website can comprise a “second resource provider website” (e.g., to differentiate it from a “first resource provider website” described above with reference to FIG. 3).
  • the resource provider computer 354 can comprise a second resource provider computer and the interaction can comprise a second interaction.
  • a passkey generated during an interaction with one resource provider computer can be used to authenticate a user during an interaction with another resource provider computer.
  • the two resource providers are the same, i.e. , in some embodiments, the first resource provider computer and the second resource provider computer can comprise a same resource provider computer and the first resource provider website and the second resource provider website can comprise a same resource provider website.
  • an initialization request message (e.g., a second initialization request message) can be transmitted to passkey server 560 (sometimes more generically referred to as a “server computer”).
  • the passkey server 560 can receive the initialization request message from the user device 552, e.g., via resource provider computer 554 and/or authentication server computer 556 (which may comprise a 3-D Secure authentication server) or from the resource provider computer 554 itself.
  • the initialization request message can comprise device data associated with the user device 552.
  • an HTML “iframe” embedded in the resource provider website can be used to transmit the device data from the user device 552 to the passkey server 560, e.g., via a user device SDK (e.g., accessible by a browser application) that enables device data to be read from the user device 552.
  • a user device SDK e.g., accessible by a browser application
  • the device data can include any suitable data that can be used to identify the user device 552, e.g., via “device fingerprinting” processes.
  • the device data can include a numerical or alphanumerical code that can be used to identify the user device 552 (e.g., a phone number, an international mobile equipment identity (IMEI) number, an embedded identity document (EID) number, etc.).
  • IMEI international mobile equipment identity
  • EID embedded identity document
  • the device data can also include, as examples, an IP address, geolocation data, a browser type or browser version number, processor data (e.g., identifying a processor or microprocessor type or model number), a model number, a manufacturer name, an operating system identifier, device component data (e.g., identifying any types of components in the user device such as a biometric reader, an NFC antenna, etc.), etc.
  • processor data e.g., identifying a processor or microprocessor type or model number
  • model number e.g., identifying a processor or microprocessor type or model number
  • a manufacturer name e.g., identifying any types of components in the user device
  • device component data e.g., identifying any types of components in the user device such as a biometric reader, an NFC antenna, etc.
  • the passkey server 560 can determine a device identifier based on the device data.
  • the device identifier can uniquely identify the user device 552 based on its associated device data.
  • the passkey server 560 can determine a device identifier based on the device data.
  • the passkey server 560 could rely on an external authentication provider or device intelligence provider, which could generate the device identifier based on the provided device data and return the device identifier to the passkey server 560.
  • the passkey server 560 could hash the device data (or some subset of the device data), thereby generating a device hash.
  • the device identifier can comprise the device hash.
  • the device identifier can be used by the passkey server 560 to look up a database record corresponding to user device 552.
  • a database record can indicate whether user device 552 is enrolled in a passkey-based authentication system according to embodiments, e.g., if a passkey (or a component of a passkey, e.g., a related public key) is recorded in the database record in associated with the user device 552 and any applicable credential (e.g., the credential provided at step S502, e.g., a PAN).
  • a passkey or a component of a passkey, e.g., a related public key
  • the passkey server 560 can determine a session identifier (e.g., a “second session identifier”).
  • the session identifier can generally identify the interaction between the user 550 and the resource provider, or e.g., a “session” associated with the interaction, e.g., a particular “authentication session” taking place in order to authenticate the user 550.
  • a session identifier can be determined in any appropriate manner, e.g., a session identifier could comprise the next sequential number in a sequence of numbers used as session identifiers.
  • the passkey server 560 can determine that the user device 552 is capable of performing an authentication process using a digital signature, e.g., is capable of performing passkey-based authentication methods according to embodiments.
  • the passkey server 560 can make this determination based on the received device data. For example, in some embodiments, in which the user 550 and user device 552 are authenticated via FIDO passkeys, the passkey server 560 can determine that the user device is capable of performing the authentication process using the digital signature by determining that the user device is FIDO compatible.
  • the passkey server 560 could determine, based on the device data, whether the user device 552 has any appropriate APIs for performing authentication using a digital signature, e.g., a universal second factor (U2F) API, a “WebAuthn” API, etc.), and whether the user device can support any appropriate authentication protocols (e.g., the client to authenticator protocol CTAP1 or CTAP2).
  • a digital signature e.g., a universal second factor (U2F) API, a “WebAuthn” API, etc.
  • the passkey server 560 can also determine whether the user device 552 has any form of secure memory that can securely store a private key for authentication (e.g., a private key that can be used to generate the digital signature), such as a “digital wallet”, “hardware wallet” (e.g., implemented using a secure chip or trusted platform module), a “vault”, “keychain”, etc.
  • the passkey server 560 can further determine whether the user device 552 possesses any hardware or components that may be used for user authentication, e.g., a biometric interface (such as a fingerprint scanner or a camera for performing an iris scan or facial recognition) as part of determining whether the user device 552 is capable of performing an authentication process using a digital signature.
  • a biometric interface such as a fingerprint scanner or a camera for performing an iris scan or facial recognition
  • the passkey server 560 can transmit the session identifier to the resource provider computer 554. Alternatively or additionally, the passkey server 560 can transmit the session identifier to user device 552. The passkey server 560 can additionally transmit a flag indicating that the user device 552 is capable of performing an authentication process using a digital signature, e.g., that the user device 552 is capable of performing a FIDO authentication process. In some embodiments, the passkey server 560 can transmit the session identifier and the flag via the authentication server computer 556 (which can comprise a 3-D Secure server).
  • the passkey server 560 can receive the session identifier (also referred to as a “second session identifier”) and interaction data associated with the interaction (also referred to as a “second interaction”).
  • the interaction data can comprise a credential (e.g., a PAN), as well as various other data, such as a resource provider identifier (e.g., a merchant identifier), an interaction amount (e.g., a transaction amount), a currency, a transaction UUID (unique universal identifier), etc.
  • the passkey server 560 can receive the session identifier and the interaction data from the resource provider computer 554, e.g., via authentication server computer 556 (which may comprise a 3-D Secure authentication server).
  • the passkey server 560 can receive the session identifier and interaction data from the user device 552 instead of the resource provider computer 554.
  • the passkey server 560 can identify a database record from a database.
  • the database record can indicate that the credential is associated with the device identifier and a public key of a public-private key pair (e.g., comprising or corresponding to a passkey).
  • the publicprivate key pair can comprise a Fast Identity Online (FIDO) passkey.
  • FIDO Fast Identity Online
  • Steps S504-S510 generally do not require any input on behalf of the user.
  • the user 550 could be displayed a brief “loading” or “working” screen on user device 552, e.g., as depicted in view 604 of FIG. 6A.
  • an authentication request including an authentication request object can be sent by the authentication server computer 556 to the passkey server 560.
  • Passkey server 560 can then initiate passkey-based authentication of user 550 (e.g., at step S514 described below).
  • the user 550 and user device 552 can be authenticated using passkey-based authentication.
  • the passkey server 560 can transmit a challenge message to the user device 552.
  • the user device 552 can sign the challenge message using a private key of the public-private key pair to produce a digital signature (which can be verified by the passkey server 560 to authenticate user 550, e.g., as described in more detail below).
  • an authentication confirmation message can be displayed to the user 550 of user device 552, e.g., via a web browser application.
  • the authentication confirmation message can be displayed to the user 550 in an iframe in the resource provider website.
  • the authentication confirmation message can correspond to a server computer website associated with the passkey server 560.
  • the user device 552 can sign the challenge message using the private key of the public-private key pair responsive to user confirmation of the authentication confirmation message.
  • View 606 of FIG. 6B shows an authentication confirmation message, which the user 550 can confirm via selecting button 622.
  • the authentication confirmation message can include various interaction data, enabling the user 550 to confirm these interaction data prior to authentication. For example, in a payment transaction, a transaction amount can be displayed to the user 550, enabling the user 550 to confirm that they are not being overcharged.
  • the challenge message can comprise the interaction data.
  • a challenge message comprising interaction data to authenticate the user device 552 guarantees that the interaction data was presented to the user 550 in some form (e.g., by being transmitted to the user device 552, displayed in an authentication confirmation message, etc.). This can be useful during later authorization of the interaction, as the digital signature produced by signing the challenge message can be presented to an authorizing entity (e.g., operating authorizing entity computer 566), both confirming that the user 550 was presented details about the interaction (in the form of the interaction data) and was authenticated using passkey-based authentication methods according to embodiments (e.g., as the challenge message was signed using the private key to generate the digital signature).
  • an authorizing entity e.g., operating authorizing entity computer 566
  • the user device 552 can authenticate the user 550 of the user device 552 prior to signing the challenge message using the private key.
  • the user device 552 can authenticate the user 550 of the user device 552 using a biometric sample, passcode and/or password.
  • the user device 552 can sign the challenge message using the private key responsive to successfully authenticating the user via the biometric sample, passcode, or password.
  • Views 608 and 610 of FIGs. 6B and 6C generally show such an authentication process. In views 608 and 610 the user is prompted to use facial recognition to sign-in, e.g., via message 618.
  • passkeys according to embodiments can be device-bound, passkey-based authentication methods according to embodiments naturally demonstrate that the user 550 is in possession of their user device 552, satisfying the “something they have” authentication factor. If the user 550 is additionally authenticated via a biometric or password, that satisfies either the “something they are” or “something they know” authentication factor, meaning that at least two factors have been used to authenticate the user 550.
  • biometrics for unlocking purposes (e.g., fingerprint scans or thumbprint scans, facial recognition, etc.), and many users are used to providing such biometrics in order to use their user devices.
  • methods according to embodiments can provide two (or more) factor authentication, from the user’s perspective, they only needed to provide one form of authentication, e.g., a passcode, password, or biometric sample.
  • the user 550 does not need to e.g., receive a one-time passcode sent via text or email and input it into a web form. In this way, embodiments of the present disclosure provide a frictionless user experience.
  • the user device 552 can transmit the digital signature to the passkey server 560.
  • the passkey server 560 can then validate the digital signature using the public key of the public-private key pair, which the passkey server 560 could have identified in a previous step, e.g., when identifying a data record corresponding to the device identifier at step S504. In this way, the passkey server 560 and user device 552 can be used to authenticate user 550 and user device 552. After authenticating the user 550 and user device 552, steps S516-S522 can be performed (as described below) in order to authorize and complete the interaction between user 550 and the resource provider.
  • the passkey server 560 can provide a message indicating that the user device 552 has been authenticated.
  • the message in which the public-private key pair corresponds to a FIDO passkey, the message can comprise a FIDO payload.
  • the passkey server 560 can provide the message indicating that the user device 552 is authenticated to the authentication server computer 556.
  • the passkey server 560 can use a directory server 558 and the credential to identify an access control server 564 associated with authorizing entity computer 566.
  • the authorizing entity computer 566 can be associated with the credential, e.g., the authorizing entity computer 566 can comprise a computer system associated with an issuing bank (authorizing entity) that issued the credential (e.g., a PAN) to user 550.
  • the passkey server 560 can provide the message by transmitting the message to the access control server 564.
  • the message can comprise the digital signature.
  • the digital signature can be generated by the user device 552 by encrypting a challenge message using the private key.
  • the challenge message can comprise interaction data corresponding to the interaction between user 550 and the resource provider. As such, generating the digital signature can effectively comprise signing the interaction data.
  • the passkey server 560 can provide the message by providing the message to the authorizing entity computer.
  • the authorizing entity 566 computer can validate the interaction between the user 550 and the resource provider computer by analyzing the digital signature. For example, the authorizing entity computer 566 may have received an authorization request message from the resource provider computer 554, e.g., requesting authorization for an interaction between user 550 and the resource provider.
  • the authorization request message can contain the interaction data. For example, if the interaction comprises a payment transaction, the authorization request message can include a transaction amount and a merchant identifier.
  • the authorizing entity computer 566 can validate the interaction by decrypting the digital signature using the public key and comparing a result of the decryption to the interaction data from the authorization request message. Generally, if the digital signature was generated using a challenge message comprising the interaction data, decrypting the digital signature should reproduce the interaction data. In this way, the authorizing entity can confirm that the interaction data provided by the resource provider and the interaction data provided by the user are identical, providing evidence that the interaction is legitimate. [0120] Various steps described above can be performed with other computer systems, entities, and devices depicted in FIG. 5.
  • the authentication server computer 556 can send the message (which can comprise, e.g., a FIDO payload) to the access control server 564 via directory server 558.
  • This step can generally inform the authorizing entity that a passkey-based authentication method according to embodiments was performed in order to authenticate user 550 and user device 552.
  • a success message can be sent from the access control server 564 to the authentication server computer 556 via the directory server 558.
  • the success message can also be passed to the resource provider computer 554.
  • an authorization request message can be sent to the authorizing entity computer 566 in order to request authorization for the interaction between user 550 and the resource provider.
  • the resource provider computer 554 can generate the authorization request message and send it to the authorizing entity computer 566.
  • the resource provider computer 554 may be assisted by a processing network 562 (e.g., VisaNet), which may route the authorization request message to the correct authorizing entity computer 566.
  • the authorizing entity computer 566 can then generate an authorization response message and return it to resource provider computer 554 via processing network 562.
  • the authorization response message can indicate whether the interaction has been approved (e.g., if the user 550 has been authenticated) or has been declined. Based on the authorization response message, the resource provider computer 554 can either complete or terminate the interaction.
  • the passkey server 560 can provide the message by transmitting the message to the authorizing entity computer 566, e.g., directly or via the authentication server computer 556, directory server 558, processing network 562, etc.
  • the authorizing entity computer can generate an authorization response message.
  • the authorization response message can indicate the interaction is approved (e.g., based on the information contained in the message).
  • the authorizing entity computer 566 can transmit the authorization response message to the resource provider computer 554.
  • the resource provider computer 554 can complete the interaction responsive to receiving the authorization response message.
  • Steps S516-S522 generally do not require action on the part of the user 550 or user device 552.
  • the user device 552 can be used to display a “loading” or “working” page to the user 550, e.g., as depicted in view 612 of FIG. 6C.
  • a message can be displayed to the user 550 indicating the status of the interaction, e.g., indicating whether the interaction was approved or declined, as shown in view 614 of FIG. 6D.
  • FIG. 7 shows an exemplary user device 700.
  • a user device may comprise a computer system (e.g., a desktop or laptop computer, a tablet, a mobile phone, a smartwatch, etc.).
  • a computer system e.g., a desktop or laptop computer, a tablet, a mobile phone, a smartwatch, etc.
  • User devices and computer systems mentioned herein may utilize any suitable number of subsystems.
  • a user device 700 includes a single computer apparatus and the subsystems can be the components of the computer apparatus.
  • a user device can include multiple computer apparatuses with internal components, each being a subsystem of the user device.
  • the subsystems shown in user device 700 can be connected via a system bus 720. Additional subsystems such as a printer 718, keyboard 714, computer readable media 722 (including system memory, storage devices, etc.), data collection device 716 (e.g., a camera, microphone, accelerometer, GPS unit, fingerprint scanner, etc.), monitor 710 (e.g., a display screen, such as an LED display), which is coupled to display adaptor 708, and others, are shown.
  • a printer 718 e.g., keyboard 714, computer readable media 722 (including system memory, storage devices, etc.), data collection device 716 (e.g., a camera, microphone, accelerometer, GPS unit, fingerprint scanner, etc.), monitor 710 (e.g., a display screen, such as an LED display), which is coupled to display adaptor 708, and others, are shown.
  • data collection device 716 e.g., a camera, microphone, accelerometer, GPS unit, fingerprint scanner, etc.
  • monitor 710 e.
  • Peripherals and input/output (I/O) devices which couple to I/O controller 706, can be connected to the user device 700 by any number of means known in the art such as an input/output port 712 (e.g., USB, FireWire®).
  • I/O port 712 or an external interface 704 e.g., Ethernet, Wi-Fi, Near Field Communication, Bluetooth, ZigBee interfaces, etc.
  • networks, devices, and computer systems such as a wide area network such as the Internet, a mouse input device, a scanner, an access device (e.g., a point-of-sale terminal), a resource provider computer, a passkey server, an access control server, etc.
  • User device 700 can include a plurality of the same components or subsystems, e.g., connected together by external interface 704, by an internal interface, or via removal storage devices that can be connected and removed from one component to another component. Additionally, user device 700 may lack (even temporarily) some of the components and subsystems depicted in FIG. 7. As such, it should be understood that the various components and subsystems depicted in FIG. 7 are optional.
  • system bus 720 allows the processor 702 (which may comprise a “central processor”, “central processing unit”, “CPU”, or other like terms) to communicate with each subsystem to control the execution of instructions or code from computer readable medium 722 (e.g., system memory, a fixed disk such as a hard drive, a solid state drive, an optical disk, etc.), as well as the exchange of information between subsystems.
  • computer readable medium 722 e.g., system memory, a fixed disk such as a hard drive, a solid state drive, an optical disk, etc.
  • Various software modules 724- 734 can be used to implement various methods described herein. It should be understood that the particular software modules depicted in FIG. 7 (and their configuration) are intended to represent only one possible implementation, selected for ease of exposition, and are not intended to be limiting.
  • FIG. 7 does not depict an operating system (i.e. , system software that manages hardware and software resources, provides common services and task scheduling, etc.), even though many user devices have operating systems.
  • an operating system i.e. , system software that manages hardware and software resources, provides common services and task scheduling, etc.
  • These software modules can include a browser application 724.
  • the browser application 724 may enable a user to navigate to various websites, e.g., for the purpose of performing interactions with resource providers via resource provider websites.
  • the browser application 724 may enable various transmissions of data as described above.
  • the browser application 724 may enable the user to provide a credential to a resource provider computer, may enable the user to enroll in a passkey-based authentication system according to embodiments, etc.
  • user device 700 can include a resource provider application 726, which may enable the user device 700 to interface with a resource provider computer without using browser application 724.
  • a resource provider application 726 could comprise, e.g., a smartphone application associated with a large ecommerce merchant.
  • User device 700 can further include a cryptography module 728 and a secure memory 730, which can be used to perform various cryptographic operations described herein. For example, user device 700 can use cryptography module 728 to generate public-private key pairs (as part of passkey-based authentication enrollment) as well as digitally sign challenge messages using private keys. User device 700 can use secure memory 730 to store such private keys, as well as any relevant credentials, if necessary.
  • a cryptography module 728 can be used to perform various cryptographic operations described herein.
  • user device 700 can use cryptography module 728 to generate public-private key pairs (as part of passkey-based authentication enrollment) as well as digitally sign challenge messages using private keys.
  • User device 700 can use secure memory 730 to store such private keys, as well as any relevant credentials, if necessary.
  • User device 700 can additionally include a biometric module 732 that the user device 700 can use to perform biometric authentication of a user, including collecting biometric samples via a data collection device 716 (such as a fingerprint scanner or a camera) and analyzing those biometric samples (e.g., by comparing them to biometric data stored in secure memory 730) in order to biometrically authenticate the user, e.g., prior to digitally signing a challenge message during passkey-based authentication.
  • a biometric module 732 that the user device 700 can use to perform biometric authentication of a user, including collecting biometric samples via a data collection device 716 (such as a fingerprint scanner or a camera) and analyzing those biometric samples (e.g., by comparing them to biometric data stored in secure memory 730) in order to biometrically authenticate the user, e.g., prior to digitally signing a challenge message during passkey-based authentication.
  • User device 700 can additionally include a device data software development kit (SDK) 734, which can be used by the user device 700 to produce and transmit device data to a passkey server, e.g., enabling the passkey server to determine a device identifier as part of passkey-based authentication methods according to embodiments.
  • SDK device data software development kit
  • FIG. 8 shows an exemplary passkey server 800.
  • a passkey server may comprise a computer system (e.g., a server computer). As described above, computer systems mentioned herein may utilize any suitable number of subsystems. Examples of such subsystems are shown in passkey server 800.
  • a passkey server includes a single computer apparatus and the subsystems can be the components of the computer apparatus. In other embodiments, a passkey server can include multiple computer apparatuses with internal components, each being a subsystem of the passkey server.
  • the subsystems shown in passkey server 800 can be connected via a system bus 820.
  • Additional subsystems such as a printer 818, keyboard 814, computer readable media 822 (including system memory, storage devices, etc.), data collection device 816 (e.g., a camera, microphone, accelerometer, GPS unit, etc.), monitor 810 (e.g., a display screen, such as an LED display), which is coupled to display adaptor 808, and others, are shown.
  • Peripherals and input/output (I/O) devices which couple to I/O controller 806, can be connected to the passkey server 800 by any number of means known in the art such as an input/output port 812 (e.g., USB, FireWire®).
  • I/O port 812 or an external interface 804 can be used to connect passkey server 800 to various networks, devices, and computer systems, such as a wide area network such as the Internet, a mouse input device, a scanner, an access device (e.g., a point-of-sale terminal), a user device, an authentication server computer, a directory server, an access control server, etc.
  • Passkey server 800 can include a plurality of the same components or subsystems, e.g., connected together by external interface 804, by an internal interface, or via removal storage devices that can be connected and removed from one component to another component. Additionally, passkey server 800 may lack (even temporarily) some of the components and subsystems depicted in FIG. 8. As such, it should be understood that the various components and subsystems depicted in FIG. 8 are optional.
  • system bus 820 allows the processor 802 (which may comprise a “central processor”, “central processing unit”, “CPU”, or other like terms) to communicate with each subsystem to control the execution of instructions or code from computer readable medium 822 (e.g., system memory, a fixed disk such as a hard drive, a solid state drive, an optical disk, etc.), as well as the exchange of information between subsystems.
  • computer readable medium 822 e.g., system memory, a fixed disk such as a hard drive, a solid state drive, an optical disk, etc.
  • Various software modules 824- 834 can be used to implement various methods described herein. It should be understood that the particular software modules depicted in FIG. 8 (and their configuration) are intended to represent only one possible implementation, selected for ease of exposition, and are not intended to be limiting.
  • FIG. 8 does not depict an operating system, even though many server computers have operating systems.
  • These software modules can include a device identifier module 824.
  • the device identifier module 824 can be used by passkey server 800 to receive and interpret user device data, as well as generate user identifiers based on such user device data.
  • Device identifier module 824 can be used in conjunction with a database management module 826, which can be used by passkey server 800 to manage database 828, e.g., to identify, add, delete, duplicate, etc., data records stored in database 828. As described above, such data records can be identified via device identifiers and can be used to establish a mapping between credentials, user devices, and public key components of passkeys used in methods according to embodiments.
  • Passkey server 800 can further include a signature verification module 830, which can be used by passkey server 800 to verify digital signatures produced by user devices as part of passkey-based authentication methods according to embodiments, e.g., passkey server 800 can use signature verification module 830 to verify digital signatures using a public key corresponding to a user device private key.
  • a signature verification module 830 can be used by passkey server 800 to verify digital signatures produced by user devices as part of passkey-based authentication methods according to embodiments, e.g., passkey server 800 can use signature verification module 830 to verify digital signatures using a public key corresponding to a user device private key.
  • Passkey server 800 can further include a registration module 832, which can be used to perform various steps associated with registering a user device with passkey-based authentication methods according to embodiments, e.g., involving determining whether a user device is compatible with passkey-based authentication methods according to embodiments (e.g., is FIDO compatible), whether the user device is already enrolled in passkey-based authentication methods according to embodiments, initiating an alternative authentication process prior to registering the user device, etc.
  • a registration module 832 can be used to perform various steps associated with registering a user device with passkey-based authentication methods according to embodiments, e.g., involving determining whether a user device is compatible with passkey-based authentication methods according to embodiments (e.g., is FIDO compatible), whether the user device is already enrolled in passkey-based authentication methods according to embodiments, initiating an alternative authentication process prior to registering the user device, etc.
  • Passkey server 800 can additionally include an interaction processing module 834, which passkey server 800 can use to perform various steps associated with processing an interaction or otherwise enabling the authorization of an interaction.
  • passkey server 800 can use interaction processing module 834 to forward the digital signature to an access control server or authorizing entity computer (via a directory server if necessary), in order to inform an authorizing entity that a user device has been authenticated using passkey-based authentication methods according to embodiments.
  • a computer system includes a single computer apparatus, where the subsystems can be components of the computer apparatus.
  • a computer system can include multiple computer apparatuses, each being a subsystem, with internal components.
  • a computer system can include a plurality of the components or subsystems, e.g., connected together by external interface or by an internal interface.
  • computer systems, subsystems, or apparatuses can communicate over a network.
  • one computer can be considered a client and another computer a server, where each can be part of a same computer system.
  • a client and a server can each include multiple systems, subsystems, or components.
  • any of the embodiments of the present invention can be implemented in the form of control logic using hardware (e.g., an application specific integrated circuit or field programmable gate array) and/or using computer software with a generally programmable processor in a modular or integrated manner, and thus a processor can include memory storing software instructions that configure hardware circuitry, as well as an FPGA with configuration instructions or an ASIC.
  • a processor can include a single-core processor, multi-core processor on a same integrated chip, or multiple processing units on a single circuit board or networked. The computations can be performed in parallel by the different processing units and/or different processing threads of a single processing unit.
  • 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 a series 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) or Blu-ray 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) or Blu-ray disk, flash memory, and the like.
  • the computer readable medium may be any combination of such storage or transmission devices.
  • the order of operations may be re-arranged.
  • a process can be terminated when its operations are complete but could have additional steps not included in a figure.
  • a process may correspond to a method, a function, a procedure, a subroutine, a subprogram, etc. When
  • 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.
  • a computer readable medium 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 (e.g., as firmware) 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.
  • any of the methods described herein may be totally or partially performed with a computer system including one or more processors, which can be configured to perform the steps.
  • embodiments can involve computer systems configured to perform the steps of any of the methods described herein, potentially with different components performing a respective step or a respective group of steps.
  • steps of methods herein can be performed at a same time or in a different order. Additionally, portions of these steps may be used with portions of other steps from other methods. Also, all or portions of a step may be optional. Additionally, any of the steps of any of the methods can be performed with modules, circuits, or other means for performing these steps.
  • Any operation performed with a processor may be performed in realtime.
  • the term “real-time” may refer to computing operations or processes that are completed within a certain time constraint.
  • a time constraint may be 30 seconds, 1 minute, 10 minutes, 30 minutes, 1 hour, 4 hours, 1 day, or 7 days, or different from any of these.
  • computer systems, subsystems, or apparatuses can communicate over a network.
  • one computer can be considered a client and another computer a server, where each can be part of a same computer system.
  • a client and a server can each involve multiple systems, subsystems, or components.
  • methods may involve various numbers of clients and/or servers, including at least 10, 20, 50, 100, 200, 500, 1 ,000, or 10,000 devices.
  • Methods can include various numbers of communication messages between devices, including at least 100, 200, 500, 1 ,000, 10,000, 50,000, 100,000, 500,000, or one million communication messages.
  • Such communications can involve at least 1 KB, 1 MB, 10 MB, 100 MB, 1 GB, 10 GB, or 100 GB of data.
  • a recitation of “a”, “an” or “the” is intended to mean “one or more” unless specifically indicated to the contrary.
  • the use of “or” is intended to mean an “inclusive or,” and not an “exclusive or” unless specifically indicated to the contrary.
  • Reference to a “first” component does not necessarily require that a second component be provided.
  • reference to a “first” or “second” component does not limit the referenced component to a particular location unless explicitly stated.
  • the term “based on” is intended to mean “based at least in part on.”

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Health & Medical Sciences (AREA)
  • Life Sciences & Earth Sciences (AREA)
  • Biodiversity & Conservation Biology (AREA)
  • Biomedical Technology (AREA)
  • General Health & Medical Sciences (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

L'invention concerne, dans des modes de réalisation, des procédés et des systèmes pour authentifier des utilisateurs de dispositifs utilisateurs à l'aide de clés d'accès, en particulier pendant des interactions avec des fournisseurs de ressources (par exemple, des systèmes informatiques qui fournissent des ressources en ligne), ce qui permet une authentification pratique et sécurisée d'utilisateurs. Pendant une interaction, des données de dispositif provenant d'un dispositif utilisateur peuvent être fournies à un serveur de clé d'accès. Le serveur de clé d'accès peut déterminer un identifiant de dispositif correspondant au dispositif utilisateur à l'aide d'une empreinte digitale de dispositif. Le serveur de clé d'accès peut identifier que le dispositif utilisateur permet d'effectuer une authentification à l'aide d'une signature numérique et d'identifier en outre une clé publique correspondant au dispositif utilisateur. Le serveur de clé d'accès peut transmettre un message de défi au dispositif utilisateur, qui peut signer le message de défi à l'aide de sa clé privée et transmettre la signature numérique résultante au serveur de clé d'accès. Le serveur de clé d'accès peut vérifier la signature numérique à l'aide de la clé publique afin d'authentifier le dispositif utilisateur.
PCT/US2025/039758 2024-07-30 2025-07-29 Procédé et système d'authentification cryptographique sécurisée Pending WO2026030384A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US202463677033P 2024-07-30 2024-07-30
US63/677,033 2024-07-30

Publications (1)

Publication Number Publication Date
WO2026030384A1 true WO2026030384A1 (fr) 2026-02-05

Family

ID=98655489

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2025/039758 Pending WO2026030384A1 (fr) 2024-07-30 2025-07-29 Procédé et système d'authentification cryptographique sécurisée

Country Status (1)

Country Link
WO (1) WO2026030384A1 (fr)

Similar Documents

Publication Publication Date Title
US12506739B2 (en) Unified identity verification
US10592872B2 (en) Secure registration and authentication of a user using a mobile device
CN111819555B (zh) 利用在线认证的安全远程令牌发布
JP6648110B2 (ja) クライアントをデバイスに対して認証するシステム及び方法
US9642005B2 (en) Secure authentication of a user using a mobile device
US20210243029A1 (en) Biometric verification process using certification token
CA2945703C (fr) Systemes, appareil et procedes pour une authentification amelioree
US9521548B2 (en) Secure registration of a mobile device for use with a session
EP3138265B1 (fr) Sécurité améliorée pour un enregistrement de dispositifs d'authentification
US20140164254A1 (en) Authenticating Remote Transactions Using a Mobile Device
US20130226813A1 (en) Cyberspace Identification Trust Authority (CITA) System and Method
US10489565B2 (en) Compromise alert and reissuance
KR20210142180A (ko) 효율적인 챌린지-응답 인증을 위한 시스템 및 방법
US20230052901A1 (en) Method and system for point of sale payment using a mobile device
US12423450B2 (en) Data broker
JP2023538860A (ja) 短距離トランシーバを介した検証済みメッセージングのためのシステムおよび方法
EP2747363A1 (fr) Procédé de validation de transaction au moyen d'un dispositif de communication
WO2026030384A1 (fr) Procédé et système d'authentification cryptographique sécurisée
WO2023064064A1 (fr) Afficheur d'informations de dispositif sécurisé à authentification à l'aide d'un kit de développement de logiciel (sdk)
TW201804384A (zh) 電子卡片建立系統及其方法
US20260046131A1 (en) Pass-key based credential processing
US20260113195A1 (en) Device binding using cryptographic keys
WO2026060417A1 (fr) Authentification basée sur une clé d'accès pour le protocole 3d sécurisé
WO2025071588A1 (fr) Authentification sécurisée faisant appel à une application logicielle
CN120223421A (zh) 物联网设备所有权的管理、核验方法和装置

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: 25848254

Country of ref document: EP

Kind code of ref document: A1