tags:

views:

61

answers:

1

Hello,

I would like some feedback

I think the title speaks already for itself, but here is my perspective.

For instance, if I have (multiple) shopping site, that also gives out airmiles or something similar that is directly related to exchange of moneyvalue, - is openID still safe enough or should the site have there own login procedure like it is with banks.

EDIT

If OpenID can be used for the initial identifacation, how is it that the extra personal information the consumer has to provide for the site can be linked with the openID verification procedure. Is there like a permanent token that I get from openID, that I store with the rest off the personal registration information?

Is this approach usefull,safe enough to implement openID?

any thoughts,opinions, please?

thanks, Richard

+1  A: 

If you need personal information, you have to ask for them regardless of being a provider or not.

OpenID itself has nothing to do with any data besides the identifier, and user's password.
Personal data is managed by an extension, like AX, which can't and shouldn't be trusted to provide real data, or any data at all.

In other words:

  • if you're a provider, you have to ask for the data because you won't get anything from anywhere automatically
  • if you're a consumer, you may get some data from an OP, but you must verify them yourself (and possibly ask for missing data). For example, you usually can't trust the provided email to be valid

Is it secure?

Implemented properly, it's most likely secure enough. At least to the point that it's impossible to hack into an account without hacking the provider.

That said, I can't prove it's secure, and I have no knowledge about any work claiming to do so (or otherwise). So far, I've never heard of a vulnerability in the protocol itself.

Mewp
Thank you, that's almost a complete answer, but do you think like in my original (edited) question that it would be a usefull implementation, if it's not other then avoiding the creation off another login/password. I guess this would be extra then, because not everyone has an openID provider.
Richard
The most usual approach for consumers is to allow normal registration/login, and optionally OpenID auth. This lets users choose the method they want to use. You have asked how to store the data -- as you have noticed, OpenID handles only authentication. Once you verify that the identity belongs to the user, it's no different from standard auth. You store the data along with the user's login and password, and with openid login == identity, and password is null. Whether it is secure or not has nothing to do with openid, but with your implementation.
Mewp