Method for enforcing the usage of a credential by a wallet

Abstract

A method for enforcing the usage of a credential by a wallet is provided, wherein the credential is stored in the wallet and comprises embedded logic self-asserting its usage, wherein the method comprises: · receiving, by the wallet, an attribute request indicating at least one attribute type and action to be performed by the wallet; · retrieving, by the wallet, at least one attribute stored in the credential, and getting the associated embedded logic, · inputting, by the wallet, at least part of the attribute request and the embedded logic to an action logic engine of the wallet, the action logic engine determining if the at least one attribute stored in the credential can be used in response to the attribute request; and · if action is granted by the action logic engine, performing, by the wallet, the requested action with the requested attribute.

Description

[0001] METHOD FOR ENFORCING THE USAGE OF A CREDENTIAL BY A WALLET

[0002] DESCRIPTION

[0003] TECHNICAL FIELD

[0004] This invention relates to the technical field of digital credentials and associated attributes, and, particularly, to multi-type credential wallets intended to store identity-related credentials and non-identity credentials such as payment cards or car keys.

[0005] In advantageous embodiments, the invention proposes credentials with embedded logic that self-asserts how they should be used thus moving away from hardcoded logics in classical wallets.

[0006] BACKGROUND OF THE INVENTION

[0007] An attribute refers to any characteristic that is proper to a given person (either natural or legal). The attributes are typically issued by an issuing authority (e.g., governments or institutions), that enable person’s authentication (e.g., given name, surname, address, citizenship, birthdate, age, etc.) or proves he / she has certain claims e.g., education qualifications, driver license status, etc. Such personal attributes are usually written on physical credentials, such as an ID card or passport but, with the emergence of online services, and seeking user-friendliness, these attributes tend to be further represented in a digital form and securely stored in digital wallets.

[0008] In short, the issuer (e.g., still governments or institutions) asserts certain attributes about the wallet’s holder, thus creating a credential containing these claims, and transmits I issues the verifiable credential to the holder, which securely stores it in its wallet. When the holder wishes to selectively disclose his / her attributes to a verifier, it generates a Presentation (similar schema than the credentials) that the verifier can validate.

[0009] Despite the above well-established ecosystem, the particulars about how to encode and transmit the data, process requests, or verify information depends on the specific format chosen. Among all the existing ones, ISO / IEC 18013-5 specification and W3C’s Verifiable Credentials Data Model v2.0 specification are widely used today, each defining a different attribute schema (i.e., structure, logical organization, type and namespace(s) of the attestedattributes), data format (i.e., the way data is formatted in the credentials) and proof mechanisms (i.e., how to attest credentials for integrity and authenticity).

[0010] These digital wallets have evolved beyond simple identity tools to become comprehensive credential management systems. They now tend to aggregate the pre-existing payment cards or tokens, and the upcoming car (or door) keys in a single place.

[0011] Historically, the wallets handled the different credentials based on hardcoded action logics that refer to the rules and decision-making processes that govern how credentials function within the wallet. These built-in behaviours determine what can be done with the credentials, when, and how.

[0012] However, not all the credentials in the wallets are just identity documents to present, and the associated possible actions to be performed with them are exponentially growing. For instance, car key credentials can unlock cars, but also start the engine, prove its ownership, etc. Therefore, inventors have found that hardcoding the action logics for every credential type in the wallet limits addressing new use cases and is less flexible to evolve.

[0013] This integration of diverse credentials into a single secure management system, e.g., the wallet application, represents one of the most sophisticated security challenges in consumer technology, balancing security, privacy, and convenience through carefully design action logic unique to each credential type.

[0014] SUMMARY OF THE INVENTION

[0015] The present invention provides a solution for all the aforementioned problems by a method for enforcing the usage of a credential by a wallet according to claim 1 , a wallet application according to claim 6, and a credential according to claim 7. In dependent claims, preferred embodiments of the invention are defined.

[0016] In a first inventive aspect, the invention provides a method for enforcing the usage of a credential by a wallet, wherein the credential is stored in the wallet and comprises embedded logic self-asserting its usage. The method comprises the following steps:

[0017] • receiving, by the wallet, an attribute request indicating at least one attribute type and action to be performed by the wallet;

[0018] • retrieving, by the wallet, at least one attribute stored in the credential, and gettingthe associated embedded logic,

[0019] • inputting, by the wallet, at least part of the attribute request and the embedded logic to an action logic engine of the wallet, the action logic engine determining if the at least one attribute stored in the credential can be used in response to the attribute request; and

[0020] • if action is granted by the action logic engine, performing, by the wallet, the requested action with the requested attribute.

[0021] Throughout the description, a credential should be understood as a cryptographically secured digital representation of attributes, entitlements, or capabilities issued by an authority, that can be securely stored in a digital wallet, and can be verified without requiring direct interaction with the issuer at the time of verification. They all serve as trusted digital proxies that allow the holder to prove something about themselves - their identity, their payment authority, their access rights - through a secure digital interaction. A credential according to the invention encompasses: identity-related credentials (e.g., W3C’s VCs, ISO mDL) and non-identity-related credentials (e.g., car keys, and wallet-hosted payment cards).

[0022] Advantageously, embedding the logic into the credential itself rather than foreseeing every possible action doable with the stored credentials and setup the wallet accordingly, enables the wallet to successfully handle various credential-specific actions and to support different use cases without having to hardcode the associated logic. It allows addressing evolving scenarios and new credential types without re-engineering the wallet application.

[0023] By attaching / embedding the action logic into the credential data itself, it becomes active and can participate in its rightful usage, thus performing validations, transformations, or mapping of its data.

[0024] There are examples of the industry where the issuer can place its “terms of use” of a specific credential, or where the wallet’s holder places his / her “terms of use” inside a verifiable presentation, see e.g., in W3C’s VC Data Model v2.0. However, this termOfUse property is a static literal representation of constraints that either the issuer or the holder wants to apply to the shared credential and that are plainly communicated to the verifier, who is supposed to abide by its rules.

[0025] The fact of letting the issuer embed the logics into the credential itself before its onboardingto be afterwards enforced by the wallet’s action logic engine indeed foster the development of secure, privacy-preserving, and convenient multi-type credential wallet technology. In a preferred embodiment, the wallet is a multi-type credential wallet able to store identity-related credentials and non-identity credentials such as payment cards and car keys.

[0026] In a preferred embodiment, the embedded logic of the credential is set, and signed, by the credential issuer before onboarding into the wallet.

[0027] In a particular embodiment, the embedded logic of the credential is a wide embedded logic self-asserting its usage at credential level, and the credential further comprises sub-logics at attribute level; the action logic engine being configured to interpret the wide embedded logic and the attributes-specific sub-logic against an attribute request.

[0028] In a particular embodiment, the embedded logic, or the attribute-specific sub-logic, at least defines:

[0029] • the supported protocols such as ISO mDL, W3C Verifiable Credential, etc., or • the supported transmission technologies such as Bluetooth Low Energy (BLE), Ultra-WideBand (UWB), or Near-Field Communication (NFC), etc., or

[0030] • the supported action: authentication, attribute presentation, transaction signing, unlock a door, start engine, etc.

[0031] As an example, as per today’s situation, car keys supporting Car Connectivity Consortium (CCC) spec, can be used through NFC, BLE and UWB; whereas current identity standards support NFC, BLE, QR codes, etc.

[0032] In a second inventive aspect, the invention provides a wallet application installable into a host computer and configured to in turn store at least one credential, wherein the wallet comprises both a generic application logic setting generic rules such as how to access, retrieve, or transform the attribute credentials, and an action logic engine to enforce the embedded logic of the stored credentials upon receiving attribute requests.

[0033] The wallet may be embodied, preferably, as a user device such as a smartphone, a desk computer, a laptop, a touchpad, a personal digital assistant, or any other device having adequate processing capabilities and communication interfaces, such as described hereafter, storing or including a digital wallet (either software or hardware). The digital wallet may be an application locally stored on the user device or remotely accessed (e.g., web-browser based application) by the user device. In an embodiment, the digital wallet is associated with, or include in, a digital safe, a secure enclave or a secure element, SE. The data stored in the e.g., digital safe can only be accessed, read and write, by the digital wallet, so that other applications cannot access this data without requesting access to the digital wallet.

[0034] In a preferred embodiment, the wallet is a multi-type credential wallet able to store identity-related credentials and non-identity credentials such as payment cards and car keys. The wallet can preferably support ISO / IEC 18013-5 specification, W3C’s Verifiable Credentials Data Model v2.0, Car Connectivity Consortium (CCC) spec., EM -related specs., 3-D Secure (3DS) protocols, and others standard formats.

[0035] In a third inventive aspect, the invention provides a credential to be stored in a wallet application, and usable in the method of the first inventive aspect, wherein the credential comprises embedded logic self-asserting its usage set, and signed, by the credential issuer before being onboarded into the wallet.

[0036] A credential according to the invention comprises:

[0037] (1) structured data assertions about a subject (e.g., identity attributes, payment authorization in a payment card, access rights in a car key, educational achievements), (2) cryptographic proof material (e.g., certificates and digital signatures created with the issuer's private key),

[0038] (3) trust framework establishing the authority of the issuer and the validity of the credential (e.g., certificate chains, DIDs, banking placeholders or tokens, and other keys), and (4) embedded logic self-asserting how it needs to be used.

[0039] For exemplary purposes, in a simplified and generic manner, it will be considered that a credential comprises: attested data, cryptographic secret (e.g., key(s)), certificate attested by issuer, and embedded logic. A way to see the convergence of car keys towards identity credentials is considering that the car key is an attribute for device / machine / car identity.

[0040] In a particular embodiment, the embedded logic is a wide embedded logic self-asserting its usage at credential level, and further comprising sub-logics at attribute level.

[0041] All the features described in this specification (including the claims, description and drawings) and / or all the steps of the described method can be combined in any combination,with the exception of combinations of such mutually exclusive features and / or steps.

[0042] DESCRIPTION OF THE DRAWINGS

[0043] These and other characteristics and advantages of the invention will become clearly understood in view of the detailed description of the invention which becomes apparent from a preferred embodiment of the invention, given just as an example and not being limited thereto, with reference to the drawings.

[0044] Fig. 1 shows the evolution from physical cards, to single-type credential wallet apps, to multi-type credential wallets.

[0045] Fig. 2 shows a schematic representation of the logic compilation during issuance and the resulting credential according to some embodiments of the invention.

[0046] Fig. 3 shows a schematic representation of the wallet’s workflow during presentation, according to some embodiments of the invention.

[0047] DETAILED DESCRIPTION OF THE INVENTION

[0048] In figure 1, it is depicted the industry evolution from physical cards, to use-specific apps, to multi-type credential wallets. Given their constrained development environment, typically regulated and standardised, physical cards and specific apps are credentials integrating the logic that control their usage. However, generic wallets need to be prepared to encompass diverse use cases and even evolve towards new credential types, rendering no well-defined method to manage the logic of the onboarded credentials.

[0049] As an example, these credentials can be formatted as per ISO / IEC 18013-5 specification (i.e., mDL doc), W3C’s Verifiable Credentials Data Model v2.0 (i.e., VC), Car Connectivity Consortium (CCC) spec., EMV-related specs., etc.

[0050] Today, wallets developers need to hardcode the plausible actions the wallet holders may wish to undertake with its credentials or, more often, implement the policy documents distributed by each of the Standard-Setting Organizations of the wallet’s supported standards. Since standards evolve, wallet developers frequently patch the platforms to be compliant with the latest technology updates.Sometimes, these hardcoded rules align in certain aspects, but there is never 100% matching. For instance, the ISO / IEC 18013-5 standard (i.e., mDL) takes a highly structured approach, while W3C’s VC approach provides more flexibility in its implementation. In mDL, the wallet for instance contains hardcoded categories of information known as data groups, which include personal details, user privileges, and document metadata. Fixed derivation rules handle transformations like converting birth dates to age verification booleans without revealing actual birth information. The transport protocol hierarchy defines precise rules for selecting between NFC, BLE, and QR communication methods based on e.g., availability and security preferences. On the other hand, in W3C’s VC implementations, the proof generation supports for instance various cryptographic proof formats including JSON Web Signatures, BBS+ signatures for advanced selective disclosure, and linked data proofs.

[0051] Regarding payment cards, the wallet never stores the actual card number. Instead, through a process called tokenization, the real card details are replaced with a secure token that only works on the specific wallet. Then, during a transaction, the wallet creates a one-time dynamic security code for each purchase rather than using the static CW on the physical card. The wallet's payment logic then needs to include specific rules for different contexts: for in-store purchases, it activates only when near an NFC terminal and requires biometric authentication, while for in-app purchases, it follows different authentication protocols while still maintaining security.

[0052] Digital car keys represent a newer addition to multi-credential wallets with their own unique implementation. Modern digital car keys use e.g., Ultra- Wideband (UWB) or Bluetooth Low Energy (BLE) technology to enable precise location awareness. This allows the car to detect exactly when the owner approaches, creating a seamless experience where the car unlocks as you near it. The provisioning process involves a secure handshake between the car manufacturer's backend, the vehicle, and the wallet. The car generates a unique cryptographic key that is securely transmitted to your wallet's secure element.

[0053] The present invention provides a method for enforcing the usage of a credential by a wallet that is based on 2 main components: on one hand, the fact that credential itself embed the logic that self-asserts its envisaged usage, and, on the other hand, the fact that the wallet comprises an action logic engine configured to receive the attribute request and the embedded logic outputting a granting I denying message. In a particular embodiment, this message can be an automatic resume / block of the regular workflow.Regarding the credential formatting (see figure 2), each credential embeds the plausible actions in the form of action logic scripts along with the attested attributes or claims. During issuance, the issuer issues (or refreshes) the credential in a standard manner further including the issuer-defined action scripts to the attested claims. As part issuance process, the issuer compiles the action logic(s) to bytecodes (e.g., using WebAssembly) and embeds them into the credential. Subsequently, the issuer signs the proof and / or certificates covering the logic(s) as well.

[0054] The embedded logic of the credential is 2-fold:

[0055] • a wide embedded logic self-asserting its usage at credential level, and

[0056] • sub-logics at attribute level.

[0057] The credential-level wide embedded logic is configured to address scenarios (e.g., validating access control for presentation) for the whole credential. Whereas sub-logics at attribute level would provide fine-grained validation of usage of credential attributes such as sharing maiden name of mother or authorizing sharing of car key to a friend for specific period of time.

[0058] As seen in figure 2, the action logics are in the form of compiled bytecodes (e.g., using WebAssemby or Wasm). In short, they take credential and reference parameters as input and generate the output. Action logics needs to understand the attribute request containing the type of requested action, associated inputs from the request and reference to the attached instance of the credential to successfully evaluate the action output.

[0059] Action logic can be developed in many high-level programing languages such as C, C++, RUST, GO Lang, Typescript, etc. Converting these high-level code into portal formats such as WebAssembly enables cross platform execution of action logic across multi-platform wallet applications can run on.

[0060] Hereinafter, there are provided 2 enabling examples of credentials with embedded logic, the first one relating to a Personal Identification Data, PID, credential, and the second one relating to a payment credential.

[0061] Example of ISO mDL-formatted PID credential with embedded action logic:{

[0062] version": "1.0",

[0063] "documents": [

[0064] {

[0065] "docType":

[0066] "issuerSigned": {

[0067] "nameSpaces": {

[0068] "eu.europa.ec.eudi.pid.1": [

[0069] 24(« {

[0070] "digestID": 0,

[0071] "random":

[0072] h'8798645B20EA200E19FFABAC92624BEE6AEC63ACEEDECFB1 B80077D22BFC20E9

[0073] "elementidentifier": "family_name",

[0074] "elementvalue": "Doe"

[0075] } »),

[0076] 24(« {

[0077] "digestID": 0,

[0078] "random":

[0079] h'8798645B20EA200E19FFABAC92624BEE6AEC63ACEEDECFB1 B80077D22BFC20E9

[0080] "elementidentifier": "given_name",

[0081] "elementvalue": "John"

[0082] ]} >>)

[0083] "eu.europa.ec.eudi.pid.action.1": [

[0084] 24(« {

[0085] "digestID": 0,

[0086] "random":

[0087] h'8798645B20EA200E19FFABAC92624BEE6AEC63ACEEDECFB1 B80077D22BFC20E9

[0088] "" ""

[0089] "" "

[0090]

[0091] }

[0092] }

[0093] "issuerAuth": []

[0094] }

[0095] }-

[0096] Example of W3C’s VC-formatted payment credential with embedded action logic:

[0097] {

[0098] "©context": ["https: / / www.w3.org / 2018 / credentials / v1 ", "https: / / schema.org / "] "id": "http: / / example.edu / credentials / 332","type": ["VerifiableCredential", "Paymentcredential"],

[0099] "issuer": "https: / / example.edU / issuers / 4",

[0100] "issuanceDate": "2017-02-24T19:73:24Z",

[0101] "actionLogic": {

[0102] "actionCode"="_actionForWholeCredBase64...",

[0103] "actionl_ist"= {"*:(rightsToRequest)", "present:"}

[0104] "version": "1.0.0",

[0105] ["iban": {

[0106] "actionCode"="_actionForAttributel_evelBase64",

[0107] "actionl_ist"= {"pay: ('transactionData')"}

[0108] }

[0109] }

[0110] }.

[0111] "credentialsubject": {

[0112] "name": "J. Doe",

[0113] "iban": "123123124-342423",

[0114] "expiryDate": "2050-03-15"

[0115] }.

[0116] "proof': {

[0117] }

[0118] }

[0119] In figure 3, it is depicted the enforcement of the allowed credential’s actions by the wallet during a so-called credential presentation. The credential presentation is a well-known mechanism of using identity-related attributes enabling selective disclosure within a secure infrastructure. The widely adopted ones are mDL and W3C’s VC. In short, a verifier requests the wallet’s holder to disclose some holder’s attributes and, after successfully performing device engagement (e.g., computing shared secrets for channel establishment), the verifier passes to the wallet an attribute request indicating the type of attribute it aims at knowing. The wallet checks which credentials store such type of attributes, and, if found, asks the holder for consent. Then, the wallet prepare an attribute presentation following the correct format and sends it to the verifier which can be either autonomously verify the user’s attribute values or consult the issuer before enforcing its verifier’s policies. The identity-related ecosystem, alike the payment or vehicle ones, are strongly marked by cryptography bringing then trust to every iteration in the workflow.

[0120] Therefore, figure 3 focusses on the “presentation” of a holder’s personal attribute, but it can similarly address the opening of holder’s car, or performing a payment transaction with holder’s banking card.

[0121] When the presentation request on an attribute is initiated, the wallet finds the corresponding credential and executes its action logic. Namely, the wallet inputs at least part (or all) of the attribute request and the embedded logic to the wallet’s action logic engine which determines if the at least one attribute stored in the credential can be used in response to the attribute request.

[0122] If successful, the wallet combines the output of the action logic with the regular data needed to prepare the response to the verifier.

[0123] To this end, the wallet comprises a generic app logic that determines, as per today, the overall treatment of the incoming requests; and an action logic engine that locally enforces the allowed actions of the overall credential and specific attributes. As depicted in figure 3, the parameter [pres_req] refer to the request from external entities (e.g., verifiers) requesting the specific action(s). The parameter “pres_req” would either be DocRequest (ISO mDL / mID), PresentationRequest (W3C’s VC), OIDC4VP Digital Credentials Query Language (DCQL) formatted request, etc. The second parameter [cred_ref] is a reference to the instance of the credential itself that is present in the wallet.

[0124] Thus, the generic app logic processes the incoming request [pres_req] from the requesting party (e.g., verifier) by looking up the credential, or specific attribute, from within the wallet [cred_ref], passes on (i.e., callback) the credential embedded logic to the action logic engine, gets back the output from the action logic engine (res, [act_output[ns:val]) and finally combines it with further data to deliver the response back to the requesting party. That is, generic app logic implements common behaviours across multiple credential such as processing of the Presentation Request on a credential, selective disclosure of attributes and preparation generic Presentation Response. In addition, the generic app logic advantageously invokes the action logic engine providing the Presentation Request and a reference to the associated credential in the wallet.As for the action logic engine, it is the bytecode in charge of processing the request throughout the execution of a credential wide logic applying to the whole credential targeted by the request, and the execution of attribute-specific sub-logic applying to each attribute constitutive of the credential. In other words, action logic engine loads credential wide byte code and sub-logic bytecode at attribute level, execute those bytecodes with the parameters ([pres_req],[cred_ref]), and collects the results returned (res, [act_output[ns:val]) from the action logics to be merged with the final Presentation Response.

Claims

CLAIMS1 A method for enforcing the usage of a credential by a wallet, wherein the credential is stored in the wallet and comprises embedded logic self-asserting its usage, wherein the method comprises:• receiving, by the wallet, an attribute request indicating at least one attribute type and action to be performed by the wallet;• retrieving, by the wallet, at least one attribute stored in the credential, and getting the associated embedded logic,• inputting, by the wallet, at least part of the attribute request and the embedded logic to an action logic engine of the wallet, the action logic engine determining if the at least one attribute stored in the credential can be used in response to the attribute request; and• if action is granted by the action logic engine, performing, by the wallet, the requested action with the requested attribute.2.- The method according to claim 1, wherein the embedded logic of the credential is set, and signed, by the credential issuer before onboarding into the wallet.3.- The method according to any of claim 1 or 2, wherein the embedded logic of the credential is a wide embedded logic self-asserting its usage at credential level, and the credential further comprises sub-logics at attribute level; the action logic engine being configured to interpret the wide embedded logic and the attributes-specific sub-logic against an attribute request.4.- The method according to any of claims 1 to 3, wherein the embedded logic, or the attribute-specific sub-logic, at least defines:• the supported protocols such as ISO mDL, W3C Verifiable Credential, etc., or • the supported transmission technologies such as Bluetooth Low Energy (BLE), Ultra-WideBand (UWB), or Near-Field Communication (NFC), etc., or• the supported action: authentication, attribute presentation, transaction signing, unlock a door, start engine, etc.5.- The method according to any of claims 1 to 4, wherein the wallet is a multi-type credential wallet able to store identity-related credentials and non-identity credentials such as payment cards and car keys.6.- A wallet application installable into a host computer and configured to in turn store at least one credential, wherein the wallet comprises both a generic application logic setting generic rules such as how to access, retrieve, or transform the attribute credentials, and an action logic engine to enforce the embedded logic of the stored credentials upon receiving attribute requests.7.- A credential to be stored in a wallet application, and usable in the method of claim 1, wherein the credential comprises embedded logic self-asserting its usage set, and signed, by the credential issuer before being onboarded into the wallet.8.- The credential according to claim 7, wherein the embedded logic is a wide embedded logic self-asserting its usage at credential level, and further comprising sub-logics at attribute level.

Images