Broadcast intent signaling using decentralized networks

Abstract

Embodiments disclosed herein relate to a computing system and method for broadcasting the intent of a first user to a second user of a decentralized network. The computing system and method are implemented in a decentralized network that implements a distributed ledger that supports one or more decentralized identities (DIDs) of one or more users of the computing system. An intent is received from a first user of the computing system. The intent data defines a potential interaction between the first user and a second user of the computing system. A broadcast message is generated. The broadcast message includes the DID of each of the first users and information specifying the potential interaction. The generated broadcast message is provided to the second user.

Description

Background Art

[0001] Most documents or records used to prove identity are issued by centralized organizations, such as governments, schools, employers, or other service centers or regulatory organizations. These organizations usually maintain the identity of each member in a centralized identity management system. A centralized identity management system is a centralized information system used to organize and manage issued identities, their authentication, authorization, roles, and privileges. Centralized identity management systems are considered secure because they usually use professionally maintained hardware and software. Typically, the identity issuing organization will establish the terms and requirements for registering people in the organization. Finally, when one party needs to verify the identity of another party, the verifying party often needs to obtain information to verify and / or authenticate the identity of the other party through a centralized identity management system.

[0002] A decentralized identifier (DID) is a new type of identifier that is independent of any centralized registry, identity provider, or certificate authority. Distributed ledger technology (such as blockchain) provides the opportunity to use fully decentralized identifiers. Distributed ledger technology uses a global distributed ledger to record transactions between two or more parties in a verifiable manner. Once a transaction is recorded, the data in that portion of the ledger cannot be retroactively changed without changing all subsequent ledger portions, which provides a fairly secure platform. In a broader sense, a DID can also include DID methods that specify how clients register, replace, rotate, and / or recover keys. DID methods can also set key expiration dates.

[0003] The subject matter claimed herein is not limited to embodiments that solve any disadvantages or that operate only in environments such as those described above. Rather, this background is merely provided to illustrate one exemplary technology area where some embodiments described herein may be practiced. Summary of the invention

[0004] This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter.

[0005] Embodiments disclosed herein relate to a computing system and method for broadcasting an intent of a first user to a second user of a decentralized network. The computing system and method are implemented in a decentralized network that implements a distributed ledger that supports one or more decentralized identities (DIDs) of one or more users of the computing system. An intent is received from a first user of the computing system. The intent data defines a potential interaction between the first user and a second user of the computing system. A broadcast message is generated. The broadcast message includes the DID of each of the first users and information specifying the potential interaction. The generated broadcast message is provided to the second user.

[0006] Additional features and advantages will be set forth in the description that follows, and in part will be apparent from the description, or may be learned through the practice of the teachings herein. The features and advantages of the present invention may be realized and obtained by the instructions and combinations specifically indicated in the appended claims. The features of the present invention will become more apparent from the following description and the appended claims, or may be learned through the practice of the present invention as described below. BRIEF DESCRIPTION OF THE DRAWINGS

[0007] In order to describe the manner in which the above-recited and other advantages and features are obtained, a more particular description of the subject matter briefly described above will be rendered by reference to specific embodiments illustrated in the accompanying drawings. Understanding that these drawings depict only typical embodiments and are not therefore to be considered limiting of scope, the embodiments will be described and explained with additional specificity and detail through the use of the accompanying drawings, in which:

[0008] Figure 1 An example computing system is shown in which the principles described herein may be employed;

[0009] Figure 2 An example environment for creating a decentralized identity (DID) is shown;

[0010] Figure 3 An example environment of a DID identity hub is shown;

[0011] Figure 4 An embodiment for broadcasting a first user's intent to a second user of a decentralized network is shown; and

[0012] Figure 5 A flow chart illustrating an example method for broadcasting an intent of a first user to a second user of a decentralized network. DETAILED DESCRIPTION

[0013] Embodiments disclosed herein relate to a computing system and method for broadcasting an intent of a first user to a second user of a decentralized network. The computing system and method are implemented in a decentralized network that implements a distributed ledger that supports one or more decentralized identities (DIDs) of one or more users of the computing system. An intent is received from a first user of the computing system. The intent data defines a potential interaction between the first user and a second user of the computing system. A broadcast message is generated. The broadcast message includes the DID of each first user and information specifying the potential interaction. The generated broadcast message is provided to the second user.

[0014] Embodiments disclosed herein provide a technological advancement relative to traditional systems that do not utilize a distributed network using decentralized identifiers. For example, embodiments disclosed herein allow a computing system to generate a broadcast message that broadcasts the intention of a first user to interact with a second user in a particular manner. These interactions may be for the purpose of selling or purchasing a product or service. They may also interact with the second user in some other way, such as collaborating on a research product. These broadcast messages may be of interest to the second user and may be provided to them and then used to facilitate communication between the first user and the second user. This is a technological advancement because parties that otherwise may not know each other are now able to communicate with each other. This advantageously provides enhanced markets and other platforms in which the first user and the second user can interact with each other in new ways.

[0015] Because the principles described herein can be implemented in the context of a computing system, Figure 1 Some introductory discussion describing the computing system. This description then returns to the principles of the DID platform for the remaining figures.

[0016] Computing systems now increasingly take many forms. A computing system may be, for example, a handheld device, an appliance, a laptop computer, a desktop computer, a mainframe, a distributed computing system, a data center, or even a device that is not traditionally considered a computing system, such as a wearable device (e.g., glasses). In this specification and claims, the term "computing system" is broadly defined to include any device or system (or combination thereof) that includes at least one physical and tangible processor, and a physical and tangible memory that can have computer executable instructions that can be executed by the processor thereon. The memory may take any form and may depend on the nature and form of the computing system. The computing system may be distributed in a network environment and may include multiple constituent computing systems.

[0017] like Figure 1As shown, in its most basic configuration, computing system 100 typically includes at least one hardware processing unit 102 and memory 104. Processing unit 102 may include a general-purpose processor and may also include a field programmable gate array (FPGA), an application-specific integrated circuit (ASIC), or any other dedicated circuit. Memory 104 may be physical system memory, which may be volatile, non-volatile, or some combination of the two. The term "memory" may also be used herein to refer to non-volatile mass storage such as physical storage media. If the computing system is distributed, processing, memory, and / or storage capabilities may also be distributed.

[0018] Computing system 100 also has a number of structures on it that are generally referred to as "executable components." For example, memory 104 of computing system 100 is shown as including executable component 106. The term "executable component" is a name for a structure that is well known to those of ordinary skill in the computing arts as a structure that can be software, hardware, or a combination thereof. For example, when implemented in software, one of ordinary skill in the art will understand that the structure of an executable component may include a software object, routine, method, etc. that can be executed on a computing system, whether or not such executable component is present in a stack of the computing system, or whether or not the executable component is present on a computer-readable storage medium.

[0019] In this case, one of ordinary skill in the art will recognize that the structure of the executable component exists on a computer-readable medium so that when interpreted by one or more processors of a computing system (e.g., by a processor thread), the computing system is caused to perform a function. Such structure can be directly computer-readable by the processor (as is the case if the executable component is a binary file). Alternatively, the structure can be constructed to be interpretable and / or compiled (whether in a single stage or in multiple stages) to generate such a binary file that can be directly interpreted by the processor. When the term "executable component" is used, this understanding of the example structure of an executable component is well within the understanding of one of ordinary skill in the computing arts.

[0020] The term "executable component" is also well understood by those of ordinary skill to include structures such as hard-coded or hard-wired logic gates that are implemented exclusively or almost exclusively in hardware, such as in a field programmable gate array (FPGA), an application specific integrated circuit (ASIC), or any other special circuit. Therefore, the term "executable component" is a term for structures understood by those of ordinary skill in the computing field, whether implemented in software, hardware, or a combination. In this description, the terms "component", "agent", "manager", "service", "engine", "module", "virtual machine", etc. may also be used. As used in this specification and cases, these terms (whether expressed using modifying clauses or not) are also intended to be synonymous with the term "executable component" and therefore also have structures that are well understood by those of ordinary skill in the computing field.

[0021] In the following description, embodiments are described with reference to actions performed by one or more computing systems. If such actions are implemented in software, one or more processors (of the associated computing system that performs the action) direct the operation of the computing system in response to having executed the computer executable instructions constituting the executable components. For example, such computer executable instructions may be embodied in one or more computer readable media forming a computer program product. An example of such operations involves data manipulation. If such behavior is implemented exclusively or almost exclusively in hardware, such as in an FPGA or ASIC, the computer executable instructions may be hard-coded or hard-wired logic gates. The computer executable instructions (and manipulated data) may be stored in a memory 104 of the computing system 100. The computing system 100 may also include a communication channel 108 that allows the computing system 100 to communicate with other computing systems via, for example, a network 110.

[0022] Although not all computing systems require a user interface, in some embodiments, the computing system 100 includes a user interface system 112 for interfacing with a user. The user interface system 112 may include an output mechanism 112A and an input mechanism 112B. The principles described herein are not limited to the precise output mechanism 112A or input mechanism 112B, as this will depend on the nature of the device. However, the output mechanism 112A may include, for example, a speaker, a display, a tactile output, a hologram, etc. Examples of the input mechanism 112B may include, for example, a microphone, a touch screen, a hologram, a camera, a keyboard, a mouse for other pointer input, any type of sensor, and the like.

[0023] The embodiments described herein may include or utilize a dedicated or general-purpose computing system including computer hardware, such as, for example, one or more processors and system memory, as discussed in more detail below. The embodiments described herein also include physical and other computer-readable media for carrying or storing computer-executable instructions and / or data structures. Such computer-readable media may be any available media accessible by a general-purpose or special-purpose computing system. The computer-readable medium storing computer-executable instructions is a physical storage medium. The computer-readable medium carrying computer-executable instructions is a transmission medium. Therefore, by way of example and not limitation, embodiments of the present invention may include at least two distinct computer-readable media: a storage medium and a transmission medium.

[0024] Computer-readable storage media includes RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other physical and tangible storage media that can be used to store the desired program code components in the form of computer-executable instructions or data structures and can be accessed by a general or special purpose computing system.

[0025] A "network" is defined as one or more data links that enable electronic data to be transmitted between computing systems and / or modules and / or other electronic devices. When information is transmitted or provided to a computing system via a network or other communication connection (hardwired, wireless, or a combination of hardwired or wireless), the computing system properly treats the connection as a transmission medium. The transmission medium may include a network and / or data links that can be used to carry the required program code components in the form of computer executable instructions or data structures and can be accessed by general or special computing systems. Combinations of the above should also be included within the scope of computer-readable media.

[0026] In addition, upon reaching various computing system components, program code components in the form of computer executable instructions or data structures can be automatically transferred from the transmission medium to the storage medium (or vice versa). For example, computer executable instructions or data structures received over a network or data link can be buffered in RAM within a network interface module (e.g., "NIC") and then ultimately transferred to the computing system RAM and / or low-volatility storage media at the computing system. Therefore, it should be understood that storage media can be included in computing system components that also (or even primarily) utilize transmission media.

[0027] Computer executable instructions include, for example, instructions and data that, when executed at a processor, cause a general purpose computing system, a special purpose computing system, or a special purpose processing device to perform a specific function or group of functions. Alternatively or additionally, the computer executable instructions may configure a computing system to perform a specific function or group of functions. Computer executable instructions may be, for example, binary files or even instructions that have undergone some translation (e.g., compilation) before being directly executed by a processor, such as intermediate format instructions, such as assembly language, or even source code.

[0028] Although the subject matter has been described in language specific to structural features and / or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the features or acts described above. Rather, the described features and acts are disclosed as example forms of implementing the claims.

[0029] Those skilled in the art will appreciate that the present invention can be implemented in a network computing environment with various types of computing system configurations, including personal computers, desktop computers, laptop computers, message processors, handheld devices, multiprocessor systems, microprocessor-based or programmable consumer electronics, network PCs, minicomputers, mainframe computers, mobile phones, PDAs, pagers, routers, switches, data centers, wearable devices (such as glasses), etc. The present invention can also be implemented in a distributed system environment, where local and remote computing systems perform tasks through a network link (through a hardwired data link, a wireless data link, or a combination of a hardwired and wireless data link). In a distributed system environment, program modules can be located in local and remote memory storage devices.

[0030] Those skilled in the art will also appreciate that the present invention may be practiced in a cloud computing environment. A cloud computing environment may be distributed, although this is not required. When distributed, a cloud computing environment may be distributed internationally within an organization and / or have components owned across multiple organizations. In this specification and in the claims that follow, "cloud computing" is defined as a model for enabling on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services). The definition of "cloud computing" is not limited to any of the other numerous advantages that may be derived from such a model when properly deployed.

[0031] The remaining figures may discuss various computing systems that may correspond to the previously described computing system 100. The computing systems of the remaining figures include various components or functional blocks that can implement various embodiments disclosed herein as will be explained. The various components or functional blocks can be implemented on a local computing system or can be implemented on a distributed computing system that includes elements residing in the cloud or implementing aspects of cloud computing. The various components or functional blocks can be implemented as software, hardware, or a combination of software and hardware. The computing systems in the remaining figures may include more or fewer components than those shown in the figures, and certain components may be combined as appropriate. Although not necessarily shown, the various components of the computing system may access and / or utilize processors and memories, such as processor 102 and memory 104, as needed to perform their various functions.

[0032] Now about Figure 2 Give some introductory discussion of decentralized identities (DIDs) and the environments in which they are created and reside. Figure 2 As shown, DID owner 201 may own or control DID 205, which represents the identity of DID owner 201. DID owner 201 may register a DID using a creation and registration service, which will be explained in more detail below.

[0033] DID owner 201 may be any entity that can benefit from a DID. For example, DID owner 201 may be a human or a human organization. Such organizations may include companies, departments, governments, institutions, or any other organization or group of organizations. Each person may have a DID, and the organization(s) to which each person belongs may also have a DID.

[0034] DID owner 201 may alternatively be a machine, system or device, or a collection of (multiple) machines, (multiple) devices and / or (multiple) systems. In other embodiments, DID owner 201 may be a sub-part of a machine, system or device. For example, a device may be a printed circuit board, where the sub-parts of the circuit board are the individual components of the circuit board. In such an embodiment, a machine or device may have a DID and each sub-component may also have a DID. DID owner may also be a software component, such as described above with respect to Figure 1 An example of a complex executable component 106 may be an artificial intelligence. An artificial intelligence may also have a DID.

[0035] Thus, DID owner 201 may be any reasonable entity, human or non-human, that is capable of creating a DID 205 or at least has a DID 205 created for them and associated with them. Although DID owner 201 is shown as having a single DID 205, this is not the case, as there may be any number of DIDs associated with DID owner 201, depending on the circumstances.

[0036] As described above, DID owner 201 can create and register DID 205. DID 205 can be any identifier that can be associated with DID owner 201. Preferably, the identifier is unique to the DID owner 201, at least in the scope of the expected use of the DID. For example, the identifier can be a locally unique identifier, and it may be more desirable to be a globally unique identifier for identity systems that are expected to operate globally. In some embodiments, DID 205 can be a uniform resource identifier (URI) (such as a uniform resource locator (URL)) or other pointer that associates DID owner 201 with a mechanism for participating in a trusted interaction with DID owner 201.

[0037] DID 205 is "decentralized" because it does not require a centralized third-party management system for generation, management, or use. Therefore, DID 205 remains under the control of DID owner 201. This is different from traditional centralized IDs that are based on centralized authority trust and are still under the control of enterprise directory services, certificate authorities, domain name registries, or other centralized authorities (collectively referred to as "centralized authorities" in this article). Therefore, DID 205 can be any identifier that is under the control of DID owner 201 and independent of any centralized authority.

[0038] In some embodiments, the structure of DID 205 can be as simple as a username or some other human-understandable term. However, in other embodiments, to improve security, DID 205 may preferably be a random string of numbers and letters. In one embodiment, DID 205 may be a string of 128 letters and numbers. Therefore, the embodiments disclosed herein do not rely on any specific implementation of DID 205. In a very simple example, DID 205 is shown as "123ABC".

[0039] Also like Figure 2 As shown, DID owner 201 controls a private key 206 and a public key 207 pair associated with DID 205. Because DID 205 is independent of any centralized authority, private key 206 should always be under the full control of DID owner 201. That is, the private key and public key should be generated in a decentralized manner to ensure that they are always under the control of DID owner 201.

[0040] As will be described in more detail below, the private key 206 and public key 207 pair may be generated on a device controlled by the DID owner 201. Therefore, the private key 206 and public key 207 pair should not be generated on a server controlled by any central authority, as this may result in the private key 206 and public key 207 pair not always being completely under the control of the DID owner 201. Figure 2 While this description describes private and public key pairs, it should also be noted that other types of reasonable cryptographic information and / or mechanisms may also be used depending on the circumstances.

[0041] Figure 2 Also shown is a DID document 210 associated with DID 205. As will be explained in more detail below, DID document 210 may be generated when DID 205 is created. DID document 210, in its simplest form, describes how to use DID 205. Thus, DID document 210 includes a reference to DID 205, which is the DID described by DID document 210. In some embodiments, DID document 210 may be implemented according to a method specified by a distributed ledger 220, which is to be used to store representations of DID 205, as will be explained in more detail below. Thus, DID document 210 may have different methods depending on the particular distributed ledger.

[0042] DID document 210 also includes a public key 207 or some other equivalent cryptographic information created by DID owner 201. Public key 207 can be used by third-party entities that obtain permission from DID owner 201 to access information and data owned by DID owner 201. Public key 207 can also be used to verify that DID owner 201 actually owns or controls DID 205.

[0043] DID document 210 may also include authentication information 211. Authentication information 211 may specify one or more mechanisms by which DID owner 201 is able to prove that DID owner 201 owns DID 205. In other words, the mechanisms of authentication information 211 may show proof of the binding between DID 205 (and therefore it's DID owner 201) and DID document 210. In one embodiment, authentication information 211 may specify that public key 207 is used in a signing operation to prove ownership of DID 205. Alternatively or additionally, authentication information 211 may specify that public key 207 is used in a biometric operation to prove ownership of DID 205. Thus, authentication information 211 may include any number of mechanisms by which DID owner 201 is able to prove that DID owner 201 owns DID 205.

[0044] The DID document 210 may also include authorization information 212. The authorization information 212 may allow the DID owner 201 to authorize a third-party entity to modify the DID document 210 or portions of the document without giving the third party the right to prove ownership of the DID 205. For example, the authorization information 212 may allow the third party to update any specified set of one or more fields in the DID document 210 using any specified update mechanism. Alternatively, the authorization information may allow the third party to limit the use of the DID 205 by the DID owner 201 for a specified period of time. This may be useful when the DID owner 201 is a minor child and the third party is the child's parent or guardian. The authorization information 212 may allow the parent or guardian to limit the use of the DID 201 until the child is no longer a minor.

[0045] The authorization information 212 may also specify one or more mechanisms that the third party will need to follow to prove that they are authorized to modify the DID document 210. In some embodiments, these mechanisms may be similar to those discussed above with respect to the authentication information 211.

[0046] The DID document 210 may also include one or more service endpoints 213. A service endpoint may include a network address at which a service operates on behalf of the DID owner 201. Examples of specific services include discovery services, social networks, file storage services such as identity servers or hubs, and verifiable claims repository services. Thus, the service endpoints 213 serve as pointers to services that operate on behalf of the DID owner 201. The DID owner 201 or a third-party entity may use these pointers to access services that operate on behalf of the DID owner 201. Specific examples of service endpoints 213 will be explained in more detail below.

[0047] The DID document 210 may also include identification information 214. The identification information 214 may include personally identifiable information, such as the name, address, occupation, family members, age, hobbies, interests, etc. of the DID owner 201. Thus, the identification information 214 listed in the DID document 210 may represent different roles of the DID owner 201 for different purposes. For example, the role may be pseudo-anonymous, for example, the DID owner 201 may include a pseudonym in the DID document when identifying him or her as the author of an article published on a blog; the role may be completely anonymous, for example, the DID owner 201 may only want to disclose his or her position or other background data (e.g., school teacher, FBI agent, adult over 21 years old, etc.), but not disclose his or her name in the DID file; and the role may be specific to who the DID owner 201 is as an individual, for example, the DID owner 201 may include identifying him or her as a volunteer for a specific charity organization, an employee of a specific company, a winner of a specific award, etc.

[0048] The DID document 210 may also include credential information 215, which may also be referred to herein as a certification. The credential information 215 may be any information associated with the background of the DID owner 201. For example, the credential information 215 may be (but is not limited to) qualifications, achievements, government IDs, government entitlements such as a passport or driver's license, payment providers or bank accounts, college degrees or other educational history, employment status and history, or any other information about the background of the DID owner 201.

[0049] The DID document 210 may also include various other information 216. In some embodiments, the other information 216 may include metadata specifying when the DID document 210 was created and / or when it was last modified. In other embodiments, the other information 216 may include a cryptographic proof of the integrity of the DID document 210. In further embodiments, the other information 216 may include additional information specified by a particular method of implementing the DID document or desired by the DID owner 201.

[0050] Figure 2 A distributed ledger or blockchain 220 is also shown. The distributed ledger 220 can be any decentralized, distributed network including various computing systems that communicate with each other. For example, the distributed ledger 220 can include a first distributed computing system 230, a second distributed computing system 240, a third distributed computing system 250, and any number of additional distributed computing systems as shown by ellipsis 260. The distributed ledger or blockchain 220 can operate according to any known standard or method for distributed ledgers. Examples of conventional distributed ledgers that can correspond to the distributed ledger or blockchain 220 include, but are not limited to, Bitcoin [BTC], Ethereum, and Litecoin.

[0051] In the context of DID 205, a distributed ledger or blockchain 220 is used to store a representation of DID 205 pointing to DID document 210. In some embodiments, DID document 210 may be stored on an actual distributed ledger. Alternatively, in other embodiments, DID document 210 may be stored in a data store (not shown) associated with distributed ledger or blockchain 220.

[0052] As described above, a representation of DID 205 is stored on each distributed computing system of the distributed ledger or blockchain 220. For example, in Figure 2This is shown as DID hash 231, DID hash 241, and DID hash 251, which are ideally identical copies of the same DID. DID hash 231, DID hash 241, and DID hash 251 can then point to the location of DID document 210. Distributed ledger or blockchain 220 can also store many other representations of other DIDs, as shown by reference numerals 232, 233, 234, 242, 243, 244, 252, 253, and 254.

[0053] In one embodiment, when DID user 201 creates DID 205 and associated DID document 210, DID hash 231, DID hash 241, and DID hash 251 are written to distributed ledger or blockchain 220. Distributed ledger or blockchain 220 thus records that DID 205 is now deregistered. Because distributed ledger or blockchain 220 is decentralized, DID 205 is not controlled by any entity other than DID owner 201. In addition to a pointer to DID document 210, DID hash 231, DID hash 241, and DID hash 251 may include a record or timestamp specifying when DID 205 was created. When DID document 210 is modified later, this may also be recorded in DID hash 231, DID hash 241, and DID hash 251. DID hash 231 , DID hash 241 , and DID hash 251 may also include a copy of public key 207 , such that DID 205 is cryptographically bound to DID document 210 .

[0054] Figure 3 An embodiment of an environment 300 in which a DID such as DID 205 may be utilized is shown. Specifically, environment 300 will be used to describe the use of DID 205 associated with one or more decentralized storage devices or identity hubs. It should be noted that Figure 3 This may include first Figure 2 Reference to the elements discussed therefore uses the same reference numerals for ease of explanation.

[0055] like Figure 3As shown, environment 300 includes various storage devices or identity hubs 310 associated with DID owner 201. For example, storage devices or identity hubs 310 may include a first identity hub 311, a second identity hub 312, a third identity hub 313, and a fourth identity hub 314. Ellipses 315 indicate that there may be any number of additional storage devices or identity hubs, as appropriate. It should be noted that identity hub 310 is considered a decentralized storage device because, as will be explained in more detail below, the identity hub can be addressed through the use of DID 205 and its corresponding DID document 210. In addition, although the identity hub may be hosted by a third party, all access to the identity hub is based on permissions determined by DID owner 201.

[0056] In one embodiment, the first identity hub 311 can be implemented at a first cloud storage provider, the second identity hub 312 can be implemented at a second cloud storage provider, the third identity hub 313 can be implemented as part of a home computing system, and the fourth identity hub 314 can be implemented as part of a mobile device. Therefore, the various identity hubs 310 can be implemented across different service providers, such as two different cloud storage providers. In addition, the various identity hubs 310 can be implemented as a combination of storage provided by a third party such as two cloud storage providers and storage devices owned by the DID owner 201 such as a home computing system and a mobile device. Of course, the various identity hubs 310 can be implemented as other storage devices and services depending on the circumstances.

[0057] In one embodiment, identity hub 310 can be multiple instances of the same identity hub. This is represented by line 310A. Therefore, various identity hubs 310 can include at least some of the same data and services. Therefore, if any changes are made to one of the identity hubs 310, the changes can be reflected in the remaining identity hubs. For example, the first identity hub 311 and the second identity hub 412 are implemented in cloud storage and may therefore be able to save a large amount of data. Therefore, a complete data set can be stored in these identity hubs. However, identity hubs 312 and 313 may have less storage space. Therefore, in these identity hubs, descriptors of the data stored in the first identity hub and the second identity hub may be included. Alternatively, a record of changes made to the data in other identity hubs may be included. Therefore, either the changes in one of the identity hubs 310 are fully replicated in the other identity hubs, or at least a record or descriptor of the data is recorded in the other identity hubs.

[0058] Because identity hubs can be multiple instances of the same identity hub, a complete description of only the first identity hub 311 will be provided, as the description may also apply to identity hubs 312-315. As shown, identity hub 311 may include a data storage device 320. Data storage device 320 may be used to store any type of data associated with DID owner 201. In one embodiment, the data may be a collection 322 of a specific type of data corresponding to a specific protocol. For example, collection 322 may be medical record data corresponding to a specific protocol for medical data. Collection 322 may be any other type of data.

[0059] The data storage device 320 may also store attribute data 321. The attribute data may include attribute information describing various interests and preferences of the DID owner 201. For example, such attribute information may include the DID owner's 201 favorite food, favorite sports, favorite hobbies, favorite vacation spots, favorite entertainment, etc. Therefore, the attribute data 321 about the DID owner 201 may be information provided by the DID owner 201 or it may be information flashed from an interaction with a third party.

[0060] In some embodiments, the data store may also include telemetry data that includes information about the data usage of the DID owner 201. For example, the telemetry data may include data about which websites the DID owner 201 visits, how long he or she visits the websites, and which devices are used to visit the websites. The telemetry data may also include data about which products the DID owner 201 purchases and where they are purchased. Thus, the telemetry data may be any data about the usage patterns of the DID owner 201.

[0061] In some embodiments, identity hub 311 may have a permission module 330 that allows DID owner 201 to set specific authorizations or permissions for third parties, such as third parties 301 and 302, to access the identity hub. For example, DID owner 201 may provide his or her spouse with access permissions to all data 320. Alternatively, DID owner 201 may allow access to his or her doctor to obtain any medical records. It should be understood that DID owner 201 may allow any number of third parties to access a subset of data 320. This will be explained in more detail below.

[0062] For example, a first subset of data may have a permission that allows the data to be exposed publicly but does not include any authentication of the DID owner 201. This type of data may be used for relatively unimportant data, such as color schemes, etc. A second subset of data may have a permission that allows the data to be exposed publicly and includes authentication of the DID owner 201. A third subset of data may have a permission to encrypt a subset of data using a private key 206 and a public key 207 pair (or some other key pair) associated with the DID owner 201. This type of data will require a party to have access to the public key 207 or some other associated public key in order to decrypt the data. The process may also include authentication of the DID owner 201. A fourth subset of data may have a permission that limits the data to a third-party subset. This may require the use of a public key associated with the third-party subset to decrypt the data. For example, the DID owner 201 may allow the permission to specify that only a public key associated with a friend of the DID owner 201 can decrypt the data.

[0063] In some embodiments, the identity hub 311 may include a proof store 340 that includes various proofs 341, 342, and any number of additional proofs associated with the DID owner 201, as indicated by ellipsis 343. Proofs may also be referred to as credentials or verified credentials, such as the credential 215 of the DID document 210. That is, proofs or verified credentials may provide information about the DID owner 201 and / or about various entities that interact with the DID owner 201. As previously described, proof 340 may be (but is not limited to) qualifications, achievements, government IDs, government entitlements such as passports or driver's licenses, payment providers or bank accounts, college degrees or other educational history, employment status and history, or any other information about the background of the DID owner 201. Thus, proof 340 may be used to verify the identity of the DID owner 201.

[0064] The identity hub 311 may also have a messaging module 345. In operation, the messaging module allows the identity hub to receive messages, such as requests from parties such as third parties 301 and 302 to access data and services of the identity hub. In addition, the messaging module 345 allows the identity hub 311 to respond to messages from third parties and also communicate with the DID resolver 350. The DID resolver 350 may be a service, application, or module that is configured to search the distributed ledger or blockchain 220 for a DID document associated with the DID in operation. Thus, in this embodiment, the DID resolver 350 may search the distributed ledger or blockchain 220 using the DID 205, which may result in the DID resolver 350 finding the DID document 210. The ellipsis 316 indicates that the identity hub 311 may have additional services, as the situation warrants.

[0065] In an example embodiment, DID owner 201 may provide DID 205 to third-party entity 301 so that the third party may access data or services stored on identity hub 311. Once third party 301 has access to DID 205, he or she may access DID resolver 350 to access DID document 210. As previously described, DID document 210 may include endpoint 213, which is an address or pointer to identity hub 311. Third party 301 may then access identity hub 311 using the address or pointer.

[0066] The third party 301 may send a message to the messaging module 345 requesting permission to access the data in the identity hub 311. The messaging module 345 may then send a message to the DID owner 201 asking whether the third party 301 should be allowed to access the data. Because the DID owner 201 desires to provide access to the data, the DID owner 201 may allow the third party 301's permission, and the permission may be recorded in the permission 330.

[0067] The messaging module 345 can then send a message to the third party 301, notifying the third party that he or she can access the data. The identity hub 311 and the third party 301 can then communicate directly, allowing the third party to access the data. It should be noted that in many cases, it is actually the identity hub associated with the third party 301 that is communicating with the identity hub 311. However, it may be the device of the third party 301 that is communicating.

[0068] Advantageously, the above process allows the identity hub 311 and third parties 301 to communicate and share data without requiring the third party to access the identity hub 311 in a conventional manner. Instead, communication is provided in a decentralized manner using the DID 205 and DID document 210. This advantageously allows the DID owner to fully control the process.

[0069] like Figure 3 As shown, third party 302 may also request permission to access identity hub 311 using DID 205 and DID document 210. Thus, embodiments disclosed herein allow access to any number of third-party identity hubs 310.

[0070] Figure 4 An embodiment of an environment 400 in which a DID such as DID 205 may be utilized is shown. Specifically, environment 400 will be used to describe the use of DID 205 in connection with an intent broadcast service. It should be noted that Figure 4 This may include first Figure 2-3 Reference to the elements discussed therefore uses the same reference numerals for ease of explanation.

[0071] As shown, in addition to DID owner 201, environment 400 also includes user 410, user 420, user 430, and any number of additional users, as indicated by ellipsis 405. Figure 4 As shown, user 410 may own or control DID 411, user 420 may own or control DID 421, and user 430 may own or control DID 431. It will be noted that DID 411, DID 421, and DID 431 are generated and stored on the distributed ledger or blockchain 220 in the manner previously described for DID 205. Therefore, users 410, 420, and 430 may also have DID documents associated with their respective DIDs, and may also have one or more identity hubs that include proofs that can be used to verify the identities of users 410, 420, and 430. Therefore, the DID documents and identity hubs associated with users 410, 420, and 430 may be similar to the DID documents 210 and identity hubs 310 previously described with respect to DID owner 201, and therefore do not require further detailed explanation. Although not shown, each of users 405 may also have an associated DID and DID document. It will also be noted that users 410, 420, and 430 (as well as user 405) may be human users, institutional users such as businesses or organizations, or any other type of reasonable owner.

[0072] As shown, DID owner 201 can control management module 401. Management module 401 can be used by DID owner 201 to generate DID 205 and can be an example of a DID wallet, etc. Management module 401 can be implanted on one or more devices owned or used by DID owner 201, such as a smartphone or computer. As previously described, DID owner 201 can also access identity hub 311 (or any identity hub 310).

[0073] In some embodiments, DID owner 201 may desire to broadcast intent data 402 to one or more of users 410, 420, 430 (or possibly any of users 405), indicating that DID owner 201 desires to interact with one or more other users. For example, DID owner 201 may desire to buy or sell a product or service. Alternatively, DID owner 201 may desire to meet or collaborate with one or more of other users in a non-commercial manner such as a social interaction such as a date. Therefore, intent data 402 can be about any type of interaction that DID owner 201 desires to have with one or more of users 410, 420, 430 (or possibly any of users 405). Therefore, the embodiments disclosed herein are not limited to any particular type of interaction desired by DID owner 201 as the subject of intent data 402.

[0074] In some embodiments, intent data 402 may be published or generated by DID owner 201 in his or her ID hub 311. In other embodiments, intent data 402 may be published or generated by DID owner 201 in management module 401. In this manner, those users who receive notification of intent data 402 from a broadcast service may communicate with ID hub 311 or management module 401 to access intent information 402, as will be explained in more detail below.

[0075] Intent data 402 may include intent information 403 that may specify information about the intent. For example, intent information 403a may specify the subject of the intent, or in other words, the type of interaction that DID owner 201 desires. For example, intent information may specify a particular product or service that DID owner 201 wants to buy or sell. For example, if DID owner 201 is a gardener, intent information 403a may specify that he or she is providing gardening services or that he or she is looking to buy some equipment or hire an employee. Alternatively, if DID owner 201 is interested in collaborating with another user on a research project, intent information 403a may specify information about the research project.

[0076] Intent data 402 may also include intent information 403b, which may provide information on how to interact with DID owner 201 so that one or more of users 410, 420, and 430 can interact with DID owner 201 in a desired manner. For example, intent information 403b may specify how to specifically communicate the user's desire to purchase or sell a product or service specified by intent information 403a to DID owner 201. Intent information 403b may also specify what actions are required to complete the interaction specified by intent information 403a.

[0077] In some embodiments, the intent data 402 may also include proofs 340, which include the previously described proofs 341 and 342. The inclusion of one or more proofs 340 may allow the DID owner 201 to verify that he or she is capable of providing the service or product specified in the intent information 403a. For example, if the DID owner 201 is a gardener, then one or more proofs 340 may prove that he or she is, in fact, a gardener. If the DID owner 201 expects to collaborate on a research project, then the proof 340 may prove that he or she is qualified to conduct such research. Therefore, the inclusion of proofs 340 in the intent data 402 provides verification about the DID owner 201 that may be helpful to one of the users 410, 420, and 430. The embodiments disclosed herein are not limited to any particular proof included in the intent data 402, as all types of proofs are considered.

[0078] In some embodiments, the intent data 402 may also include attribute data 321, which includes attributes 321a and 321b. As previously described, the attribute data 321 may include further information about the DID owner 201. In the embodiments disclosed herein, the attribute data 321 may be used to provide additional information about the DID owner 201 related to the subject of the intent specified in the intent information 403a. For example, if the DID owner 201 is a gardener, one or more attributes 321 may specify that the DID owner conducts business in Seattle, Washington. The attribute may also specify the time when he or she performs gardening and landscaping. In this way, any one of the users 410, 420, or 430 who access the intent data 402 and need gardening and landscaping services but do not live in Seattle or want a gardener who is more experienced than the DID owner 201 will know that the DID owner 201 may not be the person who provides such services. The embodiments disclosed herein are not limited by any specific attributes included in the intent data 402, because all types of attributes are considered.

[0079] As shown, environment 400 includes data broadcast service 440. In one embodiment, data broadcast service 440 may be implemented by a third party, such as a provider of DID management module 401 and / or a provider of identity hub 310. In some embodiments, data broadcast service 440 may be hosted on a server computer separate from DID owner 201 or any device owned by users 410, 420, and 430. In other embodiments, data broadcast service may be hosted by management module 401 on a device owned by DID owner 201.

[0080] As shown, data broadcast service 440 may include DID 445. DID 445 may be generated and stored on distributed ledger or blockchain 220 in the manner previously described for DID 205. Although not shown, DID 445 may also be associated with a corresponding DID document that defines how to use DID 445 in a manner similar to DID document 210. DID 445 may also have an associated private and public key pair that allows third parties to access data broadcast service 440 using DID 445.

[0081] It will be noted that because the data broadcasting service 440 includes the DID 445, the data broadcasting service 440 is able to interact with the DID owner 201 and the users 410, 420, and 430 in a decentralized manner. Thus, even though the data broadcasting service 440 may be owned by a commercial entity or the like, because the data broadcasting service 440 is part of a decentralized network supported by the distributed ledger or blockchain 220, no identifying information about the DID owner 201 and the users 410, 420, 430, and 405 can be determined without these users granting permission to the data broadcasting service 440. Thus, the DID owner 201 and the users 410, 420, 430, and 405 maintain control of their respective identities associated with the data broadcasting service 440.

[0082] The data broadcast service 440 may include a broadcast module 450. The broadcast module 450 may represent physical and software elements that may be associated with the data broadcast service 440 to broadcast data. In operation, the broadcast module 450 may receive intent data 402 including intent information 403a and 403b from the DID owner 201. The broadcast module may then generate a broadcast message 451 that includes the DID 205 as an identifier of the DID user 201 and the intent data 402 including the intent information 403a and 403b. Although not shown for ease of explanation, the intent data 402 included in the broadcast message 451 may also include one or more proofs 340 and one or more attributes 321, as previously described.

[0083] Then, the broadcast module 450 can broadcast the broadcast message 451 to the user 410, the user 420 and the user 430, such as Figure 4 Although not shown, the broadcast message 451 may also be sent to any number of additional users 405, which in some embodiments may be thousands or even millions of users. Thus, the embodiments disclosed herein provide a way for the DID owner 201 to broadcast desired intents to a large number of users in a decentralized manner.

[0084] Upon receiving the broadcast message 451, users 410, 420, and 430 may store the intent data 402 in an identity hub or some other location they control. As previously described, intent information 403a may provide details about the interactions that the DID owner 201 is interested in. Intent information 403b may include information about how the user can interact with the DID owner 201. In addition, since the broadcast message 451 includes the DID 205 of the DID owner 201, users 410, 420, and 430 may use the DID 205 and the untrusted ledger or blockchain 220 and the DID document 210 in the manner previously described to contact the DID owner 201. If any of the users 410, 420, and 430 are interested in interacting with the DID owner 201 in the manner specified by the intent data 402, they may interact according to the intent information 403b. For example, they may access ID hub 311 where they can find additional information about a particular interaction desired by DID owner 210, and also send various messages about the desired interaction to DID owner 201. Alternatively, if these users are not interested in the interaction specified in intent data 201, any of them may simply ignore broadcast message 451.

[0085] For example, assume that DID owner 201 is interested in receiving an offer for his or her house. Therefore, DID owner 201 can generate intent data 402, which has intent information 403a specifying that the house is for sale and intent information 403b specifying how to interact with DID owner 201. The intent data can also include proof 340 and attributes 321, which provide additional information about DID owner 201 related to purchasing the house, such as location. The intent data can be stored in ID hub 311 or management module 401 and provided to broadcast service 440.

[0086] The broadcast module 450 can then generate a broadcast message 451 in the manner previously described and provide the broadcast message to users 410, 420, and 430. If user 430 is interested in purchasing a house at the location of DID owner 201's house, user 430 can interact with DID owner 201 using DID 205 based on intent information 403a.

[0087] In some embodiments, Figure 4 As shown, user 410 can control an administration module 412 that functions in a similar manner as administration module 401. Additionally, user 410 can access an identity center 413 that is similar to identity center 311.

[0088] Thus, user 410 may generate intent data 414 in management module 412 or identity hub 413. In a manner similar to intent data 402, intent data 414 may include intent information 415, which may include intent information 415a and may include intent information 415b. Intent information 415a and 415b may correspond to previously described intent information 403a and 403b, respectively, and thus require no further explanation. Intent data 414 may also include proof 416, which includes proofs 416a and 416b, and may also include attributes 417, which includes attributes 417a and 417b. Proof 416 and attributes 417 may be stored in identity hub 413. Proof 416 and attributes 417 may correspond to proof 340 and attributes 321 previously described with respect to DID owner 201, and thus require no further explanation.

[0089] Assume that user 410 is also interested in receiving an offer on his or her house. Therefore, user 410 may generate intent data 414 having intent information 415a specifying the sale of the house and intent information 415b specifying how to interact with user 410. Intent data 414 may also include one or more of proof 416 and attributes 417, if appropriate.

[0090] Thus, in such an embodiment, the broadcast module 450 may also include an aggregation module 460. In operation, the aggregation module 460 may be able to determine intent data from multiple users that is related to or based on similar desired interactions specified by the intent data. For example, multiple users may desire to sell their respective homes. The aggregation module 460 may then generate a single aggregate broadcast message 465 that combines all of the intent data.

[0091] For example, Figure 4 As shown, the aggregation module 460 can generate a broadcast message 461, which includes the DID 205 of the DID owner 201 and the intent data 402, and the intent data 402 includes the intent information 403a and 403b and any certifications and attributes as needed. As described above, in this example embodiment, the intent information 403a specifies the house sale of the DID owner 201, and the intent information 403b specifies how to interact with the DID owner 201.

[0092] Similarly, aggregation module 460 can generate broadcast message 462, which includes DID 411 of user 410 and intent data 414, which includes intent information 415a and 415b and any certifications and attributes as needed. Since in the current embodiment, user 410 desires to sell his or her house, intent information 415a can specify that the house is for sale, and intent information 415b can specify how to interact with user 410. Ellipses 463 indicate that any number of additional users can also provide intent data related to selling a house, which can be used to generate any number of additional broadcast messages.

[0093] Aggregation module 460 can then generate an aggregate broadcast message 465 that includes all intent data from various users related to the sale of the house. Aggregate broadcast message 465 can then be sent to users 420 and 430 and any number of additional users 405. As previously discussed with respect to broadcast message 451, users receiving aggregate broadcast message 465 can store the message in the identity hub and can use the intent information to select various houses they are interested in potentially purchasing and interact with DID owner 201, user 410, or other users. Of course, they can also simply ignore aggregate broadcast message 465 if desired.

[0094] It is understood that one or more of users 420 and 430 may receive broadcast message 451 or aggregated broadcast message 465 from intent data broadcast service 440, and may want to know whether the party generating the intent information is trustworthy. This may be particularly true if users 420 and 430 have never heard of DID owner 201 or user 410 or have had any interaction with DID owner 201 or user 410, which is likely the case. In some embodiments, proofs 340 and 416 may provide sufficient assurance to users 420 and 430. However, in other embodiments, DID owner 201 or user 410 may not include proofs in intent data, or they may not have accumulated enough proofs. Alternatively, users 420 and 430 may not believe the proofs or may not trust them. Therefore, intent data broadcast service 440 may also include trust module 470. In operation, trust module 470 can determine trust scores 471 of various users associated with intent broadcast service 440. In one embodiment, trust score 471 may be determined based on the frequency with which each user interacts with the user sending the broadcast message in a desired manner using a broadcast message from another user. In other words, trust score 471 measures the frequency with which the user interacting with the sending user using the broadcast message has a positive experience.

[0095] For example, assume that DID owner 201 has a history of using intent data broadcast service 440 to sell a house or conduct other business. In this case, trust module 470 can determine how often another user, such as users 410, 420, and 430, uses the broadcast message from user DID owner 201. If a certain percentage of users do use the broadcast message in a satisfactory manner, perhaps measured based on a threshold, a relatively high trust score 471 can be generated. Conversely, if only a small percentage of users who use the broadcast message do so in a satisfactory manner, or if DID owner 201 has only used intent data broadcast service 440 for a short period of time, then a relatively low trust score 472 can be generated.

[0096] In response to receiving the broadcast message, one or more of the users 410, 420, and 430 may access the trust score 471 from the intent data broadcast service 440. The users 410, 420, and 430 may then make a determination as to whether to interact with the DID owner 201 based on the trust score 471. Advantageously, the use of the trust score 471 helps to provide trust to the various users associated with the intent data broadcast service 440 in their interactions with each other.

[0097] The intent broadcast data service 440 may also include a subscription module 480. In operation, the subscription module 480 may allow a user, such as user 430, to subscribe to broadcast messages of interest. For example, in the example above, DID owner 201 and user 410 generate a broadcast message that specifies the desired interaction of selling their house. If user 430 is a user who wants to buy a house, user 430 may subscribe only to broadcast messages related to selling a house. In this way, user 430 will not receive broadcast messages related to other types of interactions, such as products and services, that he or she is not interested in. Therefore, the subscription module 480 allows user 430 to receive more focused data.

[0098] The intent data broadcast service 440 may also include an advertising module 490. In operation, the advertising module 490 may allow any user associated with the intent data broadcast service 440 to generate an advertisement 495 related to a service, product, etc. This advantageously helps ensure that a particular user is at least included in any broadcast message related to an advertisement 496.

[0099] For example, assume that DID owner 201 is a patent attorney. In this case, he or she can have advertisement module 490 generate advertisement 495 that can associate DID 205 with being a patent attorney. At a later time, when intent data broadcast service 440 determines in the manner previously described that user 420 may be interested in hiring a patent attorney, intent data broadcast service 440 can ensure that broadcast message 451 from DID owner 201 with intent data 402 related to patent law services is sent to user 420.

[0100] The following discussion now relates to various methods and method actions that can be performed. Although method actions may be discussed in a particular order or illustrated in a flowchart as occurring in a particular order, the particular order is not required unless otherwise specified or because an action is dependent on another action being completed before that action.

[0101] Figure 5 A flow chart of an example method 500 for broadcasting an intent of a first user to a second user of a decentralized network is shown. The method can be implemented in a computing system implemented in a decentralized network that implements a distributed ledger configured to support one or more decentralized identities (DIDs) of one or more users of the computing system. Figure 2-4 Method 500 is described with reference to one or more of the following.

[0102] Method 500 includes receiving intent data (510) from one or more first users of a computing system. The intent data defines one or more potential interactions between one or more first users of a computing system and one or more second users. For example, as previously described, intent data broadcast system 440 may receive intent data 402 from DID owner 201 or intent data 414 from user 410. The intent data may define potential interactions between DID owner 201 and / or user 410 and users 420, 430, and possibly any number of users 405. As described, a potential interaction may be a desire to sell or purchase a particular product or service. Potential interactions may be non-commercial interactions, such as collaboration on a research project or some social interactions, such as dating, etc.

[0103] Method 500 includes generating one or more broadcast messages (520). The broadcast message includes the DID of each of the one or more first users and information specifying potential one or more interactions. For example, as previously described, the broadcast module 450 can generate a broadcast message 451 or an aggregate broadcast message 265. The broadcast message can include the DID 205 of the DID owner 201 and / or the DID 411 of the user 410. The broadcast message can also include intent information 403a and 415a specifying the subject or type of the intended interaction. The broadcast message can also include intent information 403b and 415b specifying how to interact with the DID owner 201 or the user 410.

[0104] Method 500 includes providing the generated one or more broadcast messages to one or more second users (530). For example, as described above, intent broadcast service 440 may provide broadcast message 451 to one or more of users 410, 420, or 430 or provide aggregated broadcast message 465 to one or more of users 420 and 430.

[0105] For the processes and methods disclosed herein, the operations performed in the processes and methods may be implemented in different orders. In addition, the operations outlined are provided only as examples, and some of the operations may be optional, combined into fewer steps and operations, supplemented with further operations, or expanded into additional operations without departing from the essence of the disclosed embodiments.

[0106] The present invention may be implemented in other specific forms without departing from the spirit or features of the present invention. The described embodiments should be considered illustrative and not restrictive in all aspects. Therefore, the scope of the present invention is indicated by the appended claims rather than by the foregoing description. All changes falling within the equivalent meaning and scope of the claims should be included within their scope.

Claims

1. A computing system implemented in a decentralized network implementing a distributed ledger, the distributed ledger configured to support one or more decentralized identities (DIDs) of one or more users of the computing system, the computing system comprising: one or more processors; as well as One or more computer-readable media having computer-executable instructions thereon, the computer-executable instructions being structured so that when executed by the one or more processors, the computing system: receiving intent data from one or more first users of the computing system, the intent data defining one or more interactions between the one or more first users and one or more second users of the computing system, wherein the intent data received from the one or more first users includes attestation data, wherein the attestation data includes credential information; generating a trust score for the one or more first users, the trust score being based on a frequency with which the one or more second users interact with the one or more first users in a manner specified by the intent data; generating, by the one or more first users of the computing system, one or more broadcast messages, the one or more broadcast messages including a DID of each of the one or more first users and information specifying the one or more interactions and the attestation data; wherein the DID is owned by each of the one or more first users of the computing system; as well as The generated one or more broadcast messages are provided to the one or more second users.

2. The computing system of claim 1 , wherein the computer executable instructions are configured to further cause the computing system to: Based on at least some of the generated broadcast messages having similar interactions, at least some of the generated one or more broadcast messages are aggregated into a single aggregate broadcast message. 3 . The computing system of claim 1 , wherein the one or more broadcast messages provided to the one or more second users are broadcast to all second users associated with the computing system. 4 . The computing system of claim 1 , wherein the one or more broadcast messages provided to the one or more second users are sent only to second users that have subscribed to receive the one or more broadcast messages.

5. The computing system of claim 1 , wherein the computer executable instructions are configured to further cause the computing system to: An advertisement is generated based on the intent data received from the one or more first users. 6 . The computing system of claim 1 , wherein the intent data received from the one or more first users further comprises attribute data.

7. The computing system of claim 1, wherein the information specifying the one or more interactions comprises a subject matter of the one or more interactions and information specifying how to interact with the one or more first users.

8. A method in a computing system for broadcasting an intent of a first user to a second user of a decentralized network implementing a distributed ledger, the computing system being implemented in the decentralized network, the distributed ledger being configured to support one or more decentralized identities (DIDs) of one or more users of the computing system, the method comprising: receiving intent data from one or more first users of the computing system, the intent data defining one or more interactions between the one or more first users and one or more second users of the computing system, wherein the intent data received from the one or more first users includes attestation data, wherein the attestation data includes credential information; generating a trust score for the one or more first users, the trust score being based on a frequency with which the one or more second users interact with the one or more first users in a manner specified by the intent data; generating, by the one or more first users of the computing system, one or more broadcast messages, the broadcast messages including a DID of each of the one or more first users and information specifying the one or more interactions and the attestation data; wherein the DID is owned by each of the one or more first users of the computing system; as well as The generated one or more broadcast messages are provided to the one or more second users.

9. The method according to claim 8, further comprising: Based on at least some of the generated broadcast messages having similar interactions, at least some of the generated one or more broadcast messages are aggregated into a single aggregate broadcast message.

10. The method of claim 8, wherein the one or more broadcast messages provided to the one or more second users are broadcast to all second users associated with the computing system.

11. The method of claim 8, wherein the one or more broadcast messages provided to the one or more second users are sent only to second users that have subscribed to receive the information.

12. The method according to claim 8, further comprising: An advertisement is generated based on the intent data received from the one or more first users.

13. The method of claim 8, wherein the intent data received from the one or more first users further includes attribute data.

14. The method of claim 8, wherein the information specifying the one or more interactions includes a subject matter of the one or more interactions and information specifying how to interact with the one or more first users.

15. A computer program product comprising one or more computer-readable storage media having computer-executable instructions thereon, the computer-executable instructions being configured such that, when executed by one or more processors of a computing system, the computing system is caused to perform a method of broadcasting an intent of a first user to a second user of a decentralized network, the method comprising: receiving intent data from one or more first users of the computing system, the intent data defining one or more interactions between the one or more first users and one or more second users of the computing system, wherein the intent data received from the one or more first users includes attestation data, wherein the attestation data includes credential information; generating a trust score for the one or more first users, the trust score being based on a frequency with which the one or more second users interact with the one or more first users in a manner specified by the intent data; generating, by the one or more first users of the computing system, one or more broadcast messages, the broadcast messages including a DID of each of the one or more first users and information specifying the one or more interactions and the attestation data; wherein the DID is owned by each of the one or more first users of the computing system; as well as The generated one or more broadcast messages are provided to the one or more second users.

16. The computer program product of claim 15, further comprising: Based on at least some of the generated broadcast messages having similar interactions, at least some of the generated one or more broadcast messages are aggregated into a single aggregate broadcast message.

17. The computer program product of claim 15, wherein the intent data received from the one or more first users further comprises attribute data.

18. The computer program product of claim 15, wherein the information specifying the one or more interactions comprises a subject matter of the one or more interactions and information specifying how to interact with the one or more first users.

Images