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

[Eric Tiffany]

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