Hi All,

Since it's a lot easier to just put a server-to-server mechanism in
place, than it is to argue about what it should be used for - can we
perhaps instead attempt to agree that server-to-server is going to be
something potentially useful in at least some cases, and go ahead and
specify it?

I believe there is a good use case for my OP (that I have chosen to
trust as the gatekeeper to all my personal information) being allowed
to store my data, arbitrate (server-to-server) access to it, and
propagate (server-to-server) updates.  This isn't complicated - HTTPS
transport over existing endpoints is sufficient.

Wednesday, April 4, 2007, 9:06:49 AM, Anders Feder wrote:
>... Currently, if my OP turns rogue or otherwise fail to serve me...

The idea that OP's might turn hostile, and that RP's are more
trustworthy seems completely backwards to me.  When I choose an OP (or
I download and run my own), I'll take trust, reputation, and safety
into account.  When I choose all my RP's, I'll essentially ignore
trust, reputation, and safety because I've already chosen my OP to
handle all this for me.  It's also safer to trust one OP, than it is
to trust (for example) all 100 RPs I've used.  And that's not even
*starting* on the fact that I can change my OP away from any rogue one
any time I want anyhow...

I can understand that folks involved with RPs and associated
development will be horrified at the idea of giving their users
control of their information.  If I was an RP, I would not like to let
my customers revoke my access to their details: I'm going to want my
hypothetical RP to spam them indefinitely, continue to charge their
credit card long after they've gone, sell their details to marketing
companies, count them as "active users" when I try to sell my RP to
google, provide their address to snail-mail campaigners or police,
send unsolicited text messages to their mobile phones, plunder their
data to retaliate against them when I find them saying nasty things
about my RP in public, and so forth. 

Every now and then, some RPs might even violate user trust and
secretly store user "OP-Only" information without permission: the RP
will be easily named and shamed when they're "found out" - which they
will easily be, as soon as a user revokes access and then (for
example) discovers the RP still sent them spam.

Here's some things I want to do, but that OpenID does not currently
support - but could with server-to-server support:

1. 1-click, or zero-click Single-Sign-On (no typing)

2. Single-Sign-Off

3. "User-Centricity" (This is in "quotes" because I define this as
   "Giving ME full control of MY information")
   A) propagating changes to my info out to RPs
   B) revoking access to my info at RPs
   C) auditing the usage of my info by RPs
   D) access authorization ( SAML+X-GTRBAC / XACML )
      eg: facilitating grants by 3rd parties allowing users to access
          RP facilities (eg: data that RP cannot physically store)
   E) identity protection
4. Other: I'm not the only one who's looking to implement facilities
   that require more than just a browser-transported, user-present
   OpenID interaction.

All server-to-server comms will be properly secured and authenticated
(ie: no old/rogue/non-authorative OP will be able to influence any RP)

Kind Regards,
Chris Drake

specs mailing list

Reply via email to