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> specs@openid.net
MA> http://openid.net/mailman/listinfo/specs



_______________________________________________
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Reply via email to