Browse Prior Art Database

Framework for API Access Brokerage

IP.com Disclosure Number: IPCOM000249574D
Publication Date: 2017-Mar-03
Document File: 2 page(s) / 29K

Publishing Venue

The IP.com Prior Art Database

Abstract

1) An average smartphone user has a considerable number of third party applications downloaded from app stores. Many of these applications require access to user resources such as ID, profile, location, messaging etc. for which they need to connect to multiple service providers. The user is subject to an authentication, delegation workflow for each external service used by an application. This has to be performed individually for each application installed by the user. 2) Each application is responsible for connecting with other domains and managing user identity across domains. Much of the effort in integrating with a new service goes into implementing the handshake required for receiving end user authorization for resources hosted by the provider. 3) Applications need to make multiple invocations to perform a single task. Not only are such low level resource requests inefficient but also undesirable from user privacy perspective. Exposing a low level information model to third parties results in more information being shared, than strictly necessary. Moreover, permissions granted to third parties can be used outside the intended context.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 42% of the total text.

1

Framework for API Access Brokerage

Users typically interact with a large number of service providers over the cloud, each specializing in providing a certain type of service, e.g. email, chat, blogging, calendar, mapping, content sharing, location sharing etc. By virtue of providing the service, the service provider maintains a set of resources on behalf of the user. These resources could include personal information such as profile, contacts, pictures etc. but also basic capabilities offered by the service provider platform, such as ability to read or post messages on behalf of the user, getting user location, status etc. Service provider platforms often expose these resources to third parties through APIs. This allows third parties to build applications that leverage these capabilities to provide add-on services or for enriching user experience.

To protect privacy of the user, service providers hosting these resources require user to explicitly authorize access to third parties. User is authenticated by the service provider and then requested to delegate permissions to access a resource to a third party. This allows the third party to make authorized calls to the service provider API to obtain the resource for a limited time. While this approach is better than sharing user credentials with third parties, we note the following drawbacks with the current approach.

1) An average smartphone user has a considerable number of third party applications downloaded from app stores. Many of these applications require access to user resources such as ID, profile, location, messaging etc. for which they need to connect to multiple service providers. The user is subject to an authentication, delegation workflow for each external service used by an application. This has to be performed individually for each application installed by the user. 2) Each application is responsible for connecting with other domains and managing user identity across domains. Much of the effort in integrating with a new service goes into implementing the handshake required for receiving end user authorization for resources hosted by the provider. 3) Applications need to make multiple invocations to perform a single task. Not only are such low level resource requests inefficient but also undesirable from user privacy perspective. Exposing a low level information model to third parties results in more information being shared, than strictly necessary. Moreover, permissions granted to third parties can be used outside the intended context.

Prior Art • Identity as a service protocols such as OAuth 2.0 allow a user to share resources at an API provider with a third party application without sharing credentials with a third party. http://tools.ietf.org/html/rfc6749 • Unified social network APIs: Singly.com and OneAll provide APIs that expose information from multiple social network API providers.

http://www.oneall.com/ http://www.singly.com/ • US8549073 B2: Cross social network data...