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 email@example.com http://openid.net/mailman/listinfo/specs