-Shade
_______________________________________________
general mailing list
gen...@openid.net
http://openid.net/mailman/listinfo/general
Allen
Think about the message its sending.
Who would want to put their family photos on a site they may not be able to access tomorrow (when some OP goes belly-up)?
Surely an RP needs to assure its users that there exists the means to replace the OP? The dotcom bust taught us that lots of service companies do infact go belly-up, in the usual boom/bust cycle.
Would be strange if the UCI mission of openid facilitates data and identity portability, but then the failure engineering of the overall service still means you can STILL easily lose access.
Presumably, the RP might retain the users email address(es) from the sreg handoff, so it can send access-recovery URLs granting the users access WITHOUT using any of registered OP(s) for the account.
From:
general...@openid.net [mailto:general...@openid.net] On Behalf Of Andrew
Arnott
Sent: Wednesday, April 01, 2009 5:39 PM
To: Allen Tom
Cc: general
Subject: Re: [OpenID] Live Icons for visual recognition of IDP logos
[Peter Williams]
There used to be this piece of software for the Atari (probably for
other platforms, too), that would suddenly spring into action, make a
mosquito fly around your screen, turn your mouse pointer into a
mosquito swat, and prevent you from doing anything on your computer
until you managed to catch the fly. Very hilarious.
I was always waiting for the version that one could run on somebody
else's X11 display. Your proposal sounds like I'm getting what I
wanted, for all platforms ;-)
I was thinking more along the lines of "We accept these:" and the
icons would be indicators rather than clickable. But if the different
icons *are* clickable that way, it shouldn't be too much more complex
to have the "banner" scroll as a default but let you navigate in
either direction by mousing over the appropriate hotspots.
There seem 3 main technical choices, for _mainstream_ failure engineering addressing OPs (or suspension/cessation of assertion-minting privileges by the OP, under its terms of service).
RPs normally bind multiple openids to the account
RPs host a new vanity XRDS, delegating to both the introducing OP and to at least itself (as a fallback OP)
RPs offer account recovery/restoration, based on some or other authentication scheme
My wife just had an unpleasant ebay experience, leading ebay to suspend her account after 3 years happy-ebaying (after some merchant made a (dubious in my independent view) allegation, but who played the trust game under ebay’s reputation rules MUCH better than she did). Loss of the ebay auction privileges was no great shakes (Peter is less poor this month, than last). But …Ah, sorry.! Now No more access to “your” photos on photoshare.com for you , dear _former_ ebay-susbcriber.
Honestly, Peter, the belly-up OP is what scares me the most about OpenID. And I really like OpenID. As large and well-written as myopenid.com <http://myopenid.com> seems to be, I'd never recommend my less-tech-savvy family use it over yahoo.com <http://yahoo.com> or google.com <http://google.com> as an OP because I'm not convinced myopenid.com <http://myopenid.com> will be around for 25 years. That's why I use my "vanity" url. It's not for vanity at all... it's for my own identity protection. But the vanity url has to be at my own domain name so that no belly-up company can take down my identity. That obviously isn't a solution that will work for my friends and family.
I prefer this, too. I do think that the "SINGLE sign on" part of
OpenID may eventually become non-viable, as OpenID becomes used for
banks and other RP's that everyone needs to interact with but who
can't, for security, allow users to use the same credentials with all
their different OP's. (This would not be a problem for any one of
those OP's going belly-up, but *would* be a problem when worrying
about one of them turning hostile, one of them being compromised, or
the user's smart-card being stolen.)
No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.5.285 / Virus Database: 270.11.35/2034 - Release Date: 04/01/09 06:06:00
There seem 3 main technical choices, for _mainstream_ failure engineering addressing OPs (or suspension/cessation of assertion-minting privileges by the OP, under its terms of service).
RPs normally bind multiple openids to the account
RPs host a new vanity XRDS, delegating to both the introducing OP and to at least itself (as a fallback OP)
RPs offer account recovery/restoration, based on some or other authentication scheme
I absolutely agree. But is there any recommended way to do that,
in terms of a consistent user interaction? In fact I haven't seen very
many RPs in the wild attempt the multiple id support yet, though it
seems to be something that we should strongly try to encourage.
The way that my own RP does that is that when you're already logged
in (say using identity A) and you try to login again (with id B) without
having logged out first, it will
1. Put up a page that says you were already logged in before, and
2. Ask if you would you like to add the identity you just logged in
to the same user account; or instead login as a new user (thus
logging the first one out).
In between 1 and 2 the user is sort of in a limbo session state.
I know their OpenID identity, but I haven't mapped them to a
local user account yet.
Obviously to do this I must maintain a mapping of OpenID identities
to local user accounts; and this is a many to one mapping. This means
that the OpenID identity is NOT my user account identity; but instead that
the OpenID identity REFERENCES my user account identity. A
subtle but important distinction.
Furthermore once a user is logged in, they can go to their user
"preferences" screen; where a list of all their OpenID identities is
shown. From there they can delete any of them.
Obviously, if you don't have an account recovery system in place
(such as via verified email), then you need to prevent the user from
deleting ALL of their identities lest they be locked out. Also, since the
only way to add an identity is to actually use it first (login with it), I don't
have to worry about them only having identities left which have never
been "tested", and thus chance them locking themselves out.
--
Deron Meranda
Unless that's the goal, aka account deletion - though if the Privacy
Policy doesn't explicitly *permit* users to remove all their personal
information (anticipating that all their accounts will soon be
compromised, perhaps), it's not unknown to retain the user's data
indefinitely (and leave it exposed to any future exploits).
-Shade
JanRain's RPX account mapping API helps link multiple OpenID accounts so you don’t have to change your database schema to support multiple OpenID accounts.
Cheers,
Brian
==============
Brian Kissel
Cell: 503.866.4424
Fax: 503.296.5502
-----Original Message-----
From: general...@openid.net [mailto:general...@openid.net] On Behalf
Of Deron Meranda
Sent: Thursday, April 02, 2009 1:40 PM
To: Allen Tom
Cc: general
Subject: Re: [OpenID] Live Icons for visual recognition of IDP logos
On Thu, Apr 2, 2009 at 2:36 PM, Allen Tom <at...@yahoo-inc.com> wrote:
__________ Information from ESET NOD32 Antivirus, version of virus signature database 3984 (20090402) __________
The message was checked by ESET NOD32 Antivirus.
Obviously to do this I must maintain a mapping of OpenID identities
to local user accounts; and this is a many to one mapping. This means
that the OpenID identity is NOT my user account identity; but instead that
the OpenID identity REFERENCES my user account identity. A
subtle but important distinction.
[Peter Williams] Other websso schemes call the latter session translation. Its main and not-particularly subtle benefit is it allows loose coupling of the identity management systems of 2 or more peers: 1 at OP, another at RP#1, another at an affiliate of RP#1. This contrasts with the tightly coupled vision, which I know some folks consider “true” openid. In that view of the world, any RP that retains a local login or an RP-centric affiliate network is not a “true & faithful” openid participant.
I agree that there is a distinction, but the latter is true on most
systems that support only one identifier too, and is in fact consistent
with how OpenID was originally described: OpenID allows you to prove
that you own a URL. One application of that is to prove that you own a
user account that references that URL, which is a special case of
asserting that you're the same person I saw last time. (for some
wishy-washy definition of "person".)
This is the main reason why I make a point of saying "identifier"
instead of "identity" in this context. My identity is a more abstract
concept that is difficult to define.
I still think the traditional semantics are much clearer, than distinguishing acts of denoting from acts of reference OR using special nouns.
You get a session on the OP, by authenticating. You want to get a session on RP, by not authenticating. To get from one to the other, you use a session translation service.
That's the service.
The rest is protocol.
> -----Original Message-----
> From: general...@openid.net [mailto:general...@openid.net] On
> Behalf Of Martin Atkins
> Sent: Thursday, April 02, 2009 10:01 PM
> To: general
> Subject: Re: [OpenID] Live Icons for visual recognition of IDP logos
>
I'm possibly misusing the term here but if OpenID is "user-centric"
then its recovery mechanism should be too. RP trusts OP to
authenticate the user. RP could also trust the OP to provide
information that can be used to authenticate the user independently
from the OP. This would be useful for a several reasons (one-to-one
privacy, OP unavailable, domain expiration, bear attacks a data
center, totalitarian government takes over).
Just to illustrate the concept further, here's an **example** of how
this could work. (Walk away with the concepts here, not the details,
please.)
When you sign up for the OP, you are asked to supply an emergency
passphrase. A signature is generated by the function
"hash( your_openid + emergency_pass )". This signature is given to
each RP you sign into. When your OP is not available, the RP can still
authenticate you by using the traditional "Identifier + Credential"
method in widespread usage today by asking you for your emergency
passphrase. The RP will never know your emergency passphrase until it
needs to know. Obviously, this must not be the same credentials used
to authenticate with your OP.
Again, the above is just an example. The concept can be expanded upon
to provide a decentralized account recovery protocol.
=Rabbit
We have a globally implemented technology which we want to replace
with a new technology although it might not be immediately understood
in the way that it needs to be.
I would equate this to when we had globally implemented HTML which we
wanted to replace with XHTML although it wasn't immediately understood
by browsers in the way it needed to be.
Imagine instead of having one OpenID-UX standard, web developers were
given two standards to choose from based on the needs of their target
market; OpenID-UX-Transitional and OpenID-UX-Advanced. One would be
highly informative and assume the user knows nothing about OpenID and
may in fact have their head stuck in their computer chair for the
third time while the other assumes the user is familiar with OpenID
and has used it to login before.
Imho, the community is currently missing a huge opportunity to
bootstrap the OpenID brand into recognition by being properly paired
with popular OpenID-enabled brands. I'm a little stunned there has
been research discovering users are more likely to click on a huge
"Google Sign In" button instead of an almost transparent OpenID logo.
I always felt like that should be obvious. People know what Google is.
The problem I have with this, and where I feel there is a missed
opportunity, is that the Google brand does not mean login. The Google
brand means search or maps or even porcelain kittens before it means
login the way OpenID means login. I really feel that OpenID should be
directly paired with the Google logo each and every time a user signs
in with OpenID + Google and same with every other service.
The reason is recognition. If OpenID becomes the recognizable symbol
for "login" as Flickr means "photos" and Google means "search", you
eventually won't need to leverage popular brands as desperately as you
do now.
So, imho, there needs to be a OpenID-UX-Transitional standard that
closely pairs the OpenID logo to recognized brands. OpenID should not
stand on it's own as it's own option because that communicates to most
users that it is just as different as MySpace is to Google is to
Yahoo! is to X is to Z.
=Rabbit