Re: Question: multiple IdPs?
On 10/18/06, Recordon, David [EMAIL PROTECTED] wrote: Yeah, the XML file can be based elsewhere. It is especially noteworthy that unless users are combining services, the XRDS document can be the same one that the IdP has issued to go with the IdP-specific URL. For instance, if I want to use another URL with my myopenid account, I just have to add a meta tag pointing to http://josh.myopenid.com/xrds. This means that for non power-users, it's still just as simple as adding one tag to the top of the HTML. Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: IdP assisting user to present previous identifier
On 19-Oct-06, at 8:40 AM, Drummond Reed wrote: I agree the scenarios Dick proposes here make sense. However if the IdP can change an identifier parameter, it should be openid.portable, since: a) that's the one the RP is going to store, and b) that's the one the IdP MUST return with a different value anyway in the directed identity use case (case 1 at http://www.lifewiki.net/openid/ConsolidatedDelegationProposal). We need to carefully consider the security implications, but I believe they are covered by a simple rule: if the IdP returns a DIFFERENT openid.portable parameter value than the one sent by the RP, then the RP MUST verify that the IdP is authoritative for the new openid.portable identifier by doing discovery. If the RP finds that a different IdP is authoritiative, Which is what happens in directed identity. it MUST reinitiate login with that IdP. (Which essentially amounts to an OpenID login redirect.) Not sure that should be automatic. I think the user should be given the choice about what to do then. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: PROPOSAL: rename Identity Provider to OpenID Provider
Martin Atkins wrote: Granqvist, Hans wrote: Why not simply call the idp idp, and prefix it OpenID idp if context or clarification is needed, all referencing an OpenID spec def of OpenID idp? While I guess I agree with your objection, I don't like the redundant ID in OpenID IdP. It makes it awkward to say out loud, if nothing else. Perhaps we can say its full name is OpenID Authentication Provider, but shorten it to just OpenID Provider when the context is obvious? (or just call it an AP and have done with it?) I was thinking OpenID Authenticator since you don't really provide authentication, it's something you do. -- Pete smime.p7s Description: S/MIME Cryptographic Signature ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Two Identifiers - no caching advantage
On 10/19/06, Josh Hoyt [EMAIL PROTECTED] wrote: when she has control Sorry that I didn't put this all in one message, but: I think it's worthwhile to be aware of what might happen in scenarios where your identifier has been stolen, but it should not have much bearing on which proposal gets accepted, since the attacker will have been able to inflict much greater harm elsewhere. I doubt that the protocol can offer much protection if someone actually gets control of your identifier. For instance, some RPs will offer a way to transition an account from one identifier to another (for e.g. domain names expiring). The attacker can just transition those accounts to an identifier of hers. Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: PROPOSAL: OpenID Form Clarification (A.4)
Recordon, David wrote: Combining this with the fact that there is no viable way to enforce sections 8.1 or A.4 being MUSTs, I do not believe that they should be changed from SHOULDs. The only conceivable way I could see of enforcing something like this is telling a Relying Party that they cannot use OpenID Authentication if they don't follow these non-essential markup requirements; that is not something I am willing to do. Be liberal in what you accept, be conservative in what you send. Enforcement is not a requirement. Having said that, I think I agree with you: SHOULD is probably strong enough to ensure that those who can, will. -- Pete smime.p7s Description: S/MIME Cryptographic Signature ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Two Identifiers - no caching advantage
On 19-Oct-06, at 11:18 AM, Josh Hoyt wrote: On 10/19/06, Dick Hardt [EMAIL PROTECTED] wrote: sigh reread the attack. The portable identifier and the IdP do match. In fact, this makes me think of an attack that *would* succeed if the IdP-specific identifer was not in the response: when she has control, she initiates a log-in, but traps the response (it's valid, but never gets submitted to the relying party). The trapped response would only be valid for a short period of time since the RP checks that the response is not stale by looking at the nonce, otherwise this attack could be used in many other places. After you regain control, she has a valid response for your identifier and you have no way to invalidate it. If the IdP-specific identifier was in the response, changing that would invalidate the response. If you want that to happen, then you have to spec out that the RP is verifying the IdP-specific identifier and portable identifier binding when it receives it. That is not in the current proposal. -- Dick ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: OpenID Login Page Link Tag (was RE: PROPOSAL: OpenID Form Clarification (A.4))
Isn't this a case where the Yadis infrastructure should be used instead of Yet Another Link Tag? On Oct 19, 2006, at 8:21, Drummond Reed wrote: Martin, I agree with Dick, this is a fascinating idea. P3P had the same idea notion for a site advertising the location of the P3P privacy policy: it defined a standard HTML/XHTML link tag that could be put on any page of a site that told the browser where to locate the P3P policy document for the site (or for any portion of the site). http://www.w3.org/TR/P3P/#ref_syntax Are you proposing the same thing for OpenID login? (Kewl!) =Drummond -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dick Hardt Sent: Thursday, October 19, 2006 12:53 AM To: Martin Atkins Cc: specs@openid.net Subject: Re: PROPOSAL: OpenID Form Clarification (A.4) On 19-Oct-06, at 12:35 AM, Martin Atkins wrote: Dick Hardt wrote: In order for the RUA to detect that a site supports OpenID, it sees a form with a single input with a name of openid_identiifier. The RUA can then look at the action and post the data directly to the RP. I think it'd be better to implement this as either a META or a LINK element alongside a standard protocol for communicating with the nominated URL. This way the site can declare on *all pages*, rather than on the forms-based login page, that it accepts OpenID auth. This allows the user to go to the RP's home page (or any other page) and click the OpenID Login button on the browser's toolbar and have it work. That is an interesting idea. Would you like to take a stab at more specifics? -- Dick ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs Johannes Ernst NetMesh Inc. http://netmesh.info/jernst ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: [PROPOSAL] Handle http://[EMAIL PROTECTED] Style Identifiers
Back at the dawn of the Web I made the mistake of thinking that the address bar was the place you type a URI. We now know that it is the place you type a search term that may be a URL in canonical form or may be a domain name or may be a search term to be thrown at a search engine. It was one of the principle innovations in Netscape over Mosaic. Any identifier can be represented as a URI. Just stick SCHEME: in front. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Recordon, David Sent: Thursday, October 19, 2006 9:46 PM To: specs@openid.net Subject: [PROPOSAL] Handle http://[EMAIL PROTECTED] Style Identifiers In meeting with a large service provider this week, an issue around end user usability came up. The concern they expressed was that users are know how to enter usernames or email addresses to initiate the login process. While directed identity allows the user to enter example.com, they feel that it still is a bit of a stretch at this time for any major deployment of OpenID. The proposal we came up with was within the spec describing what to do if someone were to enter [EMAIL PROTECTED] in a Relying Party's OpenID login form. The idea is that the RP splits the string on the @ and then treats example.com as the IdP Identifier. This thus doesn't actually require any changes to the protocol itself. Any Relying Party can do this today, but they desire to see this as part of the specification itself so they wouldn't be doing anything special. Within the http://www.lifewiki.net/openid/ConsolidatedDelegationProposal proposal, in case one, openid.identity would be set to http://openid.net/identifier_select/2.0; and then instead of openid.portable being empty, in this case [EMAIL PROTECTED] would be sent to the IdP. While not perfectly mapping to the definition of the openid.portable field, it doesn't seem like that much of a hack to do this. While I certainly am not looking to re-kindle the Why a URI? debate, http://[EMAIL PROTECTED] is also technically a valid URI. It is used in many cases by browsers to provide a username when making a web request. So while this is a little funky, I really think the increased usability offered by describing what a RP should do when a string like this is entered seems to outweigh the potential conceptual confusion. Thoughts? --David ___ 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: XRI confusion
Dick, you are right that there are usability challenges with i-numbers and XDI.org and the i-broker community is working to address them. Although persistent identifiers are used everywhere in local systems (directories, databases, object stores, etc.), and the concept has been around at the Internet level since the late '90s in the form of URNs (http://en.wikipedia.org/wiki/Uniform_Resource_Name), the need to integrate them into a digital identity layer is only just emerging. As with each new Internet layer, there's some stuff that just has to get figured out ;-) =Drummond -Original Message- From: Dick Hardt [mailto:[EMAIL PROTECTED] Sent: Thursday, October 19, 2006 9:26 AM To: Drummond Reed Cc: 'Recordon, David'; 'Martin Atkins'; specs@openid.net Subject: Re: XRI confusion That provides clarity on the process, thanks. If the user knows that their i-name has been changed, then when you write here: http://www.lifewiki.net/openid/ConsolidatedDelegationProposal Summary of Motivations: ... 4. Enable RPs to take advantage of XRI CanonicalDs to protect End-Users from ever having their Portable Identifier reassigned (and thus their identity taken over). ... his is just in case they don't get alerted to their i-name being changed? btw: I have no idea what my i-numbers are, and it was not clear to me that I had them when I got them. I think there are some real usability issues here, but this is likely not the place to address those. :-) -- Dick On 19-Oct-06, at 8:12 AM, Drummond Reed wrote: Exactly. An i-name being reassigned is very similar to a domain name being reassigned -- the previous owner is going to know they no longer own it. For example, if you register blame.ca, you're going to receive multiple notices from your DNS registrar that you need to renew it, and if you don't, you know it is almost certain to be reassigned. The same is true for i-name registrants. With regard to i-numbers, every registrant is notified of their i- number, and their i-broker retains a record of the i-number. Because an i- number is NEVER reassigned, if a registrant chooses not to renew an i-name, they ALWAYS have their i-number. Note that since the i-name and i-number are directly synonymous, i.e., the i-number resolves the same XRDS as the i-name, if a registrant know their i-number, they can always use it to login at any OpenID RP at which they had previously used any i-name synonym for that i-number. =Drummond -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Recordon, David Sent: Thursday, October 19, 2006 4:09 AM To: Dick Hardt; Martin Atkins Cc: specs@openid.net Subject: RE: XRI confusion How would Alice buy =foo when Bob already owns it? --David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dick Hardt Sent: Thursday, October 19, 2006 3:58 AM To: Martin Atkins Cc: specs@openid.net Subject: Re: XRI confusion On 19-Oct-06, at 12:44 AM, Martin Atkins wrote: Dick Hardt wrote: How would a user ever learn what their CanonicalID is? The user doesn't need to know his i-number. The system discovers that for him. If there Portable Identifier (i-name) is reassigned, then they will be sent to an IdP for the new Canonical ID is, expecting credentials from the new owner. The user will never make it back to the RP, and they will have no easy way of proving they are the owner of the CanonicalID. I don't really understand this paragraph, but when the i-name is reassigned it'll cease to point at the same XRDS and will thus not point at the IdP anymore - unless the new owner also has an account with that IdP, of course. But they have a different i-number, so the IdP can distinguish them. Bob has the i-name =foo. Alice has =foo reassigned to her. Bob does not know this. Bob goes to an RP, enters =foo and gets sent somewhere he cannot authenticate since =foo resolves somewhere else. Bob does not know what to do. =foo does not resolve to his i-number any more. How does he find out what it is so that he can get a his i- name to point to it? Additionally, in the proposal, the i-name is not sent from the RP to the IdP, so how does the IdP know which i-name to address the user as? I would hope that an IdP, given that I've already established a relationship with it, can find something better to address me with than a URI. It should be calling me Martin. Perhaps, although I would like my IdP to let me know which Identifier I am going to present to the RP. -- Dick ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs
