ULX Face-to-face Meeting 2010-10-19

Owned by Former user (Deleted)
Last updated: Nov 08, 2010 by Former user (Deleted)Version comment
5 min read

Kantara ULX GROUP Teleconference

Date and Time

  • Date: 2009-10-19
  • Time: 1-5pm
  • Location: FT Labs

Attendees

  1. Gael Gourmelen
  2. Ingo Friese
  3. Benoit Bailleux
  4. Bill Braithwaite
  5. Sebastien Brault (FT)
  6. Alam Mohammed
  7. Fulup Ar Foll
  8. Mikael Atest
  9. Keith Uber
  10. Sampo Kellomaki
  11. Paul Trevithick
  12. Trent Adams

Agenda

  1. Introductions
  2. Use case #1
  3. General observations
  4. Meeting frequency

Minutes

Definitions
  • We agreed to use the term "ISA" (Identity Selection Agent) as the thing that presents the UI that allows a user to select an IdP across these three ISA architectures:
    • RP-embedded (e.g. our prototype)
    • Active Client (e.g. some future version of Higgins or OpenInfoCard)
    • Website (analogous to how Janrain's hosted service works, or how Orange's prototype (http://quizagain.com) works)
  • We noticed that there are two kinds of ISA implementations:
    • ISAs that know something about the user (e.g. what IdPs they have accounts on, or prefer, etc.)
    • ISAs that know nothing at all about the user
Scope of ULX Project
  • If you think about the ISA being a hub with three spokes: the human-user, the RP and the IdP.
  • To date we've focused on the ISA-to-human interaction. 
  • We need to do more usability testing of our UX but at least we have a straw man to test.
  • Action-Item: Valeska to double check that our design is compatible with support for people with disabilities
  • Moving forward we are starting to specify the RP-to-ISA (one way) data flow and IdP-to-ISA (one way) data flow
Additional Semantics in RP-to-ISA data flow (part I)

We discussed the need for these two additional metadata fields:

  • "screenType": a four valued field: WAP, MobileWeb, Web, TV
  • "language": the language that the ISA should use to display its little bits of text

Action-Item: Gael agreed to add the above to the Inputs to the Selection UI and send an email to Scott to inform him that these should be considered for inclusion into the SAML UI Metadata spec.

Note: Ideally the ISA should send the above two fields to the IdP when invoking the IdP. This, however, is out of scope of the ULX WG.

Additional Semantics in RP-to-ISA data flow (part II)

We discussed the need to support "grouping" of IdPs in the ISA. This allows the RP to organize sets of IdPs into some groups (categories). These groups could be based on the kind of IdP (e.g. "banks", "national-id", "personal-idp"), or based on LOA, or authentication type. Requirements:

  • Support for N groups
  • Each group is a text string
  • The RP would specify an ordered list of groups with (trusted) IdPs listed (in order?) within each group
  • There is a ULX-published "well known group" strings that SHOULD be used. 
    • COMMENT: Why do we need to get Kantara ULX involved in creating this recommended registry if the groupings are entirely defined by the RP? 

PAUL: We need more discussion on this.

Additional Semantics in RP-to-ISA data flow (part III)
  • Currently we've been thinking that the RP would explicitly list the IdPs that it trusts. 
  • But we should add support for Trust Framework white lists. So the RP would just list the Trust Framework (aka Federation) instead of a list of IdPs
Staying out of the authN/Z flows

There was a lot of discussion of the role of ULX and the ISA component in the overall architecture. The general consensus was that we are trying to stay away from whatever authentication and authorization flows.

Some felt that the scope of ULX should include all three of these:

  • The definition of the semantics of RP-to-ISA and IdP-to-ISA metadata
  • The definition of a concrete data format (e.g. JSON) for RP-to-ISA and IdP-to-ISA metadata
  • The definition of a method (for each of the three ISA architectures) for fetching these two kinds of metadata

We discussed that there are three possible models of how an ISA can work WRT existing authN/Z flows:

  1. The ISA only makes a choice of IdP and gets out of the way. The RP engages directly with the user's choice of IdP. In other words the RP trusts the IdP. No trust is required in the ISA itself.
  2. The IdP-to-RP chain of trust is cut in half. The RP trusts the ISA. The ISA acts as an RP from the point of view of the IdP. The IdP provides claims (e.g. SAML tokens) to the ISA. The ISA forwards the claims/values to the RP.
  3. A variant on #2 above where there are two Trust Frameworks involved: IdPs-to-ISA trust framework, and ISA-to-RPs trust framework.

Most felt that the choice of model (above) is not relevant to the work of this ULX WG.

Assurance levels (LOA) of attributes/claims

There was a discussion about the desirability of being able to have RPs specify the minimum LOA they require for a particular attribute. Lots of questions about how the LOA should be defined.

UX Documentation Working Draft
  • There was general agreement that we need a UX Design Considerations (or some such name) document to go along with our dynamic HTML prototype of our ISA.
  • This document should include documentation of the design decisions that have been made. For example:
    • Why do we not show the claims being requested? OAuth makes this impossible to know, but other protocols are declarative, so why don't we show them?
    • Why do we think the UX meets disability requirements?
    • Why do we show 6 account-buttons?
    • Why are they mini-card-shaped?
    • Why do we have the search field?
    • Why didn't we include direct support for username/password on the main surface of the ISA? 
    • Why did we NOT specify a ULX-standardized "login/connect/whateveryoucallit" button as Mozilla Account Manager is doing. Why did we decide to allow the RP site to do whatever it wishes to invoke the ISA)?
    • What are the width and height of the account-buttons
    • Why can you only choose one account button (in other words why did we choose to NOT support claims aggregation (from multiple IdPs))? Do we have a bias towards just quickly getting the user signed in and then ask the user later about getting more claims.
ULX Scope/Futures
  • Sampo asked if the ULX group is trying to define how an ISA is triggered?
    • PAUL: this is currently undefined for the Website-based ISA architecture.
    • PAUL: Avoco, Orange, DT and Janrain should have input here.
  • As the user fills in a form, the RP captures the data. It was suggested that we could define ways that these data attributes could be captured and with the click of a button stored into a personal data store (or and ISA/PDS combination)
ULX Budget
  • We asked the Kantara LC for 5,000 USD for 2011. (We asked for $10k for 2010).
Mikael from L'Entrouvert Presentation

Mikael presented some research work (based on his earlier PhD work) on an "ISA" (what he called a RUE (Rich User Environment)). The architecture that he's looking at is cloud-based and is a Web proxy from the point of view of the browser. This eliminates the need for an active client, yet it can intercept existing auth flows (e.g. OpenID), etc. and can support multiple protocols, could support ZKP (zero knowledge proofs (e.g. uProve)), etc. His trust model was that the user trusts the RUE and the RUE interacts with RPs and IdPs on the user's behalf.

Next Teleconference

  • Time: 08:00 PDT | 11:00 EDT | 15:00 UTC/GMT | 17:00 CEST (Time Chart)
  • Skype: +9900827042954214
  • US Dial-In: +1-201-793-9022
  • Room Code: 295-4214