[OpenID] MultiAuth and MultiFactor Authentication

Nat Sakimura sakimura at gmail.com
Fri Jan 30 22:27:47 PST 2009


I think this discussion should occur in specs ML....

Having said that...

I envision that OPs eventually get dicomposed to

1) Discovery providers
2) Assertion providers

When we speak of OP right now, it is 1) + Special case of 2), which is a
credential validator.
(It usually does not talk about the registration quality, so it is not even
an identity provider.)

In the presentation that I use here in Japan, there appears two types of OP.

One is a "casual" OP that one uses for blogging etc. The other is a Bank.
A parson creates a session with a site using the authentication assertion
provided by
the "casual" OP. When he decides to check out, then the site demans a higher

assurance assertion, and is redirected to the Bank OP, etc.

=nat

On Sat, Jan 31, 2009 at 3:08 PM, SitG Admin <sysadmin at shadowsinthegarden.com
> wrote:

> 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.
>
> 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.
>
> 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.
>
> (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.)
>
> 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.
>
> -Shade
> _______________________________________________
> general mailing list
> general at openid.net
> http://openid.net/mailman/listinfo/general
>



-- 
Nat Sakimura (=nat)
http://www.sakimura.org/en/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://openid.net/pipermail/general/attachments/20090131/4d28a126/attachment.htm>


More information about the general mailing list