<HTML><HEAD></HEAD>
<BODY>
<DIV id=idOWAReplyText15555 dir=ltr>
<DIV dir=ltr><FONT face="Times New Roman" color=#000000 size=3>Nat:</FONT></DIV>
<DIV dir=ltr><FONT face="Times New Roman" color=#000000 size=3></FONT> </DIV>
<DIV dir=ltr><FONT face="Times New Roman" color=#000000 size=3>For fun and experimentation, why dont we simply setup a SAML1.1 connection from my composite SAML/openid OP to some demo Shib IDP? As far as the Shib IDP would be concerned, the exchange ould just looks like any other sp-initiated WebSSO flow. The combined flow would create the illusion of the end user of an openid2 logon to SPs, that in reality is controlled the existing Shib IDP.</FONT></DIV>
<DIV dir=ltr> </DIV>
<DIV dir=ltr>I know you've told me several times, but I can never quite remember what it is about Shib's profile of SAML1.1 that means it cannot cooperate with a standard SAML1.1 endpoint, out of the box. Tell me again, and Ill see what I can to make my SP (co-resisident with the listener with the frontend openid2 protocol port) behave more like a Shib SP on the backend.</DIV>
<DIV dir=ltr> </DIV>
<DIV dir=ltr>If things go down to the very wire formats that I cannot influence , I suppose I can add yet another layer 7 bridge where - my SAML backend protocol machine can leverage yet another intermediary SP/SP gateway handoff - to talk now to the Shib IDP.</DIV></DIV>
<DIV dir=ltr><BR>
<HR tabIndex=-1>
<FONT face=Tahoma size=2><B>From:</B> Nate Klingenstein<BR><B>Sent:</B> Wed 3/12/2008 8:37 AM<BR><B>To:</B> Peter Williams<BR><B>Cc:</B> OpenID List<BR><B>Subject:</B> Re: [OpenID] OpenID; a single choice<BR></FONT><BR></DIV>
<DIV><PRE style="WORD-WRAP: break-word">Peter,
Unless you're talking about a separate EDUCAUSE initiative of which
I'm unaware, you might mean InCommon, which is based primarily on
Shibboleth and a profile of SAML 1.1 right now. It's still growing at
a good pace, but it's actually dwarfed by some of the federations in
other countries for research & education, such as the not-to-be-
abbreviated UK Access Management Federation for Education and Research
and SWITCHaai. A federation is a group of identity providers and
applications(though some believe only identity providers) that agree
to exchange resources and user data under a common trust framework.
http://www.incommonfederation.org/participants.cfm
Discovery is the biggest challenge in SP-initiated federated identity,
and we've spoken of it for years as the "WAYF problem." I don't think
today's solutions are optimal -- certainly not button proliferation,
and probably not user typing. Cardspace-like technologies ameliorate
a lot of problems, including this. You can see a few of the large-
scale approaches attempted so far at Microsoft's DreamSpark and
Elsevier ScienceDirect (Windows LiveID registration required at the
former; "Athens/Other Institutional Login" required at the latter).
http://channel8.msdn.com/
http://sciencedirect.com/
Applications serving smaller communities have smaller lists, buttons,
or make specific presumptions.
Thanks,
Nate.
On 12 Mar 2008, at 15:21, Peter Williams wrote:
> We should look to the educause pilot, to see how effective sp-
> initiated websso is, in the academic sphere - where each of 3000
> colleges is logically an idp/op (only 30 tho, so far)
>
> -----Original Message-----
> From: Eddy Nigg (StartCom Ltd.) <eddy_nigg@startcom.org>
> Sent: Wednesday, March 12, 2008 8:06 AM
> To: tom <tom@barnraiser.org>
> Cc: OpenID List <general@openid.net>
> Subject: Re: [OpenID] OpenID; a single choice
>
> tom:
>> Is it only me that has an
>> issue with this given that before long pages will be covered with
>> many
>> logos and that I'll end up having to search for the OpenID logo?
>>
>> I appreciate the "open" aspects of OpenID, but for the user would
>> it not
>> be better to have the browser manufacturers agree on a way to store
>> an
>> OpenID and auto-direct to my OP rather than giving the user a zillion
>> logos on a screen?
>>
> This has been anticipated and was obvious (even by design). OpenID has
> refused to address the issues of a trust point or federated network of
> OpenID operators and this is the result. There are and will be many
> sites which will trust only their own or a very narrow choice of
> OpenID
> providers.
>
> When making these suggestions more then 1 1/2 years ago I was booed
> down....something about "taking away the freedom to operate randomly
> OPs" was mentioned many times. Well, you can blame these idiots today
> for refusing to address this issue, because, yeah...their freedom is
> going to be taken away by reality now, and not by providing and
> organizing a framework which would have allow RPs to trust OPs
> according
> to agreed rules and accepted standards. In a federated network of OPs
> and some established criteria everybody could trust anybody....
>
> --
> Regards
>
> Signer: Eddy Nigg, StartCom Ltd. <http://www.startcom.org>
> Jabber: startcom@startcom.org <xmpp:startcom@startcom.org>
> Blog: Join the Revolution! <http://blog.startcom.org>
> Phone: +1.213.341.0390
>
>
> _______________________________________________
> general mailing list
> general@openid.net
> http://openid.net/mailman/listinfo/general
</PRE></DIV></BODY></HTML>