Hi Martin, You wrote MA> The "age" of the information needs to be taken into account here.
When the information (rightly) lives at the OP instead of the RP, none of that age complexity exists. It's *my* name. It's *my* credit card. If any RP wants this info, make them come to me (my OP) and get it. Let me say "no". Let me know each time they ask. But most importantly, let me (my OP) provide the correct, updated info each time the RP wants it. Kind Regards, Chris Drake Wednesday, April 4, 2007, 5:45:55 PM, you wrote: MA> Anders Feder wrote: >> >> 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 ... >> MA> information is old, then the RP would presumably be hesitant to act on MA> it without verification. MA> What constitutes "old" information depends on the attribute... things MA> like "Full Name" are, for many people, changed never or at most once in MA> their lives. However, things like a credit card number tend to change MA> every few years as cards expire. MA> Some information has a built-in expiry date (such as credit card MA> details), while other information just has a "likelyhood of change". MA> This implies to me that the following three things are needed: MA> * The possibility of a hard expiry date on a particular piece of MA> information. MA> * "soft" expiry dates which are more like "refresh this every n MA> months", where the RP gets less and less convinced about the accuracy of MA> the data as it ages, but may continue to use it for some time even when MA> it's "a bit old". MA> * The ability for an RP to request a refresh of attributes it stores MA> without necessarily including the user in the transaction. (The user MA> presumably will have made approval/revoking decisions out of band at an MA> earlier time.) MA> _______________________________________________ MA> specs mailing list MA> firstname.lastname@example.org MA> http://openid.net/mailman/listinfo/specs _______________________________________________ specs mailing list email@example.com http://openid.net/mailman/listinfo/specs