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)
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.
IssueID | Issue Title | Notes | ||||||||
---|---|---|---|---|---|---|---|---|---|---|
1 | Entities as Agents (Clients, Services)
| API Security turns out to be the driver for taking up non-person entities | ||||||||
2 | Authorization policies have a fundamental structure
| |||||||||
3 | ||||||||||
4 |