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

06.25.2007 F2F Agenda

Revision as of 16:43, 26 June 2007 by Paul.socialphysics.org (Talk | contribs) (List of Topics)

Higgins Face-to-Face meeting June 25-27, 2007

Location: at the IBM office on 425 Market Street in San Francisco Room: 5761-19-19201 (19th floor)

Hotel: Those who are participating in Catalyst may want to stay at the nearby Hilton.

The event will start Monday, June 25 at 8:30 and end Wednesday at noon.

Coffee and munchies Monday and Tues morning.

Expected Attendees

Monday morning:

  1. Greg Byrd (IBM/NCSU) - working on the Configuration component
  2. Mike McIntosh (IBM) - working mostly on Token Service
  3. Tony Nadalin (IBM)
  4. Mary Ruddy (Parity, SocialPhysics)
  5. Paul Trevithick (Parity, SocialPhysics)
  6. Jim Sermersheim (Novell) - working on IdAS mostly
  7. Andrew (Andy) Hodgkinson (Novell) - H2 config
  8. Shane Weeden (IBM, Australia)
  9. Bruce Rich (IBM Austin) - working on RP
  10. Anthony Bussani (IBM Zurich) - works on idemix
  11. Abhi Shelat (IBM Zurich)
  12. Markus Sabadello (Parity)

Later:

  1. Drummond Reed (Cordance)
  2. Nataraj Nagaratnam (IBM)
  3. Dale Olds (Novell)
  4. Kermit Snelson (Subjectivity) Tuesday and Wednesday only
  5. Uppili Srinivisan (Oracle)

Monday June 25th --Prep for Interop demo (all day)

9:25am Introductions

9:30 Interop Status/Review

  • Run through each deployment scenario, do all scenarios interop with each other
  • Paul has started to capture interop results here CardSpace_Interop (H1 only)
  • TODO: Paul will update this table with latest results by the end of Monday
  • Discussion of many final bugs, and issues related to interop

10:10 Paul demos H1

  • If you have WinZip installed, then the Higgins.xpi tries to download as a .zip file (and you have to rename it)
  • Agreed that the H2 and H3 do NOT need Terms of Service and Privacy Policy HBX Setup Wizard pages
  • Discussion of need for HBX to handle H3 config as well (e.g. new option to autodetect localhost RPPS service)
  • HBX: need to merge in the latest ZHBX code
  • HBX's "card selector" is NON modal (some of us think this is a bug, some of us think it is a feature)
  • Paul explained that the I-Card Manager (ICM) will be rewritten to use Google's GWT toolkit as its license (Apache 2.0) is more compatible with EPL than what we've been using (LGPL).
  • Feedback on ICM: the "import i-card" button is too small

11:15 AndyH Status of H2

  • Need Kevin Miller's Perpetual Motion Firefox plugin
    • Long term plan to add the ability to launch a native app to HBX (it's needed for H3 in any case)
    • Novell will likely volunteer to do this work (will coordinate with MaximK)
  • H2 on the Bandit site:
    • YUM repository set up (use YAST)
    • RPMs with all dependencies
    • instructions, etc.
  • We'll demo it tomorrow

New Higgins download Page Structure

New structure for http://www.eclipse.org/higgins/downloads.php

  • Component Builds (as it is today)
    • Idas 0.8 Nightly
    • Idas 0.7 Stable
  • Higgins Browser Extension
    • Higgins Browser Extension (just a simple URL (no fancy button, etc.)

2:30pm AnthonyB and AndyH I-card store APIs

  • The proposal is that Higgins standardize an API for managing i-card storage. This would be a lower level API from the I-Card Provider issues
  • Anthony presented IBM's CardStore interfaces
    • synchFromMap()
    • synchFromStore() (e.g. to .crds file)
  • Andy
    • store returns an identifier and a blob--this is what an i-card is instantiated from
  • Questions
    • All agree that it is an import/export format
    • No presumption that .crds is the working format
  • Requirements
    • Should it work with USB (e.g. moveable media)
    • Andy: we already support multiple card stores. The UI component can be actively looking for new stores (e.g. USB key being plugged in) or a hot folder can be specified. We're using the Gnome keyring to store pw. You create a cardstore (automatically put an entry in the keyring associated with the guid of the store). We assoc a pw with the gui of the store. If you take it to another machine.
    • Multiple instances of the CardStore implementations
    • Paul: the question is what layer for triggering should happen.
    • Andy: probably better to have higher level
    • Andy: we need a common exchange format AND storage format. E.g. H1, H2, H3 could all point to.
    • H1: for scalability reasons will probably have to migrate a file to a db-based
    • Paul: we can all agree on the need for common interchange formats
    • Decision1: Higgins will use .crds as the common interchange format
    • Decision2: Higgins will define new card types (beyond p-cards, m-cards)
    • Decision3: Higgins will standardize on Thomas/Anthony's CardStoreStrategy interface. H1 and H2 will adapt to it.

2:55 review of i-card terminology

  • Paul presented; proposal is to use terms narrowly

3:05pm Greg: Configuration Component

  • Mike: wants to look at what OSGI can provide and figure out how this relates to the work we've done so far in the Configuration. Want to fit well into the OSGI model (if it is present).

IdAS Registry -> Discovery Generalization Discussion

  • Need to define requirements better (ability to enumerate is sometimes needed). Some just drop a .jar into a folder; some need complex configuring.
  • Should we define the use cases for each component where we have "registry"-like needs

First step:

  • Write a new IdAS Registry (define new interfaces)
  • Useful idea: XRDS ConfigHandler -> ConfigurableInstance
  • Novell's Context Providers are already implementing ConfigurableComponent
    • Get Factory, configure it with the stuff that will end up in the XRDS SEP
  • Parity will do the same to its Context Providers
  • Decision: Markus and Drummond to create a proposal for how this first registry can work with (a) just a local XRDS file (b) a resolver running on localhost and (c) normal internet-scale XRI resolution
  • first we need a "Context Registry" --a resolver that resolves ContextId to a SEP (looks up the service type)
  • second we need to look for a Context Provider by service type from above
  • the second SEP indicates the ContextFactory class (and any configuration metadata suitable for the factory itself (context independent))
  • instantiate the factory and configure it with the metadata from above
  • on factory call createContext passing the configuration metadata (now a Map) from the first SEP above

4:05pm Jim: IdAS

  • Jim: working on passwords update methods (e.g. updateAuthenticationMaterials) (including at the IContext level) [will try to follow Bruce's proposal]
  • Handling secrets: Mike suggests a special attribute type ISecretAttribute
  • Decision: Bruce is going to write a proposed replacement for IContext.open() to move it more toward a JAAS-like approach (e.g. callback)
  • API extensibility
    • e.g. to handle new use cases: ability to request not just a set of specific attributes, but a restriction on the values of these attributes
    • we don't want to keep adding arguments
    • Proposal: add 1 param to every IdAS method: list of tuples {type-string/URI/etc, object}
    • Raj's Proposal: using callbacks to get additional capabilities (may be issues related to multi-threading)

4:36pm HBX Updates and convergence

  • We have slightly diverged recently
  • The main reason was that H1 codestream uses a app server (e.g. Tomcat)
  • Secondary reason is the ability to kick off the local process
  • Abhi: has changed SOAP messages to deal with optional claims
  • Goal: Same HBX can work with H3 or H2 or H1
  • Not done: RP's Privacy Policy display. New button: "Display Privacy Policy"
    • need to change the messages to include this
  • We need granular attribute selection in HBX (in addition to select all optional attributes)

5:05pm i-card history metadata (per card and per site)

  • we can model this "per card per site" if we retain the last time used at each site for each card
  • currently no stds for representation of this i-card stuff:
    • last time used
    • sites where the card is used
    • what optional claim preferences you selected per site

5:15 Adjourn

Tuesday June 26th -- Higgins F2F meeting (9-5pm)

9:25 Mary: Open Eclipse Higgins Meeting

  • Reminder of IP rules of meeting
  • Higgins developer call canceled for this week

9:25 Paul: Catalyst Session (Paul & Kim)

  • Review of proposed PPT slides to be presented

9:35 Andy: H2 Demo & Discussion

  • Demo of H2 Card Selector
  • UI based on Glade and GTK
  • Uses Gnome keyring
    • currently one process (not ISS Client UI + deamon)
    • OpenSUSE 10.2
    • cards stored in secure card store
    • showed "Card Selector"
    • showed p-card, selection of optional claims
    • showed creation of personal card (no edit fields yet)
    • don't yet show privacy policy
    • plan to make personal cards consistent with m-cards (only show values when hit preview)
    • import .crd of .crds (import of .crds brings them in)
    •  ? where should the issuer be displayed
    • trying to keep card selector to 640x480 (for human factors reasons)
    • card history: plan a popup dialog (also add menu functions)
  • Card Manager demo
    • show issuer and card name
    • you can do a preview (generated by specifying an RP=self)
  • Discussion of architectural differences from H1/H3
    • HBX / KM-PM: as discussed: add capability to shell out to HBX, setup wizard enhancements H1-3
    • I-Card Managers:
      • H3 I-Card Manager:
        • manages .crds files; e.g. read in manipulate, write out
      • H2 I-Card Manager:
        • very similar to H3 but more functionality
      • H1 I-Card Manager

10:30am H1/3 v. H2 harmonization

  1. H2 architecture changes required
    • IdAS in native form
    • "pluggable ISS"
  2. H1/3 architecture changes
    • Rename "ISS Client UI" "I-Card Selector"
    • CardStoreStrategy layer inserted
    • implement SOAP/XML interface to IdAS [IBM likely to volunteer resources for this]

10:45 30-min break

11:15: RP Enablement Component [Bruce]

Java Servlet (2.3 (circa 2001))

  • New RP code (WAR file)
  • We will deploy this onto the same Eclipse server as the higgins Token Service
  • Code to be sumbitted to Higgins project next week
  • Servlet 2.3 Authentication Filter
    • You can snap the filter into any WAR file
    • You configure it though the web.xml (aka deployment descriptor)
  • Also contains a logout servlet
  • Goal is to have a downloadable WAR with comments about how to configure for your location
  • TODO: Paul: figure out where in the CVS to put this code
  • currently no validation on the SAML assertion (e.g. attributes)
  • TODO: add pluggable validation API
  • Also implemented: a listener (e.g. as webapp comes up, reads keystore, etc.)

Demo App

  • one small override to default Apache configuration
  • login.jsp, logout.jsp
  • multilogin.jsp HTML,XHTML triggers
  • index.jsp -- root of the webapp
  • plugable for multiple protocols (OpenID)

Scope, Dimensions of

  1. support for all Higgins-defined web interaction types
    • (e.g. "informationCard", "r-card", "z-card")
  2. languages (Java, PHP, Perl, Python, Ruby, C++)
    • perhaps we need to at least tackle a couple
  3. how app-specific components (e.g. MediaWiki modules, etc.)

Lunch noon-1:30pm

5pm: Adjourn

7pm: Higgins Dinner

  • Restaurant: Buca Di Beppo [approx: 13] 855 Howard Street
  • Near Moscone

Wednesday June 27th -- Higgins F2F meeting (9-noon)

  • Location: Hilton 4th floor, 3rd tower, room 22 & 23
  • Note: no breakfast, coffee, scones, etc. (everyone is on their own)

Wednesday June 27th -- Evening in the hospitality suite (6-9pm)

List of Topics

  • Equinox integration
  • informationCard, web interaction types, extensibility to other card types
  • Higgins Development processes
    • What's not working (e.g. missing nightly build scripts, build script compiler??, automated tests, test doc, missing wiki pages, etc.)
    • General policy for refactoring packages
  • Milestone 0.9
    • Declaring victory on M0.8
    • Planning out M0.9
    • Scheduling next F2F and next demo

See Also

Back to the top