Patent Application Titled “Decentralized Attribute-Based Access Control” Published Online (USPTO 20230388287): Patent Application

2023 DEC 14 (NewsRx) -- By a News Reporter-Staff News Editor at Insurance Daily News -- According to news reporting originating from Washington, D.C., by NewsRx journalists, a patent application by the inventors DINGLE, Pamela (Redmond, WA, US); JAHROMI, Babak Ghane (Redmond, WA, US); KOEN, Peter (Trausdorf an der Wulka, AT); LATZELSPERGER, Paul (Upper Austria, AT); MARINO, James (Newtown, PA, US); VAN DER WIELE, Stefanus Martinus (Alkmaar, NL), filed on May 31, 2022, was made available online on November 30, 2023.

No assignee for this patent application has been made.

Reporters obtained the following quote from the background information supplied by the inventors: “The present disclosure relates to data management. More particularly, the present disclosure relates to techniques for controlling access to data and/or services.

“Access control allows organizations to control how users, employees, and/or third parties access data and/or services in a manner that meets security, privacy, and/or compliance requirements. In some cases, such requirements are set by security best practices and official regulations, such as general data protection regulation (GDPR), health insurance portability and accountability act (HIPAA), national institute of standards and technology (NIST), etc. These regulations often require organizations to audit and place controls over the entities that can access sensitive information.”

In addition to obtaining background information on this patent application, NewsRx editors also obtained the inventors’ summary information for this patent application: “In the following description, for purposes of explanation, numerous examples and specific details are set forth in order to provide a thorough understanding of the present disclosure. Such examples and details are not to be construed as unduly limiting the elements of the claims or the claimed subject matter as a whole. It will be evident to one skilled in the art, based on the language of the different claims, that the claimed subject matter may include some or all of the features in these examples, alone or in combination, and may further include modifications and equivalents of the features and techniques described herein.

“Described here are techniques for providing an attribute-based access control for decentralized federations. FIG. 1 illustrates a decentralized federation 100 for controlling data and service access according to some embodiments. As shown, federation 100 includes federation members 105a-n and federation authority 110. In some embodiments, each of the federation members 105a-n is using a separate cloud computing system. That is, federation 100 is a multi-cloud federation in some such embodiments. In this example, each of the federation members 105a-n has applied to join, and received acceptance to, federation 100 via federation authority 110. In addition, each of the federation members 105a-n is configured to provide services to other federation members 105a-n and consume services offered by the other federation members 105a-n. For example, when a first federation member 105 wants to consume a service offered by a second federation member 105, the first federation member 105 identifies the second federation member 105 (e.g., by querying federation authority 110 for a list of members) and sends the second federation member 105 a request for a list of services offered by the second federation member 105. In response to the request, the second federation member 105 retrieves information associated with the first federation member 105 (e.g., verifiable claims, verifiable credentials, etc.). Based on the information associated with the first federation member 105, the second federation member 105 can determine a subset of available services provided by the second federation member 105 and determine terms of access for each of those available services. A second federation member 105 may determine different subsets of available services based on different information associated with different first federation members 105. Similarly, a second federation member 105 can determine different terms of available services based on different information associated with different first federation members 105. In this manner, a particular federation member 105 is able to provide different access to data and/or services to other federation members 105 based on different attributes associated with the other federation members 105. After determining available services and terms for the services, the second federation member 105 may send the subset of available services to the first federation member 105. The first federation member 105 can access any of the available services according to the respective terms determined for the service.

“Federation authority 110 is responsible for managing membership to federation 100. As illustrated in FIG. 1, federation authority 110 includes member manager 115, policies and rules storage 120, and member registry storage 125. Policies and rules storage 120 stores policies, rules, and required claims for determining membership to federation 100. Member registry storage 125 stores unique identifiers (e.g., decentralized identifiers (DIDs)) associated with members in federation 100 and/or references to such unique identifiers. In some embodiments, storages 120 and 125 are implemented in a single physical storage while, in other embodiments, storages 120 and 125 may be implemented across several physical storages. While FIG. 1 shows storages 120 and 125 as part of federation authority 110, one of ordinary skill in the art will appreciate that policies and rules storage 120 and/or member registry storage 125 may be external to federation authority 110 in some embodiments. In some embodiments, the various operations described herein that are performed by federation authority 110 (e.g., processing policies, rules, memberships, etc.) may be implemented in a decentralized manner across multiple computing devices and/or systems. In some such embodiments, the decentralized processes can be performed in parallel as appropriate.

“Several example data flows will now be described by reference to FIGS. 2-4. Specifically, these example data flows show how a new member joins a federation, how federation members control access to services and/or data between each other, and how a federation member accesses services and/or data provided by another federation member. FIG. 2 illustrates an example data flow 200 for joining federation 100 according to some embodiments. Data flow 200 may represent the flow of data between each of the federation members 105a-n and federation authority 100 when the federation member 105 is applying to join federation 100. As depicted, data flow 200 includes applicant 205 and federation authority 110. For this example, applicant 205 is not yet part of federation 100. Applicant 205 includes catalog manager 210 and identity data storage 215. Identity data storage 215 stores identity information associated with the applicant 205. Examples of such identity information include verifiable claims, verifiable credentials (e.g., world wide web consortium (W3C) verifiable credentials), etc. In some embodiments, a verifiable credential is tamper-proof credential that can be verified cryptographically. In some cases, identity data storage 215 is implemented as a decentralized web node. In some embodiments, a decentralized web node (DWN) is a data storage and message relay mechanism used to locate public or private permissioned data related to a given DID.

“Catalog manager 210 is configured to manage a catalog of available service contracts provided by other federation members (e.g., federation members 105a-n). In some embodiments, a service contract may specify a set of services provided by a federation member (e.g., a service for accessing data, a service for processing data, etc., or any other service(s) that provides software functionalities). In this example, it is assumed that applicant 205 has already obtained a unique identifier associated with applicant 205. Specifically, applicant 205 has obtained a DID (e.g., a W3C DID) for this example. In addition, applicant 205 has created self-description 220, that includes information describing applicant 205. For this example, self-description 220 includes a list of services for participation in federation 100, claims associated with applicant 205, attributes associated with applicant 205, etc.

“The example data flow 200 begins by applicant 205 contacting, at 250, federation authority 110 using the DID for identifying federation authority 110. Applicant 205 then accesses self-description 225, which includes information required to apply for membership to federation 100 (e.g., rules, attributes, required claims, etc.), of federation authority 110. In some instances, applicant 205 the DID for identifying federation authority 110 includes a reference to self-description 225. In some such instances, applicant 205 uses the reference in the DID to access self-description 225. Based on the information in self-description 225, applicant 205 sends, at 255, federation authority 110 a request to join federation 100 along with DID 255, which is the DID for identifying applicant 205.

“In response to the request, federation authority 110 uses DID 255 to access, at 265, self-description 220 of applicant 205. In some embodiments, DID 255 includes a reference to self-description 220. In some such embodiments, federation authority 110 uses the reference in DID 255 to access self-description 220. Then, federation authority 110 determines whether to allow applicant 205 to join federation 100 by checking the claims in self-description 220 against the policies, rules, and mandatory claims stored in policies and rules storage 120. If the claims associated with applicant 205 satisfy the policies, rules, and mandatory claims, member manager 115 determines that applicant 205 is allowed to join federation 100. Otherwise, member manager 115 does not allow applicant 205 to join federation 100. Here, member manager 115 determines that applicant 205 is allowed to join federation 100. As such, member manager adds applicant 205 to member registry storage 125 (e.g., by adding DID 255 to member registry storage 125). Additionally, member manager 115 generates verifiable credential 275 indicating that applicant 205 is a member of federation 100. Next, member manager 115 sends, at 270, VC 275 to applicant 205. Upon receiving VC 275, applicant 205 stores it in identity storage 215. Then, catalog manager 210 initiates the discovery of service contracts offered by other federation members (e.g., federation members 105a-n).”

There is additional summary information. Please visit full patent to read further.”

The claims supplied by the inventors are:

“1. A non-transitory machine-readable medium storing a program executable by at least one processing unit of a device associated with a first member in a federation, the program causing the at least one processing unit to: send a federation authority a request for a list of unique identifiers (IDs) associated with members belonging to the federation managed by the federation authority; receive from the federation authority the list of unique IDs; for a unique ID in the list of unique IDs associated with a second member belonging to the federation, determine a set of communication information for communicating with the second member; based on the set of communication information associated with the second member, send the second member a request for a list of available services; in response to receiving a request for verifiable credentials from the second member, provide the second member a set of verifiable credentials associated with the first member, wherein the second member determines the list of available services based on the set of verifiable credentials and a set of policies and rules; and receive the list of available services from the second member.

“2. The non-transitory machine-readable medium of claim 1, wherein the program further causes the at least one processing unit to send the second member a particular unique ID for identifying the first member, wherein the second member uses the particular unique ID to retrieve the set of verifiable credentials associated with the first member.

“3. The non-transitory machine-readable medium of claim 1, wherein the program further causes the at least one processing unit to store the list of available services in a catalog of available services provided by members in the federation.

“4. The non-transitory machine-readable medium of claim 1, wherein the program further causes the at least one processing unit to: receive a selection of an available service provided by a member of the federation; send the member a request for a service negotiation; and receive from the member a service agreement and a set of data for accessing and consuming a service specified in the service agreement.

“5. The non-transitory machine-readable medium of claim 4, wherein the program further causes the at least one processing unit to send the member the set of data and a request to consumer the service.

“6. The non-transitory machine-readable medium of claim 1, wherein the list of unique IDs comprises a set of decentralized identifiers (DIDs) associated with members belonging to the federation.

“7. The non-transitory machine-readable medium of claim 1, wherein each member in the federation belong to a separate cloud computing system.

“8. A method executable by a first member of a federation, the method comprising: sending a federation authority a request for a list of unique identifiers (IDs) associated with members belonging to the federation managed by the federation authority; receiving from the federation authority the list of unique IDs; for a unique ID in the list of unique IDs associated with a second member belonging to the federation, determining a set of communication information for communicating with the second member; based on the set of communication information associated with the second member, sending the second member a request for a list of available services; in response to receiving a request for verifiable credentials from the second member, providing the second member a set of verifiable credentials associated with the first member, wherein the second member determines the list of available services based on the set of verifiable credentials and a set of policies and rules; and receiving the list of available services from the second member.

“9. The method of claim 8, further comprising sending the second member a particular unique ID for identifying the first member, wherein the second member uses the particular unique ID to retrieve the set of verifiable credentials associated with the first member.

“10. The method of claim 8 further comprising storing the list of available services in a catalog of available services provided by members in the federation.

“11. The method of claim 8 further comprising: receiving a selection of an available service provided by a member of the federation; sending the member a request for a service negotiation; and receiving from the member a service agreement and a set of data for accessing and consuming a service specified in the service agreement.

“12. The method of claim 11 further comprising sending the member the set of data and a request to consumer the service.

“13. The method of claim 8, wherein the list of unique IDs comprises a set of decentralized identifiers (DIDs) associated with members belonging to the federation.

“14. The method of claim 8, wherein each member in the federation belong to a separate cloud computing system.

“15. A system associated with a first member in a federation comprising: a set of processing units; and a non-transitory machine-readable medium storing instructions that when executed by at least one processing unit in the set of processing units cause the at least one processing unit to: send a federation authority a request for a list of unique identifiers (IDs) associated with members belonging to the federation managed by the federation authority; receive from the federation authority the list of unique IDs; for a unique ID in the list of unique IDs associated with a second member belonging to the federation, determine a set of communication information for communicating with the second member; based on the set of communication information associated with the second member, send the second member a request for a list of available services; in response to receiving a request for verifiable credentials from the second member, provide the second member a set of verifiable credentials associated with the first member, wherein the second member determines the list of available services based on the set of verifiable credentials and a set of policies and rules; and receive the list of available services from the second member.

“16. The system of claim 15, wherein the instructions further cause the at least one processing unit to send the second member a particular unique ID for identifying the first member, wherein the second member uses the particular unique ID to retrieve the set of verifiable credentials associated with the first member.

“17. The system of claim 15, wherein the instructions further cause the at least one processing unit to store the list of available services in a catalog of available services provided by members in the federation.

“18. The system of claim 15, wherein the instructions further cause the at least one processing unit to: receive a selection of an available service provided by a member of the federation; send the member a request for a service negotiation; and receive from the member a service agreement and a set of data for accessing and consuming a service specified in the service agreement.

“19. The system of claim 15, wherein the instructions further cause the at least one processing unit to send the member the set of data and a request to consumer the service.

“20. The system of claim 15, wherein the list of unique IDs comprises a set of decentralized identifiers (DIDs) associated with members belonging to the federation.”

For more information, see this patent application: DINGLE, Pamela; JAHROMI, Babak Ghane; KOEN, Peter; LATZELSPERGER, Paul; MARINO, James; VAN DER WIELE, Stefanus Martinus. Decentralized Attribute-Based Access Control. U.S. Patent Application Number 20230388287, filed May 31, 2022 and posted November 30, 2023. Patent URL (for desktop use only): https://ppubs.uspto.gov/pubwebapp/external.html?q=(20230388287)&db=US-PGPUB&type=ids

(Our reports deliver fact-based news of research and discoveries from around the world.)