> -----Original Message-----
> From: Rich Salz [mailto:r.salz@...]
> Sent: 01 April 2002 15:18
> To: email@example.com
> Subject: Re: [soapbuilders] Sessions
> Wow, Jorgen, where to begin? I disagree with just about everything in
> your note.
Wow, Rich, I think you have misunderstand almost everything in my note
> First off, this mailing list has
> already done more for interop than the SAML group ever will.
That is because this group is focused on interoperability testing, and
the SAML group is focused on standards setting.
That was EXACTLY my point!
> For quite some time, security sessions will be SSL/TLS, much
> more than
> it will be SAML. The current installed base of name/password
> over SSL is
> not going to throw that out for SAML as part of their move to
> XML. When
> you throw in the Liberty/Hailstorm issues, it's gonna be even worse.
I completely agree that transport level session features will remain
important for a very long time. However, transport-level features such
as SSL work on a hop-by-hop basis, so the only way to achieve end-to-end
session functionality with a complex network infrastructure topology
involving SOAP routers, SOAP firewalls and SOAP processing nodes is at
the XML level. This can either be done on an application-specific basis
or using some sort of "standardized representation".
We cannot and should not stop people using app-specific ways of doing
this if they want to, but I am saying that there are already emerging
standard for this "standardized representation" without trying to invent
yet another one. We already have more than enough competing and
overlapping standards in the XML space to confuse the market for some
considerable time to come!
> I predict SSL will dominate for at least the next two years.
> Therefore,application-specific sessions -- XML cookies, if
> you will --
> are more important for the foreseeable future.
See comments above, although I think am making a distinction between XML
cookies being used at the application level and the same ideas begin
used at the system level under the guise of infrastructure standards
such as SAML Session Assertions, whereas you may not be.
Nothing would stop you taking the SAML Sessions document and using it on
an application-by-application basis right now. Or for that matter the
OTA Sessions or UDDI Sessions systems. They are all just schemas, after
> It would be nice if the
> frameworks supported a common mechanism to UDDI (gak) could have the
> same state mechanism as a Goole search, all supported by the SOAP
> infrastructure without having to recreate it all the time.
I agree it might be "nice", but this is not something that we
(SoapBuilders) can mandate use of in practice for every application in
I suggest that over time the focus will move away from session support
on an application-specific basis towards this being part of standard web
services platform services once the necessary standards specifications
(such as SAML Session Assertions) are in place and agreed.
Transport-level session support such as SSL or HTTP Cookies will run
alongside and throughout this evolution, and are totally orthogonal to
it in my opinion.
I don't think you actually disagree with me so much at all, Rich! :-)
Try Cape Clear for all your Web Services software needs.
CapeConnect - Enterprise-grade Web Services Runtime Platform
CapeStudio - Professional Web Services Development Suite