Skip to main content

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.

Jump to: navigation, search

Difference between revisions of "ISAP"

m (HBXP moved to ISAP: Feedback at Internet Identity Workshop was that this protocol needed to be more generalized, so we're renaming it Identity Selector Authentication Protocol)
(Authentication)
 
(One intermediate revision by the same user not shown)
Line 1: Line 1:
 
== About ==
 
== About ==
This page summarizes the requirements for a simple HBX (Higgins Browser Extension) Provisioning protocol ([[HBXP]]).  
+
This page summarizes the requirements for a proposed protocol called [[ISAP]] (Identity Selector Authentication Protocol).
  
This protocol is needed for the case where an HBX uses a Web-based i-card service (Higgins Web Service). It provides the ability for a Higgins user to setup and configure their HBX to use the [[HBX Auth]] protocol to securely and privately talk to the XRDS Provider and the Higgins Web Service of their choice.  
+
== Goals ==
 +
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.
  
== Terms and Actors ==
+
== Terms ==
; User : The actor using Higgins and represented by a Higgins Identity Agent and by an XRDS document at an XRDS Provider.
+
; User : The actor using an IS on a Device for identity selection and i-card management.
; Higgins Identity Agent : An instance of an HBX and an HWS provisioned and operating on behalf of a User.
+
; Device : The hardware employed by a User to run an IS.
; HBX (Higgins Browser Extension) :  The portion of a Higgins Identity Agent that runs locally on a User’s device(s).
+
; IS (Identity Selector) :  The trusted code that runs locally on a Device to authenticate the User and facilitate i-card selection.
; HWS (Higgins Web Service) : The portion of a Higgins Identity Agent that runs on a server remote from a User’s device(s).
+
; 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.
; HPS (Higgins Provisioning Service) : A web service provided on behalf of a Higgins community to securely and privately provide HBXP provisioning metadata to Users in the community.
+
; IA Provider : The service provider offering an IA to the User.
 +
; [[ISAP]] : 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 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 actor hosting the XRDS document and exposing the HBXP interface.
+
; XRDS Provider : The service provider hosting the XRDS document and exposing the ISAP provisioning interface.
 +
; [http://dev.inames.net/wiki/XRDSP XRDSP] : The generic XRDS Provisioning protocol currently being defined at [http://iss.xdi.org XDI.org].
 
; SEP : Service Endpoint in an XRDS document.
 
; SEP : Service Endpoint in an XRDS document.
; TOS : Terms of Service (offered by XRDS Provider and by HWS).
+
; TOS : Terms of Service (offered by the XRDS Provider, IdP, and IA).
; [http://dev.inames.net/wiki/XRDSP XRDSP] : The generic XRDS Provisioning protocol defined at XDI.org.
+
; [[HBXP]] : The HBX Provisioning protocol defined by the Higgins Project.
+
; [[HBX Auth]] : The HBX Authentication protocol defined by the Higgins Project that enables the HBX to securely and privately authenticate to the HWS. The purpose of [[HBXP]] is to setup and configure an HBX and HWS to use [[HBX Auth]].
+
  
 
== General ==
 
== General ==
# The protocol MUST be as simple as possible (but no simpler) and easy to implement.
+
# 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 work with any OpenID-addressable XRDS document, i.e., XRDS documents that represent URLs (HTTP(S) URIs), XRIs, or any combination.
  
== Functional ==
+
== XRDS Provisioning ==
# The protocol MUST enable an HBX and HWS to provision an XRDS document so a User can use [[HBX Auth]].
+
# The protocol MUST enable an IS, ISAP Provider, and IA Provider to provision an XRDS document so a User can use [[ISAP]], including:
## The protocol MUST support registration of a new XRDS document at an XRDS Provider that supports [[HBXP]].
+
## Registration of a new XRDS document at an XRDS Provider that supports [[ISAP]].
## The protocol MUST support provisioning of an existing XRDS document at an XRDS Provider that supports [[HBXP]].
+
## Provisioning of an existing XRDS document at an XRDS Provider that supports [[ISAP]].
# Provisioning functions MUST include:
+
# XRDS provisioning functions MUST include:
## Add a HWS SEP (including priority).
+
## Add an ISAP SEP (including priority).
## Modify a HWS SEP (all attributes and elements, including priority).
+
## Modify an ISAP SEP (all attributes and elements, including priority).
## Delete a HWS SEP.
+
## Delete an ISAP SEP.
## The protocol MUST support the ability for a User to provision more than one HWS in their XRDS document (enabling the User to select a HWS in the HBX 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.
+
== PKI Provisioning ==
# The protocol MUST support the ability for a User to change:
+
# 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.
## Their XRDS Provider while continuing to use the same HWS.
+
# 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.
## Their HWS while continuing to use the same XRDS Provider.
+
 
 +
== Portability ==
 +
# 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.
  
 
== Usability ==
 
== Usability ==
# The protocol MUST enable an XRDS Provider and an HWS to communicate to a User adequate information for the User to make an informed decision regarding registration with the XRDS Provider and authorization of the HWS.
+
# 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 both the XRDS Provider and HWS.
+
## This includes communication of -- and explicit user consent to -- the TOS for all Providers.
 +
# Credentials/passwords:
 +
## 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.
  
== Security ==
+
== Authentication ==
# The protocol MUST ensure that the participants being represented to the User by the HBX (the XRDS Provider, HPS, and HWS) are authenticated.
+
# The protocol MUST provide reasonably strong authentication.
# The protocol MUST provide reasonable assurance that only the User, XRDS Provider, and HWS can perform the provisioning operations specified by the protocol.
+
# The protocol MUST be highly phishing-resistant.
# The protocol MUST provide reasonable assurance that, when complete, only the User is able to authenticate via [[HBX Auth]].
+
# 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.
 +
 
 +
== Impersonation ==
 +
# 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).
  
 
== Privacy ==
 
== Privacy ==
# The protocol MUST support non-correlation between the XRDS Provider and the HWS, i.e., the option for the URL(s) or XRI(s) used to identify the User and resolve to the User’s XRDS document at the XRDS Provider to NOT be shared with the HWS. This enables an HWS to operate (using appropriate data encryption) in a fully data blinded mode, where it has no knowledge of the identity of the User.
+
# 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.
  
 
== Accountability ==
 
== Accountability ==
''Currently N/A – accountability is more a function of a generalized provisioning protocol like [http://dev.inames.net/wiki/XRDSP XRDSP] or an authentication protocol like [[HBX Auth]].''
+
# 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.

Latest revision as of 16:30, 12 December 2007

About

This page summarizes the requirements for a proposed protocol called ISAP (Identity Selector Authentication Protocol).

Goals

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.

Terms

User 
The actor using an IS on a Device for identity selection and i-card management.
Device 
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.
ISAP 
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.
XRDSP 
The generic XRDS Provisioning protocol currently being defined at XDI.org.
SEP 
Service Endpoint in an XRDS document.
TOS 
Terms of Service (offered by the XRDS Provider, IdP, and IA).

General

  1. The protocol MUST be as simple as possible (but no simpler) and be relatively easy to implement.
  2. The protocol MUST work with any OpenID-addressable XRDS document, i.e., XRDS documents that represent URLs (HTTP(S) URIs), XRIs, or any combination.

XRDS Provisioning

  1. The protocol MUST enable an IS, ISAP Provider, and IA Provider to provision an XRDS document so a User can use ISAP, including:
    1. Registration of a new XRDS document at an XRDS Provider that supports ISAP.
    2. Provisioning of an existing XRDS document at an XRDS Provider that supports ISAP.
  2. XRDS provisioning functions MUST include:
    1. Add an ISAP SEP (including priority).
    2. Modify an ISAP SEP (all attributes and elements, including priority).
    3. Delete an ISAP SEP.

PKI Provisioning

  1. 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.
  2. 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.

Portability

  1. 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).
  2. 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.
  3. The protocol MUST support the ability for a User to change any of the following without changing the others:
    1. Their XRDS Provider.
    2. Their ISAP Provider.
    3. Their IA Provider.

Usability

  1. 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.
    1. This includes communication of -- and explicit user consent to -- the TOS for all Providers.
  2. Credentials/passwords:
    1. The protocol MUST NOT require the User to remember more than one credential for daily usage.
    2. The protocol MAY require the User to remember/look up a second credential for first-time registration/reprovisioning of an an IS.
  3. The protocol MUST NOT require but MUST support the use of strong portable credentials such as OTP (one-time passwords) or keyfobs.
  4. The protocol MAY require the use of two or more communication/authentication channels for first-time provisioning or reprovisioning on an IS.

Authentication

  1. The protocol MUST provide reasonably strong authentication.
  2. The protocol MUST be highly phishing-resistant.
  3. 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.
  4. 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.
  5. 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).
  6. The User's authentication credential MUST NOT ever be in the clear except when entered into the IS by the User.

Impersonation

  1. 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).

Privacy

  1. 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

  1. 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.

Accountability

  1. 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.

Back to the top