Thursday, April 5, 2007, 3:50:49 AM, Martin wrote: MA> Chris Drake wrote: >> 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. >>
MA> I think you're kidding yourself if you believe that RP's won't cache the MA> information they obtain. True - we may not always be able to force some RPs to not violate our trust. This is not, in my opinion, a justification for preventing any IP from acting in a trustworthy way, and definitely not a justification to deny users the opportunity (by omitting the mechanism from the protocol) to select RPs who claim not to cache information. 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. 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. 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" 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. When a rogue RP violates your trust and caches data without your permission, that's bad. When you choose not to specify a server-to-server channel, you're forcing *every* RP to behave in exactly the way that your theoretical rouge RP might have done. What's a bigger mistake? Having a few bad apples, or having no apples at all? Chris. _______________________________________________ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
