?

Log in

No account? Create an account

Previous Entry | Next Entry

Strong Auth And OpenID

So Paul Madsen talks about the podcast where Aldo interviewed Avery Glasser of VXVSolutions about their recent integration of OpenID into their identity provider. Yesterday, Avery announced that they had integrated their voice print authentication technology into an OpenID identity provider. On the OpenID General list, I said, "This is really cool to see, the first public OpenID IdP that uses something other than usernames and passwords for authentication!".

A few weeks ago, a proposal came up to add a parameter to OpenID Authentication 2.0 called "authentication_age". The idea was that a relying party could request that the IdP re-authenticate the user if the user hadn't authenticated in the past X minutes. The IdP would then use this parameter in the response to inform the relying party how long ago authentication was performed. This proposal created a lot of discussion, not around its validity, but rather around the other pieces of meta-data (such as authentication type which Paul is asking for here) to be returned as well. In the end, we decided that instead of embedding this single parameter into the protocol at this time, it would be more beneficial to develop an extension to allow IdPs to provide much richer information to relying parties within an OpenID Authentication request.

What Paul mentions in his post is how currently there is no way within OpenID Authentication 1.1 or 2.0 for a relying party to find out from an Identity Provider that strong authentication, such as voice print analysis, has taken place. So to Paul's last question, quite honestly I don't think a relying party would use this technology today, but that actually isn't the point. Rather, this shows how important it is that an extension to OpenID be developed to support the exchange of meta-data about how authentication on the IdP was performed. It also continues to show the wide range of interest in OpenID for a multitude of uses, which reinforces why it is so important that OpenID itself remain light-weight, modular, and flexible so that people can build upon and extend the core specifications depending on their specific needs.

So to Paul, Avery, and others interested in this, I'd love to help you all develop an extension to really make things like strong authentication useful in OpenID!

Tags:

Comments

( 3 comments — Leave a comment )
scsi
Nov. 9th, 2006 10:07 pm (UTC)
If I ever see the line:
"OpenID Guru David Recordon talks about on his blog..."
I'm going to throw up.. :)
mart
Nov. 9th, 2006 10:39 pm (UTC)

I continue to chuckle each time I see these suggestions for ways for IdPs to boast about how good their authentication is.

Any attempt to discriminate by RPs will just cause IdPs to start lying. There is no way to prove that a given means of authentication has been used, and if there's no way to validate the data there's no point in sending it. There is no implied trust relationship between RP and IdP to make it acceptable to take these claims on face value.

While I don't disagree that it would be useful, I really don't see it as practical.

ext_17971
Nov. 11th, 2006 08:14 am (UTC)
Extensions Ahoy
David,

Yep - we definitely should talking about a couple of extensions as part of the Attributes Exchange (at a minimum). I've been kicking around internally the idea of three new attributes:

identification_method: the method used when the user originally enrolled for an ID. This could be "anonymous" or "unverified" or stronger, such as "credit card" meaning that the user provided a valid credit card or "Passport" meaning that the person provided a national ID of some sort for confirming the identity. There might even be a place to state if the ID was verified in person (like with CACert WoT), or remotely (credit card verification, faxed documents, etc"

authentication_mode: how the user authenticates, from a broad scale. Either weak or strong. Strong meaning smartcard, tokenID, biometric etc. and weak generally meaning passwords and pins.

authentication_method: how the user actually authenticated for that session: voice biometric, fingerprint, Verisign VIP token (had to throw that in), SecurID, PIN, password, etc...

Now, again, these should be attributes that could be requested by the Consumer/RP at the point of authentication. Things like identification_method would only have to be requested at registration, while the authentification_method and _mode would (could) be requested by the Consumer/RP at each login.

The interesting point when to Mart's assumption that IdPs would be prone to "lie" when it comes to the methods and modes for enrolling and verification - that completely seems unrealistic to me. For any IdP to remain successful, they will have to have a level of trust in the community. If it comes to light that an IdP is falsifying any information, the word will get out and immediately get that IdP blacklisted. Remember - there's nothing that says that an RP/Consumer can't look at the URL and choose to block access to those Identity URLs. That's the beauty of the decentralized model. You'll end up with built-on-the-fly federations of IdPs who trust eachother, RPs that choose to accept all Identity URLs or only some based on the IdP, authentication_mode, etc.

What it comes down to is the fact that there are three main functions when it comes to identity management: identification, authentication and authorization - and the amount that any RP/Consumer puts their faith into an IdP is based on their reputation within the community as well as specific contractual relationships.

For example, if Joe's IdP - a brand new entity - said that they're providing physically verified identification (inspecting a passport) and using biometric authentication - went to a bank and said that their IDs should used to allow bank customers to log into their accounts, they'd probably be shooed away. Why? Because the IdP doesn't have any trust built in the community.

Now, and not because it's David's blog I'm writing on, let's say that Verisign made the same claim - they're trusted in the security community, they're willing to make contractual commitments to their methods and modes for identifying a user at enrollment and authenticating the user for general usage - they would most likely be trusted by the banks.

Which leads to authorization - something that is completely out of scope to the IdP. A RP/Consumer has the ability - and to a certain level, the responsibility, to make judgements about what an authenticated user can and cannot do. These decisions will be made based on the relationship with the IdPs, and the information that the IdP provides. A bank might only authorize users coming in from certain "trusted" IdPs - and by trusted, the ones that that SPECIFIC bank chooses to trust, not some sort of overseeing body dictating which are trusted and which are not.

This is the sort of demand-driven trust federation building that will help push OpenID into becoming a standard not only for blogs and wikis, but also for real commerce applications - but to help make this happen, you need to provide information about how you initially validated the user's claimed identity (not the job of the OpenID standard, but the job of the IdP) and how you authenticated the user (also the job of the IdP). The OpenID standards should support transmitting that data - but leave it to the IdP and RP/Consumer to determine how to use it.
( 3 comments — Leave a comment )