Identity API


Considerations


Nomenclature

Device

A device is a unique computer/machine used to connect and interact with the system.

Principal

A principal is an entity that can be authenticated by a computer system or network. It's definition is abstract and not particular to any one part of the API.

User

Every principal that authenticates with the API is represented by a User. It holds basic but unique and hopefully globally accessed things like name, age, email, password, entitlements, social info, etc.. Basically: Some original information about this User, and how they access the API.

User-Profile

Every user will have some personal and app specific information: League details, product references, personal interests, etc.. E.G. My (a fan's) favorite teams, (possibly) Top-level Fantasy data, subscriptions may end up here, weight/height, etc...

Domain

Defines the explicit relationship for given roles and entitlements so that similar/same roles cannot contradict each other. An example is 'NDC' vs 'DAL_CMS' vs 'NOW' where all contain a 'USER' Role, yet their entitlement composition will differ based on novel use cases. E.G. An 'NDC' 'USER' cannot 'READ' documents in 'CMS' like a 'DAL_CMS' 'USER'.

Role

Roles must maintain contextual affinity. Role is specific to a Domain such as 'NDC', or 'DAL_CMS', and defines a collection of entitlements. An Example is 'AUTHOR' which will likely have entitlements to write, edit and publish documents for a specific Domain (e.g. 'DAL_CMS').

Entitlements

Entitlements are a nuanced relationship between a Role and resource - defined by the application owner. An example is 'PUBLISH' for 'DAL_CMS' which gives that Role the ability to publish documents via the Cowboys part of the CMS. Essentially they are permissions.