Server-to-server channel

[Douglas Otis]

On Apr 4, 2007, at 12:45 AM, Martin Atkins wrote:

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

This may seem to be off topic, but I really don't see reluctance in  
using public key cryptography.  DKIM would be one such example.   
Nearly every gateway, and access point can utilize this means of  
authentication.  Think of this as yet another means to control an  
account without relying upon OpenID.  OpenID opens the door, where  
you then hand them your public key.

One might also wish to specifically define attributes containing  
public keys used by the identity.  This would be information uploaded  
by the individual after creating their id_rsa.pub key information  
using either system tools or specialized applications.  This would  
provide an alternative access method that would not rely upon OpenID  
exchanges.  Here again, an expiry might prove handy, and so would a  
means to revoke the key.  Perhaps this would be done by overlaying  
it.  There could be keys used to authorize some other automated  
service, or to act as a replacement for OpenID once the key has been  
established.  One might be defined for email, IM, VoIP, etc.

-Doug