Hi Martin, Yes - sorry - I accidentally hit "reply" instead of "reply all". I later did re-post to the list though. For the benefit of the list, your reply is at the end here.
Re-reading my reply, I think my wording sounded pretty strong, and I might not have made it clear that I'm not pushing for 100% of data to "live" at the OP: rather - I want to give the user a choice in the matter (that is - after all - the entire spirit of "user-centric"). I want users to have the *option* to decide whether to "sign up" to RP#A or RP#B, and be able to base their decision upon the data-handling and protection practices of the RP. Some RP's will want to store everything just like they do today. Some will want to embrace user centricity and give their customers full control, and most will probably tread a line somewhere inbetween. As long as we build something that supports all this, then we can leave it up to the normal market forces to steer the "Identity future" the way they want - with the key issue (for us) being that OpenID has the chance to persist in this future. Right now - OpenID is right at the bottom of the pile, being almost the worst "Identity 2.0" protocol currently on the market. IMHO - this is a problem that's easily fixed. I wrote: >> Yes - this could be a tough drain on RP and OP resources. Tough. You wrote: MA> You can't just wash your hands of this problem because it doesn't suit MA> your rather bizarre idea about how the world should be. Sites need to be I contest that I *am* allowed to "wash my hands" at this point, because it is absolutely my problem: I operate an OP, and I'm involved in helping RPs accomplish "Web 2.0" goals. I'm smack in the middle of all the consequences that flow from allowing users to control their own data howsoever they wish. I further contest that the idea of me being in control of my own information about me is not bizarre. It might not be how anything on the web works today - true - but I'm pretty confident this is something most people do, or will, want. Imagine you're at the newsagent buying a magazine. You hand over your credit card, and the shopkeeper says "No problem - I'm happy to sell you your goods, but I need you to first agree to let me make a photocopy of your credit card, grab you name and email address, and keep it in all on our files for the next 10 years. Oh - and we'll need to be sending you the occasional marketing message from time to time over those 10 years as well." Now *that* is something that almost everyone will agree is bizarre. Imagine, instead, the exact same thing occurs on a web site, instead of at a newsagent. Nobody even blinks when this gross misuse of *my* information actually does occur. I would go as far as to say that opinions contrary to mine about "how the world (internet) should be" are in fact the "bizarre" ones!! --- My suggestion for how an OP might choose to present the kinds of data-protection defaults users might want would be for the OP to have a set of "per-user global account preferences". Mum and Dad users can click the "convenient" radiobutton. Political activists can click the "strong protection" radiobutton. Folks inbetween can be given middle-road defaults, and/or anyone can be given per-use overrides. Whichever OPs (or OP software packages that you choose to download and run yourself) that do these things the best, should then quite quickly become the market leaders. As long as the protocol supports the protection, the market can innovatively offer it. The challenges I see at present, are these: 1. How should an RP advertise to an OP what it's server-to-server endpoint is. 2. How should an OP advertise to an RP the same thing. 3. How should an RP indicate to user-agents (eg: browser plugins like SSO enablers, secure chrome/anti-phishing/anti-virus addons, form-fillers, OP helpers [or even OP software itself, if running on an end-users home machine]) that it is an "OpenID 2.0" enabled service in the first place. I've pushed for this to be standardized and enforced, because it offers the absolute strongest future support for new technologies - and I do so again now. If my web browser, upon visiting www.example.com, can immediately detect that it's an OpenID 2.0 site (eg: through a <link> tag on every page, or the root or base URL, or HTTP headers, or whatever) - a massive pile of cool opportunities all spring up to make "Web 2.0" *seriously* more compelling, useful, and protective for everyone. Heck - Cardspace already did this - so we don't even have to argue the merits: They learned the long, hard, and painful way that excluding the user agent seriously undermines the trust and usefulness of Identity management. Kind Regards, Chris Drake Thursday, April 5, 2007, 5:14:58 PM, you wrote: MA> Not sure if you deliberately took this off-list, but I'll reply directly MA> and let you divert it back to list if you want. :) MA> 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. >> MA> You can't just wash your hands of this problem because it doesn't suit MA> your rather bizarre idea about how the world should be. Sites need to be MA> able to attribute contributions to users, and in order to do that they MA> need the user's name. A forum site cannot retrieve the name of every MA> user that took part in a topic from their respective OPs while rendering MA> the topic page. "Tough" is not an acceptable answer: rendering a topic MA> page is a legitimate function of a forum site and attributing each MA> 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. MA> Right. Some people had been talking about not allowing this out-of-band MA> information fetching. Even without the need for the user to be present, MA> 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" MA> On the contrary, I'm saying that if you don't want RPs to retain user MA> information then you should include some TECHNICAL MEASURE that prevents MA> them from doing so. MA> I think an acceptable compromise is to instead give users a way to MA> express their wishes about how the data can be retained in the form of a MA> "update this every n months/weeks/years/whatever" or a hard "expires on MA> this date"-type rule. This way you acknowledge that there are indeed MA> applications that need to retain user information for certain purposes MA> and allow the user to have some control over this process. You could MA> also put in a "don't retain this at all" flag, which in my forum case MA> would probably cause the forum to just identify you by your raw OpenID MA> 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. MA> I have nothing against the server-to-server channel. In fact, the MA> server-to-server channel is a prerequisite for the "update this every n MA> 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. MA> So a way is is needed for: MA> * A trustworthy RP to indicate how long it would like to retain MA> certain items of data MA> * A user to indicate how long he would like certain items of data MA> retained for, or how often the RP should try to refresh that data. MA> * A way for the user to prevent further updates of a particular MA> attribute by a particular RP after a certain date. MA> The first and second points above would, I think, be helped by defining MA> some reasonable defaults for each attribute type, just so that the MA> average user doesn't necessarily have to spend ages entering update MA> frequencies and expiry dates every time some attributes are requested MA> for the first time. _______________________________________________ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
