View source for 04.30.2007 F2F Agenda

Agenda for Higgins face-to-face meeting in Austin, Texas, April 30 - May 3, 2007. 

==Logistics==

Location: IBM Austin, 11501 Burnet Road, Austin, Texas, 78758. Report to building 904 to get your badge. The meeting will be held in building 901 room 3G17.

The event will start Monday April 30 at 1:00 and end Thursday May 3 at mid day. 

[[Hotel List for IBM Austin]]
See [http://www.research.ibm.com/arl/visitor/index.html visitor information] for google map, etc.

==Expected Attendees==
# Jeff Broberg (CA)
# Greg Byrd (NCSU)--for first part only
# Andy Hodgkinson (Novell)
# David Kuehr-Mclaren (IBM)
# Mike McIntosh (IBM)
# Tony Nadalin (IBM)
# Nataraj Nagaratnum (IBM)
# Mary Ruddy (SocialPhysics)
# David Recordon (VeriSign) Monday EOD to Tuesday EOD only
# Drummond Reed (Cordance)
# Jim Sermersheim (Novell)
# Paul Trevithick (SocialPhysics)
# Abhi Shelat (IBM)
# Jim Yang (Identyx)

== Draft Agenda==
(Hopefully we have the order right now.)

* Architecture/Design sessions: April 30th 1pm - May 2nd noon
* Development Discussions:    May 2nd noon - May3rd noon

==MONDAY (April 30th) 1pm ==

=== 1pm: STS 60 min [MikeM] [Brian and Paula to participate by phone] ===        
*Recent Refactoring [MikeM]
**Bindings
**Extension Points
**Deployments
*higgins.eclipse.org status[MikeM]
====New Package Hierarchy (org.eclipse.higgins.sts) ====
* api (most depend on this one)
* xmlsecurity-apache
* common
* server
** token
*** username
*** ALF
*** SAML
*** identity
*** encrypt
** mapper
*** appliesTo
*** default
** trust
** metadata
** profile
* client
* binding
** common
** axis1x
** servlet
*** metadata
*** profile

====New *.api package====
* new packages org.eclipse.higgins.sts.api.* --this is where all the interfaces live. 
** org.eclipse.higgins.sts.api.client
** org.eclipse.higgins.sts.api.server
* new interface IInformationCard (extends ITokenCard and ICard)
** this interface is temporarily here, it will move to and be harmonized with org.eclipse.higgins.icard
* org.eclipse.higgins.sts.client
** this is a reference impl of org.eclipse.higgins.sts.api.client
** can create an STS request. this is where I was forced to create IInformationCard
** this package is primarily for use by i-card selectors
** Mike has org.eclipse.sts.binding.axis1x
*** TestManage.java does everything necessary to connect to an STS, (e.g. create request, handle response)

====Misc====
* TestManaged.java and TestPersonal.java will use the reference impl packages to illustrate the process and use of APIs
* Mike is trying to move IdAS dependency into
** token.identity package
** profile servlet package
* Daniel: what are your ideas about documentation
* Mike: This is important. I forgot to mention something. What I'm thinking that there will be deployment-dependent WAR files. We currently have all these flexible deployment scenarios, but for sample deployments it would be nice if we could create, for example, a "personal STS deployment." 
* Daniel: what folks run into: the fact that we need strong encryption JAR files, is an example of all of these little things that folks run into
* Mike: we need to come up with documentation for different audiences
* for developers 
* for people who are deploying it
* Daniel: I have some raw material on "deploying an IdP"
* Mike: Paula has also made a stab at it; Brian has contributed a lot to this. I'd like to find the time and/or tech writer resource to get this right.
* Daniel: if we at least have the doc on all the pieces that are explorable.
* Mike: yes, as soon as the code settles down I'll get more into this.
* Mike: there may be a couple more extension points (e.g FIPS-compliant crypto impl), and there are a few more. We might want to add audit to our discussions this week. At least an extension point that could emit audit records
* Raj: this approach of separating interfaces into *.api is good for other Components 
* Raj: essentially proposes org.eclipse.higgins.api.sts (instead of org.eclipse.higgins.sts.api)

===2:45pm Higgins RP Support [60 min] [Jeff B] (Brian, Uppili to participate by phone)=== 
* What is the near term (Higgins 1.0) scope of this area? 
* Chuck has offered code, but he's wondering who will take care of it
* RP Component Design proposal [MikeM]
** Policy Generation/Publication
*** e.g. CardSpace Object Tag Generation
** Protocol
*** e.g. OpenId, WS-Federation, SAML Redirection
** Token Consumption
*** e.g. CardSpace Token Decrypt, Verify, and Validate

* JeffB: The motivation for this came out of work at CA to work with CardSpace
* Examples of capabilities:
** token dissasembly
** dynamic generation of the <object> tag
** mechanism for the storage and retrieval of the certificates (the private keys required for the dissassembly)
* Tony, so what you're saying:
** Enable the RP with policy (building
** Signature validation of the signature
* Mike: I'd like to be able to build a component that would be support CardSpace, OpenId and "foo" --any protocol. We'd set properties on this Component to say what protocols you want it to support. It would generate the content embedded with the page that comes to the user. The user does something and redirects and gets back to some piece of code that handles the response. The model for the Component to sort of support all of that.
* Jeff: I'm interested in putting in work for this
* Jeff: what do we mean by validating claims
* Mike: Examples of claim validation the RP might want through some parameters on the component:
** if "now" is in the validity the token 
** if the claims required are present
* Jeff: Apache just came out with a CardSpace module. There's an opportunity for us to contribute.
* Paul: language support?
* Jeff: I think we need to support a number of different languages
* Jeff: This is a missing piece of the Higgins architecture
* Jim: how many crossover points with Pamela project?
* Paul: okay, so the consensus is that Jeff will work with Mike and Brian to work on scoping this project.

=== Demos and Interop Planning Uppili to participate (1 hour)===  
*Collaborative session to review and update the rows in the OSIS "Identity Agent" chart
*Discussion of interop
*IIW: pre-work
*Burton: interop demos

== TUESDAY ==

===7:30am: Continental Breakfast===

===8:30am: HBX [60 minutes] [Abhi, Paul]=== 
* Abhi: Demo of IBM Z-HBX with identity mixer and CardSpace support
* Paul: HBX startup wizard
** Authentication to hosted Higgins (IdA) service
*** using i-name/OpenID or using URL+email
*** choosing passphrase
*** seeding with i-name/OpenID or URL
* r-card HTML <object type="application/r-card">
**p.requiredClaims = list of claim URIs [like CardSpace]
**p.providedClaims = list of claim URIs
**p.tokenType = <tokenType> [like CardSpace]
**p.encryptionMethod = <encryptionMethod>
**p.useRCard = True
**p.relyingParty = <DN of RP>
**p.rCardImage = <cardImage> [CardSpace image spex]
**p.rCardRPURL = <feedURL>
**p.rCardProtocol = XDI or RSS+SSE or Atom or OpenID-AX
* RP security policy expression language
** where does it stand; can we augment it per r-card?
* Multiple HBX versions to support H1, H2, H3, H4?
* Relationship to Kevin Miller's Perpetual Motion code
* Security: MITM attacks--do we need to add some native code/PKI/etc.?

*Paul’s section

*Paul – Walking through the start-up wizard
*Mike –There are different kinds of Higgins services
*Paul – Trying to take naïve view,  .. choice of providers.  Need to know which one to use
*Alex – Sounds like an identity mashup – give it a descriptive name.  Could still put *Higgins in the name
*Paul – Already downloaded the add-on, so know the name Higgins
*Paul – Also have a concept of seeding it.  It downloaded it from a promoter, it could have already an i-name or open-id identifier and URL of Higgins service.  So user doesn’t have to type anything.  If get from Eclipse might not be seeded.  Someone may want to download HBX and point it to its own service
*David – Why no same card interface?  Define a card provider.  
*Jim  - Another default deployment, a locally instantiated service analogous to ..
*Paul – this is the H1 deployment scenario – everything is in the cloud
**H2 – rich client selector, can be more secure, 
**H3 – All local, still different processes
**H4 – Novell and CardSpace like, embedded.  Eclipse community asks for embedded.  *Minimal API’s.
*Paul – We do envision one HBX that can work in all of these scenarios.  
*Paul – First question is where is my service?
*Mike – Maybe Higgins Identity Agent Service (for the name)
*Alex – It needs something.
*Paul – Continues to walk through the Start-up wizard.
*Abhi – Why not just copy and past the URL.
*Paul – Could provide a package with lots of services associated with an I-name, etc. provide a package
*Abhi – How did it map to the URL
*Drummond – Used XRI resolution
*Paul – His i-name provider offers that as a service, Higgins service and Open-Id service, etc.
*Paul – This could have been an OpenID.
*David – Are their spoofing concerns
*Drummond – Need to specify HTTPS if want it used..  I-names can be set up to use HTTPS. 
*Paul – Need to pick a passphrase.  This is no ordinary password.  It is a master password to service
*Tony – Password to what?
*Mike – Why can’t you generate a key?
*Paul – We used to generate a random key, but then it isn’t memorable
*Paul – We are just throwing this out for feedback
*Paul – AOL disks used a similar approach
*David – But isn’t this open to a dictionary attack.
*Paul – Lets move on..
*Paul – Still showing the sign-in demo
*Alex  - So that will help you fill in passwords to sight
*Paul – We have done some.  
*Paul – Wants to have engine in HBX – can use different scripts.  Sxipper and Roboforms are examples of products that try to so something similar
*Paul – Have been talking with Kevin Miller.
*Andy – For purposes of the demo, used Kevin’s launcher.
*Paul – Because it has native code in it, there is possibility for higher authentication.  Put PKI in it…
*Paul – Where do we stand on the relying party security policy statement?  Is there a formal policy language?
*Abhi – Idemix has a policy language
*Paul – Do we have any intention to unify those policy languages
*Abhi – We can’t express the idemix policy in the simple language
*Paul – Could we express the simple stuff in the idemix language?
*Abhi – At ISS level, we were thinking about normalizing it.  Call it “P”.
*Paul – There are personal, managed and relationship cards
*Paul – Relationship cards – a card to capture relationship with Amazon.  Signon might be a small part of it.
*Abhi – Current model is Amazon stores all the info about our relationship.
*Paul – Paul wants both Amazon and user to have the data
*Jim – It would be cool if people could trust the site to generate reputation.  It if could be put on the card in a signed trusted way…
*Paul – This is the original vision behind Higgins. 
*Mary - Yes
*Paul – Reviews contents of R-card
*Abhi -  What is the token type?
*Paul – Potentially this could be made to work peer-to-peer without a signing authority
*Paul – Show me the cards that have the greatest utility for coming-up with the required claims.  We envision shopping cards, etc. Archetypes of cards.  It builds a token and posts it, just like cards space, but there is one extra thing. What is the end point where I will service these attributes..  We set up a permanent channel, for example RSS SSE, synchronization.  Looks like CardSpace only richer.
*Paul – Google says Atom is the way to go.  Drummond says use something designed for this: XDI.  The idea is setting up a channel and calling it an r-card.
*Drummond – Like Attention Trust does for click stream
*Paul – If you change your address, the user can be in control of who automatically gets this.
*Mike – Why would you use a relationship card rather than a managed card?
*Tony – Managed cards can be more dynamic.  
*Tony – How do you do peer-to-peer reputation in a single claim
*Jim – The claim value would need to be multi-part
*Tony – Hard to do in what we currently have as a claim URI.
*Paul – There is an end point that the agent manages and does a get.
*Paul – An r-card is a pointer to a context, that could be hosted everywhere.  Lets either side update without an authentication.
*Jim – Much like a managed card has an endpoint to an STS
*Drummond – It is like making a managed card bi-directional
*Mike – Had though of that being more peer-to-peer.  Almost a three way relationship.  Deligate assess to some resource.  It is a deligation card.  Here is a card for Paul.  Only he can use this for this purpose at this service.
*Paul – The way he was thinking of doing this,  .. 1.0 doesn’t address authorization, but we could build this in
*Mike – There is an underlying assumption of authorization happening based on the identity we are asserting.  This is a fundamental assumption.  Doesn’t think it covers that case he cares about
*Paul –It is silent on authorization, but everything is now.
*Paul – If there is a way to do this all with SAML attributes, then we could do that
*Raj – What tell end users when they need to choose which  card.
*Paul – We support multiple card selection 
*Raj – What is the difference between a managed card and a relationship card.
*Paul – Relationship card lets you do this and could also let the card be a token issuing card.
*Paul – Still concerned about whether we can make it clear enough, what is authoritative.
*Drummond – Could say relationship card is a superset
*Paul – One thing companies don’t like about CardSpace is get the picker each time. An r-card is policy driven.  Don’t bother me.
*Tony – Let me get fished each time, I don’t want to know about it.
*Mike – Could set a policy, if I’m connected to this site, with an SSL certificate, then…
*Mike – It is important to have the SSL part.
*Mike – Another thing, you no longer know…  You may not know if you are logged in.  Paul - Have some browser real-estate to use (to provide status).
*David – Plan to release an open///
*Paul – Have a check to indicate if you want to be bothered every time.  OK. We think the default is wrong with CardSpace.
*Jim – May want to maintain very different personas for a site.
*Paul – Yes, there may be different “stem cell” cards
*Drummond – Would you use HBX to switch the role
*Paul – That is an issue.
*Paul – We just have a mouse icon.  Will also have the currently signed-in user name.  OpenID is going to release one at IIW.  We think we need one also.  IT represents your account to the different users.  HBX must be multi-account aware, for family members also.  There should be timeouts..  FIelfox has master passwords.  This isn’t a radical thought.

*Abhi’ section

*Abhi :There is a relying party protocol support thing.  There is also Mike’s STS.  Has chuck’s google code.
*Abhi  - Showed managed card version of selector and idemix selector.  Idemix  credentials are neither managed nor self asserted.  They are their own class.
*Paul  - Does it make sense to present idemix as cards?  
*Abhi – The announcement generated some patent claims.  We are trying to remove all the contested cryptography sot that the code can be committed.
*Abhi  - They are building a flicker ++ thing  that will use idemix.  Can sign something anonymously.
*Abhi - Can do the signatures using the same modules
*Tony – We still have multiple HBX’s
*Paul –Trying to get Abhi’s stuff put into our system
*Abhi – Had a call last week.  Recommends a two day co-located session  It would be great to have Maxim work on the interop
*Tony – We have 3 code bases for HBX. We should use this time to address this.
*Paul – Showed the i-card manager
*Abhi – That’s great
*Paul – Can be an open source answer to Plaxo
*Abhi – Oh really.  What does it hit on the back end?
*Paul  - The i-card registry has some organization.
*Paul  - Would like the idemix to be expressed as a card.  So for cards with the same UI
*Tony – HBX potentially needs to be able to select multiple icard-managers and ISS’s
*Abhi – Does it include the audit trial
*Paul – Envisioning it being don at the i-card-registry level.  Haven’t been working on that
*Tony –If someone were to look at Higgins today, they wouldn’t know what it is.
*Paul – There are different people driving it in different ways.

===10:20am: ISS UI, ISS, I-Card Registry [Andy] (40 minutes -to be continued)===
* Illustrate the architecture Novell has been putting together
** All written in C and C++
** Uses Kevin Miller's Perpetual Motion Firefox plug-in (XPCOM) to launch ISS Client UI
** ISS Client UI (written in GTK)) 
** ISS talks XML_RPC to ICardRegistry
** ICardRegistry allows for pluggable ICardStoreProviders
** Multiple card stores allow for portability of cards
*** Motivation: local cardstore at home and another on an FTP "card provider" server
*** Preserve the card data as it came to N-i-card registry
*** Some auditing stuff should stay with the card
*** One cardstore at a time
*** Can import cards from CardSpace (also can specify the claims manually)
*** Implemented own signing
*** Two deployment approach:
**** ISS Client UI always runs locally and is a client to
**** issd (analogous to H RPPS) listening on/off the box (uses XML RPC)
** Andy suggested that auditing information should live with the cards (there had been a thread that this information should live with the i-card registry)
** Andy <please fill in here> the flow related to how the secret store is used
* Talk about what has been implemented
* Discuss convergence at the conceptual/architectural level
** Comparison to Parity Ukraine versions of i-card registry, i-card providers
* Discuss protocol-level interoperability
* ICard Interfaces
* Dependencies
** GTK --UI support lib
** openSSL --used for the X509 certs, RSA key gen and SHA2
** liveXML and XMLsec will go away
* Have checked in a snapshot of the code into Higgins
* We should align the C++ client library with Mike's java client library
* Need to align the C++ i-card interfaces with the Higgins interfaces
* Notion of PersistentCard (id and value)
* i-card registry has management methods
* card store mirrors these methods (implemented by a store provider)
** implement a particular kind of card store (CASA, filesystem)

===11am: OpenID [Paul, Duane, David Recordon] (Uppili, Duane, Tom to call-in.)===
* Various ways to integrate OpenID
* OpenID thru managed card (the username is overloaded with the OpenID URI)
*** flow: managed card request to STS
**** STS ask IdAS "OpenID" CP 
***** This CP uses mapping to map either SREG attributes or new AX
***** CP provides read-access to an OP
*** CP acts both as an OpenID RP and as an OpenID user's browser
** STS Protocol adaptation
** URICard / OpenID 
** Token Extension
** HBX doing openID auth

* Standardized OpenID Claim URIs [David]
** Mike: it would be easy to extend the MSFT managed card a bit. (e.g. some fragment of the CardId URI was the OpenId)
** Mike: the protocol between IdA and TS is WS-Trust. 
** David: I'd like to define a Claim URI (in CardSpace displaying it as an OpenID)
** Tony: WS-Federation now allows claim URI values in the claims (e.g. enum values). The dialect constrains where the Claim types might be. Claim Types are per dialect.
** Tony: OpenID could define a dialect here.
** Drummond: so the same Claim URI could be used in different dialects

===1:00pm: [75 min] Dial into Burton Group interoperability call during lunch break===

===2:00pm: IdAS Registry [Paul, Jim, Drummond]===
* Review [[IdAS Registries Proposal 2B]]
* Implementation of the IdAS Registry itself	 
* Implementation of the IdAS/CP configuration API	 
** We want a standardized API for IdAS CP configuration

===3:00pm: IdAS API and Data Model [Jim] (Tom to call in) ===
* Update operations, a summary
** Folks wanted to be able to walk to the node and make updates. The problem is that some CPs don't allow this. We needed to allow the CP to batch a set of updates to the backing store. Went through detour of proposals that included transactions, and got back out of that. Jim distilled [[IdAS Update Proposals]]. Result: as you go through the values on attributes of DSes and when they are done, at the IDigitalSubject level we have an applyUpdates method to "make it so". 
** Jim: I think the noise has gone down and people seem happy with it. 
** This has spawned a number of side conversations about the [[Higgins Data Model]]

===3:30pm: Data model issues [Jim]===
* Update folks on what's going on
* [[IdAS Update Proposals 2]]

===4:30pm: Use Cases [60 min] [David Kuehr-Mclaren]===
* Review new detailed use cases - identify gaps if any, and discussed possible API enhancements

===6:00pm: Dinner sponsored by IBM===

==WEDNESDAY==


===8:30pm: Use Cases [60 min] [David Kuehr-Mclaren] (continued)===
===9:00am IdAS API and Data Model continued [Jim] ===
* Review/Discuss - Data model - IdAS, metadata, value - discussions (1 hour)
* IdAS APIs and SPIs - should we look at separating those? (30 mins)
* Moving to a JAAS or JAAS-like model for AuthN materials passed to IContext.open (30 mins)
* Transactions
* Authorization
** example use case: the i-card manager relies on the "source" metadata to know who can edit an attribute
* Model-changing APIs (e.g. add/rm attribute types)
* Shallow vs. Deep API methods --currently all methods are shallow (i.e it is the responsibility of the IdAS client to follow SubjectRelationship links)

===10:30am IdAS  Service Descriptions [Alex]===
* IdAS refactoring for service descriptions  (1.5 hour)
** Refactor or add a layer on top which exposes IdAS in a service-friendly way?

===LUNCH===
===12:40pm: IPR [30 min] [Mary] ===
* Update and risk management discussion
* What code should be in Higgins

===RCP enablement===
*Integration
**OSGi Components
**ISS
**STS



===1pm: Project Planning [Paul] ===
* Review [[Milestone 0.8]]
* Adjust overall Milestone plan
* Review new component owner checklist ("ToDo" , nightly builds)
* Propose daily "Higgins Hour" on #higgins. The component owners mentioned commit to attend the #higgins channel during this hour
** Monday 11am ET: IdAS Service (and extensions) [[User:jimse.novell.com | Jim]], [[User:tdoman.novell.com | Tom]], Duane
** Tuesday 11am ET: Token Service, etc. [[User:mikemci.us.ibm.com | Mike]]
** Wednesday 11am ET: i-cards and the i-card manager, i-card registry, ISS Client UI [[User: vkokhan.aquasoft.dp.ua | Valery]], [[User:Sergey.parityinc.net | SergeiY]], Andy
** Thursday: noon --regular Higgins weekly meeting
** Friday: 11am ET: HBX, RPPS, ISS [[User:maxim.parityinc.net | Maxim]], [[User:Abs.zurich.ibm.com | Abhi]]

===2:00pm: Next Steps ===
* Need to define RP code for June interop
* Next F2F Hilton San Francisco (probably at the IBM office on 425 Market Street in San Francisco) Room: 5761-19-19201 (19th floor?)
** Monday June 25th --prep for Interop demo (all day)
** Tuesday June 26th -- Higgins F2F meeting (all day)
** Wednesday June 27th -- Higgins F2F meeting (9-noon)
** Wednesday June 27th -- evening in a hospitality suite (6-9pm)

===2:20pm: Elbow-to-Elbow Integration / Development Discussions Begins ===

* Half day or full day of working session time so that people can work F2F on their various ongoing projects.

====Junit testing====

====Nightly Builds====
* Branching?
* "incubation-" label needs to be done by 5/7.

==THURSDAY (morning only)==
===8:30am: Elbow-to-Elbow Integration / Development Discussions (Continued) ===

===Configuration (Mike. Duane & Daniel on phone)===
* Mike gave an in-depth look at the way the STS configuration component works
** Configuration is packaged as a Map.
*** A Configuration Handler an convert an XML file (or stream, or DOM) into a configuration map (see Configuration.xml for an example)
**** The configuration XML source contains a table of SettingsHandlers. These allow the XML elements to be converted into the Map keys and values.
** Configuration should be available as a separate Higgins component. We'll call it "Configuration"

===IdAS Registry (Markus joined by phone)===
* IdAS Registry is only one case where we're interested in discovery, configuration, and instantiation of a Higgins Provider.
** We propose to create a Higgins component called "Discovery"
*** We still need to meet the use cases from the proposal at [[IdAS_Registries_Proposal_2B]]
*** The Discovery component should allow us to define a "normalized representation" of what we need (much as Mike has done by normalizing configuration to a Map). One way to arrive at this normalized representation, would be to use XRI resolution, and Markus will be working on that.  Other ways may be added in the future (WS-Addressing, etc.)
** To begin with, Markus will concentrate on working on the resolver and converting over to XRDS.
*** We'll continue to focus on IdAS until the more general model becomes more crystallized.
** Jim will convert one or two existing Context Realms files to Configuration files for Markus to reference.

===Securing Card Stores===
* 

===Packaging===
* Deployments for M0.8
* Support for multiple versions of components, should the Token Service be offered as an OSGI version also?

== See Also ==
* [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]