Re: Two Identifiers - no caching advantage
Dick Hardt wrote: On 21-Oct-06, at 10:52 PM, Josh Hoyt wrote: On 10/21/06, Dick Hardt [EMAIL PROTECTED] wrote: 2) the RP does not verify the binding between the portable identifier and the IdP-specific identifier in the response. to the one the attacker controls and the IdP has mapped This is the part where I think you're wrong. The RP MUST verify that binding, whether it is by keeping state, self-signing the request (which gets passed through to the response) or doing discovery again. I agree the RP SHOULD do that. The proposal does not specify that. I thought we had that conversation. I have not looked at the patch that you sent. Perhaps you address the issue there. My point though is: why have the RP bind the IdP-specific identifier and the public identifier? Why not let the IdP be responsible for this? In 1.x when the IdP was not aware of the public identifier, then the RP had to do the binding. Now that the IdP is aware of the public identifier, it would be simpler and logical for the IdP to be responsible for the binding. It is doing it anyway. All the RP wants is which public identifier is the user, and is the IdP authoritative for it. If delegation is going to require cooperation from the IdP anyway, there's no longer any value in having the distinction between a public identifier and an IdP-local identifier. The hypothetical IdP IdP-tastic can just store a relationship between http://mart.vanitydomain.com/ and my user account at IdP-tastic. There's no need for http://mart.idp-tastic.com/ anymore, and with that gone delegation is no longer useful: the public identifier, whatever it might be, is the only identifier. Any disadvantages to uniting the public identifier and the IdP identifier are also disadvantages of having the IdP do the binding as you describe. For simplicity's sake, I'm currently only willing to vote positively for one of the following scenarios: * Have only one identifer in the protocol. Remove delegation entirely. IdP maintains relationships between arbitrary identifiers and its local user accounts. IdP no longer needs to issue its own identifiers, though it can if desired. This makes life simpler for RPs, but has the risk that delegation would become an IdP premium feature, which may hurt users in the long term. * Protocol has two distinct identifiers: public and IdP-local. Relying party manages delegation. IdP does not even know that the delegation has taken place and has no way to stop it happening [1]. RP now has to do more work, but identifier portability now comes for free. Having the IdP deal with the public identifier while still keeping the IdP-local identifier (and thus delegation) is, it seems to to me, muddled nonsense; the whole purpose of delegation was to make these identifiers distinct. [1] Conceivably a mischievous IdP could make use of knowledge of how particular RPs round-trip their delegation state to block it, but that would be an arms race in the RP's favour rather than a designed-in mechanism for detecting delegation. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: PROPOSAL: RP identifier
On 19-Oct-06, at 10:24 AM, Martin Atkins wrote: Dick Hardt wrote: Agreed that it is desirable to have multiple RP endpoints for an RP. Does openid.realm then uniquely identify an RP? ie. no other RP will use the same Realm? I'd say that if two endpoints are within the same realm that they are by definition part of the same RP. This does raise the question of what to do when one realm exists inside another, but I suppose the most obvious answer is to select the most specific of the available options — that is, the one with the least wildcardy-ness[1]. Someone probably should define precisely how the specificity of realms works if it isn't in the spec already. This goes back to the original question I had: how does the IdP uniquely identify the RP. I guess if the realm string is different, then it is a different RP, even if one is contained in another. The issue here is that realm is an overloaded parameter. It is being presented to the user for the user to decide if it wants to IdP to provide similar results to any RP return_to that matches the wildcard. It is also being used by the IdP to uniquely identify the RP. [1] Now *that* is a good word! I like it! ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: [PROPOSAL] Handle http://[EMAIL PROTECTED] Style Identifiers
On 22-Oct-06, 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). 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. Obviously we can just follow the existing model of a free form field that says Enter your OpenId but most of the time we will end up failing the users saying we don't accept your OpenId. Just bad user experience in our opinion. So instead we want to somehow message the user saying these are the only IDPs we trust - whether showing a drop down list of IDPs on the login form or something else, we want to see a standard way of doing it so user's don't feel like they are in an alien world from one RP to another (ofcourse keeping aside the phishing issues). We totally agree that adding another option to the already confusing list of account types is a bad idea. OpenID Authentication allows you to know it is the same user that you saw last time. In many ways, it is an automated mechanism for public sites that allow anyone to create an account by selecting a username and a password. Limiting users to come from only a small set of IdPs is like limiting which ISPs can connect to your website -- it is not the user-centric model. For example, if you have not seen an identifier before, you may require them to enter a captcha. When you see them again, and if they did not do something *bad*, then you may not need to prompt them for the *captcha* again. What is different with OpenID vs email is that there is certainty that the user actually is the user. With email, there is no certainty that the from: field really is who sent the message, which is what a number of protocols in the SMTP world are working to resolve.. Just like in the battle with spam, once you have the identity of the user, then you can have 3rd party assertions from someone you trust (if needed) to have more data about the user. For example, there may be a service provider that asserts that a given identifier belongs to a user that has a *good* reputation. -- Dick ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: [PROPOSAL] Handle http://[EMAIL PROTECTED] Style Identifiers
While I'd certainly agree that a goal is letting anyone setup and IdP and have it work on any RP, I see that as utopia. The protocol should certainly support that, as well as not do anything to actively thwart it. With that said, OpenID as a protocol can be used in cases where this may not be desired. I agree that the best way to look at this is by creating a distributed trust/reputation network. This thus allows a RP to intelligently make a decision of if it should accept a given identifier, or the IdP it is hosted on. Right now I see this as needed to really bootstrap large scale adoption. Any word from Karmasphere about something like this Meng? --David P.S. Plain-text kills all fonts. :) From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kaliya Hamlin Sent: Sunday, October 22, 2006 3:43 PM To: specs@openid.net Subject: Re: [PROPOSAL] Handle http://[EMAIL PROTECTED] Style Identifiers 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. 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. 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. __ Identity Woman: Saving the world with user-centric identity. www.identitywoman.net ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Two Identifiers - no caching advantage
* Protocol has two distinct identifiers: public and IdP-local. Relying party manages delegation. IdP does not even know that the delegation has taken place and has no way to stop it happening [1]. RP now has to do more work, but identifier portability now comes for free. I'm much more in favor of that, though see the value in having the IdP know the public identifier so that it can correctly prompt the user. I think one identifier, with the IdP managing the entire relationship is too much of an architectural jump from 1.1. Take LiveJournal for example, somehow I doubt we'd see delegation support in this case anytime soon. I think what is important is keeping the simplicity of delegation in 1.1, while cleaning up the metaphor and making it more user-friendly at the same time. Perfection is the enemy of the good. --David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Martin Atkins Sent: Sunday, October 22, 2006 1:34 PM To: specs@openid.net Subject: Re: Two Identifiers - no caching advantage Dick Hardt wrote: On 21-Oct-06, at 10:52 PM, Josh Hoyt wrote: On 10/21/06, Dick Hardt [EMAIL PROTECTED] wrote: 2) the RP does not verify the binding between the portable identifier and the IdP-specific identifier in the response. to the one the attacker controls and the IdP has mapped This is the part where I think you're wrong. The RP MUST verify that binding, whether it is by keeping state, self-signing the request (which gets passed through to the response) or doing discovery again. I agree the RP SHOULD do that. The proposal does not specify that. I thought we had that conversation. I have not looked at the patch that you sent. Perhaps you address the issue there. My point though is: why have the RP bind the IdP-specific identifier and the public identifier? Why not let the IdP be responsible for this? In 1.x when the IdP was not aware of the public identifier, then the RP had to do the binding. Now that the IdP is aware of the public identifier, it would be simpler and logical for the IdP to be responsible for the binding. It is doing it anyway. All the RP wants is which public identifier is the user, and is the IdP authoritative for it. If delegation is going to require cooperation from the IdP anyway, there's no longer any value in having the distinction between a public identifier and an IdP-local identifier. The hypothetical IdP IdP-tastic can just store a relationship between http://mart.vanitydomain.com/ and my user account at IdP-tastic. There's no need for http://mart.idp-tastic.com/ anymore, and with that gone delegation is no longer useful: the public identifier, whatever it might be, is the only identifier. Any disadvantages to uniting the public identifier and the IdP identifier are also disadvantages of having the IdP do the binding as you describe. For simplicity's sake, I'm currently only willing to vote positively for one of the following scenarios: * Have only one identifer in the protocol. Remove delegation entirely. IdP maintains relationships between arbitrary identifiers and its local user accounts. IdP no longer needs to issue its own identifiers, though it can if desired. This makes life simpler for RPs, but has the risk that delegation would become an IdP premium feature, which may hurt users in the long term. * Protocol has two distinct identifiers: public and IdP-local. Relying party manages delegation. IdP does not even know that the delegation has taken place and has no way to stop it happening [1]. RP now has to do more work, but identifier portability now comes for free. Having the IdP deal with the public identifier while still keeping the IdP-local identifier (and thus delegation) is, it seems to to me, muddled nonsense; the whole purpose of delegation was to make these identifiers distinct. [1] Conceivably a mischievous IdP could make use of knowledge of how particular RPs round-trip their delegation state to block it, but that would be an arms race in the RP's favour rather than a designed-in mechanism for detecting delegation. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: [PROPOSAL] Handle http://[EMAIL PROTECTED] Style Identifiers
For starters please don't use Comic Sans in professional correspondence. it is very hard to read (or take seriously) http://bancomicsans.com/home.htmlOn 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. 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. 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. __Identity Woman: Saving the world with user-centric identity. www.identitywoman.net ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: [PROPOSAL] Handle http://[EMAIL PROTECTED] Style Identifiers
Dick Hardt wrote: What is different with OpenID vs email is that there is certainty that the user actually is the user. I'm a little confused. How is there certainty that the user actually is the user? The viability of the identifier representing the same user is dependent on the OpenID provider not recycling identifiers. Or did you just mean that in email, authentication is not always required for someone to use an email identifier? Note that the OpenID protocol does not prevent idp.spammers.com from allowing any identifier to be used and authenticated regardless of whether it's the same user or not. It is incumbent on the relying parties to determine if they will allow identifiers authenticated by a particular idp. Thanks, George ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: PROPOSAL: RP identifier
On 22-Oct-06, at 12:55 PM, Recordon, David wrote: In the case where there are two realms: http://*.livejournal.com http://dick.livejournal.com I would have my IdP treat them as separate relying parties. If the RP directly decided to set the realm differently, then I'd imagine the application has a reason for doing so. This is of course different than having a realm of http://*.livejournal.com and then a return_to of http://www.livejournal.com the first time and then http://dick.livejournal.com the second time, where my IdP would treat them as the same RP. So yes, RPs should be uniquely identified by the realm parameter. I would agree with this. The spec does not specify that. Another thing to add to the edit list? -- Dick ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: [PROPOSAL] Handle http://[EMAIL PROTECTED] Style Identifiers
[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 OpenIDuniverse 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
Re: [PROPOSAL] Handle http://[EMAIL PROTECTED] Style Identifiers
Dick Hardt wrote: On 20-Oct-06, at 10:14 AM, George Fletcher wrote: Of course, my expectation is that this syntax would be optional; the user can always specify their full URI identifier. I agree that this kind of an identifier is not portable, but I'm guessing that most users wouldn't know how to tweak their blog to add the necessary OpenID 1.1 HTML code to change their IDP. Most users, just use flickr for photos and if flickr supported OpenID, could potentially use some URI defined for them by flickr as an OpenID identifier. This identifier from flickr would not be very easily portable. My understanding of the proposal from David was that this was a way to discover the user's IdP, not that the email was an identifier. -- Dick Sorry to imply that email should be a valid identifier. That wasn't my intent. I'm fine with where this discussion is headed (and has headed in the past; after reading the old threads). For wide spread adoption it will be very important to have a If you're not sure what to enter, click here link on the login form to try and explain to users what they might be able to try as identifiers. My comment was really trying to speak to the issue of identifier portability. Is there an OpenID definition for this? If I have an OpenID provided by SomeSite as http://george.somesite.com, then how is that identifier portable? For it to be portable, somesite.com would have to allow me to either (a) change the HTML code of my public page (though if I read the draft 2.0 spec correctly, the HTML method is deprecated) or (b) provide some mechanism where I could change the IDP service URL returned in the XRDS document. If somesite.com does not provide either of these mechanisms, then this identifier is not portable. Also, the viability of my identifier may be dependent on the service. For instance, somesite.com may have a rule that says if I delete my SomeSite account, then they will no longer authenticate my identifier. Of course, user choice always enters in and I can choose to not use that service as my OpenID identifier provider. The i-names infrastructure does solve some of this by focusing on the identity management issues. Though here I'm paying explicitly for this portability service (along with others). Thanks, George P.S. Should this discussion get moved to the general list? ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: [PROPOSAL] Handle http://[EMAIL PROTECTED] Style Identifiers
[Please pardon me if I am spamming the spec mailing list with general comments/issues that might have been discussed before] It's not the problem of just making AOL users OpenId enabled, so they can access 3rd party RPs (use http://www.aol.com/loginId or http://aimpages.com/loginId or http://journals.aol.com/loginId, etc) - as someone else said it's a matter of educating the users (even if it takes long time based on user's geek level - because pretty much every IDP out there today tries to educate users about how to make sure they are not entering their credentials at a phishing site, but it still happens). 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). 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. Obviously we can just follow the existing model of a free form field that says "Enter your OpenId" but most of the time we will end up failing the users saying "we don't accept your OpenId". Just bad user experience in our opinion. So instead we want to somehow message the user saying these are the only IDPs we trust - whether showing a drop down list of IDPs on the login form or something else, we want to see a standard way of doing it so user's don't feel like they are in an alien world from one RP to another (ofcourse keeping aside the phishing issues). We totally agree that adding another option to the already confusing list of account types is a bad idea. 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. Instead of it being an additional attribute that IDP can advertise as supported (which an RP can get via the Attribute Exchange protocol), if it can be baked into the "authentication" response, itself as a required field, it would help in having a common way of doing a locally stored identity discovery. If it can be generated similar to how PPID (Private Personal Identifier) is generated dynamically by Infocard it would be a great addition to OpenId IMO. thx =Praveen.alavilli [EMAIL PROTECTED] wrote: On 20-Oct-06, at 12:17 PM, John Panzer wrote: Kaliya * wrote on 10/20/2006, 11:57 AM: I think it is a terrible idea. 1) If you put something out into the market that looks like an e- mail it will be used like an e-mail. I have personal experience with this. I had a AIM handle for the Mac part of the universe [EMAIL PROTECTED] (it was not an e-mail address) but because it looked like one people used it like one and I basically had to go to .mac and pay for an account so that the wires did not cross. This came out of the discussions we have about a smooth migration path for our users at AOL. In our case the [EMAIL PROTECTED] nickname is also a resolvable email address, though it may not be the primary mail account of the user. I'd suggest that as a best practice, anywhere that a [EMAIL PROTECTED] nickname is used, it should also be a resolvable email address. And there should always be an option to not use something that looks like an email address. 2) I think OpenID is new and needs a new way to identify folks. And it is our job to teach people about this new way. Lots of services give people homepages within their spaces...myspace, AIMpages etc. so they can use those URL's if they don't have one yet they can get one. There's a bootstrapping problem here. It's very, very hard to promote the use of something that requires a more complex login flow to replace something that is very simple (albeit limited and in its own silo). How can we cross this chasm? Our suggestion is to support existing practice of [EMAIL PROTECTED] in a standard way, while being open to new practices. Once we can support both we can gain experience and start gradually migrating people over to the new world. At least that's my take. I empathize with your problem John, but I agree with Kaliya and others. Lets take another step back and envision what the login box prompt will say. In OpenID 1.x it was: "Enter your OpenID" With some text to explain what an OpenID was. With OpenID 2.0, we have something like: "Homesite | i-name | OpenID" (Homesite being
Re: [PROPOSAL] Handle http://[EMAIL PROTECTED] Style Identifiers
On 22-Oct-06, at 5:05 PM, George Fletcher wrote: Dick Hardt wrote: What is different with OpenID vs email is that there is certainty that the user actually is the user. I'm a little confused. How is there certainty that the user actually is the user? The viability of the identifier representing the same user is dependent on the OpenID provider not recycling identifiers. Or did you just mean that in email, authentication is not always required for someone to use an email identifier? With SMTP, a bad guy can forge the headers. With OpenID, there is a presumption the user has selected a trust worthy IdP that will only present the user's identifiers when it really is the user. Note that the OpenID protocol does not prevent idp.spammers.com from allowing any identifier to be used and authenticated regardless of whether it's the same user or not. It is incumbent on the relying parties to determine if they will allow identifiers authenticated by a particular idp. Actually, idp.spammers.com cannot do that. The URL has metadata that states which IdP(s) are authoritative. What idp.spammers.com can do is flood an RP with a bunch of identifiers. But this is no different then a script creating new accounts on a system and is defended using the same mechanisms such as throttling and captchas. -- Dick ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: [PROPOSAL] Handle http://[EMAIL PROTECTED] Style Identifiers
On 22-Oct-06, at 7:00 PM, George Fletcher wrote: Dick Hardt wrote: With OpenID, there is a presumption the user has selected a trust worthy IdP that will only present the user's identifiers when it really is the user. Doesn't this imply that both the user and RP have to know which IdP's are trust worthy? It is a choice by the user. Just like the user chooses with ISP to move their data, which browser to run, which OS to run. IN general, those are not dictated by the RP. Actually, idp.spammers.com cannot do that. The URL has metadata that states which IdP(s) are authoritative. What idp.spammers.com can do is flood an RP with a bunch of identifiers. But this is no different then a script creating new accounts on a system and is defended using the same mechanisms such as throttling and captchas. So why can't idp.spammers.com allow anyone to enter a URI of http://idp.spammers.com/name that resolves to a valid XRDS document. The RP then follows the IdP service link back to https://idp.spammers.com and does the association exchange. Now the RP re-directs the user to https://idp.spammers.com for the login page, which just re-directs the user back to the RP with the valid assertion fields. idp.spammers.com does not have to ask the user for authentication credentials (that is out of scope for the spec). For commenting on blogs this would be similar to bugmenot for web subscription services. So of course, the RP just needs to blacklist idp.spammers.com. But now we are back in the same situation we have today where its a race between spammers setting up IdPs and RPs black-listing them. I don't understand why the RP needs to do that ... is the RP wanting to do something it can't do today? Fundamentally, trust worthiness is paramount to making the system work. For now, this means RPs will likely have some sort of ACL (black or white) for the IdPs that they deal with. The trust I am referring to is the user trusting the IdP to not let someone else impersonate them. George: would you explain what problem you are wanting to solve so that we can deal with a concrete example? There are use cases OpenID solves today, and others require additional features that currently are not in the specification. -- Dick ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: [PROPOSAL] Handle http://[EMAIL PROTECTED] Style Identifiers
Dick Hardt wrote: On 22-Oct-06, at 7:00 PM, George Fletcher wrote: Dick Hardt wrote: With OpenID, there is a presumption the user has selected a trust worthy IdP that will only present the user's identifiers when it really is the user. Doesn't this imply that both the user and RP have to know which IdP's are trust worthy? It is a choice by the user. Just like the user chooses with ISP to move their data, which browser to run, which OS to run. IN general, those are not dictated by the RP. I agree it is the user's choice to pick a trust worthy IDP. However, if un-trust worthy IDPs exist, and users choose them, then the RP (in order to protect itself) has to determine which IDPs it considers trust worthy. Hence both the user and the RP have to know which IDPs are trust worthy and which are not. Actually, idp.spammers.com cannot do that. The URL has metadata that states which IdP(s) are authoritative. What idp.spammers.com can do is flood an RP with a bunch of identifiers. But this is no different then a script creating new accounts on a system and is defended using the same mechanisms such as throttling and captchas. So why can't idp.spammers.com allow anyone to enter a URI of http://idp.spammers.com/name that resolves to a valid XRDS document. The RP then follows the IdP service link back to https://idp.spammers.com and does the association exchange. Now the RP re-directs the user to https://idp.spammers.com for the login page, which just re-directs the user back to the RP with the valid assertion fields. idp.spammers.com does not have to ask the user for authentication credentials (that is out of scope for the spec). For commenting on blogs this would be similar to bugmenot for web subscription services. So of course, the RP just needs to blacklist idp.spammers.com. But now we are back in the same situation we have today where its a race between spammers setting up IdPs and RPs black-listing them. I don't understand why the RP needs to do that ... is the RP wanting to do something it can't do today? No, not really. Though in most cases today the RP is also the IDP so relying on some other party to do the authentication doesn't happen too often (except within certain closely related services). There is nothing stopping the RP from looking at the URI for the IDP and not accepting it as a valid IDP. Fundamentally, trust worthiness is paramount to making the system work. For now, this means RPs will likely have some sort of ACL (black or white) for the IdPs that they deal with. The trust I am referring to is the user trusting the IdP to not let someone else impersonate them. I believe that there is also a need for the RP to trust the IdP to not allow impersonation. George: would you explain what problem you are wanting to solve so that we can deal with a concrete example? There are use cases OpenID solves today, and others require additional features that currently are not in the specification. A RP provides a personal finance service that allows users to manage portfolio information online. It also supports online bill pay services. This RP requires a set of information for the account to be created at the RP. With the current specs that RP can accept the authenticated OpenID URI and request the additional required information. Nothing different here. The issue come in the form of liability for the RP. Is the RP liable if someone gets access to someone else's information? In today's world this is the case partly because the RP is doing its own authentication. If the RP is trusting an IDP to do the authentication (plain, strong, second factor, etc) then who is liable? I suspect the RP is, though they might be able to go after the IdP. Thus the RP needs to know which IdPs are trust worthy in order to protect its liability exposure. Thanks, George ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: [PROPOSAL] Handle http://[EMAIL PROTECTED] Style Identifiers
On 22-Oct-06, at 9:04 PM, George Fletcher wrote: Dick Hardt wrote: On 22-Oct-06, at 7:00 PM, George Fletcher wrote: Dick Hardt wrote: With OpenID, there is a presumption the user has selected a trust worthy IdP that will only present the user's identifiers when it really is the user. Doesn't this imply that both the user and RP have to know which IdP's are trust worthy? It is a choice by the user. Just like the user chooses with ISP to move their data, which browser to run, which OS to run. IN general, those are not dictated by the RP. I agree it is the user's choice to pick a trust worthy IDP. However, if un-trust worthy IDPs exist, and users choose them, then the RP (in order to protect itself) has to determine which IDPs it considers trust worthy. Hence both the user and the RP have to know which IDPs are trust worthy and which are not. What is the RP needing to protect itself from? How does the RP protect itself from users that pick bad passwords or post them on sticky notes on their computer or walk away from their computer while logged in? Actually, idp.spammers.com cannot do that. The URL has metadata that states which IdP(s) are authoritative. What idp.spammers.com can do is flood an RP with a bunch of identifiers. But this is no different then a script creating new accounts on a system and is defended using the same mechanisms such as throttling and captchas. So why can't idp.spammers.com allow anyone to enter a URI of http://idp.spammers.com/name that resolves to a valid XRDS document. The RP then follows the IdP service link back to https://idp.spammers.com and does the association exchange. Now the RP re-directs the user to https://idp.spammers.com for the login page, which just re-directs the user back to the RP with the valid assertion fields. idp.spammers.com does not have to ask the user for authentication credentials (that is out of scope for the spec). For commenting on blogs this would be similar to bugmenot for web subscription services. So of course, the RP just needs to blacklist idp.spammers.com. But now we are back in the same situation we have today where its a race between spammers setting up IdPs and RPs black-listing them. I don't understand why the RP needs to do that ... is the RP wanting to do something it can't do today? No, not really. Though in most cases today the RP is also the IDP so relying on some other party to do the authentication doesn't happen too often (except within certain closely related services). There is nothing stopping the RP from looking at the URI for the IDP and not accepting it as a valid IDP. agreed, just like an RP can look at an IP address and decide not to accept it. Fundamentally, trust worthiness is paramount to making the system work. For now, this means RPs will likely have some sort of ACL (black or white) for the IdPs that they deal with. The trust I am referring to is the user trusting the IdP to not let someone else impersonate them. I believe that there is also a need for the RP to trust the IdP to not allow impersonation. George: would you explain what problem you are wanting to solve so that we can deal with a concrete example? There are use cases OpenID solves today, and others require additional features that currently are not in the specification. A RP provides a personal finance service that allows users to manage portfolio information online. It also supports online bill pay services. This RP requires a set of information for the account to be created at the RP. With the current specs that RP can accept the authenticated OpenID URI and request the additional required information. Nothing different here. The issue come in the form of liability for the RP. Is the RP liable if someone gets access to someone else's information? In today's world this is the case partly because the RP is doing its own authentication. If the RP is trusting an IDP to do the authentication (plain, strong, second factor, etc) then who is liable? I suspect the RP is, though they might be able to go after the IdP. Thus the RP needs to know which IdPs are trust worthy in order to protect its liability exposure. One of the key innovations of user-centric identity is that the RP and IdP do not need to trust each other. This is initially a tough concept to accept for people that have worked in the security industry. If an RP wants strong authentication, then the RP will request a strong authentication claim, and yes, the RP will need to trust the entity that made that claim. Note that the strong authentication may be claimed by a trusted vendor of strong auth rather then the IdP. Now here is the interesting observation about liability, if the RP *is* deciding which IdPs the user can use, *then* the RP has liability. If the IdP selection is
Re: [VOTE] Portable Identifier Support Proposal (patch)
-1 for these reasons: Complexity: There is no reason for the RP to be managing the binding between the IdP and the portable identifier. Both the IdP and the RP are verifying this. There is no extra security, and more things to go wrong in an implementation. Privacy: There is no reason for the RP to know I am using a portable identifier instead of one managed directly by the IdP I'm not sure we are all on the same page on requirements, so I will write up a little summary about that and some conclusions. I know many of you wish this issue was over, but we do need to do this one right. -- Dick On 20-Oct-06, at 10:33 PM, Recordon, David wrote: +1, though thinking we should define IdP-Specific Identifier and Portable Identifier in the terminology section. Thanks for doing this! --David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Josh Hoyt Sent: Friday, October 20, 2006 7:31 PM To: specs@openid.net Subject: Portable Identifier Support Proposal (patch) As requested [1], I have made a patch to the specification [2] that specifies the two-identifier mechanism for portable identifier support. It's attached to this message. The net effect is adding one line to the source XML file. I hope this proves useful in evaluating the proposal. Josh 1. http://openid.net/pipermail/specs/2006-October/000478.html 2. http://openid.net/svn/listing.php? repname=specificationsrev=70sc=1 (openid.net specifications svn trunk, revision 70) ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
