Patent Issued for Complex composite tokens (USPTO 11553352): eBay Inc.

2023 JAN 26 (NewsRx) -- By a News Reporter-Staff News Editor at Insurance Daily News -- According to news reporting originating from Alexandria, Virginia, by NewsRx journalists, a patent by the inventors Frederick, Gail Anna Rahn (Portland, OR, US), Vlahovic, Tatjana (San Jose, CA, US), filed on May 27, 2021, was published online on January 10, 2023.

The assignee for this patent, patent number 11553352, is eBay Inc. (San Jose, California, United States).

Reporters obtained the following quote from the background information supplied by the inventors: “Currently, many services provide Application Programming Interfaces (APIs) through which partner entities are integrated. A transaction platform can have multiple integrated partners that provide services or goods for customer transactions through platform APIs.

“For instance, a platform may have partners who accept credit cards or sensitive information from their customers. A customer’s sensitive information (e.g. credit card or personal identification data) is provided to the API of a service through a partner provider (e.g. a Payment Card Industry Data Security Standard (PCI DSS) compliant vault or Health Insurance Portability and Accountability Act (HIPPA) compliant service) that maintains the sensitive information.

“However, PCI DSS or HIPPA compliance can be complex and expensive to implement. Frequently, PCI DSS or HIPPA compliance is delegated to a compliant partner, which then participates in a transaction (e.g. a purchase or data transfer). This approach involves customers or users sharing their OAuth tokens with these compliant partners in order to perform a transaction. Sharing a token introduces security risk and prevents auditing the use of the token to accurately identify an entity participating in a transaction.

“Typically, sharing an OAuth token involves the partner impersonating another entity, such as the customer. The impersonating entity appears to the API to be the customer because the token identifies only the customer. Sharing the token creates a security risk. Impersonation of the customer prevents the token from being used to identify the impersonating entity as participating in the transaction and, therefore, limits the auditability of the transaction.

“It is with respect to these and other considerations that the disclosure made herein is presented.”

In addition to obtaining background information on this patent, NewsRx editors also obtained the inventors’ summary information for this patent: “The disclosed technology is directed toward advanced security networking protocol extensions and APIs that can extend composite tokens described in a recent OAuth proposal for delegating permissions from a subject entity to an actor entity to create trust stacks that provide for complex delegations of permissions that can be audited and verified.

“In certain simplified examples of the disclosed technologies, methods, systems or computer readable media for trust or authorization delegation for extension of OAuth multiple actor delegation in accordance with the disclosed technology involve receiving a first authorization request from a subject client and responding to the first authorization by sending a first token having a first set of permissions to the subject client. The disclosed technology also involves receiving a second authorization request from a first partner actor, the second authorization request including the first token and responding to the second authorization request by linking the first partner actor to the subject client in a trust stack pertaining to the subject client and sending a second token to the first actor partner with a second set of permissions, where the second token comprises a first complex token that identifies the subject client and the first partner actor. The technology further involves receiving a third authorization request from a second partner actor, the third authorization request including the second token and responding to the third authorization request by linking the second partner actor to the first partner actor in the trust stack, and sending a third token to the second actor partner with a third set of permissions, where the third token comprises a second complex token that identifies the first partner actor and the second partner actor.

“Examples in accordance with certain aspects of the disclosed technology can further include receiving an access request to a resource from the second partner actor, the access request including the third token and granting access to the resource based on the third set of permissions. Other examples in accordance with other aspects of the disclosed technology can include determining the second set of permissions based on either a union or intersection of permissions for the subject client and permissions for the first partner actor. In still other examples, the disclosed technologies can include determining the third set of permissions based on either a union or intersection of permissions for the subject client, permissions for the first partner actor, and permissions for the third partner actor.

“In certain examples, the authorization delegation pertains to a financial transaction, the first partner actor is not configured for compliance with a standard for secure handling of customer financial data, and the second partner actor is configured for compliance with the standard for secure hadling of customer financial data.

“In certain other examples, the subject client can be an end user, the first partner actor can be a service provider to the end user, and the second partner actor can be a subcontractor to the first partner. In certain of these examples, the second partner actor is configured to provide one or more of shipping, packaging, warehousing and insurance to the first partner.”

The claims supplied by the inventors are:

“1. A computer-implemented authorization delegation method for extension of OAuth multiple actor delegation, the method comprising: receiving a first authorization request from a subject client; responding to the first authorization by sending a first token having a first set of permissions to the subject client; receiving a second authorization request from a first partner actor, the second authorization request including the first token; responding to the second authorization request by: linking the first partner actor to the subject client in a trust stack pertaining to the subject client, and sending a second token to the first actor partner with a second set of permissions, where the second token comprises a first complex token that identifies the subject client and the first partner actor; receiving a third authorization request from a second partner actor, the third authorization request including the second token; responding to the third authorization request by: linking the second partner actor to the first partner actor in the trust stack, and sending a third token to the second actor partner with a third set of permissions, where the third token comprises a second complex token that identifies the first partner actor and the second partner actor; and where the authorization delegation pertains to a financial transaction and: the first partner actor is not configured for compliance with a standard for secure handling of customer financial data; and the second partner actor is configured for compliance with the standard for secure handling of customer financial data.

“2. The method of claim 1, the method including: receiving an access request to a resource from the second partner actor, the access request including the third token; and granting access to the resource based on the third set of permissions.

“3. The method of claim 2, the method including: determining the second set of permissions based on either a union or intersection of permissions for the subject client and permissions for the first partner actor.

“4. The method of claim 3, the method including: determining the third set of permissions based on either a union or intersection of permissions for the subject client, permissions for the first partner actor, and permissions for the third partner actor.

“5. The method of claim 1, where: the subject client comprises an end user; the first partner actor comprises a service provider to the end user; and the second partner actor comprises a subcontractor to the first partner.

“6. The method of claim 5, where: the second partner actor is configured to provide one or more of shipping, packaging, warehousing and insurance to the first partner.

“7. The method of claim 1, where the method includes: receiving a fourth authorization request from a third partner actor, the fourth authorization request including the third token; responding to the fourth authorization request by: linking the third partner actor to the second partner actor in the trust stack, and sending a fourth token to the third actor partner with a fourth set of permissions, where the fourth token comprises a third complex token that identifies the second partner actor and the third partner actor.

“8. A system for trust delegation, the system comprising: one or more processors; and one or more memory devices in communication with the one or more processors, the memory devices having computer-readable instructions stored thereupon that, when executed by the processors, cause the processors to: receive a first authorization request from a subject client; respond to the first authorization by sending a first token having a first set of permissions to the subject client; receive a second authorization request from a first partner actor, the second authorization request including the first token; respond to the second authorization request by: linking the first partner actor to the subject client in a trust stack pertaining to the subject client, and sending a second token to the first actor partner with a second set of permissions, where the second token comprises a first complex token that identifies the subject client and the first partner actor; receive a third authorization request from a second partner actor, the third authorization request including the second token; respond to the third authorization request by: linking the second partner actor to the first partner actor in the trust stack, and sending a third token to the second actor partner with a third set of permissions, where the third token comprises a second complex token that identifies the first partner actor and the second partner actor; where the authorization delegation pertains to a financial transaction and: the first partner actor is not configured for compliance with a standard for secure handling of customer financial data; and the second partner actor is configured for compliance with the standard for secure handling of customer financial data.

“9. The system of claim 8, the system including stored instructions that, when executed by the processors, cause the processors to: receive an access request to a resource from the second partner actor, the access request including the third token; and grant access to the resource based on the third set of permissions.

“10. The system of claim 9, the system including stored instructions that, when executed by the processors, cause the processors to: determine the second set of permissions based on either a union or intersection of permissions for the subject client and permissions for the first partner actor.

“11. The system of claim 10, the system including stored instructions that, when executed by the processors, cause the processors to: determine the third set of permissions based on either a union or intersection of permissions for the subject client, permissions for the first partner actor, and permissions for the third partner actor.

“12. The method of claim 8, where: the subject client comprises an end user; the first partner actor comprises a service provider to the end user; and the second partner actor comprises a subcontractor to the first partner.

“13. The system of claim 12, where: the second partner actor is configured to provide one or more of shipping, packaging, warehousing and insurance to the first partner.

“14. The system of claim 8, where the system includes stored instructions that, when executed by the processors, cause the processors to: receive a fourth authorization request from a third partner actor, the fourth authorization request including the third token; and in response to the fourth authorization request: link the third partner actor to the second partner actor in the trust stack, and send a fourth token to the third actor partner with a fourth set of permissions, where the fourth token comprises a third complex token that identifies the second partner actor and the third partner actor.

“15. A computer storage medium having computer executable instructions stored thereon which, when executed by one or more processors, cause the processors to execute an authorization delegation method for extension of OAuth multiple actor delegation, the method comprising: receiving a first authorization request from a subject client; responding to the first authorization by sending a first token having a first set of permissions to the subject client; receiving a second authorization request from a first partner actor, the second authorization request including the first token; responding to the second authorization request by: linking the first partner actor to the subject client in a trust stack pertaining to the subject client, and sending a second token to the first actor partner with a second set of permissions, where the second token comprises a first complex token that identifies the subject client and the first partner actor; receiving a third authorization request from a second partner actor, the third authorization request including the second token; responding to the third authorization request by: linking the second partner actor to the first partner actor in the trust stack, and sending a third token to the second actor partner with a third set of permissions, where the third token comprises a second complex token that identifies the first partner actor and the second partner actor; and where the authorization delegation pertains to a financial transaction and: the first partner actor is not configured for compliance with a standard for secure handling of customer financial data; and the second partner actor is configured for compliance with the standard for secure handling of customer financial data.

“16. The computer storage medium of claim 15, the method including: receiving an access request to a resource from the second partner actor, the access request including the third token; and granting access to the resource based on the third set of permissions.

“17. The computer storage medium of claim 16, the method including: determining the second set of permissions based on either a union or intersection of permissions for the subject client and permissions for the first partner actor.

“18. The computer storage medium of claim 17, the method including: determining the third set of permissions based on either a union or intersection of permissions for the subject client, permissions for the first partner actor, and permissions for the third partner actor.

“19. The computer storage medium of claim 15, where: the subject client comprises an end user; the first partner actor comprises a service provider to the end user; and the second partner actor comprises a subcontractor to the first partner.”

There are additional claims. Please visit full patent to read further.

For more information, see this patent: Frederick, Gail Anna Rahn. Complex composite tokens. U.S. Patent Number 11553352, filed May 27, 2021, and published online on January 10, 2023. Patent URL (for desktop use only): https://ppubs.uspto.gov/pubwebapp/external.html?q=(11553352)&db=USPAT&type=ids

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