Subject: [dix] Setting aside irrelevant or incomplete histories

From: Nick Ragouzis <[email-masked]>
Date: Mon, 20 Feb 2006 17:47:21 -0800

[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-masked]> @ 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 Microsystem’s 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:   -- Entr’Overt 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 Radio@AOL, 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;   -- Communicator’s
    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;
      -- XConnect’s 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; ??SAP’s 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-masked]
https://www1.ietf.org/mailman/listinfo/dix