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

HBX Auth

Revision as of 15:59, 3 December 2007 by Drummond.reed.cordance.net (Talk | contribs) (New page: == About == This page summarizes the requirements for an HBX (Higgins Browser Extension) Authentication protocol (HBX Auth). This protocol is needed for the case where an HBX uses a ...)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

About

This page summarizes the requirements for an HBX (Higgins Browser Extension) Authentication protocol (HBX Auth).

This protocol is needed for the case where an HBX uses a Web-based i-card service (Higgins Web Service) and needs an easy, highly secure way to sign into it. Provisioning an HBX, an XRDS Provider, and a Higgins Web Service to be able to use HBX Auth is enabled by the HBX Provisioning protocol HBXP.

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).
  • 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.
  • HBXP – The HBX Provisioning protocol defined by the Higgins Project to configure an HBX to perform HBX Auth.
  • HBX Auth – The protocol defined here.

General

  1. The protocol MUST be as simple as possible (but no simpler) and easy to implement.
  2. The protocol MUST work with any XRDS Provider supporting HBXP.

Functional

  1. The protocol MUST enable an HBX to authenticate to an XRDS Provider and subsequently to an associated HWS provisioned with HBXP.

Usability

  1. The protocol MUST enable it to be as simple as possible (but no simpler) for a User to authenticate their HBX with reasonable security to an XRDS Provider and an HWS.

Security

  1. The protocol MUST provide reasonably strong authentication.
  2. The protocol MUST be phishing-resistant.

Open Issues

  1. Is session management in scope or out of scope for HBX Auth?

Privacy

  1. As with HBXP, 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

  1. The protocol MUST support the ability for implementers to provide an audit trail of protocol uses/abuses to the User and the XRDS Provider.

Copyright © Eclipse Foundation, Inc. All Rights Reserved.