[wsf-dev] wsf-dev Digest, Vol 2, Issue 3
Curtis Jones
curtis at upto11.com
Mon Feb 5 10:55:01 EST 2007
Asa et al:
I had to bail early on Friday's meeting. The minutes suggest that there was
an effort to make some decisions at the wrap-up of the meeting (e.g., DOM,
Eclipse/Ant, SOAP, etc.) -- but if any decisions were made, it's not
entirely clear in the minutes. Are we waiting for more detailed user/usage
profiles before making these decisions?
Thanks,
- Curtis
-----Original Message-----
From: wsf-dev-bounces at openliberty.org
[mailto:wsf-dev-bounces at openliberty.org] On Behalf Of
wsf-dev-request at openliberty.org
Sent: Saturday, February 03, 2007 12:00 PM
To: wsf-dev at openliberty.org
Subject: wsf-dev Digest, Vol 2, Issue 3
Send wsf-dev mailing list submissions to
wsf-dev at openliberty.org
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.openliberty.org/mailman/listinfo/wsf-dev
or, via email, send a message with subject or body 'help' to
wsf-dev-request at openliberty.org
You can reach the person managing the list at
wsf-dev-owner at openliberty.org
When replying, please edit your Subject line so it is more specific than
"Re: Contents of wsf-dev digest..."
Today's Topics:
1. OSIRIS from Spain (Asa Hardcastle)
2. Minutes from Meeting of 2-Feb-2006 (Eric Tiffany)
3. Re: Minutes from Meeting of 2-Feb-2006 (Asa Hardcastle)
----------------------------------------------------------------------
Message: 1
Date: Fri, 2 Feb 2007 17:00:18 -0500
From: Asa Hardcastle <asa.openliberty at zenn.net>
Subject: [wsf-dev] OSIRIS from Spain
To: wsf-dev at openliberty.org
Message-ID: <2FF589D9-4A0C-4CC4-8BCE-A205A6D26E3E at zenn.net>
Content-Type: text/plain; charset="us-ascii"
Hi All,
Here are the links that Ajay and Diego referred to this morning
talk later,
asa
--
Asa Hardcastle, Technical Lead, openLiberty
Tel: +1.413.429.1044 Skype: subsystem7
> Hi Asa,
>
> this mail is on behalf of Diego Lopez and myself. We would like to
> confirm that we'll gladly join today's conference call.
>
> In RedIRIS ( http://www.rediris.es/index.en.html )we are highly
> interested in openliberty and hopefully will contribute to it with
> code on some profiles, which we will develop for another project
> called OSIRIS ( http://www.itea-osiris.org ).
>
> OSIRIS aims to create an open source infrastructure that handles the
> full lifecycle of services in an heterogeneus environment. Being
> security a key issue, we will provide OSIRIS partners with a WSF layer
> to interoperate with other federations.
>
> Also we will follow discussions on the design of the library.
>
> Thanks,
>
> Ajay Daryanani
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.openliberty.org/pipermail/wsf-dev/attachments/20070202/0adee78a
/attachment-0001.html
------------------------------
Message: 2
Date: Fri, 02 Feb 2007 18:11:00 -0500
From: Eric Tiffany <eric at projectliberty.org>
Subject: [wsf-dev] Minutes from Meeting of 2-Feb-2006
To: <wsf-dev at openliberty.org>
Message-ID: <C1E92F34.1CBD6%eric at projectliberty.org>
Content-Type: text/plain; charset="US-ASCII"
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
------------------------------
Message: 3
Date: Fri, 2 Feb 2007 20:24:43 -0500
From: Asa Hardcastle <asa.openliberty at zenn.net>
Subject: Re: [wsf-dev] Minutes from Meeting of 2-Feb-2006
To: Eric Tiffany <eric at projectliberty.org>
Cc: wsf-dev at openliberty.org
Message-ID: <9CA450EF-C339-4C96-B757-B26463E7975D at zenn.net>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
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
------------------------------
_______________________________________________
wsf-dev mailing list
wsf-dev at openliberty.org
http://lists.openliberty.org/mailman/listinfo/wsf-dev
End of wsf-dev Digest, Vol 2, Issue 3
*************************************
More information about the wsf-dev
mailing list