Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
This page summarizes the requirements for a proposed protocol called ISAP (Identity Selector Authentication Protocol).
The purpose of ISAP is to enable a client-side Identity Selector to be provisioned for and authenticate to a server-side Identity Agent for "in the cloud" storage, access, and usage of a User's i-card collection. ISAP will enables a User to:
- Setup and configure their first front end Identity Selector and their first back end Identity Agent account for the first time.
- Authenticate to their Identity Agent using their Identity Selector.
- Register, provision, and authenticate additional Identity Selectors (e.g., on additional devices) to talk to the same back end Identity Agent.
- Register, provision, and authenticate additional back end Identity Agent accounts that can be talked to from the same front end Identity Selector.
- Recover an Identity Selector if it or their Device crashes or is lost.
- The actor using an IS on a Device for identity selection and i-card management.
- The hardware employed by a User to run an IS.
- IS (Identity Selector)
- The trusted code that runs locally on a Device to authenticate the User and facilitate i-card selection.
- IA (Identity Agent)
- The trusted code that runs on a server to store a User’s i-cards so the User can manage them from all their devices.
- IA Provider
- The service provider offering an IA to the User.
- The Identity Selector Authentication Protocol defined here.
- ISAP Provider
- The service provider offering ISAP authentication service to the User.
- ISPS (Identity Selector Provisioning Service)
- A web service provided on behalf of a ISAP community to securely and privately provide ISAP provisioning metadata to Users in the community.
- ISPS Provider
- The service provider offering ISPS service to the Users in an ISAP community.
- XRDS Document
- An identity service discovery document for the User hosted by an XRDS Provider as defined by XRI Resolution 2.0 Committee Draft 02.
- XRDS Provider
- The service provider hosting the XRDS document and exposing the ISAP provisioning interface.
- The generic XRDS Provisioning protocol currently being defined at XDI.org.
- Service Endpoint in an XRDS document.
- Terms of Service (offered by the XRDS Provider, IdP, and IA).
- The protocol MUST be as simple as possible (but no simpler) and be relatively easy to implement.
- The protocol MUST work with any OpenID-addressable XRDS document, i.e., XRDS documents that represent URLs (HTTP(S) URIs), XRIs, or any combination.
- The protocol MUST enable an IS, ISAP Provider, and IA Provider to provision an XRDS document so a User can use ISAP, including:
- Registration of a new XRDS document at an XRDS Provider that supports ISAP.
- Provisioning of an existing XRDS document at an XRDS Provider that supports ISAP.
- XRDS provisioning functions MUST include:
- Add an ISAP SEP (including priority).
- Modify an ISAP SEP (all attributes and elements, including priority).
- Delete an ISAP SEP.
- The protocol MUST provision the public/private key pairs necessary for the IS to perform client-side encryption/decryption of all data stored at the IA.
- The protocol MUST ensure that the key pairs can be recovered from the ISAP Provider if the IS crashes or the Device is disabled or lost.
- The protocol MUST support the ability for a User to provision more than one ISAP SEP in their XRDS document (enabling the User to select a different IA in their IS at runtime).
- The protocol MUST support the ability for the User to add, modify, or delete the URLs or XRI i-name(s) they have registered with the XRDS Provider that resolve to the XRDS document.
- The protocol MUST support the ability for a User to change any of the following without changing the others:
- Their XRDS Provider.
- Their ISAP Provider.
- Their IA Provider.
- The protocol MUST enable an XRDS Provider, ISPS Provider, ISAP Provider and an IA to communicate to a User adequate information for the User to make an informed decision regarding registration and authorization of the XRDS Provider, the ISAP Provider, and the IA Provider.
- This includes communication of -- and explicit user consent to -- the TOS for all Providers.
- The protocol MUST NOT require the User to remember more than one credential for daily usage.
- The protocol MAY require the User to remember/look up a second credential for first-time registration/reprovisioning of an an IS.
- The protocol MUST NOT require but MUST support the use of strong portable credentials such as OTP (one-time passwords) or keyfobs.
- The protocol MAY require the use of two or more communication/authentication channels for first-time provisioning or reprovisioning on an IS.
- The protocol MUST provide reasonably strong authentication.
- The protocol MUST be highly phishing-resistant.
- The protocol MUST ensure that during provisioning operations, the participants being represented to the User by the IS (the XRDS Provider, ISAP Provider, and IA Provider) are authenticated.
- The protocol MUST provide reasonable assurance that only the User, XRDS Provider, ISAP Provider, and IA Provider can perform the provisioning operations specified by the protocol.
- The protocol MUST ensure that if the IS is hacked, an attacker cannot gain access to or take over the IA (i.e., the User's authentication credential is required).
- The User's authentication credential MUST NOT ever be in the clear except when entered into the IS by the User.
- The protocol MUST ensure that neither the XRDS Provider, the ISAP Provider, or the IA Provider may impersonate the User, i.e., only the User may authenticate via ISAP and access the full features of their IA(s).
- The protocol MUST support non-correlation of the User between the ISAP Provider and the IA. This means it MUST NOT require the URL(s) or XRI(s) used to identify the User and resolve to the User’s XRDS document at the XRDS Provider and ISAP Provider to be shared with the IA Provider. This enables an IA to operate (using appropriate data encryption) in a fully data blinded mode, where it has no knowledge of the identity of the User.
Denial of Service/Robot Protection
- The protocol MUST provide a reasonable means of preventing DOS attackes and robot-based registration and creation of bogus XRDS documents, ISAP endpoints, and IAs.
- The protocol MUST support the ability for an ISAP Provider and IA Provider to provide an audit trail of protocol uses/abuses to the User.