RE: [security-services] Comment on SAML implementations and their inter-op properties

["Griffin, Robert" <rgriffin@rsasecurity.com>]

A few additional thoughts, from the perspective of working on conformance
for SAML 1.0 as well as working with customers on SAML-based solutions.

Like Eve, I welcome Daniel Blum's open letter as interesting and timely.
Particularly important is his recognition that "customers lack a high level
of confidence that they will be able to get their SAML implementations to
interoperate seamlessly with partner implementations" and the implicit
concern that this limits acceptance and implementation of SAML-based
solutions. 

All five of the suggestions Daniel makes for addressing this problem (his
points #1 and #2 each contain two distinct though related suggestions) are
certainly worth considering. 

1) Test harness and/or reference implementation. During the SAML 1.0
process, the Conformance subcommittee had a number of discussions about the
creation and support of test suites, including setting up a formal or
informal certification program by a group such as NIST. That no vendor or
third-party stepped forward to sponsor a publicly-available test suite
reflected both the commitment of resources required and the newness of the
spec. But I would fully expect the door to be open for anyone interested in
contributing to or driving such an effort.

2) Interoperability testing. (point #1, last sentence). The SAML committee
continues to sponsor interoperability events, very often with the support of
Burton Group; the next such event is, I believe, targetted for early CY2004.
We might be able to use these events to address the issue of customer
confidence by publicizing the event both beforehand and afterwards, and by
describing for industry publications the scenarios that are tested. 

3) Test harness support browser artifact SSO profile. This is certainly a
reasonable place to start; I'm assuming that the intent is to make this as
minimal a set of functionality as possible (for example, no attribute
statements in the assertion).  

4) Mandatory use case. We discussed this question a lot during SAML 1.0, and
decided that making any particular use case mandatory was inappropriate,
given the range of solutions that SAML could address. What was important, we
felt, was to specify what needed to be implemented by a vendor claiming
conformance to a profile or protocol binding. That still seems to me the
right approach, though finding a simpler way to identify what parts of SAML
a given vendor supports would be a good idea.

5) Customer information. This feels to me like a much larger issue than a
"SAML cookbook". This level of customer assistance is an area where groups
like Burton have in the past provided significant value and in which many
vendors published white papers. However, I'd be very glad to work with Eve,
John and Daniel on seeing what is currently available and what should be
added.

Early in the discussions of conformance, we distinguished between the two
related but distinct questions of conformance to spec and interoperability
among implementations. Although conformance to spec is a necessary
precondition to interoperability, it is not sufficient: even in a
single-vendor implementation of cross-domain sign-on, for example, the
details of the contract between parties determines whether requests,
responses and assertions are mutually understandable. Even though strides
can certainly be made in increasing customer confidence in SAML
interoperability, we should also encourage customers to be realistic about
the work required to understand fully the relationships among parties in a
SAML solution.

Bob Griffin 

-----Original Message-----
From: Eve L. Maler [mailto:eve.maler@sun.com] 
Sent: Monday, November 10, 2003 1:58 PM
To: 'security-services@lists.oasis-open.org'
Subject: Re: [security-services] Comment on SAML implementations and their
inter-op properties

Interesting and timely feedback.

The issue of working on a test suite came up in the September meeting, 
but we didn't get very far with it.  Perhaps we should see if Daniel 
Blum's exhortation makes it more attractive for some SAML participants 
to take on this resource-intensive task.  At the least, should we be 
planning additional interop events for various scenarios?

Regarding having a a "must-implement profile": This seems a little weird 
to me if you look at the entire range of possible and existing profiles, 
though if we couched it in terms like "*If you're doing SSO*, you must 
support XYZ profile" it would make more sense.  We discussed this idea 
very early on; maybe it's time to revisit it.

Regarding "cookbook" material, we are indeed creating more outreach 
materials, including executive and technical overviews and the FAQ. 
Maybe we (John Hughes and I?) should contact Daniel about this and offer 
the opportunity to review and make suggestions.

	Eve

Mishra, Prateek wrote:

> http://burtongroup.com/weblogs/danielblum/
> 
> - prateek
> 
> Prateek Mishra
> Director, Tech&Arch
> Netegrity
> 
> p: 781-530-6564
> c: 617-875-4970
-- 
Eve Maler                                        +1 781 442 3190
Sun Microsystems                            cell +1 781 354 9441
Web Products, Technologies, and Standards    eve.maler @ sun.com


To unsubscribe from this mailing list (and be removed from the roster of the
OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/security-services/members/leave
_workgroup.php.