[OpenID] MultiAuth and MultiFactor Authentication

[Peter Williams]

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!

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.

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.

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.

From: general-bounces at openid.net [mailto:general-bounces at openid.net] On Behalf Of Nat Sakimura
Sent: Friday, January 30, 2009 10:28 PM
To: SitG Admin
Cc: general at openid.net
Subject: Re: [OpenID] MultiAuth and MultiFactor Authentication

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<mailto: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<mailto: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://lists.openid.net/pipermail/openid-general/attachments/20090131/6308146f/attachment-0002.htm>