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

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?


specs mailing list

Reply via email to