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<br><br><div class="gmail_quote">On Sat, Jan 31, 2009 at 3:08 PM, SitG Admin <span dir="ltr"><<a href="mailto:sysadmin@shadowsinthegarden.com">sysadmin@shadowsinthegarden.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
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><br>
</blockquote></div><br><br clear="all"><br>-- <br>Nat Sakimura (=nat)<br><a href="http://www.sakimura.org/en/">http://www.sakimura.org/en/</a><br>