<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:x="urn:schemas-microsoft-com:office:excel" xmlns:p="urn:schemas-microsoft-com:office:powerpoint" xmlns:a="urn:schemas-microsoft-com:office:access" xmlns:dt="uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s="uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs="urn:schemas-microsoft-com:rowset" xmlns:z="#RowsetSchema" xmlns:b="urn:schemas-microsoft-com:office:publisher" xmlns:ss="urn:schemas-microsoft-com:office:spreadsheet" xmlns:c="urn:schemas-microsoft-com:office:component:spreadsheet" xmlns:odc="urn:schemas-microsoft-com:office:odc" xmlns:oa="urn:schemas-microsoft-com:office:activation" xmlns:html="http://www.w3.org/TR/REC-html40" xmlns:q="http://schemas.xmlsoap.org/soap/envelope/" xmlns:D="DAV:" xmlns:x2="http://schemas.microsoft.com/office/excel/2003/xml" xmlns:ois="http://schemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir="http://schemas.microsoft.com/sharepoint/soap/directory/" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:dsp="http://schemas.microsoft.com/sharepoint/dsp" xmlns:udc="http://schemas.microsoft.com/data/udc" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:sub="http://schemas.microsoft.com/sharepoint/soap/2002/1/alerts/" xmlns:ec="http://www.w3.org/2001/04/xmlenc#" xmlns:sp="http://schemas.microsoft.com/sharepoint/" xmlns:sps="http://schemas.microsoft.com/sharepoint/soap/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:udcs="http://schemas.microsoft.com/data/udc/soap" xmlns:udcxf="http://schemas.microsoft.com/data/udc/xmlfile" xmlns:udcp2p="http://schemas.microsoft.com/data/udc/parttopart" xmlns:wf="http://schemas.microsoft.com/sharepoint/soap/workflow/" xmlns:dsss="http://schemas.microsoft.com/office/2006/digsig-setup" xmlns:dssi="http://schemas.microsoft.com/office/2006/digsig" xmlns:mdssi="http://schemas.openxmlformats.org/package/2006/digital-signature" xmlns:mver="http://schemas.openxmlformats.org/markup-compatibility/2006" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns:mrels="http://schemas.openxmlformats.org/package/2006/relationships" xmlns:spwp="http://microsoft.com/sharepoint/webpartpages" xmlns:ex12t="http://schemas.microsoft.com/exchange/services/2006/types" xmlns:ex12m="http://schemas.microsoft.com/exchange/services/2006/messages" xmlns:pptsl="http://schemas.microsoft.com/sharepoint/soap/SlideLibrary/" xmlns:spsl="http://microsoft.com/webservices/SharePointPortalServer/PublishedLinksService" xmlns:Z="urn:schemas-microsoft-com:" xmlns:st="" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=Content-Type content="text/html; charset=us-ascii">
<meta name=Generator content="Microsoft Word 12 (filtered medium)">
<style>
<!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;}
@page Section1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=EN-US link=blue vlink=purple>
<div class=Section1>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Out of interest, what is the name of the bank, doing using
openid protocols for regulated financial transactions? If they are not willing
to be publicly identified, why not? Surely they are proud of their contribution?
– it is a fascinating endorsement, after all!<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>But, lets not abuse the community brand here. One party doing
openid must interwork with others doing openid. Though a trust model may limit
access, systems must “work”. A new bank partner must be able
to select any reasonably complying vendor of openid software, and expect the
systems to technically cooperate with the banks software systems - with
little further fuss.<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>If the vendor of openid software used by the bank must now supply
the bank partner’s openid software set, I don’t think we can call
that openid. That’s just the typical B2B SAML2 model, where some giant power
hub imposes software solutions on its spokes, … or imposes cisco routers
on the spokes so the hub’s MPLS vendor can now run and enforce the hub’s
“openid” trust network at the frame level.<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>I do agree on the separation of assertion maker and discovery partner.
Clearly, the control axis (s/he who runs the trust network now be very
powerful!) passes to discovery, making the assertion/attribute provider more of
a medieval donkey, doing grunt work for commodity pricing.<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<div style='border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt'>
<div>
<div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'>
<p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span
style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>
general-bounces@openid.net [mailto:general-bounces@openid.net] <b>On Behalf Of </b>Nat
Sakimura<br>
<b>Sent:</b> Friday, January 30, 2009 10:28 PM<br>
<b>To:</b> SitG Admin<br>
<b>Cc:</b> general@openid.net<br>
<b>Subject:</b> Re: [OpenID] MultiAuth and MultiFactor Authentication<o:p></o:p></span></p>
</div>
</div>
<p class=MsoNormal><o:p> </o:p></p>
<p class=MsoNormal style='margin-bottom:12.0pt'>I think this discussion should
occur in specs ML.... <br>
<br>
Having said that... <br>
<br>
I envision that OPs eventually get dicomposed to <br>
<br>
1) Discovery providers<br>
2) Assertion providers<br>
<br>
When we speak of OP right now, it is 1) + Special case of 2), which is a
credential validator. <br>
(It usually does not talk about the registration quality, so it is not even an
identity provider.) <br>
<br>
In the presentation that I use here in Japan, there appears two types of OP. <br>
One is a "casual" OP that one uses for blogging etc. The other is a
Bank. <br>
A parson creates a session with a site using the authentication assertion
provided by <br>
the "casual" OP. When he decides to check out, then the site demans a
higher <br>
assurance assertion, and is redirected to the Bank OP, etc. <br>
<br>
=nat<o:p></o:p></p>
<div>
<p class=MsoNormal>On Sat, Jan 31, 2009 at 3:08 PM, SitG Admin <<a
href="mailto:sysadmin@shadowsinthegarden.com">sysadmin@shadowsinthegarden.com</a>>
wrote:<o:p></o:p></p>
<p class=MsoNormal>One of the things I expected we might see if MultiAuth
became widely implemented, is the diversification and specialization of OP's;
instead of a single OP providing (for example) 3 factors, at varying levels of
effectiveness, each OP might focus on handling a single factor *very very
well*, and assume that the user would be involving other OP's anyway, so there
wouldn't necessarily be any weakness in any single OP not covering more than
one factor by itself.<br>
<br>
With the suspicion implied in MultiAuth's trust model, though, aren't we losing
factors? If we assume that 1 (unknown) OP is malicious, doesn't this mean that
they would be lying about whether the user authenticated at all, and therefore
we would have to subtract from our list the factor(s) that OP was assumed to
provide? The simplest setup I see for OP's to provide less than 3 factors
(assuming we're looking at the traditional three) without any being lost is 3
OP's each covering 2 out of 3 (subtracting any one OP would leave half its
factors covered by each of the other OP's), or perhaps half-a-dozen OP's (one
redundanct provider apiece) if OP's insisted on specializing down to a single
factor. This gets more complicated if we want to allow for the possibility of
one or more of those OP's going down *and then (still)* having one of the
remaining OP's be malicious.<br>
<br>
I'm rethinking whether specialization is likely to occur. It would enable OP's
to start out focusing on just one mode of authentication, rather than having to
compete in all areas from the beginning. The community's ability to
collectively duplicate a major OP's multifactor authentication would keep users
from being easily "locked-in" without any viable alternatives.<br>
<br>
(Seem unlikely? Think of how much money your company might stand to lose if
vital services were unavailable during the switch - and pretend these vital
services are something *besides* OpenID, to emulate the part where you don't
really understand how OpenID works. Think of the companies that are still
spending money on Microsoft products today, not because they are *unaware* of
free alternatives but because of the loss of productivity they would suffer
while their employees retrained with the new software. If setting up your own
OP takes too long, or too many resources, it may not be viable.)<br>
<br>
It looks like the cost:effect ratio might lose more to effect (when the users
prefer to not use so many OP's to establish their identity) than it stands to
gain from reduced cost.<br>
<br>
-Shade<br>
_______________________________________________<br>
general mailing list<br>
<a href="mailto:general@openid.net" target="_blank">general@openid.net</a><br>
<a href="http://openid.net/mailman/listinfo/general" target="_blank">http://openid.net/mailman/listinfo/general</a><o:p></o:p></p>
</div>
<p class=MsoNormal><br>
<br clear=all>
<br>
-- <br>
Nat Sakimura (=nat)<br>
<a href="http://www.sakimura.org/en/">http://www.sakimura.org/en/</a><o:p></o:p></p>
</div>
</div>
</body>
</html>