Feb 2, 2007
From OpenLiberty.org Wiki
Back to Meeting Minutes←
Present: Asa Hardcastle, Ajay Daryanani Arjandas, Diego Lopez, Conor Cahill, Davis McPherson, George Fletcher, Scott Cantor, Derrick Harcey, Curtis Jones, Teri Sigl, Scott Cantor, Eric Tiffany, Brett McDowell
Contents |
Introductions / Who's here, who wants to contribute?
- Asa Hardcastle - all code in Java - likes chickens - implementer for WSC. Great Barrington MA
- Ajay Daryanani Arjandas & Diego Lopez - Red Iris - Spanish national research network, like Internet2 - connecting universities and network centers - Spain - Working with digital ids for 5-6 yrs - planning to implement some liberty protocol - working with other European partners (Ericsson, Norwegian govt)
- Conor Cahill - conor.p.cahill@intel.com - Intel - Virginia - working in liberty since founded
- Davis McPherson - available to help with software architecture, design, and dev -- worked in liberty with epok - maryland - paying job not involved in identity -
- George Fletcher - AOL - TEG rep - Virginia - involved with liberty since late 2005 -- ARCHITECTURE
- Scott Cantor: OSU, running SSO infrastructure, contracted to Internet2. Working on SAML/Liberty since 2002.
- Derrick Harcey - Sun - Global presales team - Create demonstration platforms - host those demonstrations - Dallas
- Curtis Jones - software entrepreneur with telecom background - western mass
- Teri Sigl - Sun - Dallas Texas - similar to Derrick, focus on telcomm
- Scott Cantor - Internet2 Shiboleth - Ohio State university SSO - open saml, original author involved in liberty since 2002 -- ARCHITECTURE
- Eric Tiffany - minute taker
- Brett McDowell - employee of liberty alliance - western mass
Tools at our disposal
a. wsf-dev list phase 1: discuss and design on the list address questions like: audience(s) - use cases implementation priorities, initial features to support - based on use case technologies (dependencies? Short term/long term) Selecting an XML platform/design on which to build the ID-WSF layer code style guide, contributor guidelines b. wiki capture the work we're doing c. forum non architects and designers to ask questions as they see progress. d. hosted implementations (test harness) - open source and commercial e. sourceforge - svn / cvs
Asa: dev list should be a pretty active forum. Wiki is more for historical record of different design decisions. The forum is for questions from outside the project. Hosted implementations could be either commercial or oss, particularly SSO imples.
Scott: confirms svn appropriate choice. Davis: concurs
Conor: offers RCS
Asa: asks if anyone has a platform to
Derrick: actually 3 different Sun products that could be tested against.
Asa: having SSO bootstrap may enhance adoption
Scott: may be able to contribute some resources
Progress going forward
a. Iteratively building an architecture document & project plan on the wiki - possibly beginning with a generic outline - any suggestions for the generic outline? What about the OPF(open process framework)?
b. Once the document exists, we can start writing the code based on the spec priorities. i.e. - baseline sec mech
c. First objective post documentation will be a bare bones ClientLib with a demonstration app
Asa: who is interested in architecture?
Conor, Davis, affirmative
Scott: Interested in architecture to the extent that it will mesh with his existing tooling
Scott: experience is that nothing works together due to difference in XML stack between different projects. Layering to keep abstraction clean is very labor intensive and isn't worth it.
Asa: libraries that keep themselves open turn out to be used but
Scott: App layer is able to be more abstract than system layer
Conor: Do we use DOM model or use a Java model that uses serialized objects when necessary
Scott: can cache the DOM and be more efficient every time you need to sign or perform other ops that require serialization
Scott: try to insulate users from sigs and serialization, but at the lower level you still need to
Conor: you end up designing as a set of setters and getters against object model
Scott: sort of, actually more of marshalling and unmarshalling so that when you need the DOM you reconstitute it
Asa: important to have access to lower levels, but have a higher level api that can avoid complexity.
Asa: need for DOM is mainly sigs, and mentioned in Wash meeting (what was that date?)
Scott: security was designed with streaming in mind, but SAML doesn't lend itself for SAX based approach and Apache tried to build SAX canonicalizer into xml security stuff and found it was hard.
Asa: DOM uses more memory, but easier to get going
Scott: Annoys the Mobile guys, but if you are using Java on a phone don't worry about it (too big anyway)
Asa: What is the audience? In terms of data size?
Scott: large data is like multi-megabytes
Conor: yeah, you negotiate the connection and protocol in SOAP but the actual data (like AOLradio) is a binary protocol
Asa: like the idea of making the initial negotiation using SOAP, and then moving to another stream
Conor: but the first step should be trying to contact the established services (eg profile service). Another thing is to invoke the Disco service which is also a first step.
Asa; envisioned a sequential approach, SSO, followed by DISCO, followed by Service invoke
Conor: has C++ that knows how to invoke services
Asa: can you send a pointer to the piece of code
Conor: offers to walk through the code with Asa
Asa: what should be the process going forward. Architecture doc is Asa's responsibility, but he wants to get best input from the callers and the list
Brett: do you want to build the arch dynamically on wiki?
Asa: wiki isn't totally wonderful, but it's the best tool available
Asa: the other option is to write a document and distribute
Scott: never written an arch doc, only code!
Asa: can get very detailed in a arch doc, but doesn't envision something that detailed. Break into components, so that can be changed incrementally. Compares to radio station where planning on the wiki diminishes enthusiasm
Scott: well you are lucky if you get anyone to write documentation you are lucky. But the wiki reduces the need to continue to reinvent documentation.
Scott: but what you really need is interfaces ,not architecture. Developers can work from that and avoid stepping on each other.
Asa: should we do API first
Scott: no, but you need to get there unless there are only 1 or 2 people working
Asa: the pitch will also get more people involved. Need to have more compelling scenario than the beer-and-pizza scenario
Diego: several use cases are interesting (email sent to Asa will be forwarded)
Asa: since we are starting from the wiki, perhaps and outline (objectives, ....). There are maybe pieces that some people take for complete granted, and we need to capture those.
Brett: need to enumerate the questions we need to answer before we get going (DOM vs. SAX)
Conor: whether we need to run in a Jakarta or AXIS or ?
Scott: SOAP stack (or even having one).
Asa: WSDL issue didn't have a solution in Washington?
Scott: that's why the soap stack decision is important
Brett: are we able to answer some of these qs now?
Eric: DOM seemed to be consensus
Scott: but perhaps the Wash discussion noted that you don't get too many signed responses, so there may not be an initial need to validate sigs. The transport usually securs the response.
Conor: there is a slight hook in Disco that might use sigs, but not typical
Scott: there have been use cases discussed where the security of the Server->client might use SAML (and signing) but it hasn't been
Scott: Apache needs a DOM
Asa: The timeline of the project, and the simplicity, plus signing, seems to indicate DOM.
Brett: is there any discomfort with that
Conor: Key is that the programmers are working with objects at a level above DOM
Scott: DOM is not a fun API to work with at the app layer.
Scott: needs to be addressed on list:
- JDK version we're targeting:
- decisions on java libraries: endorse xerxes from apache. and bouncy castle.
- java development environment:
Ajay / Diego:
- eclipse and ant
- crypto - bouncy castle
Wrap Up
Brett: take a look at the Identity Landscape page, started by Gerald Beuchelt - please contribute
Weekly design discussion, status updates. Every Thursday at 8am PST we will be having a dev meeting until things are under way
