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

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

Reply via email to