[Thread note:
To avoid expanding this email, and follow on digests, I've broken
the prior email up into several different threads. As we don't have
real distinguishing topical thread names, yet ... so I didn't see
that as a problem. Apologies in advance if it's bothersome.
The original thread continues on:
1. Setting aside irrelevant or incomplete histories
2. Meaning of Simple? Basis for concrete and specific requirements.
3. SAMLv2-LowLow: Bindings and Profiles?.
]
Dick,
Dick Hardt <[EMAIL PROTECTED]> @ Tue, 14 Feb 2006 02:17:22 -0800 wrote:
<snip>
> On 25-Jan-06, at 11:03 AM, Nick Ragouzis wrote:
<snip>
Dick continued:
> > Dick Hardt wrote:
> >> Hey Tom
> >> I think the SAML authors did a great job of standardizing
> >> a language to represent assertions to be moved between systems,
> >> and was driven by vendors wanting to enable interop with between
> >> their enterprise solutions.
> >
> > NR: Um, was driven ^in part^ by such vendors. In this forum,
> > in the inclusive fashion marking this and other SDO, let's
> > be straight about this, or be silent. Self-interest has
> > many guises.
>
> Not sure what your point is here, sorry.
Great, then we're in agreement: lineage, even if appropriately
described, is irrelevant to our challenges here.
<snip>
Dick continued:
> Perhaps another way of looking at this is to ask the following
> questions:
>
> Why is SAML not widely adopted? Why is it not being used at Amazon,
> Yahoo!, Google or MSN? It has been around long enough.
> Why was SMTP standardized when X.400 was being worked on?
> Why was LDAP created when X.500 was looming?
>
> My opinion is because X.400 and X.500 were too heavy and did not
> easily solve the problems people wanted to solve.
>
> SAML solves some people's problems, but clearly is not solving a
> bunch of other people's problems, or it would have been
> adopted by now.
>
> -- Dick
Well, now we're back with that same sort of argument as with
protocol lineage. I hope we will soon drop this sort of argument
altogether.
The DIX proposal should, on its own, have definite and specific
descriptions of the gaps and directed fixes, along with the
additions that pull it together.
X.400 and X.500 might have been, be, too heavy, whatever that
means. But if we are going to design for success on that basis,
we'd also have to include other histories:
A. All the 'light' protocols and extensions that also failed
for one reason of another (lack of robustness, absence of
integration and interoperability, poor extensibility ...); and,
B. All the effort that's been required to unify these protocols
with their forks. E.g., to fatten up LDAP.
IOW, if we were going to use these sorts of generalizations, we'd
have to be more accurate and relevant in any characterization that
was intended to drive our decision making.
And we'd have to consider a few other factors too:
C. The fact that the community has learned a thing or two about
how to build an extensible, composable protocol, so we're
not working with the likes of X.400 here; and,
D. The value of community resources, and the importance of
not running off without thinking through the longer-term
and combined effects.
. . . .
For those who are not easily convinced that these aren't useful
arguments, I include the following, below:
A summary profile of the extent of adoption for the SAML-LAP
family of standards (and others that are included).
For any of these entries you'd have to apply a multiplier. I don't
know what those multipliers are, but they are very large, whether
for multi-country deployments or single-use environments. On this
basis you can hardly argue that SAML is "not widely adopted".
Other mysteries remain, however.
If we take that more seriously, for a minute, we, the community,
could make some progress by setting straight any of the silly
parochial notions that certain service providers have about
what's strategically sound or not. Division and one-upsmanship
on identity exchange is just silly nonsense.
If we are appropriately determined, we will make sure in this
effort that AS MUCH AS POSSIBLE (even if in some perspective a bit
sub-optimally) we build our innovations on, and bridge across,
existing systems as much as possible.
--Nick
Adoptions in SAML-LAP family standards. These are compiled from,
mostly, secondary sources and publicly available information.
Likely to be out-of-date, or in error. I haven't updated it in
months with information I've received. (But please send info,
I'm getting to an update.)
Certainly incomplete: e.g., it doesn't account for the main body
of the $1.2billion 2005worldwide estimate of Radicati Group; or
for the millions of consumer identities coming online in several
deployments; or for the count of actual students, researchers,
and other users behind, e.g., the Shib deployments.)
1. Implementations Certified for SAMLv1.0 Artifact Profile in
U.S. eGov E-Authentication Program: Entegrity, Entrust,
Hewlett-Packard, IBM, CA/Netegrity, Novell, Oblix (Oracle),
RSA Security, Sun Microsystems, Trustgenix (HP), DataPower
(IBM);
2. Conformance-Tested Implementations of SAMLv2 (for various web
single sign-on and SOAP profiles): Electronics and
Telecommunications Research Institute (ETRI), Ericsson,
Hewlett-Packard, IBM, NEC, NTT, Novell, Oracle, Reactivity,
RSA Security, Sun Microsystems, Symlabs, Trustgenix (HP);
3. Demonstrated Mutual SAMLv2 Interoperability: ECA/Netegrity,
DataPower (IBM), Entrust, NTT, OpenNetwork, Oracle, RSA
Security, Sun Microsystems, Symlabs, Trustgenix (HP);
4. Conformance-Tested Implementations of ID-WSF1.0 and ID-WSF1.1:
Hewlett-Packard, Nokia, Novell, NTT, Sun Microsystems,
Symlabs, Trustgenix (HP);1
5. Adoption in other standards and recommendations:
-- ID-WSF1.1 in OMA (Open Mobile Alliance) in Web Services
Enabler Releases, TV-Anytime Forum for AdvEPG (and therefore
by the DVB Project) in Europe, Asia and Americas (possibly
U.S.); -- Liberty ID-FF1.2 in SAMLv2.0; -- SAMLv2.0 in
ebXML Registry v3.0, in WS-Security SAML Token Profile 1.1 (to
be proposed), HIMSS IHE XUA for XDS (Global healthcare
interoperability specification, cross-domain authentication
including extended profiles), and in Liberty ID-WSF2.0;
-- SAMLv1.1 in Trusted Mobile Platform; -- Microsoft and
Sun Microsystems convergence profile of ID-FF1.2 (therefore
SAMLv1.1) and WS-Federation in Web SSO Interop Profile and
WS-MetadataExchange in Web SSO MEX; -- Microsoft InfoCard
(use of SAMLv2.0, now in demonstration, forthcoming in Vista,
4Q06); -- Globus Tookit for Grid Security Infrastructure
(use of SAMLv1.1 in OGSA; and GridShib Shib-to-glob attribute
gateway);
6. Open Source or Developer Tools: -- EntrOvert Lasso
(ID-FF1.2) for eGovernment; OpenSAML (SAMLv1.1, soon
SAMLv2.0); -- PingIdentity (SAML and ID-FF, and toolkit);
-- Sun Microsystems (ID-FF, and toolkit); -- Shibboleth
(SAMLv1.1, SAMLv2.0 imminent); -- Oracle (toolkit); -- NTT
for vendor integration; Guanxi and Samuel (SAML1.1 and
Shibboleth);
7. ID-WSF Deployments, including discovery and interaction
services: AOL [EMAIL PROTECTED], Axalto, Hewlett-Packard, Nokia
(including in retail handsets), Novell, NTT, Sun Microsystems,
Juniper Networks (embedded in VPN appliances), Symlabs,
Trustgenix (HP);
8. Infrastructure and Embedded Implementations: Ericsson,
Alcatel, Elios, Nokia, Trustgenix (HP), France Telecom/Orange,
IBM, Sun Microsystems, NEC, NTT, NTT DoCoMo, Vodafone,
Turkcell;
9. Education, Government, eHealth and Regulatory:
-- U.S. Government eGov E-Authentication (SAMLv1.0) for 14
major government agencies (The Danish Government have adopted
this program, in SAMLv2.0); -- BIPAC (ID-FF1.2) for
regulatory-compliant employee participation in government
independent of employer; -- EduMart (ID-WSF1.1) in Japan for
98 public schools and 24 content providers; -- HAKA
Federation (Shibboleth) of Finnish universities, polytechnics,
and research institutions; -- Juniper Networks application at
Catholic Health Systems in New York, NY; -- InCommon
(Shibboleth) 18 higher institutions of higher-education
throughout the US, including the University of California,
Cornell, Ohio State, University of Chicago, and several
content providers, such as Elsevier ScienceDirect, as well as
products such as Blackboard, WebCT, WebAssign, EBSCO, JSTOR,
and SFX; -- InQueue (Shibboleth) over 100 institutions
across the Americas, Europe, and Asia in trial; -- Joint
Warrior Interoperability Demonstration (JWID) 2003 with
Canada, Australia, New Zealand, United States, United Kingdom,
and Norway using ID-FF1.1 (larger group in CWID 2006);
-- SDSS (Shibboleth Development and Support Services) for
Edima at Edinburgh University Data Liberty for a large
collection of UK academic online resources (Shibboleth);
-- SWITCH Swiss education and Research Network (Shibboleth);
-- U.S. Department of Labor Mine Safety and Health
Administration (likely SAMLv1.0);
10. Financial Services and related: -- Fidelity Investments, in
a corporate setting 401(k) management application, uses
Liberty ID-FF, with identity services discovery techniques,
and Liberty Identity Services Personal Profiles, to isolate
corporate from personal persona; -- Communicators
SecuritiesHub (Citigroup, Credit Suisse First Boston, Goldman
Sachs, JPMorgan Case & Co, Lehman Brothers, Merrill Lynch,
Morgan Stanley, UBS Warburg) for over 24,000 institutional
investors in 60 countries co-mingling 800 analysts results;
-- ACS Electronic Land Records Exchange (eRX) electronic
recordation; -- Nationwide Insurance throughout the
producer channel; -- Niteo, for the Financial Services
Technology Consortium (FSTC), JPMorgan Chase, Wachovia, and
Bank of America; -- Workscape Inc. and Sun Microsystems
providing General Motors 401(k) services portal;
-- XConnects partnership with eBIZ.mobility Federated
Payment for fixed and mobile payments; -- Other financial
services companies thought to be active at some stage (Wells
Fargo, AmericanExpress);
11. Airlines and related: -- Star Alliance (Lufthansa, United
Airlines, SAS Scandinavian Airlines, Thai Airways
International, Air Canada and 10 more), for authentication
and resources, with Novell; -- JAL Online (travel planning,
check-in, expenses and reimbursement to credit cards) with
NTT Data; -- Boeing in two applications, one for 500,000
former employees and beneficiaries, another for MyBoeingFleet
for customer access to fleet operation and maintenance
information;
12. Supply Chain Management: -- Proctor & Gamble (also an
employee gateway); Covisint (using RSA Security FIM, for
Ford, DaimlerChrysler, Delphi, Visteon, Freightliner,
Metaldyne, Mitsubishi); ??Oracle implies PeopleSoft and
Siebel; ??SAPs wide use of
13. Protocol gateways and bridging: Trustgenix (HP),
PingIdentity, Sun Microsystem, BMC Software;
14. Other: Siemens HiPath DirX Access Federation (SAMLv1.0 and
SAMLv1.1); -- BEA, a SAMLv1.1 gateway on WebLogic Server;
-- Adobe in LiveCycle, SAMLv1.x, might be SAMLv2;
-- Evidian, with Deutsche Post on SAMLv1.1? (c. 2003) and
Liberty id-ff1.2?.
_______________________________________________
dix mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/dix
