Jump to: navigation, search

11.16.2006 F2F Outcomes

More conclusions

  • IdAS: On the issue of the java object/DigitalIdentity parameter to IContext.open(): We reiterated our earlier design: we will add an IContext.getOpenPolicy() method that will (in the long run) return a description of this Context's authentication policy expressed in our emerging (and badly named) "RP Security Policy" format. The policy will indicate the range of acceptable DIs that can be passed to IContext.open().
  • IdAS: the proposal to add transaction support methods like as begin(), commit() and rollback()) to IContext was discussed. Decisions reached:
    • We should not add any of these methods because implementing them in ALL Context Provider implementations is, for some kinds of contexts, somewhere between extremely difficult and impossible.
    • It was proposed and agreed that all IdAS method calls should be considered atomic (succeeded or threw an exception (no other outcomes)). This was as far as we should go. This was a necessary condition for potential future support for transactions.
  • ISS Web/Client UI design principles
    1. we will try to make the user experience as similar to MS CardSpace as possible
    2. except where we have usability test data that proves we have an improvement
      • E.g. a button in browser toolbar that redirects the browser to the current user's I-Card Manager
    3. except where we are required to innovate (e.g. Idemix's requirement to (sometimes) select multiple cards, not just one)
    4. except where we are absolutely convinced that we have an improvement (that we'll later verify for usability). This last, squishy category currently includes the following hypotheses:
      • The need in the browser to display some kind of identifier of the current user (in some households multiple people share the same OS account, so we need to show which person is the "active" Higgins user)
      • The need in the browser to display the current card(s) (if any) being used in the current interaction (e.g. need to remind the user what personal information about themselves is being shared/exposed)

Conclusions, decisions, etc.

  • We coordinated work for the demo of Higgins and Bandit components working together for IIW 2006 (Dec 4)
  • Progress was made on Idas Registry design & requirements
    • rename current IContextFactory.create() -> .attach()
    • add a new IContextFactory.create (that just creates)
    • agreed to adding IContext.configure() and IContextFactory.configure()
    • registry now has state and manages context configuration
    • registry now has bind operator to bind ContextRef to Context
    • Greg (and others) will continue design work
    • Agreed to leave the registry as not a singleton (for now)
  • Reviewed, corrected, updated I-Card (updated)
  • Reviewed and updated Architecture (updated)
    • settled on using "in broswer" ISS Web UI
    • made related changes to architecture diagram
  • Reviewed Components
    • emphasis on component "owners" and responsibilities
    • discussed importance of component owners early & often updating the "Requires" column for their row
  • Discussed Idemix integration
    • outcome: Abhi now understands better how to do the idemix integration
    • the "cross-card" nature of Idemix will necessitate changes
    • IBM Zurich to propose new I-Card interface
      • variant of TokenIssuerCard Interface
    • IBM Zurich to continue work on RP Security Policy
      • but with an understanding of the larger I-Card requirements
        • e.g. I-Cards with complex attribute types
  • Reversed our earlier decision about Java 5
    • Context Providers, Token Providers, etc. (plug-ins) may use Java 5
    • Higgins core and interfaces must only require Java 1.4.2
    • Agreed to document this here Developer Resources
  • Reviewed and updated Deployments (updated)
    • agreed to have this page describes only what has actually been tested and is officially supported by the project
    • Tom Doman agreed to temporarily be the "owner" of the CardSpace Managed Card Provider Deployment Scenario