Server-to-server channel

Martin Atkins mart at degeneration.co.uk
Wed Apr 4 07:45:55 UTC 2007


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 ...
> 

The "age" of the information needs to be taken into account here. If 
information is old, then the RP would presumably be hesitant to act on 
it without verification.

What constitutes "old" information depends on the attribute... things 
like "Full Name" are, for many people, changed never or at most once in 
their lives. However, things like a credit card number tend to change 
every few years as cards expire.

Some information has a built-in expiry date (such as credit card 
details), while other information just has a "likelyhood of change". 
This implies to me that the following three things are needed:

  * The possibility of a hard expiry date on a particular piece of 
information.
  * "soft" expiry dates which are more like "refresh this every n 
months", where the RP gets less and less convinced about the accuracy of 
the data as it ages, but may continue to use it for some time even when 
it's "a bit old".
  * The ability for an RP to request a refresh of attributes it stores 
without necessarily including the user in the transaction. (The user 
presumably will have made approval/revoking decisions out of band at an 
earlier time.)






More information about the specs mailing list