Interesting 'hear'. But one piece confused me. In describing the sequence by which a user would use their voice authentication to OpenID into LiveJournal, Avery said the following:
So, to LiveJournal, it thinks that you just went to any standard OpenID implementationTying in Strong Authn to SSO is great - the two pieces complement each other perfectly. Strong Auth gives SSO 'something to do' and provides value to the RP beyond convenience to the end users, and SSO makes Strong Authn practical and cost-effective.
.
.
it doesn't know that, instead of just putting in your log-in and your password, that you were actually going through and authenticating yourself by voice.
But this only works if the value of the strong authentication can flow to the RPs - this implying that the RP knows that the user actually used something beyond a password to log-in to the IDP. But, OpenID doesn't support anything to allow the IDP to make this distinction (nothing comparable to SAML's Authentication Context).
With OpenID as it is (or AFAIK expected to be in OpenID 2.0), the RP would be unable to provide a voice-authenticated user any different level of service than a password-authenticated user - this because the IDP isn't able to indicate to the RP that something different happened. The value of the strong authentication effectively disappears at the door. So, why would the RP bother?
2 comments:
Paul,
Agreed. We're starting to work with the OpenID General and Security teams to talk about adding into the OpenID Attribute Extension Draft information about the method of identification at the point of enrollment and the method used when authenticating. Now, OpenID consumers/RPs could choose to behave differently with a strong authentication OpenID IdP, or could choose to treat all the same way.
If all you are going to do with OpenID is log into livejournal, then it's not the best fit. But our vision is to take trusted enterprises who are already in the process of implementing voice security for the telephone applications, and now make that implementation also work across the web for all sorts of (OpenID enabled) applications. So, if you're going to implement voice authentication for telebanking, why not simultaneously give the bank customer the ability to use the same method for getting into web banking, or to use it for any other OpenID powered consumer?
-- Avery Glasser (CTO of VxV Solutions)
The RP doesn't have to bother but if it chose to it could keep track of those providers that provide strong auth and act appropriately when those IdP's are the ones doing the authentication.
What higher level value is a claim of strong auth from an IdP when there is no trust between the IdP and the RP anyway? Trust mechanisms are the stuff of OpenID extensions, and when OpenID gets to that point I am sure strong auth claims will be a desireable feature.
Post a Comment