I don't think it will get ugly because I think there are many ways to layer
on the functionality we are talking about. 

For example, Visa has something called 3-D Secure which is similar in many
ways to OpenID using INames. Instead of keying authentication off of INames,
they use Credit Card numbers. 

3-D Secure is implemented in one of several programs - Visa has "Verified by
Visa", Mastercard has "Securecode". Each of these programs varies the
protocol slightly, but by in large, the authentication mechanisms are
enforced by *policy* (ie you MUST use auth at least as strong as this) and
that policy is enforced (among several methods) by 1) the fact that
communication with the (credit card) directory requires clients to
authenticate *to the directory* and 2) the back channel communication is
mediated through the directory. That is one mechanism (which I really don't
recommend) that OpenID could take. 

Dick suggested a method where there is some vendor providing strong
authentication which is verifiable by anyone (or at least anyone who is part
of the club and cares). That authentication proof could ride along as an
extension element in OpenID. I suggested another approach where IDP's
themselves were "part of a club" (and there could be any number of clubs)
and that proof that the *IDP* was part of the club could come along as an
extension to the OpenID data. 

And if you are worried about how the RP knows ahead of time that an IDP can
provide the requisite extensions, we have a mechanism in the XRDS to
advertise these facts. 

So I think all these pieces are there -- it's just a matter of figuring out
how to put them together for the specific scenarios we have. I think in fact
that there will not be *one* answer, but several -- each based on the
ecosystem involved. If electronic payments systems ever use OpenID, there
will be certain controls that everyone who is participating will have to
agree to, and those controls may have to be enforceable and auditable by
multiple parties. In other scenarios, only certain parties may care (ie
RP's) and it may be untenable to impose as many extension pieces.

But I think we're getting ahead of ourselves. As long as you believe the
extensibility is in there and there is a reasonable path forward, then we
should get the basic infrastructure gelled and rolled out soon, or else
we'll never get the experience and mindshare with OpenID that we want. 

The quicker we get today done, the quicker we can get to tomorrow. 


> -----Original Message-----
> From: Chris Drake [mailto:[EMAIL PROTECTED]
> Sent: Thursday, October 05, 2006 10:22 AM
> To: Dick Hardt
> Cc: Gabe Wachob; 'Kevin Turner'; specs@openid.net
> Subject: Re: Strong Authencation (was [PROPOSAL] authentication age
> Hi All,
> 1. Amazon asks the IdP "Please assert this user is not a Robot"
>    How can it trust this occurred?
> 2. Amazon asks the IdP "Please re-authenticate this user, via
>    two-factor, two-way strong authentication"
>    How can it trust *this* occurred?
> The IdP can *say* it did, but would RPs prefer a "stronger" role to
> encourage adoption? (eg: #1 - the RP provides the captcha, and the
> hash of the solution, while the IdP returns the solution, or #2 - the
> RP provides a nonce and later looks for this nonce in the IdP's
> also-signed-by-the-authentication-vendor-technology response)
> i.e.: It might get ugly to try and add this stuff in later if we've
> not catered up-front for these kinds of interchanges.
> Kind Regards,
> Chris Drake

specs mailing list

Reply via email to