System and method for digital communication with verifiable origin

Abstract

A method for verifiable digital communication includes storing an evidence registry including sender credentials for one or more senders and deriving from the evidence registry and storing, a verify cache including a data entry for each of the senders that includes a delegate public key, metadata, and a lookup key; receiving a data structure that includes main content, a third-party delegation identifier, message metadata, and a third-party delegate signature over the message metadata; generating a lookup key using the third-party delegation identifier; executing a query on verify cache with the generated lookup key; identifying a lookup key in the verify cache matching the generated lookup key; retrieving a third-party delegate public key from the verify cache; verifying the third-party delegate signature based on third-party delegate public key, and determining the data structure is valid or invalid based on the verification of the third-party delegate signature.

Description

Attorney Docket No. 690219.0008 / 6WOSYSTEM AND METHOD FOR DIGITAL COMMUNICATION WITH VERIFIABLE ORIGIN FIELD

[0001] The present disclosure relates to verifiable digital communication, specifically methods, systems, and computer program products for signing and verification of digital communications with very low latency and very high throughput.BACKGROUND

[0002] Many forms of digital communication allow malicious parties to fake the identity of the party that originates a message, thread, or stream. Phishing and smishing are familiar examples: a hacker uses email or SMS messages, respectively, to impersonate a company with a high reputation and an existing relationship to a customer. Similar attacks can be carried out in the context of VOIP, small-audience web meetings like Zoom® and Microsoft® Teams®, large-scale streamed conferences, over-the-air broadcasts, social media posts, and other digital communications.

[0003] For forty years, the world has had digital signature and certificate technology that's theoretically capable of eliminating this vulnerability. The STIR / SHAKEN initiative is a US example of how this technology could be applied to voice; the DMARC, DKIM, and SPF standards do a similar thing for email. However, this technology has serious limitations, as demonstrated by its poor adoption. For example, this current technology isn't fast enough or scalable enough. Such existing technology is fine for browsers to check the X509 certificate behind amazon.com; a single checkAttorney Docket No. 690219.0008 / 6WOof the certificate chain takes a few internet requests that unfold over milliseconds or seconds, and then the result can be cached by an ISP, a bind server, and the local OS DNS cache, since it is unlikely to change and it is very likely to remain useful for hours, days, or weeks. However, when we are talking about billions of text messages or phone calls per day, associated with many millions of source phone numbers, with authorizations that might be short-lived, doing a 1 -second lookup on each signer, as each communication arrives, is totally impractical. Furthermore, caching, as done in existing technology, more aggressively changes trust: relying parties must trust the party doing the caching, rather than trusting the strong cryptographic evidence.Revocation and delegation patterns make this problem far, far worse. Furthermore, such existing technology has opaque and unreasonable governance. General public certificate authorities are vetted by a small cabal of the world's browser makers, behind closed doors, with little public insight. No private certificate authority (CA) ecosystems have governance strong enough to ensure the quality of cryptographic evidence for general purposes, either. Even if existing governance systems were transparent and strong, all existing approaches to governance are centralized. This is a challenge any time telecommunications cross a boundary that exceeds the scope of the centralized authority. For example, STIR-SHAKEN prescribes certain behaviors to improve assurance on US voice traffic, but it doesn't apply to traffic that originated outside the US. Since much fraud originates in call centers outside the US, US-only governance is fatally flawed. X509 certificates are ill-prepared for post-quantum attackers. Key rotation can invalidate entire chains of certificates, yet key rotation is required for longevity of the strategy. Short-lived certificates have been proposed as aAttorney Docket No. 690219.0008 / 6WOsolution, but this creates an enormous management burden, and it makes the scaling and performance problems worse.

[0004] In the past ten years, the world has seen a shift to decentralized (aka "selfsovereign") identity technologies, including verifiable credentials (VCs) and decentralized identifiers (DIDs). These represent a second-generation solution. VCs can improve on X509 certificates by making possible a far more decentralized and open governance model. DIDs can eliminate fragility by allowing cryptographic evidence to bind to identifiers rather than raw keys, so keys can be rotated without invalidating the evidence of a communication's origin. However, decentralized technologies are still not able to solve the problem of fakeable origin in telecom. Most existing DID methods have security shortcomings (no support for prerotation, not selfcertifying, no witnesses, not cryptographically agile, not ready for post-quantum), or else they rely on a blockchain or some other central authority for their security guarantees. This introduces new centralization problems. Existing DID methods almost universally lack support for multiparty signature schemes which could drastically improve robustness and they generally lack all but the crudest delegation support. The VC spec calls for trusted issuers and provides no way to chain back to a root of trust. Issuers must get their trust from a trust registry, which is once again centralized and opaque. Most seriously, second-generation approaches still do not solve the scale and performance problems. An SMS message consists of just a few hundred bytes as it flows over an SMPP pipeline — but a VC may be 5KB or 10KB in size. Attaching second-generation evidence to each message thus drastically changes the bandwidthAttorney Docket No. 690219.0008 / 6WOrequirements of the SMS delivery pipeline, and forces pervasive upgrades. Worse, the evidence would require the same kind of over-the-internet validation queries that X509 does, making them unacceptably slow.

[0005] Thus, there is an unaddressed need to generate robust evidence of the identity of originators of telecommunications traffic under fully decentralized, transparent governance; reference that evidence at extreme speed and scale; and preserve the evidence under robust, realistic maintenance regimes that upgrade its cybersecurity as cryptography and threats evolve.SUMMARY

[0006] A method for verifiable digital communication, the method including: storing, in a memory of a computing device, an evidence registry, the evidence registry including one or more sender credentials for one or more senders, deriving, by the computing device from the evidence registry, a verify cache, the verify cache including, a data entry for each of the one or more senders, each entry including a delegate public key, metadata that characterizes appropriate communications from a sender, and a lookup key, the lookup key being a combination of the unique third-party delegation identifier and at least one piece of the metadata; storing, in the memory of the computing device, the verify cache; receiving, by the computing device from a communication service provider (CSP) computing device, a data structure, the data structure including main content, a unique third-party delegation identifier, message metadata, and a third-party delegate signature over the message metadata signed with a third-party delegate private key, the message metadata including at least a reference to a senderAttorney Docket No. 690219.0008 / 6WOcredential; generating, by the computing device, a lookup key using the third-party delegation identifier included in the data structure and the message metadata of the data structure; executing, by the computing device, a query on verify cache with the generated lookup key; identifying, by the computing device, a lookup key in the verify cache matching the generated lookup key; retrieving, by the computing device, a third-party delegate public key from the verify cache; verifying, by the computing device, the third-party delegate signature of the data structure based on third-party delegate public key retrieved from the verify cache; and determining, by the computing device, the data structure is valid if the third-party delegate signature is verified, or determining, by the computing device, the data structure is invalid if the third-party delegate signature is not verified or the lookup key is not found.

[0007] A system for verifiable digital communication, the system including a communication service provider (CSP) computing device; and a processing device, the processing device configured to: store, in a memory, an evidence registry, the evidence registry including one or more sender credentials for one or more senders; derive, from the evidence registry, a verify cache, the verify cache including, a data entry for each of the one or more senders, each entry including a delegate public key, metadata that characterizes appropriate communications from a sender, and a lookup key, the lookup key being a combination of the unique third-party delegation identifier and at least one piece of the metadata; store, in the memory, the verify cache; receive, from the communication service provider (CSP) computing device, a data structure, the data structure including main content, a unique third-party delegationAttorney Docket No. 690219.0008 / 6WOidentifier, message metadata, and a third-party delegate signature over the message metadata signed with a third-party delegate private key, the message metadata including at least a reference to a sender credential; generate a lookup key using the third-party delegation identifier included in the data structure and the message metadata of the data structure; execute a query on verify cache with the generated lookup key; identify a lookup key in the verify cache matching the generated lookup key; retrieve a third-party delegate public key from the verify cache; verify the third-party delegate signature of the data structure based on third-party delegate public key retrieved from the verify cache; and determine the data structure is valid if the third-party delegate signature is verified, or determine the data structure is invalid if the third-party delegate signature is not verified or the lookup key is not found.BRIEF DESCRIPTION OF THE DRAWING FIGURES

[0008] The scope of the present disclosure is best understood from the following detailed description of exemplary embodiments when read in conjunction with the accompanying drawings. Included in the drawings are the following figures:

[0009] FIG. 1 is a block diagram illustrating a high-level system architecture for verifiable digital communication in accordance with embodiments;

[0010] FIG. 2 is a block diagram illustrating a verifier computing device in the system of FIG. 1 for verifiable digital communication in accordance with embodiments;

[0011] FIG. 3 is a flow diagram illustrating a process for verifiable digital communication in the system of FIG. 1 in accordance with embodiments;Attorney Docket No. 690219.0008 / 6WO

[0012] FIG. 4 is a block diagram illustrating an example data structure in the system of FIG. 1 for verifiable digital communication in accordance with embodiments;

[0013] FIG. 5 is a flow chart illustrating an exemplary method for verifiable digital communication in accordance with embodiments; and

[0014] FIG. 6 is a block diagram illustrating a computer system architecture in accordance with embodiments.

[0015] Further areas of applicability of the present disclosure will become apparent from the detailed description provided hereinafter. It should be understood that the detailed description of exemplary embodiments is intended for illustration purposes only and are, therefore, not intended to necessarily limit the scope of the disclosure. DETAILED DESCRIPTIONSystem for Verifiable Digital Communication

[0016] FIG. 1 illustrates a system 100 for verifiable digital communication. The system 100 can include sender computing devices 102A-102N, a delegate computing devices 104A-104N, evidence computing devices 106A-106N, verifier computing devices 108A-108N, and a communication service provider (CSP) computing device 110 communicating via network 120.

[0017] The sender computing devices 102A-102N is a computing system, such as illustrated in FIGS. 2 or 6, discussed in more detail below. For example, the sender computing devices 102A-102N may be a server, a desktop computer, a notebook, a laptop computer, a tablet computer, a handheld device, a smart-phone, a thin client, a smartwatch, or any other electronic device or computing system capable of storing,Attorney Docket No. 690219.0008 / 6WOcompiling, and organizing audio, visual, or textual data and receiving and sending that data to and from other computing devices, such as the delegate computing devices 104A-104N, the evidence computing devices 106A-106N, the verifier computing devices 108A-108N, and the communication service provider (CSP) computing device 110 communicating via the network 120. The network 120 can include one or more communication methods, such as radio frequency, local area networks, wireless area networks, cellular communication networks, Bluetooth, the Internet, email, social media, or any other suitable communication network, etc. In embodiments, the sender computing devices 102A-102N may be a computing device sending and / or receiving digital communications to and / or from one or more other sender computing devices 102A-102N via the network 120. For example, sender computing device 102A may be a smart phone and a user of the sender computing device 102A may send a text message, e.g., a short message service (SMS) message, to another user, e.g., a user of the verifier computing device 108A. Further, the sender computing device 102A-102N can store sender credentials issued by the evidence computing devices 106A-106N for the senders operating the sender computing device 102A-102N. The sender credentials are discussed in more detail below with reference to the evidence computing devices 106A-106N. It can be appreciated that in embodiments any number of senders and sender computing devices 102A-102N can be a part of the system 100. The term "sender" and sender computing devices 102A-102N as used herein can refer any originator of communication content including an initiator of a communication interaction and / or any respondent to the originator of the communication interaction. Many communication methodologies allow for two-way or multi-way transfer of data; inAttorney Docket No. 690219.0008 / 6WOsuch cases, any party that communicates is a "sender" as used herein. For example, when a consumer (e.g., sender computing device 102A) calls a telephone number that they believe belongs to their bank, the consumer (e.g., sender computing device 102A) could use this invention to send evidence — but in SIP, the call is connected when the bank sends a 200 OK response, so the bank (e.g., sender computing device 102B) could also use this invention to send evidence the other direction (e.g., to the sender computing device 102A). Similarly, a secure teleconference might be primarily an outbound broadcast — but each joining participant could also use this invention to send evidence the other direction as they authenticate such that each participant controls a sender computing device 102.

[0018] Each of the delegate computing devices 104A-104N is a computing system, such as illustrated in FIG. 6, discussed in more detail below. For example, the delegate computing devices 104A-104N may be a server, a cloud server, a smart contract, or any other electronic device or computing system capable of storing, compiling, and organizing audio, visual, or textual data and receiving and sending that data to and from other computing devices, such the sender computing devices 102A-102N, the evidence computing devices 106A-N, the verifier computing devices 108A-108N, and the communication service provider (CSP) computing device 110 communicating via the network 120. The network 120 can include one or more communication methods, such as radio frequency, local area networks, wireless area networks, cellular communication networks, Bluetooth, the Internet, email, social media, or any other suitable communication network, etc. In embodiments, the delegate computing devices 104A-104N are designated third-party delegates that signAttorney Docket No. 690219.0008 / 6WOdigital communications on behalf of the sender who is using sender computing devices 102A-102N. Each delegate who is using one of the delegate computing devices 104A-104N is designated by each sender who is using sender computing devices 102A-102N. For example, a user of the sender computing device 102A delegates to the delegate using delegate computing device 104A and the delegate computing device 104A can generate a unique third-party delegate identifier for signing digital communications on behalf of the user of the sender computing device 102A. The delegation of signatory authority and generation of the third-party delegate identifier is discussed in more detail below with reference to FIGS. 2-4. It can be appreciated that in embodiments any number of delegate computing devices 104A-104N can be a part of the system 100. For example, the sender computing devices 102A-N can all use the same delegate computing device 104A, each sender computing device 102 can use a different delegate computing device 104, or any combination of the two. In such embodiments where the delegate computing device 104A is a delegate for more than one sender computing device 102, the delegate computing device 104A generates a unique third-party delegate identifier for each sender computing device 102. In embodiments, the delegate computing device 104 can be another sender computing device 102 separate from the sender computing device 102 originating the digital communication. In yet other embodiments, the a sender can delegate their own sender computing device 102 as their delegate. In such embodiments, for example, the sender’s own sender computing device 102A can generate the unique third-party delegate identifier for signing digital communications on behalf of the user of the sender computing device 102A. Therefore, it can be appreciated that while the senderAttorney Docket No. 690219.0008 / 6WOcomputing devices 102A-102N and the delegate computing devices 104A-104N are illustrated and described separately, in some embodiments, the sender computing devices 102A-102N and the delegate computing devices 104A-104N can be the same computing device.

[0019] Each of the evidence computing devices 106A-106N is a computing system, such as illustrated in FIG. 6, discussed in more detail below. For example, the evidence computing devices 106A-N may be a server, a smart contract, a desktop computer, a notebook, a laptop computer, a tablet computer, a handheld device, a smart-phone, a thin client, a smartwatch, or any other electronic device or computing system capable of storing, compiling, and organizing audio, visual, or textual data and receiving and sending that data to and from other computing devices, such the sender computing devices 102A-102N, the delegate computing devices 104A-104N, the verifier computing devices 108A-108N, and the communication service provider (CSP) computing device 110 communicating via the network 120. The network 120 can include one or more communication methods, such as radio frequency, local area networks, wireless area networks, cellular communication networks, Bluetooth, the Internet, email, social networks, or any other suitable communication network, etc. In embodiments, the evidence computing devices 106A-106N may be operated by any suitable credentialing authority, e.g., a certificate authority, that stores, signs, and issues credentials, e.g., digital certificates, for digital communications. For example, the evidence computing devices 106A-N may store, sign, and issue a know-your-business (KYB) identity credentialsthat can be used to prove 1) a sender, e.g., the sender of the sender computing device 102A, possesses credentials proving theAttorney Docket No. 690219.0008 / 6WQsender’s identity, 2) the credentials have a valid schema, field values, and signature, 3) the credentials are signed by (or chain to) trusted parties, and 4) the credentials are not revoked or expired. Identity credentials include, but are not limited to, a verifiable legal entity identifier (vLEI), Aegis vet, Dun & Bradstreet vet, a report from a credit reporting agency, etc. Further, the same or different computing devices 106A-106N may store, sign, and issue qualification credentials that prove 1) the sender, e.g., the sender of the sender computing device 102A possesses credentials proving qualificationto use communication infrastructure in particular ways, 2) the credentials have a valid schema, field values, and signature, 3) the credentials are signed by (or chain to) trusted parties, and 4) the credentials are not revoked or expired.Qualification credentials can include, but are not limited to, campaign credentials, telephone number (TN) credentials, credentials that prove the sender's prior arrangements with a call center or settlement provider, credentials that prove the sender's right to use brand assets, credentials that prove the sender's legal or business certifications, credentials that prove the sender is an approved Al-based agent acting on behalf of its controlling entity, etc, Thus, the evidence computing devices 106A-106N provide the users of the system 100, e.g., the senders of the sender computing devices 102A-102N, with evidence that they control a particular identity, e.g., in the form of identity credentials, and evidence that they are entitled to a specific list of digital communication features, e.g., in the form of qualification credentials. It can be appreciated that in embodiments any number of evidence computing devices 106A-106N can be a part of the system 100 including a single evidence computing device 106 or more than one evidence computing device 106. ForAttorney Docket No. 690219.0008 / 6WOexample, the evidence computing device 106A can issue one type of identity credential, the evidence computing device 106B can issue a second type of identity credential, the evidence computing device 106C can issue one type of qualification credential, and the evidence computing device 106D can issue a second type of qualification credential, etc. Furthermore, a single credential may contain a mixture of identity and qualification data , or may function like an identity credential for the purposes of this invention, even though its information payload is primarily about qualification (thus enabling qualified but minimally identified senders).

[0020] Each of the verifier computing devices 108A-108N is a computing system, such as illustrated in FIGS. 2 and / or 6, discussed in more detail below. For example, the verifier computing devices 108A-108N may be a server, smart contract, desktop computer, a notebook, a laptop computer, a tablet computer, a handheld device, a smart-phone, a thin client, a smartwatch, or any other electronic device or computing system capable of storing, compiling, and organizing audio, visual, or textual data and receiving and sending that data to and from other computing devices, such the sender computing devices 102A-N, the delegate computing devices 104A-104N, the evidence computing devices 106A-N, and the communication service provider (CSP) computing device 110 communicating via the network 120. The network 120 can include one or more communication methods, such as radio frequency, local area networks, wireless area networks, cellular communication networks, Bluetooth, the Internet, or any other suitable communication network, etc. In embodiments, the verifier computing devices 108A-108N are computing systems that create and store an evidence registry, e.g., the evidence registry 203, of pre-verified sender credentials, e.g., the senderAttorney Docket No. 690219.0008 / 6WOcredentials 205, and sender third-party delegations for the users of the system 100, e.g., the sender computing devices 102A-102N. In addition, the verifier computing devices 108A-108N derive from the evidence registry 203 a view of the attributes that would necessarily characterize appropriate communications from an entitled sender, e.g., the sender of the sender computing device 102A, and the public key, e.g., the delegate public key 212, that would be used to verify signatures by the delegate signers, e.g., the delegates of the delegate computing devices 104A-104N, over any specific example of such communications, and caches this derivative data in a highspeed data structure called a verify cache, e.g., the verify cache 206. The verifier computing devices 108A-108N only need to verify the information in the evidence registry 203, e.g., the sender credentials 205 and the unique third-party delegate identifiers, once. The verifier computing devices 108A-108N verify the origin of a digital communication as often as communications are sent, and can be done in an instant, by checking to see if the attributes of the digital communication appear in the verify cache 206 (and if so, checking digital signatures against the corresponding public key). Because of this separation of the verify cache 206 and the evidence registry 203, the embodiments disclosed herein can solve the speed and scale problems that characterize the prior art. Further, because the metadata about a particular communication can be used by the verifier computing devices 108A-108N to look up data in both the verify cache 206 and the evidence registry 203, the verify cache 206 can justify any decisions the verify cache 206 recommends, by comparing the evidence registry 203 to a permanent audit trail, e.g., the audit log 230. For example, the verifier computing device 108A can receive sender credentials, e.g., the senderAttorney Docket No. 690219.0008 / 6WOcredentials 205, from one or more senders of the one or more sender computing devices 102A-102N and create the evidence registry 203 that includes all the sender credentials 205, plus the verify cache 206 derived therefrom. In embodiments, the verifier computing devices 108A-108N can store the sender credentials 205 by hashing the sender credentials 205 and indexing the sender credentials 205 according to the hashes. Further, the verifier computing devices 108A-108N can receive the unique third-party delegate identifiers and third-party delegate public keys 212 from the sender computing devices 102A-102N, the delegate computing devices 104A-104N, the evidence computing devices 106A-106N, and / or any other suitable computing device in the system 100 and the verifier computing devices 108A-108N store each unique third-party delegate identifier and the corresponding third-party delegate public keys 212 in the verify cache 206. For example, the verifier computing device 108A can combine a unique third-party delegate identifier with its corresponding computed appropriate metadata, e.g., asserted brand attributes, a signer hint, a source phone number, and / or a reference to the sender credentials 205, e.g., a hyperlink, to generate a lookup key, e.g., a lookup key 210. The verifier computing device 108A can then use the lookup key 210 to verify that digital communications sent by a sender, e.g., a sender of the sender computing device 102A, match expectations about entitled features (such as the phone number used by the sender) and the verifier computing device 108A can retrieve the third-party delegate public key 212 so a signature can be checked as well. Verification of digital communications is discussed in more detail below with reference to FIGS 2-4. It can be appreciated that in embodiments any number of verifier computing devices 108A-Attorney Docket No. 690219.0008 / 6WO108N can be a part of the system 100. In embodiments, the verifier computing devices 108A-108N can be another sender computing device 102 separate from the sender computing device 102 originating the digital communication.

[0021] The communication service provider (CSP) computing device 110 is a computing system, such as illustrated in FIG. 6, discussed in more detail below. For example, the CSP computing device 110 may be a server or any other electronic device or computing system capable of storing, compiling, and organizing audio, visual, or textual data and receiving and sending that data to and from other computing devices, such the sender computing devices 102A-N, the delegate computing devices 104A-104N, the evidence computing devices 106A-N, and the verifier computing devices 108A-108N communicating via the network 120. The network 120 can include one or more communication methods, such as radio frequency, local area networks, wireless area networks, cellular communication networks, Bluetooth, the Internet, or any other suitable communication network, etc. In embodiments, CSP computing device 110 may be any entity that provides communications services such as, but not limited to, telecommunications, media, entertainment, and applications, etc. For example, but not limited to, the CSP computing device 110 may be a server of a telecommunications entity that manages a cellular communication network and the sender computing devices 102A-N may be cellular devices operating on the cellular communication network managed by the CSP computing device 110. In embodiments, the CSP may also be a device operated directly by a sender acting as their own service provider, and in such embodiments, the sender computing devices 102A-102N may function as the CSP computing device 110. Therefore, it can be appreciated thatAttorney Docket No. 690219.0008 / 6WOin some embodiments, the sender computing devices 102A-102N and the CSP computing device 110 can be the same computing device. It can be appreciated that in embodiments any number of CSP computing devices 110 can be a part of the system 100. For example, the system 100 can include a CSP computing device 110 may be a telecommunication company, a cable company, a digital services company, an internet service provider, etc.

[0022] In embodiments, senders, e.g., the parties using sender computing devices 102A-N, want to sign traffic using evidence such as digital credentials, e.g., the sender credentials 205, that justify a belief that each sender is who they claim to be and that each sender is entitled to send digital communications under certain conditions that can be proved by evidence, e.g., the sender credentials 205. For example, the sender digital credentials 205 can be an organizational know-your-business (KYB) identity credential like a verifiable legal entity identifier (vLEI) and qualification credentials that prove the sender’s right to send the digital communications, e.g., use a particular phone number, an approval for a short message service (SMS) campaign or a subscription to a voice over Internet Protocol (VOIP) service. The specific sender credentials 205 will vary by use case. In embodiments, the sender credentials 205 are issued to the sender’s identifiers, e.g., an automatic identifier (AID), denoted by “X.aid.” The sender credentials 205 can only be used by the sender, e.g., the sender of the sender computing device 102A, because “X.aid” is associated with cryptographic keys, and the sender credentials 205 must be accompanied by signatures from those cryptographic keys whenever it is legitimately used. X.aid can be protected by very stringent signing policies. For example, a multi-signature schemeAttorney Docket No. 690219.0008 / 6WOwhere M of N signers must approve any actions, e.g., delegating signing authority to a delegate computing device 104A, that X, e.g., the sender of the sender computing device 102A, takes. The binding between X and their cryptographic keys and the strong signing policies around X drastically improve resistance to many cybersecurity attacks that plague the prior art. The sender credentials 205 can be efficiently identified by hashes of the content of the sender credentials 205, where that content has been normalized carefully. This facilitates caching, e.g., in the verify cache 206, and enables an efficient link between an entry in the verify cache 206 and the corresponding evidence in the evidence registry 203.

[0023] Information about each sender’s, e.g., the senders of the sender computing devices 102A-102N, sender credentials, e.g., the sender credentials 205, are published. For example, the senders, e.g., the senders of the sender computing devices 102A-102N, themselves can publish the sender credentials 205 and / or the evidence computing devices 106A-N can publish the sender credentials 205. The verifier computing devices 108A-108N, e.g., interested parties that will later verify digital communications from the senders, e.g., the senders of the sender computing devices 102A-102N, discover the publication of the sender credentials 205. For example, the senders, e.g., the senders of the sender computing devices 102A-N and / or the evidence computing devices 106A-N, may issue an event notification notifying the system 100 of the publication of the sender credentials 205. The verifier computing devices 108A-108N can validate the sender credentials 205 and the third-party signer delegation (a slow process that can takes seconds and multiple calls over the internet, e.g., the network 120) and build a registry, e.g., the evidence registry 203,Attorney Docket No. 690219.0008 / 6WOof known valid sender credentials 205. Since the sender credentials 205 describe how the sender, e.g., the sender of one of the sender computing devices 102A-102N, is entitled to send digital communications (e.g., what telephone numbers the sender controls or what types of SMS messages the sender is authorized to transmit), and also which delegate, e.g., delegate of the delegate computing devices 104A-104N, will be signing for the sender, the verification devices 108A-108N can use information in the sender credentials 205 to populate the verify cache 206, discussed in more detail below. The verifier computing devices 108A-108N learn about revoked sender credentials 205 with similar efficiency, allowing the evidence registry 203 and its derived verify cache 206, discussed in more detail below, to be continuously curated.

[0024] Each of the senders, e.g. , the senders of the sender computing devices 102A-102N, of the system 100 delegates to another party, e.g., one of the delegates of the delegate computing devices 104A-104N, the ability to sign digital communications on behalf of the sender. Each of the delegate computing devices 104A-104N, e.g., entity Y, creates a unique third-party delegate identifier, e.g., the unique third-party delegate identifier 210, just for this delegation relationship. This unique third-party delegate identifier can be denoted as “Y.aid-as-X-delegate,” and can be a single-signature identifier managed entirely by automation. The use of the unique third-party delegate identifier allows very efficient signing of digital communications, e.g., a sender’s cumbersome policy does not need to be activated for each signature but each sender, e.g., each sender of the sender computing devices 102A-102N, retains unilateral revocation authority at all times.Attorney Docket No. 690219.0008 / 6WO

[0025] The verifier computing devices 108A-108N learn about each sender’s, e.g., the senders of the sender computing devices 102A-N, delegation to a third-party delegate, e.g., the entities operating the delegate computing devices 104A-104N, any revocations of that delegation, and any key rotations for the sender’s or the delegate’s identifiers, e.g., the unique third-party delegate identifiers 210. Further, the verifier computing devices 108A-108N learn about any revocations in the chain of trust of the evidence, e.g., the sender credentials 205, that resolves back to the governance framework and root of trust for the sender’s credentials, e.g., the sender credentials 205. The verifier computing devices 108A-108N combine the unique third-party delegate identifier 210, e.g., the “Y.aid-as-X-delegate,” with the metadata characterizing appropriate communication by a given sender X, e.g., asserted brand attributes, signer hint, a sender (source) phone number, and a link to the sender credentials 205, e.g., a hyperlink, and uses it to build a lookup key, e.g., the lookup key 210 in a verify cache, e.g., the verify cache 206. Each lookup key 210 in the verify cache, e.g., the verify cache 206, represents a combination of the unique third-party delegate identifier 210, e.g., the ”Y.aid-as-X-delegate,” and metadata for a particular digital communication that matches expectations described by the user’s credentials, e.g., the sender credentials 205. The lookup key 210 is used to find the current public key, e.g., the delegate public key 212, for the third-party delegate, e.g., the delegate operating the delegate computing devices 104A-104N, as well as a reference to evidence stored in the evidence registry 203. The delegate computing devices 104A-104N can have software that is running in a data center of the CSP computing device 110.Attorney Docket No. 690219.0008 / 6WO

[0026] Each of the senders, e.g., the sender computing devices 102A-N, of the system 100 establishes a relationship with the CSP computing device 110. For example, each of the senders, e.g., the sender computing devices 102A-N of the system 100, may create and / or register an account with the CSP computing device 110. Each of the senders, e.g., the sender computing devices 102A-N of the system 100, presents its sender credentials to the CSP computing device 110 to prove that each of the senders, e.g., the sender computing devices 102A-N of the system 100, is allowed to send digital communications. Each of the senders, e.g., the sender computing devices 102A-N of the system 100, also informs the CSP computing device 110 that each of the senders, e.g., the sender computing devices 102A-N of the system 100, has created a relationship with the delegate computing device 104, e.g., as embodied by the unique third-party delegate identifier (“Y.aid-as-X-delegate”).

[0027] When a sender, e.g., the sender of the sender computing device 102A, wants to send digital communications, the sender computing device 102A contacts the CSP computing device 110, and provides message content plus attributes of that digital communication that allows the sender computing device 102A permissions to be assessed. In the case of SMS traffic, for example, the sender computing device 102A could provide a campaign identifier (which links to a campaign credential) plus the source phone number (which would link to a telephone number credential) and a destination phone number. The CSP computing device 110 calls the delegate computing device 104A and requests the delegate computing device 104A to provide an appropriate signature as evidence of the user’s, e.g., the sender computing device 102A, authorship of the digital communication. The delegate computing device 104AAttorney Docket No. 690219.0008 / 6WOlooks up the specific identifier it is using for the delegate-of-X relationship, e.g., the unique third-party delegate identifier (“Y.aid-as-X-delegate”). The delegate computing device 104A then uses its private key for that unique third-party delegate identifier (“Y.aid-as-X-delegate”) to digitally sign over the source and destination phone numbers, a timestamp, and whatever evidence references are asserted by the sender computing device 102A. Optionally, the delegate computing device 104A can maintain an evidence registry, e.g., the evidence registry 203, and verify cache, e.g., the verify cache 206, and the delegate computing device 104A can double-check that the signature is likely to be seen as valid by verifiers, e.g., the verifiers of the verifier computing devices 108A-108N, as a condition of signing. The delegate computing device 104A returns the signature to the CSP computing device 110, which then builds an appropriate digital communication data structure that includes the main content, a claim about the signer's identity (“Y.aid-as-X-delegate”), the signed metadata, and the signature. The digital communication data structure is discussed in more detail below with reference to FIG. 4.

[0028] Any Verifier, e.g., a party operating the verifier computing device 108A, that is downstream of the CSP computing device 110 can verify the signed digital communication by inspecting the metadata in the digital communication data structure. The party operating the verifier computing device 108A retrieves the unique third-party delegate identifier 210, e.g., “Y.aid-as-x-delegate,” and any metadata fields that were used as inputs into the signature generated by the delegate computing device 104A. The party operating the verifier computing device 108A combines the metadata fields that were used as inputs into the signature to compose a lookup key for the verifyAttorney Docket No. 690219.0008 / 6WOcache, e.g., the verify cache 206. The party operating the verifier computing device 108A uses the lookup key to execute a search on the verify cache, e.g., the verify cache 206, to identify a matching lookup key, e.g., the lookup key 210. If no match is found, the combination is invalid, and the digital communication generated by the sender computing device 102A lacks evidence of validity. This determination of invalidity can be reported to the party requesting verification, e.g., the sender of the sender computing device 102A. If a match is found, the verifier computing device 108A retrieves a third-party delegate public key 212, e.g., denoted as “Y aid-as-X-delegate. pubkey,” from the verify cache, e.g., the verify cache 206. The verifier computing device 108A uses the third-party delegate public key 212 to validate the signature that's affixed to the digital communication data structure. If the signature verifies, the digital communication data structure has a provable origin. If the signature does not verify, the digital communication data structure lacks evidence of validity. Crucially, this step requires no queries over the internet, e.g., the network 120.

[0029] The verifier computing devices 108A-108N can record decisions about the validity of the digital communication in a database, e.g., the memory 214, along with a reference to evidence in the evidence registry 203, in a permanent audit log 230.Thus, if someone, e.g., a regulating entity, later asks for justification of decisions, the verifier computing device 108A can provide the item of the verify cache 206 that justified the decision. The reference to the evidence in the evidence registry 203 in that item can be used to resolve the full form of the sender credentials 205 stored in the evidence registry 203. The unique third-party delegate identifier 210, e.g., the “Y.aid-as-X-delegate,” can be also resolved back to the delegation event that empowered Y,Attorney Docket No. 690219.0008 / 6WOe.g. , the delegate computing device 104A to act on X's, e.g., the sender of the sender computing device 102A, behalf. Further, because of the governance framework under which X's, e.g., the sender of the sender computing device 102A, sender credentials 205 were issued, and because of chaining capabilities built into the credential format used by the system 100, the governance itself can be proved, and so can a complete chain of authority back to the root of trust. Further, it can be proved that no sender credentials 205 were known to be revoked at the time the decision was made, and this proof of non-revocation can achieve very low latencies.

[0030] The methods and systems discussed herein provide for verifiable digital communications. The methods and systems discussed herein provide a novel technical solution for digitally signing and verifying digital communications with extreme efficiency by delegating signatory authority to a third-party delegate and maintaining a database linking sender credentials to the third-party delegate.Verifier Computing Device 108

[0031] FIG. 2 illustrates an embodiment of the verifier computing devices 108A-108N. It will be apparent to persons having skill in the relevant art that the embodiment of the computing system 200 illustrated in FIG. 2 is provided as illustration only and cannot be exhaustive to all possible configurations of the computing system 200 suitable for performing the functions as discussed herein. For example, the computer system 500 illustrated in FIG. 6 and discussed in more detail below can be a suitable configuration of the verifier computing devices 108A-108N. Further, as discussed above, the verifier computing devices 108A-108N can be one of the sender computing devices 102A-N;Attorney Docket No. 690219.0008 / 6WOthus, the computer system 200 also illustrates an embodiment of a sender computing devices 102A-102N.

[0032] The verifier computing devices 108A-108N can include a receiving device 202. The receiving device 202 can be configured to receive data over one or more networks via one or more network protocols. In some instances, the receiving device 202 can be configured to receive data from the sender computing devices 102A-102N, the delegate computing devices 104A-104N, the evidence computing devices 106A-106N, the CSP computing device 110, and other systems and entities via one or more communication methods, such as radio frequency, local area networks, wireless area networks, cellular communication networks, Bluetooth, the Internet, etc. In some embodiments, the receiving device 202 can be comprised of multiple devices, such as different receiving devices for receiving data over different networks, such as a first receiving device for receiving data over a local area network and a second receiving device for receiving data via the Internet. The receiving device 202 can receive electronically transmitted data signals, where data can be superimposed or otherwise encoded on the data signal and decoded, parsed, read, or otherwise obtained via receipt of the data signal by the receiving device 202. In some instances, the receiving device 202 can include a parsing module for parsing the received data signal to obtain the data superimposed thereon. For example, the receiving device 202 can include a parser program configured to receive and transform the received data signal into usable input for the functions performed by the processing device to carry out the methods and systems described herein.Attorney Docket No. 690219.0008 / 6WO

[0033] The receiving device 202 can be configured to receive data signals from the sender computing devices 102A-102N, the delegate computing devices 104A-104N, the evidence computing device 106A-106N, and / or the CSP computing device 110 that can be superimposed or otherwise encoded with digital signatures, validation responses, digital communication data structures, sender credentials, verification requests, verification responses, public and / or private keys of cryptographic key pairs, etc.

[0034] The verifier computing devices 108A-108N can also include a communication module 204. The communication module 204 can be configured to transmit data between modules, engines, databases, memories, and other components of the verifier computing device 108 for use in performing the functions discussed herein. The communication module 204 can be comprised of one or more communication types and utilize various communication methods for communications within a computing device. For example, the communication module 204 can be comprised of a bus, contact pin connectors, wires, etc. In some embodiments, the communication module 204 can also be configured to communicate between internal components of the verifier computing devices 108A-108N and external components of the verifier computing devices 108A-108N, such as externally connected databases, display devices, input devices, etc. The verifier computing devices 108A-108N can also include a processing device. The processing device can be configured to perform the functions of the verifier computing devices 108A-108N discussed herein as will be apparent to persons having skill in the relevant art. In some embodiments, the processing device can include and / or be comprised of a plurality of engines and / orAttorney Docket No. 690219.0008 / 6WOmodules specially configured to perform one or more functions of the processing device, such as a querying module 216, generation module 218, validation module 220, etc. As used herein, the term “module” can be software or hardware particularly programmed to receive an input, perform one or more processes using the input, and provides an output. The input, output, and processes performed by various modules will be apparent to one skilled in the art based upon the present disclosure.

[0035] The verifier computing devices 108A-108N also include an evidence registry 203. The evidence registry 203 can be configured to store data using suitable data formatting methods and schema and can be any suitable type of memory, such as read-only memory, random access memory, etc. The evidence registry 203 can include sender credentials 205 of the senders, e.g., the operators of the sender computing devices 102A-102N.

[0036] The verifier computing devices 108A-108N also include verify cache 206. The verify cache 206 can be configured to store data using suitable data formatting methods and schema and can be any suitable type of memory, such as read-only memory, random access memory, etc. The verify cache 206 can include one or more entries 208A-208N. Each of the one or more entries 208A-208N can include a lookup key 210, a delegate public key 212, and sender credentials reference 213, e.g., one or more pieces of metadata that would characterize authorized communications from the sender, such as, a sender (source) telephone number, a signer hint, sender brand assets, and / or a link to a particular set of credential evidence.

[0037] The verifier computing devices 108A-108N can also include a memory 214. The memory 214 can be configured to store data for use by the verifier computingAttorney Docket No. 690219.0008 / 6WOdevices 108A-108N in performing the functions discussed herein, such as public and private keys, symmetric keys, the audit log 230, etc. The memory 214 can be configured to store data using suitable data formatting methods and schema and can be any suitable type of memory, such as read-only memory, random access memory, etc. The memory 214 can include, for example, decisions regarding validity of digital communications (e.g., the audit log 230), encryption keys and algorithms, communication protocols and standards, data formatting standards and protocols, program code for modules and application programs of the processing device, and other data that can be suitable for use by the verifier computing devices 108A-108N in the performance of the functions disclosed herein as will be apparent to persons having skill in the relevant art. In some embodiments, the memory 214 can be comprised of or can otherwise include a relational database that utilizes structured query language for the storage, identification, modifying, updating, accessing, etc. of structured data sets stored therein.

[0038] The verifier computing devices 108A-108N can include a querying module 216. The querying module 216 can be configured to execute queries on databases to identify information. The querying module 216 can receive one or more data values or query strings and can execute a query string based thereon on an indicated database, such as the verify cache 206 of the verifier computing device 108 to identify information stored therein. The querying module 216 can then output the identified information to an appropriate engine or module of the verifier computing device 108 as necessary. The querying module 216 can, for example, execute a query on the verifyAttorney Docket No. 690219.0008 / 6WOcache 206 to identify and verify sender credentials and unique third-party delegate identifiers.

[0039] The verifier computing devices 108A-108N can also include a generation module 218. The generation module 218 can be configured to generate data for use by the verifier computing device 108 in performing the functions discussed herein. The generation module 218 can receive instructions as input, can generate data based on the instructions, and can output the generated data to one or more modules of the verifier computing device 108. For example, the generation module 218 can be configured to generate digital signatures, lookup keys, digital communication data structures, database queries, e.g., queries on the verify cache 206, unique third-party delegate identifiers, sender credentials, etc.

[0040] The verifier computing devices 108A-108N can also include a validation module 220. The validation module 220 can be configured to perform data validations and verifications for the verifier computing device 108 as part of the functions discussed herein. The validation module 220 can receive instructions as input, can perform data validations or verification as instructed, and can output a result of the data validations or verifications to one or more modules of the verifier computing device 108. In some cases, the input can include the data to be validated or verified and / or data to be used in the validation or verification. In other cases, the validation module 220 can be configured to identify such data, such as in the verify cache 206 and / or memory 214. The validation module 220 can be configured to, for example, verify digital signatures, sender credentials, unique third-party delegate identifiers, digital communication data structures, etc.Attorney Docket No. 690219.0008 / 6WO

[0041] The verifier computing devices 108A-108N can also include a transmitting device 222. The transmitting device 222 can be configured to transmit data over one or more networks via one or more network protocols. In some instances, the transmitting device 222 can be configured to transmit data to the sender computing devices 102A-102N, the delegate computing devices 104A-104N, the evidence computing devices 106A-106N, the CSP computing device 110, and other systems and entities via one or more communication methods, local area networks, wireless area networks, cellular communication, Bluetooth, radio frequency, the Internet, etc. In some embodiments, the transmitting device 222 can be comprised of multiple devices, such as different transmitting devices for transmitting data over different networks, such as a first transmitting device for transmitting data over a local area network and a second transmitting device for transmitting data via the Internet. The transmitting device 222 can electronically transmit data signals that have data superimposed that can be parsed by a receiving computing device. In some instances, the transmitting device 222 can include one or more modules for superimposing, encoding, or otherwise formatting data into data signals suitable for transmission.

[0042] The transmitting device 222 can be configured to electronically transmit data signals to the sender computing devices 102A-102N, the delegate computing devices 104A-104N, the evidence computing devices 106A-106N, and / or the CSP computing device 110 that can be superimposed or otherwise encoded with digital signatures, validation responses, digital communication data structures, sender credentials, verification requests, verification responses, public and / or private keys of cryptographic key pairs, etc.Attorney Docket No. 690219.0008 / 6WOProcess for Verifiable Digital Communication

[0043] FIG. 3 illustrates a process in the system 100 of FIG. 1 for verifiable digital communication.

[0044] In step 302, a sender, e.g., sender of the sender computing device 102A, stores one or more sender credentials 205. The one or more sender credentials 205 can include one or more identity credentials and / or qualification credentials issued by the evidence computing devices 106A-N.

[0045] In step 304, the sender, e.g., the sender of the sender computing device 102A, generates a digital communication to be sent to another user, e.g., a user of the verifier computing device 108A. In embodiments, the digital communication can be a short message service (SMS) message. In other embodiments, the digital communication may be a digital content request to be sent to a digital content provider. The digital communication includes at least message content, message metadata, sender credentials 205, and a third-party identifier, e.g., a unique third-party delegate identifier of the delegate computing device 104A. The digital communication may also contain a reference that can be used to look up evidence, e.g., the sender credentials 205, about the sender or the sender’s entitlements. In the case of SMS traffic, for example, the sender, e.g., the sender of the sender computing device 102A, could provide a campaign identifier that links to a campaign credential, the source phone number that links to a telephone number credential and a destination phone number.

[0046] In step 306, the sender, e.g., the sender of the sender computing device 102A, transmits the digital communication to the CSP computing device 110. In step 308, theAttorney Docket No. 690219.0008 / 6WOCSP computing device 110 receives the digital communication from the sender, e.g., the sender of the sender computing device 102A.

[0047] In step 310, the CSP computing device 110 identifies a delegate, e.g., the party operating the delegate computing device 104A, for the sender, e.g., the sender of the sender computing device 102A, and the CSP computing device 110 generates a signing request asking the delegate, e.g., the party operating the delegate computing device 104A, to provide an appropriate signature, e.g., a digital signature, as evidence of the sender’s authorship of the digital communication in step 312. The CSP computing device 110 transmits the signing request to the identified delegate, e.g., the party operating the delegate computing device 104A, in step 314. In embodiments where the sender computing device 102A and the CSP computing device 110 are the same computing device, steps 306-310 can be performed by the sender computing device 102A.

[0048] In step 316, the delegate, e.g., the party operating the delegate computing device 104A, receives the signing request from the CSP computing device 110. In step 318, the delegate, e.g., the party operating the delegate computing device 104A, identifies the unique third-party delegate identifier (e.g., Y.aid-as-X-delegate) for the sender, e.g., the sender of the sender computing device 102A. For example, the delegate, e.g., the party operating the delegate computing device 104A, can maintain a database that stores all the unique third-party delegate identifiers that the delegate uses for each of the one or more senders of the system 100, e.g., the senders of the sender computing devices 102A-N. In another example, the delegate, e.g., the party operating the delegate computing device 104A, may execute a query on a databaseAttorney Docket No. 690219.0008 / 6WOmaintained by another computing device of the system 100, e.g., the CSP computing device 110, to identify the unique third-party delegate identifier the delegate, e g., the party operating the delegate computing device 104A, uses for a particular sender, e.g., the sender of the sender computing device 102A.

[0049] In step 320, the delegate, e.g., the party operating the delegate computing device 104A, then uses a private key of a delegate cryptographic key pair for the identified unique third-party delegate identifier to sign the digital communication. For example, if the digital communication is SMS traffic, the delegate, e.g., the party operating the delegate computing device 104A, uses the private key to sign over the source phone number, a timestamp, and whatever evidence is being provided that the sender, e.g., the sender of the sender computing device 102A is authorized. In embodiments, the evidence is being provided that the sender, e.g., the sender of the sender computing device 102A, is authorized to use the sender credentials 205 included in the digital communication. In step 322, the delegate, e.g., the party operating the delegate computing device 104A, transmits the signed digital communication to the CSP computing device 110. Referring to FIG 4, an example signed data structure 350 is illustrated. The signed data structure 350 includes timestamp field 352, unique third-party delegate identifier field 354, delegate signature 356, evidence identifier field 358, and message content fields 360. The message content fields 358 can include, but are not limited to, a source telephone number, a destination telephone number, and message content, etc.

[0050] Referring back to FIG 3, in step 324, the CSP computing device 110 receives the signed digital communication from the delegate, e.g., the party operating theAttorney Docket No. 690219.0008 / 6WOdelegate computing device 104A. In step 326, the CSP computing device 110 generates a data structure based on the signed digital communication. The data structure includes the message content, a claim about the delegate’s identity (e.g., the unique third-party delegate identifier (e.g., Y.aid-as-X-delegate)), the signed metadata, and the delegate’s signature. In step 328, the CSP computing device 110 transmits the data structure to a verifier, e.g., the verifier computing device 108A, to validate the data structure. In step 330, the verifier, e.g., the party operating the verifier computing device 108A, receives the data structure from the CSP computing device 110. In embodiments, the CSP 110 transmits the data structure through the network 120, e.g., a cellular communications network, and the verifier computing device 108A intercepts the data structure to validate the data structure.

[0051] In step 332 the verifier, e.g., the party operating the verifier computing device 108A, generates a lookup key by combining the delegate’s unique third-party identifier 210 (e.g., Y.aid-as-x-delegate) and the metadata fields included in the signature of the data structure. Continuing with the example above, the verifier, e.g., the party operating the verifier computing device 108A, combines the delegate’s unique third-party identifier 210 (e.g., Y.aid-as-x-delegate) with one or more of the source phone number, the timestamp, and references to the sender’s evidence, e.g., a way to look up the sender credentials 205 of the sender of the sender computing device 102A. In step 334, the verifier, e.g., the party operating the verifier computing device 108A, executes a query on the verify cache 206 to identify a lookup key 210 that matches the generated lookup key. If a match is found in step 336, the verifier, e.g., the party operating the verifier computing device 108A, retrieves the delegate’s public key 212Attorney Docket No. 690219.0008 / 6WO(e.g., Y.aid-as-X-delegate. pubkey) from the verify cache 206, e.g., the public key of the delegate operating the delegate computing device 104A in step 338. If no match is found in step 336, the data structure is determined to be invalid, and the process proceeds to step 342 and the verifier, e.g., the party operating the verifier computing device 108A, records the invalid determination. For example, the verifier, e.g., the party operating the verifier computing device 108A, records the invalid determination in the audit log 230 in the memory 214.

[0052] In step 340, the verifier, e.g., the party operating the verifier computing device 108A, validates the data structure using the delegate’s public key 212 (e.g., Y.aid-as-X-delegate. pubkey) and records the validation determination in step 342. For example, the verifier, e.g., the party operating the verifier computing device 108, records the valid determination in the audit log 230 in the memory 214.Exemplary Method for Verifiable Digital Communication

[0053] FIG. 5 illustrates a method 400 the system 100 of FIG. 1 for verifiable digital communication.

[0054] In step 402, a processing device (e.g., the verifier computing device 108A) stores an evidence registry (e.g., the evidence registry 203). The evidence registry (e.g., the evidence registry 203) can include the digital credentials (e.g., the sender credentials 210) of the sender, e.g., the sender of the sender computing device 102A. The sender credentials (e.g., the sender credentials 205) can include, but is not limited to, an identity credential such as a verifiable legal entity identifier (vLEI), and / or a qualification credential such as a campaign credential.Attorney Docket No. 690219.0008 / 6WO

[0055] In step 404, the processing device (e.g., the verifier computing device 108A) derives a verify cache (e.g., the verify cache 206) from the evidence registry (e.g., the evidence registry 203). The verify cache 206 can include lookup keys (e.g., the lookup keys 208), third-party delegation identifier (e.g., the unique third-party delegate identifiers (e.g., Y.aid-as-x-delegate)) of the delegates, e.g., the delegates of the delegate computing devices 104A-104N, references to hashes of the sender credentials (e.g., the sender credentials 205), delegate public keys (e.g., the delegate public keys 212), and one or more pieces of metadata that would characterize authorized communications from the sender. The processing device (e.g., the verifier computing device 108A) stores verify cache (e.g., the verify cache 206) in step 406.

[0056] In step 406, the processing device (e.g., the verifier computing device 108A) receives (e.g., via the receiving device 202) a data structure from the CSP computing device 110. The data structure can include main content, a third-party delegation identifier (e.g., the unique third-party delegate identifier (e.g., Y.aid-as-x-delegate)), message metadata, and a third-party delegate signature over the message metadata signed with a third-party delegate private key (e.g., the delegate private key 212). The message metadata includes at least a reference to a sender credential (e.g., the sender credential 205) of the sender, e.g., the sender of the sender computing device 102A. The main content can be a short message service (SMS) message and the message metadata can include at least a source phone number and a timestamp.

[0057] In step 410, the processing device (e.g., the verifier computing device 108A) generates (e.g., via the generation module 218) a lookup key using the third-party delegation identifier (e.g., the unique third-party delegate identifier (e.g., Y.aid-as-x-Attorney Docket No. 690219.0008 / 6WOdelegate)) included in the data structure and the sender credential (e.g., the sender credential 205) included in the message metadata of the data structure. In step 412, the processing device (e.g., the verifier computing device 108A) executes a query (e.g., via the querying module 216) on the verify cache (e.g., the verify cache 206) with the generated lookup key. In step 414, the processing device (e.g., the verifier computing device 108A) identifies (e.g., via the querying module 216) a lookup key (e.g., the lookup key 210) in the verify cache (e.g., the verify cache 206) matching the generated lookup key.

[0058] In step 416, the processing device (e.g., the verifier computing device 108A) retrieves (e.g., via the querying module 216) a third-party delegate public key (e.g., the delegate public key 212) from the verify cache (e.g., the verify cache 206) and verifies, in step 418, (e.g., via the validation module 220) the third-party delegate signature of the data structure based on third-party delegate public key retrieved (e.g., the delegate public key 212) from the verify cache (e.g., the verify cache 206).

[0059] In step 420, the processing device (e.g., the verifier computing device 108A) determines if the data structure is valid. If the third-party delegate signature is verified, the processing device (e.g., the verifier computing device 108A) validates (e.g., via the validation module 220) the data structure. If the third-party delegate signature is not verified, the processing device (e.g., the verifier computing device 108A) determines (e.g., via the validation module 220) the data structure in invalid or the lookup key (e.g., the lookup key 210) is not found. The method 400 can further include recording the result of the data structure validation in a database (e.g., the verify cache 206).Attorney Docket No. 690219.0008 / 6WO

[0060] In the method 400 the data structure is generated by the CSP computing device 110 and generation of the data structure can include receiving, by the CSP computing device 110, from a sender via a sender computing device (e.g., the sender computing device 102A), message content, message metadata, sender credentials (e.g., sender credentials 210), and a third-party delegate identifier (e.g., the unique third-party delegate identifier (e.g., Y.aid-as-x-delegate)). The CSP computing device 110 can identify a third-party delegate (e.g., the party operating the delegate computing device 104A) based on the third-party delegate identifier (e.g., the unique third-party delegate identifier (e.g., Y.aid-as-x-delegate)) received from the sender via the sender computing device (e.g., the sender computing device 102A) and generate a verification request to verify the sender of the sender computing device (e.g., the sender computing device 102A). The verification request can include the message content, the message metadata, and the sender credentials (e.g., the sender credentials 205). The CSP computing device 110 can transmit the verification request to the identified third-party delegate (e.g., the party operating the delegate computing device 104A). The CSP computing device 110 can receive, from the identified third-party delegate (e.g., the party operating the delegate computing device 104A), a third-party delegate signature over the message metadata and the sender credentials (e.g., the sender credentials 205). The third-party delegate signature can be generated by the delegate computing device 104A using a third-party delegate private key. The CSP computing device 110 can generate the data structure.Computer System ArchitectureAttorney Docket No. 690219.0008 / 6WO

[0061] FIG. 5 illustrates a computer system 500 in which embodiments of the present disclosure, or portions thereof, can be implemented as computer-readable code. For example, the sender computing devices 102A-N, the delegate computing devices 104A-104N, the evidence computing devices 106A-N, the verifier computing devices 108A-108N, and the communication service provider (CSP) computing device 110 can be implemented in the computer system 500 using hardware, non-transitory computer readable media having instructions stored thereon, or a combination thereof and can be implemented in one or more computer systems or other processing systems. Hardware can embody modules and components used to implement the methods of FIGS. 3 and 5.

[0062] If programmable logic is used, such logic can execute on a commercially available processing platform configured by executable software code to become a specific purpose computer or a special purpose device (e.g., programmable logic array, application-specific integrated circuit, etc.). A person having ordinary skill in the art can appreciate that embodiments of the disclosed subject matter can be practiced with various computer system configurations, including multi-core multiprocessor systems, minicomputers, mainframe computers, computers linked or clustered with distributed functions, as well as pervasive or miniature computers that can be embedded into virtually any device. For instance, at least one processor device and a memory can be used to implement the above-described embodiments.

[0063] A processor unit or device as discussed herein can be a single processor, a plurality of processors, or combinations thereof. Processor devices can have one or more processor “cores.” The terms “computer program medium,” “non-transitoryAttorney Docket No. 690219.0008 / 6WOcomputer readable medium,” and “computer usable medium” as discussed herein are used to generally refer to tangible media such as a removable storage unit 518, a removable storage unit 522, and a hard disk installed in hard disk drive 512.

[0064] Various embodiments of the present disclosure are described in terms of this example computer system 500. After reading this description, it will become apparent to a person skilled in the relevant art how to implement the present disclosure using other computer systems and / or computer architectures. Although operations can be described as a sequential process, some of the operations can in fact be performed in parallel, concurrently, and / or in a distributed environment, and with program code stored locally or remotely for access by single or multi-processor machines. In addition, in some embodiments the order of operations can be rearranged without departing from the spirit of the disclosed subject matter.

[0065] Processor device 504 can be a special purpose or a general-purpose processor device specifically configured to perform the functions discussed herein. The processor device 504 can be connected to a communications infrastructure 506, such as a bus, message queue, network, multi-core message-passing scheme, etc. The network can be any network suitable for performing the functions as disclosed herein and can include a local area network (LAN), a wide area network (WAN), a wireless network (e.g., WiFi), a mobile communication network, a satellite network, the Internet, fiber optic, coaxial cable, infrared, radio frequency (RF), or any combination thereof. Other suitable network types and configurations will be apparent to persons having skill in the relevant art. The computer system 500 can also include a main memory 508 (e.g., random access memory, read-only memory, etc.), and can alsoAttorney Docket No. 690219.0008 / 6WOinclude a secondary memory 510. The secondary memory 510 can include the hard disk drive 512 and a removable storage drive 514, such as a floppy disk drive, a magnetic tape drive, an optical disk drive, a flash memory, etc.

[0066] The removable storage drive 514 can read from and / or write to the removable storage unit 518 in a well-known manner. The removable storage unit 518 can include a removable storage media that can be read by and written to by the removable storage drive 514. For example, if the removable storage drive 514 is a floppy disk drive or universal serial bus port, the removable storage unit 518 can be a floppy disk or portable flash drive, respectively. In one embodiment, the removable storage unit 518 can be non-transitory computer readable recording media.

[0067] In some embodiments, the secondary memory 510 can include alternative means for allowing computer programs or other instructions to be loaded into the computer system 500, for example, the removable storage unit 522 and an interface 520. Examples of such means can include a program cartridge and cartridge interface (e.g., as found in video game systems), a removable memory chip (e.g., EEPROM, PROM, etc.) and associated socket, and other removable storage units 522 and interfaces 520 as will be apparent to persons having skill in the relevant art.

[0068] Data stored in the computer system 500 (e.g., in the main memory 508 and / or the secondary memory 510) can be stored on any type of suitable computer readable media, such as optical storage (e.g., a compact disc, digital versatile disc, Blu-ray disc, etc.) or magnetic tape storage (e.g., a hard disk drive). The data can be configured in any type of suitable database configuration, such as a relational database, a structured query language (SQL) database, a distributed database, anAttorney Docket No. 690219.0008 / 6WOobject database, etc. Suitable configurations and storage types will be apparent to persons having skill in the relevant art.

[0069] The computer system 500 can also include a communications interface 524. The communications interface 524 can be configured to allow software and data to be transferred between the computer system 500 and external devices. Exemplary communications interfaces 524 can include a modem, a network interface (e.g., an Ethernet card), a communications port, a PCMCIA slot and card, etc. Software and data transferred via the communications interface 524 can be in the form of signals, which can be electronic, electromagnetic, optical, or other signals as will be apparent to persons having skill in the relevant art. The signals can travel via a communications path 526, which can be configured to carry the signals and can be implemented using wire, cable, fiber optics, a phone line, a cellular phone link, a radio frequency link, etc.

[0070] The computer system 500 can further include a display interface 502. The display interface 502 can be configured to allow data to be transferred between the computer system 500 and external display 530. Exemplary display interfaces 502 can include high-definition multimedia interface (HDMI), digital visual interface (DVI), video graphics array (VGA), etc. The display 530 can be any suitable type of display for displaying data transmitted via the display interface 502 of the computer system 500, including a cathode ray tube (CRT) display, liquid crystal display (LCD), light-emitting diode (LED) display, capacitive touch display, thin-film transistor (TFT) display, etc.

[0071] Computer program medium and computer usable medium can refer to memories, such as the main memory 508 and secondary memory 510, which can be memory semiconductors (e.g., DRAMs, etc.). These computer program products canAttorney Docket No. 690219.0008 / 6WObe means for providing software to the computer system 500. Computer programs (e.g., computer control logic) can be stored in the main memory 508 and / or the secondary memory 510. Computer programs can also be received via the communications interface 524. Such computer programs, when executed, can enable computer system 500 to implement the present methods as discussed herein. In particular, the computer programs, when executed, can enable processor device 504 to implement the methods illustrated by FIGS. 3 and 5, as discussed herein.Accordingly, such computer programs can represent controllers of the computer system 500. Where the present disclosure is implemented using software, the software can be stored in a computer program product and loaded into the computer system 500 using the removable storage drive 514, interface 520, and hard disk drive 512, or communications interface 524.

[0072] The processor device 504 can comprise one or more modules or engines configured to perform the functions of the computer system 500. Each of the modules or engines can be implemented using hardware and, in some instances, can also utilize software, such as corresponding to program code and / or programs stored in the main memory 508 or secondary memory 510. In such instances, program code can be compiled by the processor device 504 (e.g., by a compiling module or engine) prior to execution by the hardware of the computer system 500. For example, the program code can be source code written in a programming language that is translated into a lower-level language, such as assembly language or machine code, for execution by the processor device 504 and / or any additional hardware components of the computer system 500. The process of compiling can include the use of lexical analysis,Attorney Docket No. 690219.0008 / 6WOpreprocessing, parsing, semantic analysis, syntax-directed translation, code generation, code optimization, and any other techniques that can be suitable for translation of program code into a lower-level language suitable for controlling the computer system 500 to perform the functions disclosed herein. It will be apparent to persons having skill in the relevant art that such processes result in the computer system 500 being a specially configured computer system 500 uniquely programmed to perform the functions discussed above.

[0073] Techniques consistent with the present disclosure provide, among other features, systems and methods for verifiable digital communication. While various exemplary embodiments of the disclosed system and method have been described above it should be understood that they have been presented for purposes of example only, not limitations. It is not exhaustive and does not limit the disclosure to the precise form disclosed. Modifications and variations are possible in light of the above teachings or can be acquired from practicing of the disclosure, without departing from the breadth or scope.

Claims

Attorney Docket No. 690219.0008 / 6WOWHAT IS CLAIMED IS:

1. A method for verifiable digital communication, comprising:storing, in a memory of a computing device, an evidence registry, the evidence registry including one or more sender credentials for one or more senders, deriving, by the computing device from the evidence registry, a verify cache, the verify cache including, a data entry for each of the one or more senders, each entry including a delegate public key, metadata that characterizes appropriate communications from a sender, and a lookup key, the lookup key being a combination of the unique third-party delegation identifier and at least one piece of the metadata;storing, in the memory of the computing device, the verify cache; receiving, by the computing device from a communication service provider (CSP) computing device, a data structure, the data structure including main content, a unique third-party delegation identifier, message metadata, and a third-party delegate signature over the message metadata signed with a third-party delegate private key, the message metadata including at least a reference to a sender credential;generating, by the computing device, a lookup key using the third-party delegation identifier included in the data structure and the message metadata of the data structure;executing, by the computing device, a query on verify cache with the generated lookup key;identifying, by the computing device, a lookup key in the verify cache matching the generated lookup key;Attorney Docket No. 690219.0008 / 6WOretrieving, by the computing device, a third-party delegate public key from the verify cache;verifying, by the computing device, the third-party delegate signature of the data structure based on third-party delegate public key retrieved from the verify cache; and determining, by the computing device, the data structure is valid if the third-party delegate signature is verified, or determining, by the computing device, the data structure is invalid if the third-party delegate signature is not verified or the lookup key is not found.

2. The method of claim 1 further comprising:recording, by the computing device, the determination of the data structure validation in an audit log.

3. The method of claim 1 , wherein the data structure is generated by the CSP computing device, the generation of the data structure including:receiving, by the CSP computing device from a sender computing device, message content, message metadata, and a third-party delegate identifier;identifying, by the CSP computing device, a third-party delegate based on the third-party delegate identifier received from the sender computing device;Attorney Docket No. 690219.0008 / 6WOgenerating, by the CSP computing device, a verification request to verify the sender computing device, the verification request including the message content, and the message metadata;transmitting, by the CSP computing device, the verification request to the identified third-party delegate;receiving, by the CSP computing device, from the identified third-party delegate, a third-party delegate signature over the message metadata and, the third-party delegate signature generated using a third-party delegate private key; andgenerating, by the CSP computing device, the data structure.

4. The method of claim 3, wherein the CSP computing device receives a reference to the sender credential from the sender computing device, and wherein the verification request include the reference to the sender credential.

5. The method of claim 1 , wherein the one or more sender credentials includes at least an identity credential and / or a qualification credential.

6. The method of claim 5, wherein the identity credential is a legal entity verifiable legal entity identifier (LEvLEI) and the qualification credential is a telephone number credential.Attorney Docket No. 690219.0008 / 6WO7. The method of claim 1 , wherein the main content is a short message service (SMS) message.

8. The method of claim 1 , wherein the main content is an SIP header in VIOP traffic.

9. The method of claim 1 , wherein the message metadata includes at least a source phone number and a timestamp.

10. A system for verifiable digital communication, comprising:a communication service provider (CSP) computing device; anda processing device, the processing device configured to:store, in a memory, an evidence registry, the evidence registry including one or more sender credentials for one or more senders,derive, from the evidence registry, a verify cache, the verify cache including, a data entry for each of the one or more senders, each entry including a delegate public key, metadata that characterizes appropriate communications from a sender, and a lookup key, the lookup key being a combination of the unique third-party delegation identifier and at least one piece of the metadata;store, in the memory, the verify cache;receive, from the communication service provider (CSP) computing device, a data structure, the data structure including main content, a uniqueAttorney Docket No. 690219.0008 / 6WOthird-party delegation identifier, message metadata, and a third-party delegate signature over the message metadata signed with a third-party delegate private key, the message metadata including at least a reference to a sender credential;generate a lookup key using the third-party delegation identifier included in the data structure and the message metadata of the data structure;execute a query on verify cache with the generated lookup key; identify a lookup key in the verify cache matching the generated lookup key;retrieve a third-party delegate public key from the verify cache; verify the third-party delegate signature of the data structure based on third-party delegate public key retrieved from the verify cache; and determine the data structure is valid if the third-party delegate signature is verified, or determine the data structure is invalid if the third-party delegate signature is not verified or the lookup key is not found.

11. The system of claim 10 where the processing device is further configured to:record the determination of the data structure validation in an audit log.

12. The system of claim 10, wherein the data structure is generated by the CSP computing device, the generation of the data structure including the CSP computing device configured to:Attorney Docket No. 690219.0008 / 6WOreceive, from a sender computing device, message content, message metadata, and a third-party delegate identifier;identify a third-party delegate based on the third-party delegate identifier received from the sender computing device;generate a verification request to verify the sender computing device, the verification request including the message content, and the message metadata;transmit the verification request to the identified third-party delegate; receive, from the identified third-party delegate, a third-party delegate signature over the message metadata and, the third-party delegate signature generated using a third-party delegate private key; andgenerate the data structure.

13. The system of claim 12, wherein the CSP computing device receives a reference to the sender credential from the sender computing device, and wherein the verification request include the reference to the sender credential.

14. The system of claim 10, wherein the one or more sender credentials includes at least an identity credential and / or a qualification credential.

15. The system of claim 14, wherein the identity credential is a legal entity verifiable legal entity identifier (LEvLEI) and the qualification credential is a telephone number credential.Attorney Docket No. 690219.0008 / 6WO16. The system of claim 10, wherein the main content is a short message service (SMS) message.

17. The system of claim 10, wherein the main content is an SIP header in VIOP traffic.

18. The system of claim 10, wherein the message metadata includes at least a source phone number and a timestamp.

Images