OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: [security-services] RE: [saml-dev] RE: Is a separate"ArtifactReceiver" required?



On Tue, 10 Dec 2002, Scott Cantor wrote:

> > I would support adding a minimal extension
> > that supports flow from destination to source site. My
> > question is whether it needs to be anything more than:
> > (taken from
> > http://lists.oasis-open.org/archives/security-services/200212/
> > msg00001.html)
>
> "Needs" is the key word here. It doesn't need to be anything more, but
> in a real world implementation, one finds lots of reasons to want to do
> more.
>
> Bob, is there a Web-ISO project document that discusses any requirements
> in this area?

The document that's intended to capture this stuff is:

http://middleware.internet2.edu/webiso/docs/draft-internet2-webiso-model-01.html

but it's still quite incomplete.

> From my own experience, I can think of a few things:
>
> - error/status information from the resource site
> - customization hooks for the resource site
> - optional feature control, such as bypassing single sign-on
> - timestamp information for those willing to sync clocks helps detect
> stale redirects (the "Back" button fix)
> - ability to POST the redirect to allow session maintenance across form
> POSTs (a critical issue that requires use of the POST profile to work)

That's a good starter list (assuming we can flesh some of these out ...
8^).  Other things that I've seen systems do include:

 * policy selector:  more or less a named aggregation of feature controls;
 * delegated credentials:  request creds that the target can use to
     authenticate to downstream services;
 * integrity/disclosure protection of the request.

The implication is that a structured, extensible format is needed for this
kind of message, where it would be straightforward to build on our
existing request format (as the Liberty specs propose).

> None of that needs to be part of SAML, obviously, but I'd never deploy a
> new SSO system that didn't at least plan to deal with things like that
> at some point.

Well, "needs to be interoperable" to me equates to be "needs to be
standardized".  I can't understand why we would choose to leave
standardization of this to some other group or activity.

In particular, I am concerned about the idea that the Liberty
specifications can pick up where SAML leaves off.  The Liberty process is
not the OASIS process, Liberty standards are not OASIS standards.  I'm
more than happy to have our TC accept submissions of good work from our
friends in Liberty, but this is not a substitute for actual SSTC output in
these areas.

 - RL "Bob"




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC