[wsf-dev] Minutes from Meeting of 2-Feb-2006

Fri Feb 2 20:24:43 EST 2007

Thanks Eric, these look good.  If anyone feels they've been mis- 
minuted, please send corrections, but I'd like to accept and post to  
the site.

asa

--
Asa Hardcastle, Technical Lead, openLiberty
Tel: +1.413.429.1044 Skype: subsystem7

On Feb 2, 2007, at 6:11 PM, Eric Tiffany wrote:

> These minutes are included with the original agenda, though the  
> conversation
> didn't really always follow that outline.  See if you have any  
> corrections
> --- these will be posted on the wiki, too, I expect.
>
>
> AGENDA:
> + + + + + + + + + + +
>
> 1. Introductions
>
>
> 2. 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)
>
> * "me" Conor Cahill - conor.p.cahill at 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 - haven't been involved
>   much in liberty -- 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
>
>
>
> 3. 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
> - commercial
>     * HP is providing an HP Select Federation evaluation version
>
> 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
>
> 4. 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: 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.
>
> Asa:
>
> 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
>
> Brett:
> take a look at the Identity Landscape page on the wiki, started by  
> Gerald
> Beuchelt
> http://www.openliberty.org/wiki/index.php/Identity_Landscape
>
> !! Weekly design discussion, status updates.
> Thursday as a design meeting 8am, PST
> 2/2/07 4:46 PM
> Every Thursday at 8am PST we will be having a dev meeting until  
> things are
> under way
>
> -- 
> ____________________________________________________
> Eric  Tiffany             |  eric at projectliberty.org
> Interop Tech  Lead        |  +1 413-458-3743
> Liberty Alliance          |  +1 413-627-1778 mobile
>
>
>
> _______________________________________________
> wsf-dev mailing list
> wsf-dev at openliberty.org
> http://lists.openliberty.org/mailman/listinfo/wsf-dev