Higgins and FC2

{{#eclipseproject:technology.higgins}}

This page describes discussions between Higgins and FC2

Notes

• 11 April 2008 - Olivier Maas contacts the Higgins project and introduces his project to Mary and Paul
• 2 June 2008 - Paul presents a Higgins at an FC2 F2F meeting in Paris (see below)

FC2 / Higgins Meeting in Paris 2nd June 2008

• FC2 Agenda
  • 09.30 FC2 consortium and project presentation by J.P. Tual (head of the consortium)
  • 10.30 General Higgins presentation and roadmap by P.Trevithick
  • 12.30 Lunch
  • 14.00 Design and implementation of a user centric federation : Review of FC² use cases and issues - benefits of using Higgins and infocards for FC2 and for the final user
  • 15.30 Technical meeting : how to achieve Infocard / Liberty / OpenID interoperability using Higgins, how to share attributes, how to achieve SSO?
  • 17.00 Next steps : FC2 - Higgins collaboration
• 2 June 2008 - Paul presents a slightly earlier version of PPT

Higgins-related Issues Raised

The following are a few notes to give a sense of the discussion in the room. There were approx 20 FC2 consortium members present in addition to Paul.

1. Selecting N>1 Cards
   • There are a number of use cases wherein the user needs to present two or three i-cards in quick succession. This involves the selector popping up multiple times in a row—which would seem annoying. There are two requirements. First we would need to extend the RP “security policy” expression to request claims that could come from a set of N>1 (received) security tokens. Second, we would need to enhance the Higgins selector(s) to be able to handle a “multiple” card selection user experience. The Higgins project has experimented with this kind of N>1 selection, but much more design and exploration is required.
2. Compound Managed Cards.
   • A new idea was discussed as another solution to the N>1 required tokens/cards problem. The concept would be to support “compound” managed cards. Instead of allowing only one token service endpoint (and its supported claims) to be described, the card could support two or three (probably not more) sets of endpoint (and supported claim) metadata sections. This is a very new idea. Much more thought is needed to see if it is really a good idea or not from the use’s point of view.
3. Using Mac KeyRing to manage the selector’s “master” password.
4. Card-based Permissioning.
   • There were use cases described that moved beyond simply using cards for authorization. These cases involved the user granting permission for service A to consume data from service B. This is analogous to some “card-based Oauth” conversations that have been discussed within the Higgins project. The user would have a card from service B. When service A required permission from the user to consume data from service B, the selector would pop up, the “B” card would appear, and somewhere associated closely with the “B” card the permission question text would appear. E.g. “Do you <service A> to access your mobile telephone number from <service B>? [YES][NO]
5. Split Managed Cards.
   • It was requested that a new kind of “split” Managed Card might be required. This card type would contain two endpoint references instead of the usual one. The first would describe an authentication service. The second would be the “real” token service. The selector would request an authentication token from the first service and use it in its request to the second (real) token service.
6. Privacy Plugins for the Selector.
   • This was a very fuzzy, high level idea. The notion was that a privacy/data-handling-policy matching plugin could provide a second dimension of matching (beyond today’s matching only on the “supported claims” dimension. The RP (or SP if you prefer) could state its privacy/data-handling-policy (analogously to how today the RP describes the set of claims it requires, etc.) and the user and the IdP might also have policy constraints. The privacy plugin would provide the algorithm and UI to support matching on this second dimension. [The Higgins project has been doing some early work in this area].
7. Implicit Authentication Method for Cards.
   • After the standard UN/PW, backed-by-personal, x509, and Kerberos auth methods were described, there was a request to be able to use “implicit” auth methods as another alternative—methods such as detecting the IP address of the user’s machine.
8. Pluggable Authentication.
   • A further suggestion was made that perhaps the Higgins selector should support a plugin architecture for authentication. The selector could provide a display canvas for the plugin’s user interface. The selector would delegate to the plugins if other than the built-in methods were required.
9. Declarative vs. Justified vs. Certified Attributes/Claims.
   • Particularly relevant for R-Cards. There was a desire to make a finer set of distinctions than the “self-asserted” (aka Declarative) vs. “3rd party” (Certified) distinction. In an R-Card scenario, a user might self-assert their home address. The other (business) party might validate this address to the best of their ability. This would be a “Justified” (validated) attribute/claim value but it would fall short of being “Certified”--wherin the other (business) party is stating that it is the authority for this particular value.
10. FC2 Common Schema.
    • The use cases envisioned require attributes/claims to be consistent across multiple systems and protocols (including WS-Trust and ID-WSF protocols). There was a need to use a normalized schema (and schema mapping) such that across the entire system attributes were consistently named. [There is existing interest and some small existing work going on in this area in the Higgins project and in related projects].
11. Preserving Authentication State.
    • There seemed to be a lot of difficult work to be done to make sure that the user wasn’t unduly annoyed by repeated authentication interactions. PaulT described the “remember this card” and “remember this password” options in the (hosted) Higgins selector, but it was felt that more work was required to have a more general and robust solution.
12. ID-WSF and SAML2 integration.
    • The envisioned use cases require the user to use information cards that are backed by both the existing WS-Trust protocols as well as SAML2 and ID-WSF protocols. The expectation would be, for example, that the user would have a “government” card that would access the government circle of trust, another “telco” card that would access a telco-based circle of trust, and yet others that would use traditional WS-Trust to interact with financial IdPs.