[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. _______________________________________________ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs