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

Difference between revisions of "06.25.2007 F2F Agenda"

(2:00pm AnthonyB and AndyH I-card store APIs)
(Wednesday June 27th -- Higgins F2F meeting (9-noon))
 
(42 intermediate revisions by 2 users not shown)
Line 100: Line 100:
 
===2:55 review of i-card terminology===
 
===2:55 review of i-card terminology===
 
* Paul presented; proposal is to use terms narrowly
 
* 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)==
 
==Tuesday June 26th -- Higgins F2F meeting (9-5pm)==
==Wednesday June 27th -- Higgins F2F meeting (9-noon)==
+
===9:25 Mary: Open Eclipse Higgins Meeting===
==Wednesday June 27th -- Evening in the hospitality suite (6-9pm)==
+
* Reminder of IP rules of meeting
 +
* Higgins developer call canceled for this week
  
==List of Topics==
+
===9:25 Paul: Catalyst Session (Paul & Kim)===
 +
* Review of proposed PPT slides to be presented
  
* Secure Card Store provider
+
===9:35 Andy: H2 Demo & Discussion ===
* Configuration component
+
* Demo of H2 Card Selector
* HBX Updates and convergence
+
* UI based on Glade and GTK
* ISS Updates and convergence
+
* Uses Gnome keyring
* Develop on plan/process for harmonizing H2/Native vs. Java architectures
+
** currently one process (not ISS Client UI + deamon)
* Higgins Relying parties and their derivatives
+
** 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===
 +
# H2 architecture changes required
 +
#* IdAS in native form
 +
#* "pluggable ISS"
 +
# 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
 +
# support for all Higgins-defined web interaction types
 +
#* (e.g. "informationCard", "r-card", "z-card")
 +
# languages (Java, PHP, Perl, Python, Ruby, C++)
 +
#* perhaps we need to at least tackle a couple
 +
# how app-specific components (e.g. MediaWiki modules, etc.)
 +
 
 +
===Lunch noon-1:30pm===
 +
 
 +
===1:40pm Eclipse Equinox project and Higgins [Tony]===
 +
* Equinox project has identified requirements for storing keys, etc.
 +
* Today Equinox folks think that they can just store everything in a Java KeyStore
 +
* We need to talk to them about Higgins
 +
* We'll need to write JAAS interfaces to Higgins (so they can consume)
 +
* All part of the "How to add authentication to the RCP"
 +
 
 +
===1:45pm WS-Federation [Tony]===
 +
* Background context on WS-Federation TC
 +
* Scope is a bit beyond "federation" per se
 +
* CardSpace uses some of this technology (CS is not just based on WS-Trust,etc.)
 +
* Added generic claims language
 +
** allow you to define your own
 +
** support operators (e.g. greater than)
 +
* Expanding on the claims language to support complex values
 +
* May be adding new claim type URIs
 +
* Clarified the notion of an attribute service
 +
** specialization of an STS; give it claim types and it gives you back the values of those claims
 +
* Authorization service
 +
** another specialization of an STS; ask for authorization claim values
 +
* Federation Metadata documents
 +
** How to find various federation services
 +
** Modeled off of an EPR (e.g. URI for a privacy service)
 +
** Fetch this document, helps bootstrap (e.g. where the other services are)
 +
* Adding a confirmation message to allow confirmation: what you get back is consistent with your request
 +
* These and other things are extensions to WS-Trust (and will remain in this TC)
 +
 
 +
===2:00pm Extending the RP informationCard Object Tag [Drummond]===
 +
* Drummond: the only place this is specified is in the MSFT "Web Guide" [April 2007].
 +
* Conclusions:
 +
** we will use type="application/x-informationCard"
 +
** we will add new parameter types (e.g. to describe new token types, new parameters for idemix, new policy language statements)
 +
*** avoid namespace clashes with what MSFT has already defined
 +
** We should create high quality spex for our new extended Object tag on the Higgins wiki
 +
** TODO: [Paul]: begin work on a new icon and icon usage guidelines
 +
 
 +
===2:35pm CardSpace Interoperability Specifications===
 +
* We plan to create a new list of the items/spex not covered by the OSP
 +
* Mary to create a new "response to OSP"
 +
 
 +
===2:50pm Higgins Development processes===
 +
* Conclusion
 +
* We will take a first step and have all Component owners manually create source, javadoc and jars by the end of Milestone 0.9 (at least once)
 +
** TODO: [Mary]: Create documentation for Component Owners for how to manually (not automatically) create snapshots of the source, javadoc and .jars and create the download sub-page similar to what the automated process does (e.g. [http://download.eclipse.org/technology/higgins/idas/lastStableBuild/index.html])
 +
** TODO: [Paul]: Add to component owner checklist
 +
** TODO: [Component Owners]: Wiki page for every project
 +
** TODO: [Mike]: send request for new bugzilla components to Paul
 +
** TODO: [Paul]: create the "master" Higgins.PSF
 +
 
 +
===3:15pm Milestone M0.8===
 +
* Conclusion: Milestone M0.8 is officially done
 +
* Mike plans to create a good M0.8 WAR file for STS; work with Mary to add to the downloads page
 +
 
 +
====M0.9 Planning (July 27th)====
 +
* STS
 +
** ant builds and nightly builds
 +
** extensibility points for audit
 +
** internationalization
 +
** writeable context provider interface
 +
* Discovery (IdAS only)
 
* IdAS
 
* IdAS
* I-Card Manager
+
** authentication material modifiation methods
* RPPS / ZRPPS architecture discussion
+
** API extensibility
** Why IBM's ISS code doesn't call ICard.requestDigitalIdentity()
+
* I-Card Registry
** (We also need a new name for the RPPS Component)
+
** integrate new abstraction: CardStoreStrategy
* Discuss i-card [http://en.wikipedia.org/wiki/I-card wikipedia page]; our use of the term "personal" vs. "self-issued"
+
* Idemix: integrated but crypto libraries not yet included
* Discuss [[I-Card Interfaces]] <-- this wiki page is really out of date. Will update b4 meeting.
+
 
* Equinox integration
+
====M0.95 (August 31th)====
* Higgins Development processes
+
* focus on API refactoring
** 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
+
===Planning 1.0 (Sept 24th (DIDW=24-26th)===
* Milestone 0.9
+
* F2F meeting just before DIDW
** Declaring victory on M0.8
+
 
** Planning out M0.9
+
===3:50pm: Adjourn===
** Scheduling next F2F and next demo
+
 
== See Also ==
+
===7pm: Higgins Dinner===
 +
* Restaurant: Buca Di Beppo [approx 13 people] 855 Howard Street (near Moscone)
 +
 
 +
==Wednesday June 27th OSIS Interop==
 +
* 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)==
 +
 
 +
 
 +
 
 +
== Links ==
 
* [http://eclipse.org/higgins Higgins Home]
 
* [http://eclipse.org/higgins Higgins Home]
** [http://wiki.eclipse.org/index.php/Higgins_Wiki Wiki]
 
** [http://www.eclipse.org/higgins/higgins-charter.php Charter]
 
** [http://www.eclipse.org/higgins/goals.php Goals]
 
** [http://www.eclipse.org/higgins/plan.php Plan]
 
** [http://www.eclipse.org/higgins/faq.php FAQ]
 
** [[Architecture]]
 
** [[Components]]
 
** [http://www.eclipse.org/higgins/resources.php Developer Resources]
 
** [http://www.eclipse.org/higgins/downloads.php Downloads]
 

Latest revision as of 19:03, 26 June 2007

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

1:40pm Eclipse Equinox project and Higgins [Tony]

  • Equinox project has identified requirements for storing keys, etc.
  • Today Equinox folks think that they can just store everything in a Java KeyStore
  • We need to talk to them about Higgins
  • We'll need to write JAAS interfaces to Higgins (so they can consume)
  • All part of the "How to add authentication to the RCP"

1:45pm WS-Federation [Tony]

  • Background context on WS-Federation TC
  • Scope is a bit beyond "federation" per se
  • CardSpace uses some of this technology (CS is not just based on WS-Trust,etc.)
  • Added generic claims language
    • allow you to define your own
    • support operators (e.g. greater than)
  • Expanding on the claims language to support complex values
  • May be adding new claim type URIs
  • Clarified the notion of an attribute service
    • specialization of an STS; give it claim types and it gives you back the values of those claims
  • Authorization service
    • another specialization of an STS; ask for authorization claim values
  • Federation Metadata documents
    • How to find various federation services
    • Modeled off of an EPR (e.g. URI for a privacy service)
    • Fetch this document, helps bootstrap (e.g. where the other services are)
  • Adding a confirmation message to allow confirmation: what you get back is consistent with your request
  • These and other things are extensions to WS-Trust (and will remain in this TC)

2:00pm Extending the RP informationCard Object Tag [Drummond]

  • Drummond: the only place this is specified is in the MSFT "Web Guide" [April 2007].
  • Conclusions:
    • we will use type="application/x-informationCard"
    • we will add new parameter types (e.g. to describe new token types, new parameters for idemix, new policy language statements)
      • avoid namespace clashes with what MSFT has already defined
    • We should create high quality spex for our new extended Object tag on the Higgins wiki
    • TODO: [Paul]: begin work on a new icon and icon usage guidelines

2:35pm CardSpace Interoperability Specifications

  • We plan to create a new list of the items/spex not covered by the OSP
  • Mary to create a new "response to OSP"

2:50pm Higgins Development processes

  • Conclusion
  • We will take a first step and have all Component owners manually create source, javadoc and jars by the end of Milestone 0.9 (at least once)
    • TODO: [Mary]: Create documentation for Component Owners for how to manually (not automatically) create snapshots of the source, javadoc and .jars and create the download sub-page similar to what the automated process does (e.g. [1])
    • TODO: [Paul]: Add to component owner checklist
    • TODO: [Component Owners]: Wiki page for every project
    • TODO: [Mike]: send request for new bugzilla components to Paul
    • TODO: [Paul]: create the "master" Higgins.PSF

3:15pm Milestone M0.8

  • Conclusion: Milestone M0.8 is officially done
  • Mike plans to create a good M0.8 WAR file for STS; work with Mary to add to the downloads page

M0.9 Planning (July 27th)

  • STS
    • ant builds and nightly builds
    • extensibility points for audit
    • internationalization
    • writeable context provider interface
  • Discovery (IdAS only)
  • IdAS
    • authentication material modifiation methods
    • API extensibility
  • I-Card Registry
    • integrate new abstraction: CardStoreStrategy
  • Idemix: integrated but crypto libraries not yet included

M0.95 (August 31th)

  • focus on API refactoring

Planning 1.0 (Sept 24th (DIDW=24-26th)

  • F2F meeting just before DIDW

3:50pm: Adjourn

7pm: Higgins Dinner

  • Restaurant: Buca Di Beppo [approx 13 people] 855 Howard Street (near Moscone)

Wednesday June 27th OSIS Interop

  • 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)

Links

Back to the top