Fundamentals of API Authorization
Regardless of the particular machinery involved, users and clients must identify themselves to a service. This means users and clients have identities and credentials.
Initial axioms (from Jim Fox)
- Internet2 has a recommended identity solution for people users --- Shibboleth and InCommon metadata.
- Internet2 has an identity system for services --- InCommon Certificate Service.
- Internet2 is all about federation and inter-institutional collaboration.
Users are already well taken care of with Shibboleth, InCommon metadata and person registries. We are developing APIs for the latter. A service can easily identify a user and know about her (via attributes). Federation allows services to identify users from different institutions.
What is needed is similar support for API clients---a registry of entities. An Entity Registry, of both services and clients, supported by a standardized API, seems necessary. Entity attributes, while not the same as those of a person, are similar and could be handled by similar APIs.
The InCommon Certificate Authority already gives us one potential method of support for entity federation. A client could use its certificate to register with an entity registry, or to get a credential from an authorization service.