Re: Are the Discovery Components Done Enough? (Fwd: [security] OpenID Security Best Practices Doc)
David, Great questions -- see my thoughts/opinions inline... david On Tue, Jun 9, 2009 at 6:36 PM, David Recordon da...@sixapart.com wrote: Hey David,I've been following some of the discovery work the past few months, but don't have a clear picture if the various components are actually solid enough to begin working with. This is a valid concern. From what I can gather from the XRD discussions, it seems like the last remaining issue with XRD is the signature format to adopt. Other than that it seems like XRD is very close (XRI TC particpants correct me if I'm wrong -- I don't speak for the TC as I've mainly been lurking there). Granted, it will take time to get community feedback on XRD, and move through the OASIS standards mechanisms, but it seems like there's enough meat there to begin drafting a document that would outline how the OpenID community should utilize XRD (I think that's the expected deliverable from the Discovery 2.1 WG, anyway). To me, it seems like the 2.1 Discovery WG _could_ be happening in parallel. After all, the 2.1 Discovery WG is only producing a recommendations doc. The official 2.1 WG could choose to ignore that doc. I know XRD is moving forward, but what's the state of site-meta ( http://tools.ietf.org/html/draft-nottingham-site-meta-01)http://tools.ietf.org/html/draft-nottingham-site-meta-01%29or now WebFinger ( http://code.google.com/p/webfinger/)?http://code.google.com/p/webfinger/%29? Is there something in WebFinger which wouldn't solve OpenID discovery entirely? I'll defer to Eran on the state of site-meta. I have been participating in some preliminary (and brief) discussions on the webfinger list (see here: http://groups.google.com/group/webfinger/browse_thread/thread/7936700f02b0049b). I tend to agree with Eran about not needing to normatively specify webfinger. XRD really takes care of the entire discovery process for email addresses (we just need the intro part that says where to look when presented with an email-like identifier). Essentially, webfinger would be a 2 sentence spec: 1.) Look for an @, split the identifier around the @, and use the domain portion of the email to get the host-meta file. 2.) Use XRD to perform discovery on the identifier. I wouldn't be opposed to making a normative spec out of webfinger, but in my experience with EAUT and the discussions around email as an OpenID, there were some fundamental disagreements about authorities for email addresses. There's a significant camp of people that believe this information should be included in DNS. There's also a significant group of people who believe it could be located an XRD file (or, on the web). And some (like me) who believe it could be located in both places, with one taking precendence over the other, plus clear rules of how to behave if one authority is missing. All that to say, I think the OpenID community should take the _principles_ of webfinger, and create its own spec to deal with email addresses. The notion of getting a normative webfinger spec that satisfies every use case on the Internet (i.e., a generic webfinger spec) seems a bit unlikely to me (I could be wrong). All that to say, I think we in OpenID land should specify how _we_ treat email-like identifiers in our own normative spec, using the principles of webfinger. (whew -- sorry for being so long winded). ;) These questions and the lack of adoption of XRD, site-meta or completion of WebFinger have all contributed to my belief that we're still just not ready to redefine how OpenID's discovery process should work. My opinion is that we know enough to get the ball rolling. There are a lot of other outstanding issues relating to discovery than just XRD. It's a valid point, though, and I would be open to the counter-arguement that says, we should wait till XRD, LRDD, etc are finalized before we consider them. I guess I'm more of the opinion that the 2.1 Discovery WG is going to produce a guidance document about 2.1 Discovery, and it seems like we know enough about XRD and its associated protocols to begin discussing and drafting that document. I guess an additional, if not bigger, question is: do we need a 2.1 Discovery WG to produce a best practices doc? Thoughts? Thanks, --David ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Are the Discovery Components Done Enough? (Fwd: [security] OpenID Security Best Practices Doc)
On Tue, Jun 9, 2009 at 7:09 PM, Breno de Medeiros br...@google.com wrote: If we start the process to form a WG for discovery now, most likely the process would only be completed in 6 months, even if there was considerable agreement and stable technologies to draw from. Right now, there is quite a bit of momentum and excitement about Webfinger. The XRI TC is hoping to publish draft specs for XRD withing the next 30 days. Concurrently, and in particular after that, it is hoped that progress on webfinger will be speedy. Webfinger spec discussion may take place at either XRI TC or IETF. Even if webfinger does become its own spec, I'm not confident it will be end up looking the same in the context of OpenID (there are thorny issues like Authority to contend with: e.g., what system is the meta-data authority for an email address? DNS? Web (Host-meta?)? Both? Something-else? I guess my opinion is that this work needs to happen in both places, so why not start it here as well. Should we just start responding to all threads about OpenID 2.x discovery by saying that the discussion is taking place at some other mailing list? Last point to reiterate: There are a lot of Discovery issues besides email addresses and XRD. See the wiki for more. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Are the Discovery Components Done Enough? (Fwd: [security] OpenID Security Best Practices Doc)
Great feedback. I took the liberty to add this to the Discussion Points on the wiki page. http://wiki.openid.net/OpenID-Discovery On Tue, Jun 9, 2009 at 8:43 PM, Allen Tom a...@yahoo-inc.com wrote: My primary concern with changing OpenID Discovery is the upgrade path to the new discovery mechanism. It took way too long for everyone to upgrade to OpenID 2.0, so I'd like to have a better understanding the upgrade path to OpenID 2.1 and/or the new Discovery mechanism. Allen ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: New OP-MultiAuth Draft Published
On Sun, Jan 18, 2009 at 10:41 PM, Paul Madsen paulmad...@rogers.com wrote: Hi David, your extension is an authentication policy declaration from the user to the RP. PAPE allows the RP to declare its authentication policy to the OP (and vice versa). I wonder if there is an opportunity for convergence? I'm open to anything, although PAPE is more of an Auth extension, whereas MultiAuth (at least in its present form) is more of a Discovery extension. If the community sees value in something like this, I think a better place for it would be inside of OpenID Auth Discovery 2.1. Or at minimum a naming scheme that hilites the commonality .. UAPE :-) paul David Fuelling wrote: For anyone interested, I've put out a 2nd draft of my OP-MultiAuth idea. I think the first draft was pretty confusing, so hopefully this clarifies things a bit more. Wiki Page: http://wiki.openid.net/OP-MultiAuth Actual Draft: http://wiki.openid.net/f/openid-provider-multiauth-extension-1_0-2.html In a nutshell, the idea here is to protect end-users against a rogue OP by providing a mechanism for a Claimed Identifier to mandate that an RP get valid auth assertions from two or more different OP's before giving access to RP-protected resources. Thanks! David -- ___ specs mailing listsp...@openid.nethttp://openid.net/mailman/listinfo/specs -- No virus found in this incoming message. Checked by AVG. Version: 7.5.552 / Virus Database: 270.10.8/1899 - Release Date: 17/01/2009 5:50 PM ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
New OP-MultiAuth Draft Published
For anyone interested, I've put out a 2nd draft of my OP-MultiAuth idea. I think the first draft was pretty confusing, so hopefully this clarifies things a bit more. Wiki Page: http://wiki.openid.net/OP-MultiAuth Actual Draft: http://wiki.openid.net/f/openid-provider-multiauth-extension-1_0-2.html In a nutshell, the idea here is to protect end-users against a rogue OP by providing a mechanism for a Claimed Identifier to mandate that an RP get valid auth assertions from two or more different OP's before giving access to RP-protected resources. Thanks! David ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: [OpenID] DISCUSSION relating to OpenID Discovery 2.1
On Tue, Dec 30, 2008 at 7:00 PM, Peter Williams pwilli...@rapattoni.comwrote: I gave up half way through my careful reply, as it was approaching formatting-incomprehensible …to the poor reader trying follow it, point by inset counterpoint. Yes, I encountered the same thing in my responses. :) 1.is metadata mandatory (XRDS or HTML)? Id claim no, by design concept. My proffer of proof is an example: the op-initiated unsolicited assertion (which has no openid-classical user input stage, and thus no discovery, SAML1-like). The nature of AX update is secondary proffer. Correct me if I'm wrong, but in your proffer case, an unsolicited assertion will still have an OpenID Identifier, correct? Before accepting such an assertion, the RP should verify that the OP sending the assertion is the entity who can actually make that assertion. To do that, the RP must either perform 7.3 discovery on the claimed identifier (just for validation purposes), or the RP must validate the Claimed Identifier in some other way (referencing my previous thread, I would argue this some other way must always have its root in 7.3 Discovery -- though it's really just verfication in this scenario). So, the question becomes: How does an RP figure out who can (and who cannot) make an assertion on behalf of a given Claimed Identifier? Are you saying that the manner in which this is done is merely SUGGESTED by the spec, but that RP's can pretty much choose to figure this out any old way they want? See my response to your #5 below for why this is such a big deal to me. 2. Even if metadata via openid discovery is mandatory for an act of interworking, it's not intended (read conceived) to serve as a control framework (for authorization, privileges, permissions, contract bindings,…) I'm not sure you can separate the two -- If metadata via OpenId Discovery is mandatory, then it becomes an authority over the Claimed Identifier (regardless of intent). 3. Some folk evidently see a cousin of the openid2 XRI name servers (XDI) as the infrastructure in openid's future that is intended to play the role (one day) of a fully-fledged, very well-designed authority-based distributed control framework -representing the large-N OP-SP trust models, the attribute contracts per SP webapp, the EDI-style interworking agreement, the contract arrangements, the legal terms and conditions… However, XDI is hardly established practice in OpenID world. I'm not sure if there even exists a single production usage! It's obviously RD. (if anyone can counter this, let me know; I WANT to try it out, to see if/when it will be viable for business use.) XDI may not never come to be adopted in the finalized specs, if Nat's alternative CX regime supplants it (or the highly practical internet-based MPLS-VPNs (per Rapattoni) become the norm for wire-speed trust networking). 4. you say To my way of thinking, this should be clarified in OpenID auth 2.1 -- at the least, if an RP is going to use some non-7.3 mechanism to get an OP Endpoint URL, then that mechanism MUST be populated via traditional Discovery. Why! ..is it so important to you? This proposition essentially turns OpeniD2 into Shib. I might as well just use Shib, and get the assurance of properly specified types expressed in a decent type language. OpenId has really intellectually done nothing if all it does it replace XML with name-value pairs, and SAML metadata with XRDS, and one metadata-based control model for protocol orchestration…with another. Yes, it's very important -- see my response to your #5. But at least you are being direct and honest about the desire. The advanced notions that folks settled on 2 years ago clearly need revisiting – to see which work, which got adopted in practice, which should get dumped, and which get another try as they are obviously still works-in-progress. 5. I suspect, while focusing on points about metadata/authorization/control, we are really tangentially addressing the bugbear topic of all websso schemes: repurposing, and the desire of the asserting party to control who can repurpose an assertion (or reuse a AX response). And of course, that goes to the heart of the current social debate on who controls a users data, the user or the TTP. Once user's own their data, lots of very traditional business models go out of the door. Lots of governance models also get left behind. Ensuring that such old-model controls can be overlaid on such as websso (to control downstream actors) has to be expected. So far, the openid project has not been a foil for shib-like infrastructure governance models (though one can and should overlay those constructs on OpenID, OPTIONALLY, per trust network) Here's why this is so important to me: 1. *User Centric Identity *Ideally, I want the user to be in control of their identity, including which OP asserts for them, and also including what an RP can do with a
Re: Proposal to form Discovery Working Group
On Thu, Dec 25, 2008 at 10:56 AM, Nat Sakimura n-sakim...@nri.co.jp wrote: 2. Separation of OP into Discovery Service and Authentication Service. In the current terminology, OP spans both Discovery Service and Authentication Service. We should be explicit about it. +1. I would like to see discovery services separated from OP services too. John Bradley wrote: Breno, I agree. I recommended separating discovery into a separate doc for 2.1. There didn't seem to be support for the idea at the time, perhaps circumstances have changed and the idea will be accepted now. Regards John Bradley =jbradley ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: non-standard login mechanism
Sounds like you're simply mapping a SL UUID to an OpenID, so my opinion would be no, this does not break the spec, so long as the actual OpenID transaction utilizes the OpenID URL that you have on file in the DB. This is very similar to the other discussions going on regarding using an email address in-lieu of a user's OpenID, since in the real world the email address is the identifier users are arguably most familiar with (currently, anyway). Note here that mapping to an email address does not break the spec, but there is talk of ammending the spec to make email addresses actual OpenID's. david On Mon, Nov 17, 2008 at 1:46 AM, SignpostMarv Martin [EMAIL PROTECTED] wrote: Just polling for feedback on a bit of a non-standard login mechanism I've implemented on my site(s). 1) a user logs into Second Life, and clicks a kiosk to get a nonced URL. 2) the user gets a fairly standard OpenID form, submitting their OpenID (I'm using the Zend libraries, btw) 3) once successfully logged in via OpenID, the endpoint and avatar UUID are recorded in a db table * after this point, the OpenID url will never be entered again (unless the user wishes to change their OpenID, or perhaps for circumstances where an additional security/paranoia requirement is desired) 4) the user visit a SLOpenID v3-enabled website, entering their Second Life avatar name 5) the code checks if the name is valid, on file, and if it has an OpenID associated 6) the code then automagically submits the OpenID that is on file to the Zend libs (as opposed to accepting a POST or GET value) Do note that Linden Lab don't (currently) have an OpenID provider, and since I retired SLOpenID v2, I don't believe there are any that cater solely to Second Life Residents- though there isn't really much point in it any more, considering flickr, live journal and blogger all act as providers (all of which are used by Second Life Residents to varying degrees). The purpose of only using the Second Life name is three-fold: 1) Residents are familiar with entering their SL name (in either first/last format or a single string) in several places throughout Linden Lab's presence (viewer, websites) 2) To strive for a possible standardisation across SL-centric websites, increasing people's awareness of possible phishing attacks (see footnote) 3) To strive for a possible learned behaviour of passwordless, transparent OpenID logins in Second Life viewers (OpenID is mentioned as a possibility for OGP logins) So my question is this: Is using OpenID without the user entering the actual OpenID url breaking the spec ? ~ Marv. *phishing footnote If there are no passwords entered on a SLOpenID v3-enabled website, there is no risk of the maintainer of said site being accused of manipulating users so that they can collect the actual Second Life passwords. If the SLOpenID v3 method were to become commonplace amongst SL-centric websites, otherwise-uninformed users (e.g. those that use SL-centric services) would be immediately less trusting of phishing sites that specifically target SL users (e.g. OH HAI! U CAN HAS FREE L$ IF U ENTER UR PASSWORDS! KTHXBAI MUAHAHAHA) p.s. this email has been BCC'd to the OpenID mailing list and LL peeps, just in case you're wondering why the text of the email is rather verbose. ___ 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: [OpenID] OpenID Extension to handle Emails Addresses?
On Thu, Oct 30, 2008 at 4:01 PM, Martin Atkins [EMAIL PROTECTED]wrote: David Fuelling wrote: I would even entertain the notion of the OpenID extension doing DNS lookup first, then EAUT, though I need to think more on the topic. Alternatively, maybe we make DNS optional. At this point I'll throw in my more recent post about why DNS must be supported and must be the primary mode, with others as fallback: http://www.apparently.me.uk/18285.html Very interesting points in your blog post!! It has me wondering the following questions: 1. The arguments about using DNS could apply to OpenID in general. However, OpenID doesn't do anything with DNS. Why is this? What were the compelling reasons to not use DNS with OpenID? Is there an FAQ page somewhere about that? I have only vague recollections on the topic. 2. Do some of the larger email providers have an opinion on the mechanism used for Discovery in the email case? For instance, would Google/Yahoo/etc prefer that DNS be consulted first, or that some HTTP-based discovery be consulted first? Do they even care? However, I wouldn't necessarily object to putting the *EAUT* information in the DNS rather than the OpenID information directly. The two things I care most about at this point are: * DNS must be consulted first, for the reasons I go into in that post. * In the case where an email address is the claimed_identifier, the OpenID request must have openid.identity set to mailto:theemailaddress, not the mapped HTTP identifer. (In other words, this is an extension to OpenID *Discovery*; the rest of the protocol is unchanged.) What if the user actually wants their URL to be the claimed identifier? Would you be open to that? ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: OpenID Trusted Authentication Extension
John, Have a look at OAuth (http://groups.google.com/group/oauth). I think it's currently a private google group, but it seems like you've given a lot of thought to this type of thing, so I'm sure the group owners would welcome your input. There's a lot of activity going on over there. David On 8/26/07, John Ehn [EMAIL PROTECTED] wrote: I have created a draft of a new specification that I think will help to fill a gap in OpenID functionality. What appears to be a newer productivity feature of many websites is the ability to import and utilize information from other sites. For instance, Basecamp provides an API that allows other systems to access user data. This is a great feature, but it currently cannot be done with OpenID, due to the dependence on end-user interaction during the authentication process. The Trusted Authentication Extension provides for the ability for an OpenID Consumer to log in to another OpenID Consumer without user interaction. The end user will be able to create a trusted connection between two OpenID enabled sites, which will allow a client site to access a destination site using the end user's Identity. Please provide your comments and feedback, as they are most appreciated. http://extremeswank.com/openid_trusted_auth.html Thank you, John Ehn [EMAIL PROTECTED] ___ 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: OpenId as API authentication method
What is OAuth? The group appears to be private, so is not accessible. david On 7/27/07, John Panzer [EMAIL PROTECTED] wrote: You should probably check out OAuth: http://groups.google.com/group/oauth, and its draft spechttp://openauth.googlegroups.com/web/OAuth%201.0%20-%20Draft.rtf?gda=s1UWzkYySf4xbkOgHBZma37zlp9GzEEF__EUK3CcB8RrKx_-nmG1qiJ7UbTIup-M2XPURDT_25fdK7wDxUtwqL26wW_WahD8rT1PnKl_iYB0spTcFQ. Eran Hammer-Lahav wrote: I am not sure if this belongs in the spec list, but I'll give it a try. I would like to suggest adding some text to section 11.1 (or anywhere else that's appropriate) that will provide guidelines for using OpenID in a scenario where the OpenID RP is not the site the user is actually using. The OpenID specification is written with some bias towards implementation in a website environment which is the most common use. My aim is to use OpenID as the authentication method for establishing API sessions. I am building a web service where the client (any user of the API) requests to create a session token which can then be used to bypass authentication for a certain period of time (nothing new here). snip snip ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Do We Agree on the Problem We're Trying to Solve?
On 6/11/07, Josh Hoyt [EMAIL PROTECTED] wrote: On 6/8/07, David Fuelling [EMAIL PROTECTED] wrote: If in 50 years, a given canonical URL domain goes away, then couldn't a given OpenId URL owner simply specify a new Canonical URL in his XRDS doc? If I understand the way that David Recordon and Drummond are proposing that canonical identifiers work, this is not the case. The canonical identifier is the sole database key, and the URL that the user enters and everyone sees is reassignable and (to a certain extent) ephemeral. Control of the canonical identifier is necessary and sufficient to assert one's identity. Yes, I think that's what is intended. However, there doesn't appear to be any mechanism (aside from the proposal saying so) to enforce that the canonical identifier is the root key. Seems like somebody could arbitrarily switch their canonical id to a different canonical id, so long as the person doing the switching controls a regular OpenID and its XRDS file that specifies the canonical id. Am I missing something there? ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Do We Agree on the Problem We're Trying to Solve?
Assuming I understand things correctly, it seems like what we're calling a canonical URL in this thread is really a pseudo-canonical URL since a given OpenID's XRDS doc is what specifies the Canonical ID. If in 50 years, a given canonical URL domain goes away, then couldn't a given OpenId URL owner simply specify a new Canonical URL in his XRDS doc? If so, then It seems like there's almost a (in a good way) circular reference going on, since at certain points in time, what we're calling the Canonical URL is the unchanging/stable/authoritative URL, while at other times, the actual OpenID is the authoritative/unchanging/stable URL. In this setup, I a given person has to control 2 URL's at the same time in order to assert ownership of a given OpenID, making it difficult to lose your Identity if you lose only a single domain. In this respect, each URL provides a safeguard against the loss of the other URL. On 6/8/07, Dick Hardt [EMAIL PROTECTED] wrote: You are still trusting one registry. Of course it is your choice, but you have a single point of failure. Do you think they will still be around in 50 years? On 8-Jun-07, at 4:20 PM, Recordon, David wrote: I don't see how it requires a centralized registry, if I choose to trust that LiveJournal, or some ugly URL from AOL, etc will never go away then that is my choice. --David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dick Hardt Sent: Friday, June 08, 2007 4:08 PM To: Drummond Reed Cc: specs@openid.net Subject: Re: Do We Agree on the Problem We're Trying to Solve? On 8-Jun-07, at 4:00 PM, Drummond Reed wrote: Drummond Reed wrote: Multiple, redundant identifiers is what canonical ID mapping provides. It doesn't require a master directory; it's as distributed as OpenID itself, i.e., it simply provides a way to map a reassignable URL or XRI to a persistent URL or XRI. Dick Hardt wrote: The persistent URL or XRI *is* a master directory. What do you do when the persistent identifier is compromised, goes out of business ... That is problem B. Canonical IDs do not solve B. I completely agree that B is a hard problem. However Canonical IDs solve B if the identifier authority for the Canonical ID follows business and operational practices intended to solve B. And I think there is a solution that does not require a single, central registry. One of the other issues with the registry is it is challenging to provide directed identities. -- 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 mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Questions about IIW Identifier Recycling Table
Hey Johnny, Thanks for your clarifications and answers to my questions about [1]. Over the last few days I've been thinking about your Identifier Recycling proposal[2], in addition to other proposals (Tokens, etc). Assuming I understand things correctly, it seems as if a hybrid of the public/private token approach would seem to garner the most checks, per the IIW grid. Not sure if my idea is technically correct or not, so please let me know if what I'm proposing falls short anywhere. Here goes To make Identifier Recycling Happen: 1.) The OP should send the RP a Unique hash value as an attribute in AttributeExchange. This unique value should be the hash of : + nonce + op_secret_password + user_supplied_secret_password + rp_url. For example, SHA256[1393k3k3939k + op_recycling_password + my_recycling_password + http://example.com; ]. In this scheme, each RP will receive (via Attribute Exchange) a one-way hashed value that is unique to the OP/RP/OpenId/User combination. This value cannot be forged so long as the recycling passwords for the OP and User are not compromised. (Note that the user's recycling password should probably be different from the actual login password). 2.) When an account should be recycled, the OP should force the new user to supply a new recycling password, which will change the hash received by a given RP. This is the signal to the RP to use a different/new account on the RP side, despite having seen the OpenId before. 3.) This scheme would also protect against an OP domain expiring, and getting picked up by a malicious new owner. In this case, the OP recycling password will not be known/valid, and the the new domain owner won't be able to make auth assertions for existing RP accounts that were served by the previous OP owner. 4.) To protect legitimate users from lost recycling passwords, an account recovery mechanism will need to be in place at a given RP, so that if the RP thinks the account should be recycled, the end-user has a way to prevent this (perhaps via email, SMS message, or some other mechanism). This is a problem anyway with the other approaches. In the end, this approach seems to receive a Check under all of the headers on the IIW grid Does not require change to delegation == Check Lost Domain when owning OP == Check Active Recycling == Check Consistent 1.1 == Check (Assuming 1.1 OP/RP's can use AX -- is that true?) One identifier / New DB Field == Check (all data is stored in the AX mechanism). No Strip Fragment == Check Fragments Can be used by other mechanisms (FOAF, etc) == Check [1] http://openid.net/wiki/index.php/IIW2007a/Identifier_Recycling [2] http://openid.net/pipermail/specs/2007-May/001767.html ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Questions about IIW Identifier Recycling Table
Hey Josh, Thanks for your message and great points. See my thoughts/questions inline. On 6/7/07, Josh Hoyt [EMAIL PROTECTED] wrote: On 6/7/07, David Fuelling [EMAIL PROTECTED] wrote: Over the last few days I've been thinking about your Identifier Recycling proposal[2], in addition to other proposals (Tokens, etc). Assuming I understand things correctly, it seems as if a hybrid of the public/private token approach would seem to garner the most checks, per the IIW grid. Not sure if my idea is technically correct or not, so please let me know if what I'm proposing falls short anywhere. Here goes I'm not sure I understand what's public about this. If I understand it correctly, from the relying party's perspective, the user's account is keyed off of the pair of the identifier and the token. This sounds like URL + private token in that table. Am I missing something? Maybe I don't understand the difference between private and public tokens. My proposal used private information to create a public token that can be sent via AX (thus the hybrid term). Am I understanding the difference between private/public tokens incorrectly? This approach was rejected at IIW because: 1. An extra database field is required (whether or not the data is transmitted using attribute exchange) If the AX database schema is architected properly, then the addition of a new AX attribute should not necessitate a new database column. If this were the case, then AX would not really be feasible (how would an RP deal with a new AX attribute?). 2. There is no obvious way to tell if a user is the same user across sites (The identifier contains a secret portion) Good point. Although, let's assume that RP's display fragment-enabled OpenID's in the following manner, which overcomes the Fragments are Ugly problem: a href= http://me.example.com#1234;http://me.example.com/a Users will not be able to easily distinguish that the OpenID is owned by a different user without hovering over the URL in their browser. That said, computers will be able to, since the actual HREF is what counts, I assume. Has this been discussed wrt to fragments. 3. Concern about depending on a secret for a user to be able to sign in to a site (David's Wordpress issue) I think DR had a problem with anything that could be lost, thereby preventing access to an RP. Both Fragments and Tokens seem to suffer from this problem, since in the Fragment scheme, if I or my OP forgets what my fragment was, I won't be able to login to an RP without recycling my account (or forcing an account recovery procedure). Seems like the odds of my OP losing my fragment information are pretty slim. Identically, the odds of my OP losing my recycling_password are pretty slim, too. What's more, If *I* lose my recycling password, why should I care? Only the OP needs to deal with it, and perhaps the OP can just show me that password in an account settings page when I login(?) I'm not sure which of these issues were the basis for rejecting this approach. To me, the biggest problem with it is (2) I agree that #2 is a problem with the token approach. However, the fragment approach doesn't solve the problem of a new OP domain owner being able to make auth assertions for OpenID's that were created for a previous owner (See my proposal #3). This seems to be an edge case, but its effects are much more devastating than people not being able to visually (or otherwise) determine who owns a given OpenID. Maybe the solution is use both approaches at the same time? Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Questions about IIW Identifier Recycling Table
I wasn't at IIW, so please bear with me. In reference to the wiki at http://openid.net/wiki/index.php/IIW2007a/Identifier_Recycling, can somebody clarify what some of the terminology means? Specific questions are below. 1.) For URL+Fragment, what is the distinction between private and public? 2.) Ditto For URL+Token (I assume this means a public vs. private token?) 3.) What does DE mean in the Does not require change to DE? 4.) In the Stolen OP account header, it appears that all 4 of the proposed methods have problems. However do we really want an identifier to be recycled if an account is stolen ( i.e., what if an account is only stolen for a brief period, but then recovered?) 4.) What is Active Recycling? 5.) In the New DB Field header, doesn't an OP/RP need a new DB field in the fragment scheme, in order to distinguish between the id and the current fragment? Or does the OP/RP simply store the whole URL (fragment included) and parse as necessary? 6a.) What is MO in MO Strip Fragment? 6b.) What does the MO Strip Fragment header mean in general? Thanks! David ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
What Should an OpenId Be? [WAS: RE: Proposal for Modularizing Auth 2.0 Discovery]
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Gabe Wachob Sent: Wednesday, February 28, 2007 3:02 PM To: 'Drummond Reed'; 'Martin Atkins'; specs@openid.net Subject: Proposal for Modularizing Auth 2.0 Discovery snip Basically, the Discovery Spec would specify that for any identifier scheme to work with OpenID, it MUST define a way of being constructed into an HTTP URI and then returning a XRDS with an HTTP GET on that HTTP URI. If there are other ways of resolving it, then implementations MAY use those other methods of resolution (native resolution, if you will). In essence, this is a requirement for HTTP gateway(s) to whatever resolution infrastructure exists today. +1. Wherever we go from here, we need to be clear and define exactly what *is* and what *is not* an Open Id Identifier. A while back there was understatementsome talk/understatement about whether email addresses should be used as 1st-Class or 2nd-Class OpenIds (see the wiki here http://openid.net/wiki/index.php/Debating_Emails_as_1st-Class_or_2nd-Class_C itizens). I think it is important to be clear that it is *not* a great idea to use certain other identifiers (email address, phone number, etc) *as* OpenIds. Rather, these should instead map to OpenId Http URL's (or XRI's if possible). This is important because profile attributes like email address, telephone number, etc may or may not be private in certain circumstances. For example, logging-in with my email address at an RP, which maps my email address to a publicly-displayable OpenId, is an ok thing to do assuming I trust the RP with my email address (The RP will hopefully respect my privacy by displaying my mapped OpenId URL or XRI on publicly facing pages where appropriate). If we drift into the territory that says emails addresses (or other profile attributes) *are* OpenIds, then RP's and end-users will run into lots of problems -- E.g., an RP has a publicly facing page that needs to show a user's identifier, but doing so with an email OpenId would be bad for the end user, so the RP is stuck. Bottom Line (repeating myself): We need to be clear and define exactly what *is* and what *is not* an Open Id Identifier. I think the current spec is right on the money here: OpenId Identifiers should be an Http URI or an XRI. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: [OpenID] FW: PROPOSAL: An Extension to transform an EMail Address to an OpenId URL
-Original Message- From: Robert Yates [mailto:[EMAIL PROTECTED] For what it's worth I think that this is excellent. Thanks for the positive feedback! A couple of suggestions: 1) You probably should take a look at the URI Template spec [1]. These guys have done a lot of the work for you. The spec is still in active development and has been blogged about by the author [2], I think that they are about to release a new version with some updates. ..snip.. [1]http://www.ietf.org/internet-drafts/draft-gregorio-uritemplate-00.txt [2]http://bitworking.org/news/URI_Templates Thanks for the pointer. After briefly perusing the URI Template spec, it seems to be a perfect replacement for what I defined in the Email Transform (ET) extension (I used a '[' and they used a '}', but the idea is the same). To keep things simple (the ET extension only defines a single replacement value at present), it seems like rather than including another specification, I should just edit the ET spec to conform to the URITemplate proposal. Of course, I'm always open to other ideas/thoughts. David ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Proposal: SMTP service extension for Yadis discovery
-Original Message- From: Dmitry Shechtman [mailto:[EMAIL PROTECTED] Subject: RE: Proposal: SMTP service extension for Yadis discovery there's nothing wrong with transforming an email to an OpenId Endpoint url (using the root domain of the email). That would require a rule for such a transform. Should it be http://example.com/[EMAIL PROTECTED] Or maybe http://example.com/~bob? So an explicit resolution protocol is required. Why not deploy a plain SMTP extension? Three benefits to using Yadis (and OpenId extensions): 1.) We don't have to mess with MTA stuff (read: It's easier to do, better for adoption, etc). 2.) OP's will already be deploying YADIS (or HTML-based rel links, which could be used instead). 3.) Every site can have its own transform rule, since the transform rule can be defined in the Yadis service doc. On that last point, maybe our OpenId extension works as follows: 1.) Given an email ([EMAIL PROTECTED]), take the domain of the email and treat it as an OpenId Endpoint URL (http://example.com). 2.) Perform OpenId discovery on this URL to get a Yadis service document. 3.) Look for a service type specified by the emailToOpenId transform extension (maybe http://ext.openid.net/emailTransform or something better). 4.) If the service exists in the Yadis doc, then investigate its URI element for some sort of replacement pointer (like ['username']) and use that pointer to perform the transform. So, for example.com, the Yadis service document might include the following service: Service !-- eMail to OpenId URL Transformation Service -- Typehttp://ext.openid.net/emailTransform/Type URI priority=1http://example.org/[username]/URI /Service Using the rule above, with the wildcard/replacement indicator specified by our extension ('[username]'), we have an OpenId of 'http://example.com/bob'. 4b.) If the Service was defined as follows: Service !-- eMail to OpenId URL Transformation Service -- Typehttp://ext.openid.net/emailTransform/Type URI priority=1http://example.org/~[username]/URI /Service then the email address would map to 'http://example.com/~bob', and so forth. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: [OpenID] Questions about Spoofing OpenId
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Carl Howells Subject: Re: [OpenID] Questions about Spoofing OpenId Some care has to be taken to make sure that direct cross-linking won't work, but that's not too difficult. What do you mean by direct cross-linking? ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: [PROPOSAL] Handle http://[EMAIL PROTECTED] Style Identifiers
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Martin Atkins Sent: Friday, November 10, 2006 2:41 AM To: [EMAIL PROTECTED] Subject: Re: [PROPOSAL] Handle http://[EMAIL PROTECTED] Style Identifiers I provide email addresses to some of my friends, but I don't provide them with corresponding OpenID identities. By an unfortunate twist of fate, the domain I provide these addresses in is also my website, and since my site doesn't require authentication the WWW-Authenticate header is ignored. Consequently, http://[EMAIL PROTECTED]/ will end up at *my* website, not the website of the person who uses [EMAIL PROTECTED] Ok, so (just to clarify) in your example we're talking about an email address '[EMAIL PROTECTED]' that maps to a url at an IdP, such that the mapped URL includes the username ('http://[EMAIL PROTECTED]') [** just to be clear, this is David R's proposal...my proposal ignores the userid in the email address **] So, in your example, if you have given someone an email address with a domain 'mydomain.com', and you choose not to offer OpenId services, then emails in your domain can't be used with OpenId. I don't see the problem, -- you own the domain, after all, and should control that decision. Additionally, your scenario is also true in the case of a regular Identity URL that you give out. If you provide an Identity URL 'http://someuser.mydomain.com', but you happen to support some other User Centric Identity standard (i.e., not OpenId), and your user tries to use the URL that you provided (with an OpenId RP), he'd get the same result. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: [PROPOSAL] Handle http://[EMAIL PROTECTED] Style Identifiers
Phillip, Ok, now I understand what you're saying about not using Http in this way. However, I'm not advocating doing anything with the username part of an email (this might be where we're missing each other). I'm saying that we just take the domain + tld of an email, normalize it per the OpenId spec, and use that Http URL that we get as the URL of our IdP. Let me elaborate. In a previous message, you wrote: There are two issues here: 1) The user presentation of the identifier 2) The machine presentation The two do not need to be the same. www.cnn.com works perfectly well as a way to locate CNN. That is a perfectly acceptable user presentation. It is not an acceptable machine presentation and browsers SHOULD NOT accept href=www.cnn.com. If the user presentation value is an email (e.g., '[EMAIL PROTECTED]'), then what is wrong with the machine presentation (wrt OpenId) being 'http://example.com'? The OpenId spec is already doing this with URL's in section 8.2 (Normalization). We're mapping/normalizing 'www.cnn.com' to 'http://www.cnn.com', even though www.cnn.com is not (technically) a validly schemed Http url. Why not do the same with email addresses? -Original Message- From: Hallam-Baker, Phillip [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 08, 2006 4:37 PM To: David Fuelling Cc: specs@openid.net; [EMAIL PROTECTED] Subject: RE: [PROPOSAL] Handle http://[EMAIL PROTECTED] Style Identifiers Please don't map to Http this way. It would be fine to define a fixed mapping from a user identifier to http. But it has to respect the http scheme design and be crafted to avoid operability concerns. http://example.com/user would be acceptable as meeting the scheme design. It is absolutely critical to maintain left/right hierarchy. The username/password pieces in http were not well thought out and may have to be eliminated. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Map/Normalize Email Address to IdP/OP URL (Was [PROPOSAL] Handle http://[EMAIL PROTECTED] Style Identifiers)
Hey David, Thanks for your ideas. Some more thoughts below. -Original Message- From: David Nicol [mailto:[EMAIL PROTECTED] Sent: Thursday, November 09, 2006 6:49 PM To: David Fuelling Cc: Martin Atkins; specs@openid.net; [EMAIL PROTECTED] Subject: Re: [PROPOSAL] Handle http://[EMAIL PROTECTED] Style Identifiers On 11/9/06, David Nicol [EMAIL PROTECTED] wrote: http://[EMAIL PROTECTED] (cool addy, btw) certainly won't get anyone to David Fuelling's home page, now or in any likely future. True, http://[EMAIL PROTECTED] won't get anyone to my homepage...but it would get me to my IdP (assuming Google was my IdP, and offered such a scheme). Ideas: (1) define a way to include an e-mail address among the things obtainable with an OpenID authentication, and a transform to provide a default when none is declared I think the OpenID Simple Registration Extension will provide for this (If I understand what you're meaning) http://openid.net/specs/openid-simple-registration-extension-1_0.html (2a) declare that OpenID does not do e-mail based authentication and never will I hope this can get some more debate in some form or fashion. :) (2b) name some other mechanism for e-mail based authentication and include it by reference, blessing said method by so doing. I think that all this discussion about email userid is moving us off track. My original proposal was that the email maps/normalizes to a URL of an IdP (the userid is ignored/not used). So, '[EMAIL PROTECTED]' would be treated as if the User had entered 'http://any.edu' (the URL of their IdP/OP) into the OpenId login form. Once the user agent is redirected to the 'any.edu' IdP, the IdP would be responsible for figuring out which user is trying to login to the IdP (this is already allowed by OpenId since we can enter a homesite/IdP/OP URL into the login form). The OP might authenticate me by biometric (voice, fingerprint, DNA Sample, etc), or some other scheme, making the username portion of my email irrelevant. Just to be clear, I'm **not** advocating that an email get transformed into a URL that includes the userid of the email (although, I'd be open to entertaining the notion). ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: [PROPOSAL] Handle http://[EMAIL PROTECTED] Style Identifiers
Hi All, Sorry to re-open this can of worms, but I'm just getting a chance to chime in. I actually think David Recordan's idea re: email address to URL resolution would be a great idea! My vote would also be to allow an Email address to map to an Identity Provider URL. NOTE: The email address does not map to a Claimed Identity nor to a Verified Identity (This is key!) Assuming I'm reading David R's proposal correctly, I think the only difference between the two proposals is that in mine, the IdP doesn't need to know what email address was entered (remember, the email is NOT the identity -- it's just a mapping). Here it is proposal 1.) User enters an email address into an RP's OpenId login box. 2.) Behind the scenes, the RP resolves the email address to an OpenId URL via [Resolution Procedure] below. 3.) If the email address resolves to an Identity Provider URL, then the RP continues the OpenId protocol as if the user had entered the Identity Provider URL. 4.) If the email address does NOT resolve to an Identity Provider URL, then the RP SHOULD display a page that says something like: We're sorry, your email address doesn't not yet support Open ID. Please try a different identifier type. On the same page should be some verbiage to help educate the user about what OpenID identifiers are, and possibly how email addresses map to them. Additionally, this could be a page to educate the user about XRI's, and the other parts of OpenId that are appropriate. ### [Resolution Procedure]: An email address resolves to a valid OpenId IdP URL, per the following procedure. A1.) For a given email address of the form '[EMAIL PROTECTED]' and a corresponding domain of the form 'http(s)://domain.tld/, a RP SHOULD attempt OpenID URL discovery (See OpenId Auth 2.0 section 7.3 - Discovery) on the following URL's that are resolved out of the specified email address: 1.) http://domain.tld 2.) http://www.domain.tld The above URL's MUST be resolved by replacing the domain and tld values with corresponding values from the specified email address' 'domain' and 'tld' parameters. In addition, resolution of the above 2 alternate URL's should be done via a HEAD request to all of the URL's first, followed by a GET request to all of the URL's if no URL produces a valid Yadis Resource URL via the HEAD method. A2.) Per the OpenId spec, if URL Discovery fails, then HTML-based discovery should be attempted on the same URL's, in the same manner as above. /end proposal SIDE NOTE: For those who argue against email addresses in the OpenId login form on the grounds of confusion, these 2 email proposals should be no less confusing than trying to educate a user that the Identity URL they type in (e.g., http://aol.com) is not their identity. Both will/would take some education. Thanks! David Fuelling [EMAIL PROTECTED] -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
RE: [PROPOSAL] Handle http://[EMAIL PROTECTED] Style Identifiers
Please see my questions/ideas enclosed... Thanks! David Fuelling -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Drummond Reed Sent: Friday, October 20, 2006 1:04 AM To: 'Recordon, David'; specs@openid.net Subject: RE: [PROPOSAL] Handle http://[EMAIL PROTECTED] Style Identifiers There have been several long threads in the past about using email addresses as OpenID identifiers. The conclusion each time has been to avoid it. I don't remember all the arguments, but among them are: * Privacy: the last thing many users want to give a website is their email address. This seems reasonable at first glance. However, almost every website I have a login with (today) requests my email address so that the site can communicate with me electronically. So, if email addresses WERE used as an additional login input for OpenId, a user who didn't want to use his/her email address to login could always just use an IdP URL or XRI instead (as they can today). Am I missing the privacy concern here? * Reassignability: email addresses are not only reassignable, but for some domains, they are notoriously short-lived identifiers. Is this really such a problem? It seems to exist for URL's in the current protocol proposal anyway. For instance, most people don't own a Domain, which means they'll be using OpenID URL's that somebody else owns. Thus, URL's are reassignable too, and suffer from this in the same way (although I don't really see this as a problem). * Non-portability: unless you own the top-level domain, they aren't portable. Again, is this a problem if the email isn't the actual identifier? If we have a means of mapping an email to an OpenID Identity URL, then if the email goes away (is transferred or otherwise not in the control of the original user), then what's the problem? Point 1.) Losing an email address is no different than the case where a URL is lost/transferred/goes away. Point 2.) If a user lost his email address, theoretically the owner of the email address (example.com, e.g.) would remove the mapping from [EMAIL PROTECTED] to beth's Identity Provider URL. Point 3.) Even if the email address domain owner failed to remove this mapping, only the end-user (beth in this case) would be using the email to login. Presumably, if she switched email addresses, she would use her new address to login, and it wouldn't matter. Somebody else trying to use her email address would need to login to the IdP, and presumably be stopped there. Food for thought... =Drummond ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: [PROPOSAL] Handle http://[EMAIL PROTECTED] Style Identifiers
Hi Philip, I'm not sure I understand Please don't use HTTP this way. I was suggesting that the user enter an email address. The RP then maps the email address to a URL (which would be in the proper scheme). -Original Message- From: Hallam-Baker, Phillip [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 08, 2006 1:45 PM To: David Fuelling; specs@openid.net Subject: RE: [PROPOSAL] Handle http://[EMAIL PROTECTED] Style Identifiers Please don't use HTTP this way. That is not the semantics for http URLs. A better scheme would be to use mailto:[EMAIL PROTECTED] or to define openid:[EMAIL PROTECTED] There are two issues here: 1) The user presentation of the identifier 2) The machine presentation The two do not need to be the same. www.cnn.com works perfectly well as a way to locate CNN. That is a perfectly acceptable user presentation. It is not an acceptable machine presentation and browsers SHOULD NOT accept href=www.cnn.com. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Fuelling Sent: Wednesday, November 08, 2006 1:40 PM To: specs@openid.net Subject: RE: [PROPOSAL] Handle http://[EMAIL PROTECTED] Style Identifiers Please see my questions/ideas enclosed... Thanks! David Fuelling -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Drummond Reed Sent: Friday, October 20, 2006 1:04 AM To: 'Recordon, David'; specs@openid.net Subject: RE: [PROPOSAL] Handle http://[EMAIL PROTECTED] Style Identifiers There have been several long threads in the past about using email addresses as OpenID identifiers. The conclusion each time has been to avoid it. I don't remember all the arguments, but among them are: * Privacy: the last thing many users want to give a website is their email address. This seems reasonable at first glance. However, almost every website I have a login with (today) requests my email address so that the site can communicate with me electronically. So, if email addresses WERE used as an additional login input for OpenId, a user who didn't want to use his/her email address to login could always just use an IdP URL or XRI instead (as they can today). Am I missing the privacy concern here? * Reassignability: email addresses are not only reassignable, but for some domains, they are notoriously short-lived identifiers. Is this really such a problem? It seems to exist for URL's in the current protocol proposal anyway. For instance, most people don't own a Domain, which means they'll be using OpenID URL's that somebody else owns. Thus, URL's are reassignable too, and suffer from this in the same way (although I don't really see this as a problem). * Non-portability: unless you own the top-level domain, they aren't portable. Again, is this a problem if the email isn't the actual identifier? If we have a means of mapping an email to an OpenID Identity URL, then if the email goes away (is transferred or otherwise not in the control of the original user), then what's the problem? Point 1.) Losing an email address is no different than the case where a URL is lost/transferred/goes away. Point 2.) If a user lost his email address, theoretically the owner of the email address (example.com, e.g.) would remove the mapping from [EMAIL PROTECTED] to beth's Identity Provider URL. Point 3.) Even if the email address domain owner failed to remove this mapping, only the end-user (beth in this case) would be using the email to login. Presumably, if she switched email addresses, she would use her new address to login, and it wouldn't matter. Somebody else trying to use her email address would need to login to the IdP, and presumably be stopped there. Food for thought... =Drummond ___ 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
I wonder if it would help our discussion to clarify what is meant when we say that an email address is an identifier. While an email address does technically identify SOMETHING, here I'm using it more as a mapping. So, the way I'm conceiving of things is that the email is in fact a REAL email address. It's just that OpenId has a procedure for using it to forward a user to a proper IdP. A good parallel would be the Identity URL itself. A common user might think of this URL as something to be clicked on, and resolvable -- A Location. However, OpenID is instead/additionally using this URL in a slightly different way -- to map to an identity. Are not these two instances (email and Claimed Identity URL) misleading in the same way? (I'm actually not convinced that either is misleading, but I could be swayed). -Original Message- From: Jonathan Daugherty [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 08, 2006 1:45 PM To: David Fuelling Cc: specs@openid.net Subject: Re: [PROPOSAL] Handle http://[EMAIL PROTECTED] Style Identifiers # So, if in a hypothetical world where we have 4 potential OpenId # values that a user could enter, AND the goal is to reduce # confusion, then does it really make sense to cut out the most common # value (which is an email address)? IMHO, because using identifiers that look like email addresses would be misleading. -- Jonathan Daugherty JanRain, Inc. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: [PROPOSAL] Handle http://[EMAIL PROTECTED] Style Identifiers
Hey Dick, Couldn't one make the opposite argument -- that most people's email address NOT working when they plug it into the OpenId login field could actually be a good thing? (especially in the beginning of OpenID) I say this because such scenarios (user enters email, and RP fails because the email doesn't yet support open id) might actually be a catalyst for more people to use OpenId, especially if users start barking at their ISP/email providers to support OpenId because their email isn't working correctly with certain sites they want to use. For example, consider the following two potential scenarios that might go through a new user's mind when they first encounter OpenId: Scenario #1 (WITHOUT email allowed in the OpenId login form): User encounters an openid enabled site (RP == example.com), and decides they are curious about this new way to login (simplifying, I know -- but we're talking about a simple user). The user pretty quickly realizes that they need to somehow secure an Identity URL. The typical user (my parents, e.g.) might be inclined to say: all my other (non-openid) sites require my email address (usually) as a username. Plus, since example.com still supports email address based username+passwords anyway, why not just continue to use that? Thus, the novice user who fails to see the benefits of OpenId might just decide against OpenId because of the perceived difficulties in using it, especially in the beginning when OpenId adoption will be gaining traction, but not the majority method used for site login. Scenario #2 (WITH email allowed in the OpenId login form): User encounters an openid enabled site, and decides they are curious about the new way to login. If their email domain supports OpenId, then there's really no reason for a novice user NOT to use OpenId -- it works with the email address. On the other hand, if the RP determines that the specified email address doesn't support OpenId, it (the RP) then comes back to the User with an educational page explaining why the email doesn't work, perhaps with a call your email provider and encourage them to adopt openid...and here's why. Anyway, this might be a different perspective on whether or not the [oops, your login didn't work] is a bad thing. -Original Message- From: Dick Hardt [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 08, 2006 5:06 PM To: David Fuelling Cc: specs@openid.net Subject: Re: [PROPOSAL] Handle http://[EMAIL PROTECTED] Style Identifiers Hi David A Homesite is a new concept for users, so when they see a prompt for it, they will know they have one or not. They are not just typing in a random URL. Pretty much every user has an email address, so a prompt asking for an email would suggest to user that their email will work -- which of course hardly any will. -- Dick ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs