[EMAIL PROTECTED] wrote:
For starters please don't use Comic Sans in professional correspondence. it is very hard to read (or take seriously)  http://bancomicsans.com/home.html


On Oct 22, 2006, at 11:44 AM, Praveen Alavilli wrote:


It's more of a problem with how we can accept 3rd party OpenId users at AOL (we as an RP). Obviously for simple use cases like leaving comments on blogs it wouldn't really matter as long as the user is identified by someone (and someone doing rate limiting or something else to prevent spamming - otherwise I still can't see how it reduces spam anyway) - but when we want to take it to the next level - provide more services to these users (photos/calendar/etc.. ) we want to limit it to only a few IDPs whom we trust. (due to both security and business reasons).

This doesn't really work in the model.  The goal is to let anyone set up their own OpenID and that basically across the OpenID universe it works.  You limiting it to only like verisign or other 'big' IdP's is not really part of the vision of what we are trying to build.  Obviously behind this whole network needs to be reputation for IdPs and individual OpenID addresses. 
I understand it's not the vision of OpenId, but accepting identities from everyone else in the world is not going to happen in "reality". Obviously there is no reputation service built by trusted vendors (similar to CAs) yet. We need a short term solution atleast (though we all hate short term solutions) if we really want OpenId to be supported by big players  - isn't it ?

So this is the problem we are trying to figure out how we can message the users that we support OpenIds from certain providers (say Verisign PIP) but not from all.

This is one way to approach it and I hope you don't do it this way because it breaks what OpenID is about.
Well, it really depends on what else OpenIds are going to be used for. As I said, if it's just the blogging domain I don't think there are any issues. If we want to start pushing OpenId into a trusted and secure authentication domain (I really think it should), some changes need to happen.  Although "Reputation" is a good solution but unfortunately Reputation for IDPs or user URI's is not going to build over night. It changes the way how web apps and users got used to traditionally. Today as an example, I can goto AOL Personal Finance, create an account, setup my financial accounts, bill pay, etc.. with in few mins. If we are going to start providing the services to the user based on their Reputation scores, it changes the complete model - as a user do I need to wait for a long time before I can actually use all the cool features provided by AOL Personal Finance and do I constantly need to worry about someone mistakenly causing negative reputation on my account?  May be I am over complicating but that doesn't sound easy and can be built quickly.

Another area where we want some more clarification (if it already exists) or support is about how we can have a persistent handler (apart from URI) for a given user so it would help in cases when a user's account gets reclaimed by someone else.

ahh...that is where further reading of what i-names and i-numbers are about would help.  Because there is another level of indirection built in, when an i-name is reassigned the i-number below it is not.   This helps users not have the 'reclaiming by someone else problem' when depending on URLs.
Actually there were 2 things I was trying to point on in my previous mail (sorry I was not clear). One is the persistent id, which would probably be satisfied with i-numbers (even though I was looking more for optimization by including it as part of the authentication response itself) and second is the PPID (or LUID or SUID or whatever people refer to them in different protocols/specs), which is not just an i-number but it's an id that's different for each RP such that users cannot be tracked across different sites.

thx
Praveen




______________________________________

Identity Woman: Saving the world with user-centric identity. 
www.identitywoman.net


=

_______________________________________________ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs


_______________________________________________
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Reply via email to