Server-to-server channel

[Martin Atkins]

[I initially sent this to Chris directly, because he sent his message to 
me directly. Then I noticed he'd also replied on the list. Hopefully 
he'll see this before my private reply and we can avoid another 
go-around of duplicate messages!]

Chris Drake wrote:
 >
 > MA> For some things it's legitimate: they need to store your name because
 > MA> otherwise they'd need to talk to your OP (via you!) every time they
 > MA> render a page containing something attributed to you.
 >
 > OK - yes - I concede that some "data age" complexity does probably
 > creep back in if RPs choose to deny users the opportunity to audit the
 > use of user information.  (If I've got a choice between 2 RPs, and RP1
 > renders pages with my name in it, without giving me control over that,
 > while RP2 makes repeated calls to my OP every time it occurs: I'll
 > always choose to use RP2 - because it's the only one of the 2 options
 > that's "user centric", and gives me the ability to control the use of
 > my information.
 >
 > Yes - this could be a tough drain on RP and OP resources.  Tough.
 >

You can't just wash your hands of this problem because it doesn't suit 
your rather bizarre idea about how the world should be. Sites need to be 
able to attribute contributions to users, and in order to do that they 
need the user's name. A forum site cannot retrieve the name of every 
user that took part in a topic from their respective OPs while rendering 
  the topic page. "Tough" is not an acceptable answer: rendering a topic 
page is a legitimate function of a forum site and attributing each 
message is necessary.

 > MA> they need to store your name because
 > MA> otherwise they'd need to talk to your OP (via you!)
 > "via you!" is not a correct statement.  This is a "server-to-server"
 > topic: we're discussing a data flow that is "by your explicit prior
 > permission", but that takes place when you are not necessarily
 > present.

Right. Some people had been talking about not allowing this out-of-band 
information fetching. Even without the need for the user to be present, 
it's still prohibitively expensive.

 > MA> For other things it's more dubious than that, but the fact that it
 > MA> is technically possible means that at least some RP's will do it.
 > MA> I think it'd be a mistake to write the spec under the assumption
 > MA> that they won't unless we're going to include something that
 > MA> prevents it.
 > I do not follow your logic.  It looks like you're saying "there is an
 > opportunity for some RP's to act badly, therefore we should not even
 > try to code user-protection into the protocol"

On the contrary, I'm saying that if you don't want RPs to retain user 
information then you should include some TECHNICAL MEASURE that prevents 
them from doing so.

I think an acceptable compromise is to instead give users a way to 
express their wishes about how the data can be retained in the form of a 
"update this every n months/weeks/years/whatever" or a hard "expires on 
this date"-type rule. This way you acknowledge that there are indeed 
applications that need to retain user information for certain purposes 
and allow the user to have some control over this process. You could 
also put in a "don't retain this at all" flag, which in my forum case 
would probably cause the forum to just identify you by your raw OpenID 
identifier and have done with it.

 > By all means - include preventative code (and for some kinds of
 > attributes, digital time-stamped and signed assersions about the
 > attributes solve these problems).  But I think it's a far bigger
 > mistake to completely leave out a server-to-server channel altogether.

I have nothing against the server-to-server channel. In fact, the 
server-to-server channel is a prerequisite for the "update this every n 
months" thing because otherwise the RP would have no way to do that update.

 > When a rogue RP violates your trust and caches data without your
 > permission, that's bad.

So a way is is needed for:

  * A trustworthy RP to indicate how long it would like to retain 
certain items of data
  * A user to indicate how long he would like certain items of data 
retained for, or how often the RP should try to refresh that data.
  * A way for the user to prevent further updates of a particular 
attribute by a particular RP after a certain date.

The first and second points above would, I think, be helped by defining 
some reasonable defaults for each attribute type, just so that the 
average user doesn't necessarily have to spend ages entering update 
frequencies and expiry dates every time some attributes are requested 
for the first time.