ISAP

About

This page summarizes the requirements for a simple HBX (Higgins Browser Extension) Provisioning protocol (HBXP).

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.

Terms and Actors

User 

The actor using Higgins and represented by a Higgins Identity Agent and by an XRDS document at an XRDS Provider.

Higgins Identity Agent 

An instance of an HBX and an HWS provisioned and operating on behalf of a User.

HBX (Higgins Browser Extension) 

The portion of a Higgins Identity Agent that runs locally on a User’s device(s).

HWS (Higgins Web Service) 

The portion of a Higgins Identity Agent that runs on a server remote from a User’s device(s).

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.

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.

SEP 

Service Endpoint in an XRDS document.

TOS 

Terms of Service (offered by XRDS Provider and by HWS).

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

1. The protocol MUST be as simple as possible (but no simpler) and 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.

Functional

1. The protocol MUST enable an HBX and HWS to provision an XRDS document so a User can use HBX Auth.
   1. The protocol MUST support registration of a new XRDS document at an XRDS Provider that supports HBXP.
   2. The protocol MUST support provisioning of an existing XRDS document at an XRDS Provider that supports HBXP.
2. Provisioning functions MUST include:
   1. Add a HWS SEP (including priority).
   2. Modify a HWS SEP (all attributes and elements, including priority).
   3. Delete a HWS SEP.
   4. 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).
   5. 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:
   1. Their XRDS Provider while continuing to use the same HWS.
   2. Their HWS while continuing to use the same XRDS Provider.

Usability

1. 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.
   1. This includes communication of -- and explicit user consent to -- the TOS for both the XRDS Provider and HWS.

Security

1. The protocol MUST ensure that the participants being represented to the User by the HBX (the XRDS Provider, HPS, and HWS) are authenticated.
2. The protocol MUST provide reasonable assurance that only the User, XRDS Provider, and HWS can perform the provisioning operations specified by the protocol.
3. The protocol MUST provide reasonable assurance that, when complete, only the User is able to authenticate via HBX Auth.

Privacy

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

Accountability

Currently N/A – accountability is more a function of a generalized provisioning protocol like XRDSP or an authentication protocol like HBX Auth.