Skip to Content.
Sympa Menu

shibboleth-dev - RE: [Shib-Dev] SHIB Status call -- 6/23/2008) -- 12:00 pm EDT, 9 am PDT

Subject: Shibboleth Developers

List archive

RE: [Shib-Dev] SHIB Status call -- 6/23/2008) -- 12:00 pm EDT, 9 am PDT


Chronological Thread 
  • From: "Scott Cantor" <>
  • To: <>
  • Subject: RE: [Shib-Dev] SHIB Status call -- 6/23/2008) -- 12:00 pm EDT, 9 am PDT
  • Date: Mon, 30 Jun 2008 11:21:56 -0400
  • Organization: The Ohio State University

> If all the extensions do is make the infocard message formats bear shib
> signals, have we really made any progress? The language/protocols between
> IDP/SP might as well be klingon, if all it does it say the same thing as
the
> last extension.

The point of supporting protocols is interoperability with others'
implementations. If we were only interested in talking to ourselves,
Shibboleth wouldn't exist.

> Leaving issues of legitimacy aside, we know that Shib over SAML1 and SAML2
> implementations conceive of a world that is exclusively "pairwise".

No, the SAML profiles conceive of that world. Proxying is NOT part of the
SAML SSO profile. That's why proxying is exposed with conditions and request
features and specific processing rules for doing it on top of the basic
profile.

> We also know that
> Shib over WS-Fed differs from ADFS native, in that ADFS can (optionally)
> rely on a trusted directory to enforce nameid semantics. (For Shib, a
nameid
> is limited semantically to being just another form of an attribute.)

And we could list things Shibboleth supports that ADFS doesn't. Those are
value-adds. People should pick implementations that support the spec they
want and then have the value-adds that they need.

> For cardspace, we know the big differentiator defined by the very concept
its
> the ability of the RP to rely on a specifcally trusted intermediary
(trusted
> in the Oragne Book sense) - which allows websso to embody user-centric
> intent and involvement (in a way that is almost un-federation; un-SAML2).

The Cardspace client is not an intermediary in that sense, it's a client. If
you're trying to make some sort of argument that because Shibboleth does not
favor people who build server-side gateways that it's somehow "inconsistent"
with Infocard, that's just plain wrong.

The "non-federated" aspects of the profile introduce different
considerations and we have to come up with reasonable ways to handle that.
But they have nothing whatsoever to do with gateways.

-- Scott





Archive powered by MHonArc 2.6.16.

Top of Page