These are the high level requirements for the framework.
Service provider's point of view
Enable users to use a strong password by not requiring them to enter the password frequently. It's also possible to automate password generation, so users don’t have to remember passwords at all.
Strong authentication methods
Strong authentication methods should be used to verify the user, application, and user's consent for the application to access their data.
Credential access control
Only explicitly allowed applications can access the stored credentials.
Whenever necessary, it must be possible for an application or authentication server to trigger a secure authorization dialog with a custom message to the user. The user may be required to enter their credentials for authorization or user verification purposes. Even if the original action was requested by an application, it must not be possible for the application to forge the message triggered by the server. When necessary, it must be possible to display CAPTCHA-images, as part of the user authorization.
Display of custom elements on request
The application or authentication server must be able to trigger custom messages requesting acceptance from the user, such as updates to the terms of service (TOS).
Service credential registration
It must be possible to implement service-side credential creation/registration from an application. This can be used to create new service-side accounts, or change credentials of an existing account.
It should be possible to associate custom information, such as billing information with stored credentials.
The entity storing the credentials must be able to specify the methods and realms the credential can be used for.
It must be possible to validate the correctness or availability of the identity information, including the secret, locally or remotely, before storing the identity.
User's point of view
The user should have to enter his credentials only once per service side account, unless specific user authorization is needed for the application.
Credentials should be stored such that a third party cannot access or use the stored credentials, in case the device is lost or stolen. Even in case where the attacker is attempting to directly connect and manipulate the physical storage device.
It must be possible to safely erase the stored credentials, in case the user wants to sell or give away his device. This operation must be able to be performed by service point and should be able to be performed by the user remotely. It must not be possible for the new device owner to access credentials removed in such a way.
The user should be able to select a credential from a set of applicable ones, whenever necessary.
The user must be able to securely store their credentials. The user must also be able to decide whether a secret is stored, or just an identity.
In the case where a secret is not stored, it must be cached as long as active sessions exist or until sign-out is explicitly triggered. The secret must be prompted from the user only once, even if multiple applications are using the identity.
It must be possible to interface to hardware backed methods through the client API.
It must be possible for the user to change his secret. Whenever the secret has been changed at the service side, the user must be prompted for a new one in a secure way. The user must be prompted only once per secret change, per identity, even if multiple applications are using the same identity.
The user should be able to see, modify, and delete the stored identities. The user should be also able to authorize and de-authorize applications and/or application groups to use the identity.
The user must be able to securely back up the stored identities. It must be also possible for the user to restore the backup on a new device.
Device point of view
Malicious or unauthorized applications must not have access to the user’s secrets.
Secure user interface
It must not be possible for third party application to self-authorize any operations that need the user’s authorization. Malicious applications should not be able to fake or otherwise misrepresent the dialogs requesting user’s authorization.
Network usage must be minimized, for example by caching valid authentication tokens. Whenever an application is closed and restarted, it must be able to re-acquire the previous, still valid authentication token.
The framework must be able to determine whether the calling application has the right to perform the requested operation with the stored identity.
Application point of view
The application must be able to request authentication using the stored secret. The application should be able to perform this without retrieving the secret. Well known, standard internet protocols or methods should be supported by the framework. The application must be able to use these protocols or methods without having to re-implement them.
Standard PKI operations must be supported using stored keys, without retrieving the keys to the application.
Whenever the application requests an authentication token, the framework must renew the token automatically, if it has become invalid.
Whenever it is necessary to prompt the user for actions related to the request issued by an application, any required user interaction must happen transparently from the application’s point of view. It must be possible to make this prompt modal to the calling. It should be possible to embed the prompt to the calling application.
The storage must guarantee integrity and security of the stored secrets to the overall level of the platform. Whenever a hardware platform supports security features, those should be used for the secret storage implementation.
It must be possible to store and retrieve standard X.509 certificates. Standard envelopes, such as PKCS#7,8,12, must be supported. It must be possible to limit access scope of the stored certificates by user, application, or application group.