Anders, On 4/3/07, Anders Feder <[EMAIL PROTECTED]> wrote: > Rowan Kerr skrev: > > The RP can send an "update_url" to the OP when it fetches the > > attributes, so it will get new values when the user changes them at > > the OP. > > But the RP can't know if the "update_url" is honored, i.e. if it will > ever receive any updates from the OP. > > Imagine an RP requesting your bank account number X from your OP. Time > goes by, and your OP goes out of business. Later, you switch banks and > your account number X is assigned to someone else. In the meantime, the > RP has been preparing a payment for a job you have done for them. The RP > look up your account number in its database, and see X. And since the RP > has not received any updates to your bank account information, it > reasons that your account number is still X and consequently disburse > your payment on a stranger's account ...
When I update my information at a new OP how about some way to tell the RP it is the most authoritative. Not sure if this should be taken care of at the application or protocol level, I'd like to see it in the protocol though. The big concern I see with this is that anyone could setup an OP and claim to be the most authoritative source of information. > One could say that OpenID should not be relied on to exchange sensitive > information like bank account numbers, but 1) I think its a shame to > limit a technology with such great potential, and 2) chances are that > OpenID will be relied upon anyway - the sensitive transactions will just > be performed longer down the chain, where they can't be checked. It will happen. I already have plans to share data far more sensitive than bank accounts and have brought the idea up to a few organizations that are at least interested in the concept. So far I have looked at layers of encryption, authorization and authentication on top of OpenID to solve this though. > >> * If an OP fails to update an attribute, the RP will never know - no > >> fall-backs can be implemented. > >> > > > > Fails when? On a Store request? > > Yes, or if the Store request never leaves the OP server, for whatever > reason. The OP could tell the user if there was a failure. This way the user can notify the RP or at least be aware of the problem. Not perfect, but it could be treated just like a bounced email or DNS update failure. Wayne -- Phone: 414.208.0808 Learn something from everybody. Some people will teach you what to do, while others will teach you what not to do. _______________________________________________ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
