##AAMS INTEGRATION

###QUESTIONS

1. Should customer be able to add/remove (install/uninstall) selected app or he always have the same set of apps that can be moderated only in AAMS dashboard?
2. Do we want to completely get rid off service table? What about online player customers (there is no device ID)?
3. Is 'Application list' equivalent to application category/directory (from other app stores)?

###REQUIERMENTS

AAMS API should provide:

• client identification and authorization
• list of client applications with settings
• functionality that allows to add/remove (install/uninstall) app (this feature is currently missing in AAMS)

Problems:

I. Current it's easy to identify client using his device ID (such as MAC address). The problem appears when we want to transform AAMS to general purpose "App Store" that will work e.g. for web browsers as well.

There are 2 ways to solve this issue:

• make AAMS working only with STB devices (and keep naive authorization by device ID)
• add ability to identify other type of clients (it needs login/password authorization mechanism ; we can't just use email for example - it will cause security problems)

II. All currently working apps use service_id for session initialization request.

The problem is that the whole logic of authorizing access to the service is attached to service_id:

• active subscription lookup starts with service_id
• fail-over mechanism depends on services
• service_id is grouping subscriptions (yes, we don't need services for it, but we need to leave key/id that will group subscription within one service/app) ...etc.

There is one more option that we can consider: separate 2 terms: service and app. Services still exists in subscribe (without any settings/configuration data) and apps exists in AAMS with specific configuration that is now stored in subscribe.

###IMPLEMENTATION (draft):

AAMS TODO:

• add settings property to application to AAMS. Make it generic so any settings can be placed there (key-value storage). It allows to use single app with different settings - it covers our use case with single app for multi IPTV services.
• extend AAMS API to provide app installation/deletion
• [OPTIONAL] add global authorization mechanism that turns AAMS to multi-device app store (if we decide to go this direction)
• migrate all current services from subscribe to AAMS

APP-GATEWAY TODO:

• change session initialization mechanism

SUBSCRIBE TODO(it strongly depends on questions asked above)

GENERAL WORKING FLOW

Steps:

1. STB (client) requests AAMS API ; AAMS API responses with list of services (with app URL and settings).
2. STB redirects to specific app URL (since this moment everything happens in context of the specific app).
3. (As example it's IPTV service) App is performing it's internal authorization with App-Gateway.