RE: [OpenID] OpenID Extension to handle Emails Addresses?
The Internet has an identifier for users - it is their email address. Trying to tech users to use anything else is pointless. As far as I am concerned, we have a hierarchy of usability interests here: Users: They come first, their needs are paramount and trump all others. Authentication consumers: They come next, make admin as easy as possible, but not if it is going to hurt users. We can expect an auth consumer to have a properly configured DNS server or fix their server if broken. Identity providers: This is a serious business. I don't consider it necessary to make barriers to entry any lower than they currently are for administering a mail server. At the moment the URL centric spec seems to have this hierarchy stood on its head. In order to make matters easy for authentication providers the user is expected to futz with URLs. I have a dozen blogs, I have never considered them to be part of my core identity. They are attributes, not my name. So we have an identifier, [EMAIL PROTECTED], how do we resolve it? Well we already have a specification for that, it is the core architecture of the Internet: DNS. We use the DNS SRV record for service discovery. It is what it is designed for. It provides for fault tolerance, load balancing, fall over just like an email MX record. The simplest discovery mechanism then is: _openid.example.com SRV 1 100 80 openid.example.com or for fault tolerance: _openid.example.com SRV 1 100 80 openid1.example.com _openid.example.com SRV 1 100 80 openid2.example.com or we can redirect to a third party: _openid.example.com PTR pip.verisignlabs.com Any competent network admin can configure SRV records using any of the mainstream DNS servers that have come out in the past 8 years. Windows 2000 uses SRV as a core service. There is no need for users to know this is going on, the only point where the SRC is required is that the identity server has to advertise the service and the authentication consumer app has to be able to read it. OK so now lets think about market building a bit. Lets try to embrace and extend the competition. In my view the value of OpenID is not so much the protocol as the idea of an interoperable identifier. So lets try to capture the SAML and WS-* worlds as well. We can do this with a policy declaration: _openid.example.com TXT v=openid openid saml _openid.example.com SRV 1 100 80 openid1.example.com _openid.example.com SRV 1 100 80 openid2.example.com _saml.example.com SRV 1 100 80 saml1.example.com _saml.example.com SRV 1 100 80 saml2.example.com We don't need to just stop at establishing identity either. We can use this as a means of deploying the type of exotic authentication protocols that Stefan Brands and myself have developed which allow for anonymous authorization without authentication. Someone is going to do federated auth this way sooner or later. It is the obvious way to do it that is consistent with the Internet architecture. The only real arguable point in what I wrote is that I do not have solid data on how users will react. It is my hypothesis that they will find an email address easier than a URL. If folk want to argue that point lets test it out. The main obstacle to change here would be the effect on the legacy base. We would need to get the identity providers to upgrade (easy) and the web sites to upgrade (harder) and there would have to be some sort of change over period that we would need to think through. -Original Message- From: [EMAIL PROTECTED] on behalf of David Fuelling Sent: Thu 10/30/2008 12:20 PM To: Martin Atkins Cc: specs@openid.net; OpenID List Subject: 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
RE: [OpenID] OpenID Extension to handle Emails Addresses?
Maybe because the DNS naming system is the Internet for all practical purposes. Think about the telephone system. What parts of the system today have remained the same for a century? Pretty much everything has changed, the telephones, the switches, the wires, even the assignment of the numbers themselves. But the basic interface of 'dial number X to talk to Y' has remained constant. The DNS is the equivalent infrastructure for the Internet. Everything else will change over time. We are currently changing the packet protocol from IPv4 to IPv6 and many parts of the Web are not on the Internet at all, the are URLs embedded in print media, in CD Rom and such. The implementation will change, you might even see new TLDs replace .com or the rise of www.microsoft or whatever. But every such change must and will be incremental. I am not quite sure to interpret the last paragraph. The term 'walled garden' is a loaded one. It is used to refer to the carrier model where the carrier decides where the consumer is allowed to go. I don't think that is what end users want. But what they might well want is a model where they get to define the fences themselves. So they can fence off their financial browser from the anonymizing Web browser they use to view folk dancing Web sites and the like. Its really a matter of who gets to decide where the fence goes... From: Peter Williams [mailto:[EMAIL PROTECTED] Sent: Thu 10/30/2008 3:09 PM To: Martin Atkins; Hallam-Baker, Phillip Cc: specs@openid.net; OpenID List Subject: RE: [OpenID] OpenID Extension to handle Emails Addresses? Verisign wants validation of id related to dns (and dnssec). Wonder why? As long as an op can verify the dns assuraces and communciate them to the rp as a certificate (re)minted by itself, there is a compromise to be had here. Perhaps the op adds the domain to its own walled garden dns server, does its own dnssec, and lets its consumers bind over an mpls vpn and virual routing domain to its dns service.. That would be consistent with the openid model: as the rp app chooses the dns access point, not the op. -Original Message- From: Martin Atkins [EMAIL PROTECTED] Sent: Thursday, October 30, 2008 2:51 PM To: Hallam-Baker, Phillip [EMAIL PROTECTED] Cc: specs@openid.net specs@openid.net; OpenID List [EMAIL PROTECTED] Subject: Re: [OpenID] OpenID Extension to handle Emails Addresses? Hallam-Baker, Phillip wrote: Well we already have a specification for that, it is the core architecture of the Internet: DNS. We use the DNS SRV record for service discovery. It is what it is designed for. It provides for fault tolerance, load balancing, fall over just like an email MX record. Thanks for another voice in favor of DNS. I was beginning to feel like the only one on this side of the fence. :) The simplest discovery mechanism then is: _openid.example.com SRV 1 100 80 openid.example.com I did consider SRV, but the return value from OpenID discovery is not a hostname, it's a structure like this: * Endpoint URL * Final claimed identifier (after following redirects) * OP-local identifier (or delegate in 1.1 terminology) * OpenID version (either 1.1 or 2.0, currently) Some of these we can infer. For example, in my DNS-based proposal I just assumed that all email-based identifiers would use OpenID 2.0, because a provider's going to have to change their implementation anyway so they might as well upgrade to 2.0 while they're at it if they don't support it already. I went with a TXT record with a custom serialization, despite it being technically incorrect, both so that the information required for the above structure could be represented and also so that it can be deployed on DNS providers that only allow A, CNAME, MX and TXT records to be configured. The latter is important for the delegation case, as the main audience for delegation is people with vanity domains. OK so now lets think about market building a bit. Lets try to embrace and extend the competition. In my view the value of OpenID is not so much the protocol as the idea of an interoperable identifier. So lets try to capture the SAML and WS-* worlds as well. We can do this with a policy declaration: _openid.example.com TXT v=openid openid saml _openid.example.com SRV 1 100 80 openid1.example.com _openid.example.com SRV 1 100 80 openid2.example.com _saml.example.com SRV 1 100 80 saml1.example.com _saml.example.com SRV 1 100 80 saml2.example.com And I infer from this that you're not adverse to the idea of encoding custom formats in TXT records, so hopefully you'll appreciate my approach. However, if you've got an alternative proposal that's more DNS-pure I'd be happy to hear it. I don't claim to be a DNS expert. However, it'd take a very convincing argument for me to get behind anything that requires something other than A, CNAME, MX and TXT records though, for the reasons stated
RE: OpenID Email Discovery
separate the OpenId protocol from the discovery framework the authentication protocol negotiation mechanism could then become the architecurally precise means of deploying OpenId and the ad-hoc workarround discovery mechanisms may be regarded as fixes to support legacy infrastructure, build the deployed base etc. If we use the TXT plus SRV record approach we are able to support 100% of legacy authentication protocols and infrastructure in a manner that is compatible with 98% of the deployed DNS infrastructure or better and consistent with IETF standards. The only minor deviation here is using TXT to express the new policy records. Being able to support any authentication protocol in this manner means that the proposal is potentially one that can bring together all the different efforts in the space. It adds value for SAML, Liberty, CardSpace and Higgins supporters. From: Peter Davis [mailto:[EMAIL PROTECTED] Sent: Fri 04/01/2008 8:56 AM To: Hallam-Baker, Phillip Cc: Eran Hammer-Lahav; OpenID specs list Subject: Re: OpenID Email Discovery On Jan 3, 2008, at 6:03 PM, Hallam-Baker, Phillip wrote: NAPTR is an ietf proposed standard but there is no deployed base. well, there certainly are deployed bases where i sit, since we have DNS zones in operation with well over 40M entries... most of which are NAPTR RR's, and many, many users of these services. The reason i made the suggestion, however, is that the proposed solution (of using TXT RRs) showed examples of regx like functions for resolvers to post-process... which is precisely what NAPTR RRs were intended to provided (among other things) and that use of TXT RRs are being discouraged. the SRV RR does not provide any facilities for regx-like answers. =peterd ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: OpenID Email Discovery
On the contrary, you require the SSL certificate to match the domain of the identifier being authenticated and the problem is solved. Alternatively you use a scheme such as SAML to perform the authentication which would provide more flexibility than a transport layer security model. One reason I strongly prefer the email identifier approach is precisely because it maps so much better to PKI. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Trevor Johns Sent: Friday, January 04, 2008 6:08 AM To: Artur Bergman Cc: 'OpenID specs list' Subject: Re: OpenID Email Discovery On Jan 4, 2008, at 1:59 AM, Artur Bergman wrote: Fair or not, I am tired of hearing how un-secure DNS, when everything we do is based on it, and it being the worlds largest working distributed database. There's a difference between working and secure. For example, email works great but it's far from secure. There is SSL connecting to the provider that is being refereed from the srv/txt field. Which is no different than what you are referenced to from an A or CNAME or MX Which is why I said it depends on what is used as the claimed identifier. If the user's email address is used as the claimed identifier and I am able to change the user's record from: example.com TXT ‘OpenID * 10 https://*.example.com/’ to: example.com TXT ‘OpenID * 10 https://*.myevilsite.com/’ then all the SSL in the world won't help. If the email address _isn't_ the claimed identifier, then the end user has to validate that their OP-local identifier (which they don't know) is displayed correctly by the service provider. This is worse than an SSL failure, there isn't even a dialog asking them to click OK! Not that it matters anyway, since people just click OK. If a service provider detects an SSL failure, there's no person there to press okay. Their server will just summarily deny the authentication request. The click OK problem is only between client-server communication. This is server-server communication. -- Trevor Johns http://tjohns.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: OpenID Email Discovery
You can use domain validated SSL certificates or DNSSEC here. Either is sufficient. There is no technology gap here. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Artur Bergman Sent: Friday, January 04, 2008 6:14 AM To: Trevor Johns Cc: 'OpenID specs list' Subject: Re: OpenID Email Discovery On Jan 4, 2008, at 12:07 PM, Trevor Johns wrote: On Jan 4, 2008, at 1:59 AM, Artur Bergman wrote: Fair or not, I am tired of hearing how un-secure DNS, when everything we do is based on it, and it being the worlds largest working distributed database. There's a difference between working and secure. For example, email works great but it's far from secure. Whatever, this discussion is old and bores me. You can always go out and use DNSSEC. There is SSL connecting to the provider that is being refereed from the srv/txt field. Which is no different than what you are referenced to from an A or CNAME or MX Which is why I said it depends on what is used as the claimed identifier. If the user's email address is used as the claimed identifier and I am able to change the user's record from: example.com TXT ‘OpenID * 10 https://*.example.com/’ to: example.com TXT ‘OpenID * 10 https://*.myevilsite.com/’ then all the SSL in the world won't help. If the email address _isn't_ the claimed identifier, then the end user has to validate that their OP-local identifier (which they don't know) is displayed correctly by the service provider. This is worse than an SSL failure, there isn't even a dialog asking them to click OK! Not that it matters anyway, since people just click OK. If a service provider detects an SSL failure, there's no person there to press okay. Their server will just summarily deny the authentication request. The click OK problem is only between client-server communication. This is server-server communication. Isn't this just a lookup of email address - openid/url that is then handled as a normal openid login? Artur ___ 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 Email Discovery
This is the function of the existing DNS SRV record. _openid.example.com SRV 1 1 1 1 openid1.example.com The Internet has an architecture already. Use it, don't try to reinvent it. From: [EMAIL PROTECTED] on behalf of Eran Hammer-Lahav Sent: Thu 03/01/2008 4:01 PM To: 'OpenID specs list' Subject: OpenID Email Discovery (The full story is posted at http://www.hueniverse.com/hueniverse/2008/01/addressing-open.html but this contains the technical parts of the post). This proposal adds Email Discovery allowing users to use their email address as an OpenID. ... We need to map between the email to the OpenID identifier and this is where DNS comes in. DNS already has a system for resolving email addresses into an actual server - email resolution using an MX record. Why not add a new record type for OpenID. Basically another way to perform OpenID discovery that is all about making it user-friendly. All that is needed is a URL the site performing discovery can append the email to and treat it as an OpenID identifier. This can be done using a OpenID TXT record: 'OpenID [username rule] [priority] [URL]' where [username rule] is a wildcard expression used to match the username part of the email (everything up to the '@'), [priority] is the MX-like priority value, and [URL] is the URL used to generate the OpenID identifier. The URL uses '*' to indicate where the username is inserted, and '**' to indicate where the full, URL-encoded, email address is inserted (both optional). For example: example.com TXT 'OpenID * 10 http://*.example.com/' example.com TXT 'OpenID joe 10 http://example.org/openid?**' Which reads: for any email address '@example.com' other than 'joe' use 'http://username.example.com/' as the OpenID identifier. For email address '[EMAIL PROTECTED]' use 'http://example.org/openid?joe%40example.com' as the OpenID identifier. Rules are processed first based on the username rule match (in order of match closeness) and then on priority which is used in the same manner as MX records priority. ... There are many ways to implement identity delegation, but in the context of email identifiers and simplifying the user experience, the idea is to move the delegation mapping to the OpenID provider. When users sign-up for a new OpenID, they will be given the option, perhaps as a premium paid service, to make the OpenID provider map incoming identity checks for the user email address with their local OpenID identifier. So instead of the users telling the site about their local identity (using delegation), the OpenID provider will perform the mapping. In the above example, '[EMAIL PROTECTED]' has his OpenID managed by 'example.org'. When signing up for an OpenID at 'example.org', Joe asked it to accept identity requests for '[EMAIL PROTECTED]' or at least provide delegation discovery. When Joe tries to log into an OpenID-enabled site using '[EMAIL PROTECTED]', the site convert the email address to the URL 'http://example.org/openid?joe%40example.com' and use it like a regular OpenID identifier. 'example.org' will reply with the needed discovery information to get Joe authenticated using the OpenID protocol. By using the '**' symbol, the full email address is sent over to the OpenID provider which can perform mapping of identities other than its own local ones. This can be viewed as hosted delegated identity where the OpenID provider also provides hosting of the OpenID delegation information for the user. It doesn't require any new standards except for implementation and support by OpenID providers. --- Would love to get some feedback. Thanks, EHL ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Wiki page: Attempting to document the Email Address as OpenIddebate.
I think that it is very important to remember that there are two separate identifier issues here: 1) What the user is expected to type. 2) The cannonical representation used by the machines. In the pre-Mosaic Web browsers the URI simply did not appear in the primary chrome. Open URI was a drop down menu option with a secondary dialogue. The idea was that addresses were something that remained under the covers and just like the SGML like angle brackets were never seen (HTML only became a fully compliant SGML markup later on). The page is making tenuous distinctions between URLs and URIs that are unfortunately 100% bogus. The whole URN/URL/URI nonsense was a huge mistake as Tim Berners-Lee himself has lamented on numerous occasions, including last month when I discussed the issue with him. The URN/URL thing was never his idea, it was forced on him early on in the development of the Web when he was looking for buy in. URNs are URLs and URLs are URNs, If I take an ISBN it is nominally a URN but enter int into Amazon.com and click buy now and it just became a URL. Empirically email addresses are an important form of net identifier. If they don't fit into a taxonomic scheme that someone is peddling the answer is to jettison the scheme. Just use the nomenclature that Tim suggested in the first place. The only useful distinction to make here is by the registry. There is an important difference between an email address and an ISBN. The first is relies on the DNS system for its semantics, the second relies on the ISBN registry for its semantics. The only way to make a DNS name more permanent is to attach it to a registration scheme that makes it more permanent. So combine a DNS name and time and you have a permanent identifier albeit one that can only be resolved directly while the name continues to be owned by the same party. The only case where the choice of identifier makes a real difference is when it is used as a contact address. An authenticated blog URL is a form of contact address. An email address is another which offers greater interaction. An email address is a contact address, it is not necessarily the only contact address. If someone is offering blog hosting services to people they can also offer email should they choose. This is not likely to be the blogger's only email address unless and until something remarkable has been done in the spam control field. An 'email' address is simply the conventional conjunction of a username portion and a DNS name portion. It need not be used only for email, nor is it. It is routine for people to use RFC822 addresses for Jabber and other instant messaging applications. Over time everyone will own their own DNS domain and it will form the hub of their personal communications system. All communication modes will map onto the single unified communication identifier. By far the most likely identifier to be chosen for this purpose is the RFC822 email identifier. It is embedded in the system at this point. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Fuelling Sent: Saturday, February 10, 2007 3:54 PM To: [EMAIL PROTECTED] Cc: specs@openid.net Subject: Wiki page: Attempting to document the Email Address as OpenIddebate. Hi List, In light of my recent extension proposal to map Email Addresses to OpenId URLs, I have setup a wiki page on openid.net that attempts to capture all the pro/cons/issues that have been shared in the debate over whether this is a good idea or not. http://openid.net/wiki/index.php?title=Debating_Emails_as_OpenIds I have tried as best I can to present a non-partisan wiki page that simply details the pros/cons of each argument. Basically, the point is to document all sides of the debate, and *not* to endorse one side or the other. That said, I'm sure some of my bias is present in the initial wording, so please feel free to suggest changes to my wording, or make them yourself. In addition, please add additional arguments and rebuttals as you see fit. The page is not nearly exhaustive (I plan to add some arguments in favor + rebuttals tomorrow when I have time). Thanks! 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: [OpenID] Wiki page: Attempting to document the Email Address asOpenId debate.
The semantics of an identifier arise from its usage. It is of course entirely possible that someone might configure their system in such a way that the Kerberos principal [EMAIL PROTECTED] was different from the person with email address [EMAIL PROTECTED] was different from the person with Jabber address [EMAIL PROTECTED] But it is rather unlikely that the party who created this situation would be unaware of the potential for confusion. If there is an OpenID identifier [EMAIL PROTECTED] there may or may not be an SMTP server willing to accept mail for that address. If there is such a server the domain name owner should be expected to understand the consequences of the identifiers mapping to different principals and take whatever steps are felt necessary to ensure this. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Fuelling Sent: Sunday, February 11, 2007 9:42 PM To: 'Claus Färber' Cc: specs@openid.net; [EMAIL PROTECTED] Subject: RE: [OpenID] Wiki page: Attempting to document the Email Address asOpenId debate. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Claus Färber http://openid.net/wiki/index.php?title=Debating_Emails_as_OpenIds I'd prefer to call them [EMAIL PROTECTED] OpenIDs. The concept of using this format is not only used for email but also for other types of identifiers such as RADIUS zones or Kerberos realms. For example, [EMAIL PROTECTED] could be a RADIUS login, a Kerberos principal and a Yadis ID/OpenID but not an email address. HmmmI'm not sure about this one. I intentionally rooted my definition of Email Address in RFC2822, which is where it should be rooted (if we're going to call them 'email addresses'). Seems like anything in the form '[EMAIL PROTECTED]' would also have an identical root (RFC2822). Is that not the case for Kerberos realms and RADIUS zones? In other words, are these *not* also email addresses? 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: [OpenID] Wiki page: Attempting to document the Email Addressas OpenIddebate.
Hallam-Baker, Phillip wrote: Over time everyone will own their own DNS domain and it will form the hub of their personal communications system. All communication modes will map onto the single unified communication identifier. I don't necessarily disagree with many of your arguments, but I wonder why — if everyone owns their own DNS domain — we even need the user@ portion anymore? Largely that was included because in the early days — and even today, for many people — their addresses were [EMAIL PROTECTED] I agree. Example.com should be default be interpreted as a first class identifier. My primary personal email address (not the one I use for mailing lists) is pretty redundant since the part before the @ is the same as the part after the @ once the parent domain has been excluded. Leaving off the user@ portion doesn't make the address any less mine. The main issue here is who owns the naming registry. Under what circumstances does a name change control? The ICANN infrastructure is cumbersome but essential. Trying to replicate the DNS and ignoring the needs that led to the creation of ICANN is doomed. Trying to establish a proprietary registry is the sort of dotcom nonsense everyone apart from O'Riely and his Web 2.0 types have grown out of by now. Calling a Jabber ID an email address is a bit misleading. OK call it an RFC 822 format address then. It's entirely possible for the email address [EMAIL PROTECTED] and the JID [EMAIL PROTECTED] to be owned/controlled by different people. It is not safe to assume that the two are the same person without evidence of that. What makes a string like [EMAIL PROTECTED] an email address is the fact that you can address email to it. The fact that the two addressing schemes use similar syntax doesn't help you much. On the contrary there is a very high degree of probability that they are the same. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Proposal: An anti-phishing compromise
I think that it is an excellent idea since it allows us to have it both ways. We can continue to offer backwards compatibility with legacy infrastructure without compromising the strength of the strongest schemes. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Josh Hoyt Sent: Thursday, February 01, 2007 4:42 PM To: OpenID specs list Subject: Proposal: An anti-phishing compromise Hello, I've written up a proposal for an addition to the OpenID Authentication 2.0 specification that addresses the phishing problem. I've had some off-list discussion of it, and I think it may strike the right balance. Please provide feedback. Josh Background == We have had a lot of good discussion about how phishing relates to OpenID. There seems to be consensus that the OpenID Authentication spec should address these issues, but not consensus on how that should happen. The ways that OpenID can potentially make phishing worse: * Redirects to your provider are a fundamental part of the flow of OpenID, so being redirected to a phishing site is easy to miss * Every relying party (necessarily) needs to know who the provider is in order to verify the authentication response. This means that the site knows what UI it needs to use to phish (and even worse, it can just proxy the user to the provider) I think these two issues cover what makes phishing potentially a greater threat when using OpenID. Although these problems are significant, if a user can authenticate to their OpenID provider through an non-phishable mechanism, OpenID can make the phishing problem *less* of a threat, because there are fewer places that will need to ask for credentials. Other relevant issues: * There is no universally deployed solution to the phishing problem * There is not even a universally *accepted* solution to the phishing problem * Any technology that prevents phishing will require user-agent support or else will fundamentally change the flow of OpenID (prevent relying-party-initiated sign-in) * OpenID is intended to be deployed without requiring specific technologies to be present in the user-agent * Any general anti-phishing technology can be applied to OpenID Proposed Change === Add a single, required, boolean field to the authentication response that specifies whether or not the method the OP used to authenticate the user is phishable. The specification will have to provide guidelines on what properties an authentication mechanism needs to have in order to be non-phishable. The field is just meant to indicate that the authentication mechanism that was used is not a standard secret entered into a Web form. Analysis This proposal is a simplification of the Assertion Quality Extension [1] (AQE), and is essentially the same as what Ben Laurie proposed earlier [2]. It does not attempt to replace the AQE or require it for authentication in general. Benefits The proposal is trivial implement, it acknowledges that phishing is a problem, and forces implementers think about it. If more assurances are required, then the AQE, whitelists, and other mechanisms still need to be employed. This field just sets a minimum bar. I think that this is the right information to require, because it addresses this one thing that makes OpenID potentially worse for security, but it does not mandate specific technologies. It pushes the liability for phishing relying parties to OpenID providers, who are the ones who should be responsible for taking measures to prevent phishing. IANAL, so I don't know if this has any real teeth, but it does make it clear to people who are implementing OpenID providers that it is intended to be their responsibility to deal with the phishing issues. Drawbacks - It may be tricky to define what is meant by non-phishable. There is no way for a Relying Party to *ensure* that the OpenID provider indeed uses non-phishable authentication. If libraries are used, the library user may not read the relevant parts of the specification about phishing, and so may remain ignorant of the phishing issues. Why this should be in the core spec --- I believe that this one piece of information would be required more often than not, given the phishing implications. The prominence of being in the core specification makes it harder to ignore the phishing problem. References == 1. http://openid.net/specs/openid-assertion-quality-extension-1_0-03.html 2. http://openid.net/pipermail/general/2007-January/001340.html ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net
RE: [OpenID] Announcing OpenID Authentication 2.0 - Implementor'sDraft 11
[mailto:[EMAIL PROTECTED] On Behalf Of Ben Laurie More importantly, I think I have a solution that will make both of us happy, but I now have to go and ride my motorbike fast, so I'll detail it later. Now there is an exit line to tempt the Gods. The only way that I can see that you are going to circumvent an attempt using existing browser capabilities is to introduce a malicious login page is through use of some form of shared secret such as a picture of a cuddly animal chosen by the user or Secure Letterhead. Letterhead requires a browser upgrade so it breaks the 'existing capabilities' constraint. If you change the browser you might as well really change the browser and use a strong authentication mechanism based on PKI I think we need to take another look at the 'change the browser' case and make sure that we can take full advantage if the browser is changed. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: [OpenID] Announcing OpenID Authentication 2.0 - Implementor'sDraft 11
SSL achieves the original security goals set for it. SSL does not achieve every security goal, that is not a failure. Certainly there are no grounds for the claim PKI has failed when it has succeeded in its original limited goals. I agree that the original goals were too narrow. That is an argument I made ten years ago. This is partly about correcting that original mistake. -Original Message- From: Ka-Ping Yee [mailto:[EMAIL PROTECTED] Sent: Monday, January 22, 2007 3:05 PM To: Hallam-Baker, Phillip Cc: James A. Donald; Ben Laurie; specs@openid.net; openid-general; heraldry-dev@incubator.apache.org Subject: Re: [OpenID] Announcing OpenID Authentication 2.0 - Implementor'sDraft 11 On Mon, 22 Jan 2007, Hallam-Baker, Phillip wrote: On the contrary, PKI is the basis of the security infrastructure that so far has provided the greatest defense against Internet crime - SSL. Judged by any rational set of standards SSL has been the most successful security protocol of all time. The costs of the PKI infrastructure are negligible compared to the value of the commerce it supports. In practice SSL is primarily used to establish an encrypted channel between endpoints, not to establish reliable reciprocal identification. Given that almost no users pay any attention to certificates, what reason do we have to believe that SSL succeeds because of PKI, rather than in spite of it? By what rational set of standards do you evaluate PKI -- how frequently it is used, or how much fraud it actually prevents? -- ?!ng ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: [OpenID] Opened IPR Policy Draft
The problem is not the people who contribute, it's the ones who never join the group or agree to any license because they never intend to make or sell anything. Align with the standards bodies, that way we have the option of going to a standards body later. I have been through the pain here... The concern I have is that we don't end up in the situation that caused one of my standards groups I was trying to form to implode during formation. I want to standardize the legal part of the process. Mozilla is not a good model, there are ideological commitments there which are not widely appreciated and in certain quarters distinctly unappreciated. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Nicol Sent: Tuesday, December 12, 2006 2:02 PM To: James A. Donald Cc: specs@openid.net; Martin Atkins; Gavin Baumanis; [EMAIL PROTECTED] Subject: Re: [OpenID] Opened IPR Policy Draft On 12/12/06, James A. Donald [EMAIL PROTECTED] wrote: Changes and enhancements to the openID standard are patentable. When the standard was originally proposed, it was far from clear that it would be widely adopted, so it is unlikely that anyone patented it in time, so the original standard is safe from IP. What a headache. Let's get whoever makes the best reference implementation to release it MPL. Mozilla PL has viral patent grant language in it while explicitly allowing MPLd code to be included in Larger Projects. (not sure about the viral nature of the patent grant language; if we want a viral patent grant we might have to create the OIDPL or something) -- perl -le'1while(1x++$_)=~/^(11+)\1+$/||print' ___ 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] Opened IPR Policy Draft
Don't worry about the patent trolls there is only one way to stop them and that is not to have any money worth stealing. There are probably snots already reading the list archive so they can claim to have invented stuff. Someone claimed to have invented one IETF standard five years after the group started. Fortunately the USPTO is slightly more selective these days and the publication period gives us a chance to try a new tactic: lets file a writ for perjury on the alleged inventors. Probably won't go anywhere but given the history its worth a try. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Nicol Sent: Monday, December 11, 2006 3:04 PM To: Gavin Baumanis Cc: specs@openid.net; Martin Atkins; [EMAIL PROTECTED]; James A. Donald Subject: Re: [OpenID] Opened IPR Policy Draft but the openID standard is more than a year old already. On 12/10/06, Gavin Baumanis [EMAIL PROTECTED] wrote: So the technology is first proposed and described on this list, on 2006 December 7, 2006. It is incorporated into the standard and comes to be widely used around about, say, 2007 August. On 2007 December 5, 2007, the patent troll has a friendly individual inventor file an p! atent application claiming to have invented the technology on 2007, december 6. ___ 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] Opened IPR Policy Draft
Not a good model. Before the Web the number of patent trolls was much smaller and they were less vicious. HTTP was designed at CERN which explicitly released all the IPR into the public domain. Even then there have been many issues and many cases with disgraceful outcomes. Plenty of my own work was stolen. -Original Message- From: Chris Messina [mailto:[EMAIL PROTECTED] Sent: Monday, December 11, 2006 9:51 PM To: Hallam-Baker, Phillip Cc: David Nicol; Gavin Baumanis; Martin Atkins; specs@openid.net; [EMAIL PROTECTED] Subject: Re: [OpenID] Opened IPR Policy Draft Excuse my ignorance, but what's the IPR that governs protocols like IMAP and HTTP? Would we be able to take a similar tack with OpenID? Chris On 12/11/06, Hallam-Baker, Phillip [EMAIL PROTECTED] wrote: Don't worry about the patent trolls there is only one way to stop them and that is not to have any money worth stealing. There are probably snots already reading the list archive so they can claim to have invented stuff. Someone claimed to have invented one IETF standard five years after the group started. Fortunately the USPTO is slightly more selective these days and the publication period gives us a chance to try a new tactic: lets file a writ for perjury on the alleged inventors. Probably won't go anywhere but given the history its worth a try. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Nicol Sent: Monday, December 11, 2006 3:04 PM To: Gavin Baumanis Cc: specs@openid.net; Martin Atkins; [EMAIL PROTECTED]; James A. Donald Subject: Re: [OpenID] Opened IPR Policy Draft but the openID standard is more than a year old already. On 12/10/06, Gavin Baumanis [EMAIL PROTECTED] wrote: So the technology is first proposed and described on this list, on 2006 December 7, 2006. It is incorporated into the standard and comes to be widely used around about, say, 2007 August. On 2007 December 5, 2007, the patent troll has a friendly individual inventor file an p! atent application claiming to have invented the technology on 2007, december 6. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ general mailing list [EMAIL PROTECTED] http://openid.net/mailman/listinfo/general -- Chris Messina Citizen Provocateur Open Source Ambassador-at-Large Work: http://citizenagency.com Blog: http://factoryjoe.com/blog Cell: 412 225-1051 Skype: factoryjoe This email is: [ ] bloggable[X] ask first [ ] private ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: OpenID IPR Policy Draft
Why not just take the W3C IPR policy verbatim and change the organization name? The W3C patent policy is I believe released under creative commons for precisely this reason if not this can easily happen. The agreement was subscribed to by all the major vendors and the major open source groups. Unless someone wants to incorporate proprietary technology that they are not willing to release the rights to as required by the W3C terms this is a debate we don't need to have. Ideally the Apache, Mozilla, OASIS, W3C and IETF IPR WGs would get together and devise an industry standard acceptable to both Open Source and proprietary vendors. The introduction of suspense licenses means that it is not unthinkable that they would reach a common set of terms. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Gabe Wachob Sent: Thursday, December 07, 2006 1:01 PM To: 'Brett McDowell'; Recordon, David Cc: specs@openid.net; [EMAIL PROTECTED] Subject: RE: OpenID IPR Policy Draft Brett- We need to get consensus on what the community wants before we take this to an attorney.. However, I've done these sorts of IPR policies for standards efforts several times and I can tell you that the process of working through these IPR policies is slow, painful and expensive. I think presenting an already baked (ie already drafted by lawyers) IPR policy to this community and asking for a up/down vote is not in keeping with the spirit of this development process. -Gabe From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brett McDowell Sent: Thursday, December 07, 2006 6:48 AM To: Recordon, David Cc: specs@openid.net; [EMAIL PROTECTED] Subject: Re: OpenID IPR Policy Draft This is normally lawyer work. I recommend the companies individuals invested in OpenID immediately turn this exercise over to your legal counsel to ensure your interests--and the interests of the community--are protected appropriately. Does the new OpenID organization have legal counsel retained (I don't mean volunteers, but actually hired)? If not, that would be my second recommendation. --Brett On 12/6/06, Recordon, David [EMAIL PROTECTED] wrote: Hey guys, Been working with Gabe, and others, on starting to draft an IPR Policy for OpenID specifications. We'd appreciate feedback in terms of if what is written captures the correct intent of the community? We realize the language isn't technically as tight as it needs to be, though first want to make sure it is saying the right thing. It is largely based on the IPR Policy for Microformats. http://openid.net/wiki/index.php/IPR_Policy Thanks, --David ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs -- Brett McDowell +1.413.662.2744 ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
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
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. The scheme I would propose would incorporate a policy lookup so that it is possible to overide this mapping. The mapping to http is fine as a last resort but making it the first resort means we cannot ever change it. What I would suggest is that we resolve [EMAIL PROTECTED] as follows 1) Perform a DNS lookup for a TXT record at _openid.example.com if found perform policy processing 2) map the uri to http://example.com/user, do OpenID Policy processing: The TXT record consists of a sequence of tag=value pairs that list the authentication protocols that are supported. This allows the relying party to choose the most appropriate protocol for its needs. For example: SAML=saml.example.com SAMLLite=saml.outsourced.com OPENID This says that the identity provider supports three different authentication protocols, SAML, a reduced SAML and OPENID. -Original Message- From: David Fuelling [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 08, 2006 1:56 PM To: Hallam-Baker, Phillip Cc: specs@openid.net; [EMAIL PROTECTED] Subject: 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
RE: XRDS vs. DNS level identity (was RE: [PROPOSAL] Handle http://[EMAIL PROTECTED] Style Identifiers)
Quite a few years went into the design of DNS. The concern I have here is that to influence the wider network is a very serious challenge. Innovation in naming is the single hardest thing to do in a network protocol. I have seen UDDI, Realnames, X.500, so many proposals. When someone tells me a simple thing is too complex and then proposes to do the single hardest, most complex thing in computer networking I have concerns. -Original Message- From: Drummond Reed [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 08, 2006 7:42 PM To: Hallam-Baker, Phillip; Recordon, David; 'David Fuelling' Cc: specs@openid.net; [EMAIL PROTECTED] Subject: XRDS vs. DNS level identity (was RE: [PROPOSAL] Handle http://[EMAIL PROTECTED] Style Identifiers) Phillip, Please don't shoot me -- I am just the messenger -- but a year-long effort (Yadis) went into the design and deployment of XRDS documents as the discovery infrastructure for OpenID. There are numerous reasons for this, but they boil down to this: the XRDS layer of identity is rooted at a higher layer than that of DNS. Users don't just have DNS names in OpenID; they have URLs or XRIs. Those URLs or XRIs resolve to XRDS documents, which perform mapping of URLs/XRIs to URI-identified service endpoints. These service endpoint URIs in turn map down to services resolvable at the DNS layer (which then of course map down to machine addresses at the IP layer). I fully understand that you have seen so many attempts to reinvent it (the DNS). OpenID and URL/XRI-based identity is not an attempt to reinvent it. It is the emergence of identity infrastructure at a higher layer designed to take advantage of the abstractions available at that layer, including: * URI and XRI syntax (much richer than DNS) * HTTP and HTTPS protocols for discovery * Extensible, XML-encoded resource description metadata * Mapping of reassignable and persistent identifiers for persistent identity * Discovery of typed service endpoints I know you know my personal bias (anyone who would push the XRI boulder this long uphill has got to have a few screws loose), but at this point it seems like trying to push the XRDS layer back down into DNS would be like trying to put the genie back in the bottle. =Drummond -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Hallam-Baker, Phillip Sent: Wednesday, November 08, 2006 3:01 PM To: Recordon, David; David Fuelling Cc: specs@openid.net; [EMAIL PROTECTED] Subject: RE: [PROPOSAL] Handle http://[EMAIL PROTECTED] Style Identifiers You can make things complex in two ways, one is by adding too many curlicues to a design, another is by refusing to use the deployed infrastructure for its intended purpose. The signaling and discovery infrastructure of the Internet is the DNS. I have seen so many attempts to reinvent it. -Original Message- From: Recordon, David Sent: Wednesday, November 08, 2006 4:50 PM To: Hallam-Baker, Phillip; David Fuelling Cc: specs@openid.net; [EMAIL PROTECTED] Subject: RE: [PROPOSAL] Handle http://[EMAIL PROTECTED] Style Identifiers Involving DNS seems to make this too complex. If we're going to involve DNS, we might as well re-architect Yadis to use it as yet another discovery option. --David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Hallam-Baker, Phillip Sent: Wednesday, November 08, 2006 1: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. The scheme I would propose would incorporate a policy lookup so that it is possible to overide this mapping. The mapping to http is fine as a last resort but making it the first resort means we cannot ever change it. What I would suggest is that we resolve [EMAIL PROTECTED] as follows 1) Perform a DNS lookup for a TXT record at _openid.example.com if found perform policy processing 2) map the uri to http://example.com/user, do OpenID Policy processing: The TXT record consists of a sequence of tag=value pairs that list the authentication protocols that are supported. This allows the relying party to choose the most appropriate protocol for its needs. For example: SAML=saml.example.com SAMLLite=saml.outsourced.com OPENID This says
RE: XRDS vs. DNS level identity (was RE: [PROPOSAL] Handle http://[EMAIL PROTECTED] Style Identifiers)
What you are calling discovery is what I would term location. URL - Uniform Resource Locator The locator is completely self contained, no discovery necessary, all the information you need to resolve is there. -Original Message- From: Dick Hardt [mailto:[EMAIL PROTECTED] Sent: Thursday, November 09, 2006 2:05 AM To: Johannes Ernst Cc: Hallam-Baker, Phillip; specs@openid.net; general Subject: Re: XRDS vs. DNS level identity (was RE: [PROPOSAL] Handle http://[EMAIL PROTECTED] Style Identifiers) I agree with Johannes here. DNS is not user accessible (for good reason) Documents on a web server are relatively more accessible. wrt. DNS, I think DNSSEC could have a significant role in providing server to server discovery, specifically of key key material. -- Dick On 8-Nov-06, at 8:00 PM, Johannes Ernst wrote: Just commenting on the XRDS discovery from HTTP URLs bit. Using DNS as a mechanism, given a URL, to discover the location of, or obtain the content or equivalent of, the XRDS file, was proposed back then in Yadis 0.x days, and rejected. The reason being that any such mechanism would require the system administrator in charge of the DNS system to configure XRDS for any and all users in that domain. It would give that system administrator an effective veto (exercised by being lazy, for example) over whether or not users could use OpenID on that domain, and in particular which services to reference from that file (e.g. competitive services). There was general consensus that for a user-centric identity system, that was not desirable, and that's why we decided in favor of the HTTP header extension, its HTML equivalent, and the shortcut via the MIME type. We felt on safe ground with respect to naming design, because it's very much the same approach as, say, the reference of embedded GIFs or CSS in HTML, or the use of URLs to identify DTDs in XML. On Nov 8, 2006, at 17:19, Hallam-Baker, Phillip wrote: Quite a few years went into the design of DNS. The concern I have here is that to influence the wider network is a very serious challenge. Innovation in naming is the single hardest thing to do in a network protocol. I have seen UDDI, Realnames, X.500, so many proposals. When someone tells me a simple thing is too complex and then proposes to do the single hardest, most complex thing in computer networking I have concerns. -Original Message- From: Drummond Reed [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 08, 2006 7:42 PM To: Hallam-Baker, Phillip; Recordon, David; 'David Fuelling' Cc: specs@openid.net; [EMAIL PROTECTED] Subject: XRDS vs. DNS level identity (was RE: [PROPOSAL] Handle http://[EMAIL PROTECTED] Style Identifiers) Phillip, Please don't shoot me -- I am just the messenger -- but a year-long effort (Yadis) went into the design and deployment of XRDS documents as the discovery infrastructure for OpenID. There are numerous reasons for this, but they boil down to this: the XRDS layer of identity is rooted at a higher layer than that of DNS. Users don't just have DNS names in OpenID; they have URLs or XRIs. Those URLs or XRIs resolve to XRDS documents, which perform mapping of URLs/XRIs to URI-identified service endpoints. These service endpoint URIs in turn map down to services resolvable at the DNS layer (which then of course map down to machine addresses at the IP layer). I fully understand that you have seen so many attempts to reinvent it (the DNS). OpenID and URL/XRI-based identity is not an attempt to reinvent it. It is the emergence of identity infrastructure at a higher layer designed to take advantage of the abstractions available at that layer, including: * URI and XRI syntax (much richer than DNS) * HTTP and HTTPS protocols for discovery * Extensible, XML-encoded resource description metadata * Mapping of reassignable and persistent identifiers for persistent identity * Discovery of typed service endpoints I know you know my personal bias (anyone who would push the XRI boulder this long uphill has got to have a few screws loose), but at this point it seems like trying to push the XRDS layer back down into DNS would be like trying to put the genie back in the bottle. =Drummond -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Hallam-Baker, Phillip Sent: Wednesday, November 08, 2006 3:01 PM To: Recordon, David; David Fuelling Cc: specs@openid.net; [EMAIL PROTECTED] Subject: RE: [PROPOSAL] Handle http://[EMAIL PROTECTED] Style Identifiers You can make things complex in two ways, one is by adding too many curlicues to a design, another is by refusing to use the deployed infrastructure for its intended purpose. The signaling and discovery
RE: Making identities persistent?
If we want identities to be persistent then we are going to need to introduce a layer of indirection. This normally gets me worried about patents and such. Fortunately Multics did this, so did UNIX and VMS. Plenty of prior art. If we are serious about decentralization then map the user identifier onto a randomly assigned machine readable GUID. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Stefan Görling Sent: Wednesday, November 01, 2006 10:52 AM To: Shutra Zhou Cc: specs@openid.net Subject: Re: Making identities persistent? The reasons for raising this question was partly that I've been doing some research on how people use e-mail addresses and sad to say, you can not expect the user to make wise choices. And even so, companies go broke even the best ones. Services comes and disappear. In my research over half of the population use non-portable e-mail addresses tied to an employer, university, etc. and is likely to only live a few years. E-mail is not a stable address/identity identifier. We must not rely on it as such. If we want an identity to be persistent, it must contain a migration feature, so that I can move all their trust relations from one place to another. This of course creates a number of other issues such as security and complexibility, but it is my sincere belief that the issue should be addressed by the system and not only delegated to be dependent on wise user decisions. Therefore, my +1 is on (1) below. I will try to read back on what has been said in the past on a 'change identifier' extension and see if there is anything I can do to help. /Stefan Yes, this is important thing I thought. We should privide a spec for the consumer to change their end user's OpenID URL, optionally the end user can use multiple OpenIDs in this consuemr. And this case can be expended as this, the IdP（OpenID Server） is closed down. 2006/10/31, George Fletcher [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]: This is a good use case and I think important for both users and IdPs (now OPs [OpenID Provider] per the latest editor's conference) to consider. I see a number of options... 1. There has been some discussion regarding a change identifier extension that would allow you to change your identifier at the relying party. This would solve the use case and is necessary regardless of the other options. 2. The OP (in this case AOL.com) could continue to provide an identifier management page that would allow the user to specify the OP of choice. This requires the OP to continue to serve the XRDS doc or at least the indirection to a XRDS doc with the new OP. This is not that much extra overhead for the OP, but it will likely be a business decision as to whether to support such a feature. 3. The user gets to choose their OP so they can ensure that they don't get locked in. This is the ideal behind user-centric. However, in practice, it will take good education and time for users to understand the ramifications of their decisions. Thanks, George Stefan Görling wrote: Hi everybody, I'm trying to get a grip around your great work and have one issue that I'm not quite clear on, relevant to the discussion of using [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] identifiers, but also in a more general context. Please let me know if I've simply missunderstood my own question. http://openid.net/specs/openid-authentication-2_0-09.html#an chor48 says: OpenID is decentralized. No central authority must approve or register Relying Parties or Identity Providers. An End User can freely choose which Identity Provider to use. They can preserve their Identifier if they switch Identity Providers. Let us consider the case that I'm an AOL.com customer, and they act as an IdP providing we with an identifier. I use this identifier for 3 years for identity management on most of the services I use, due to the huge success of the standard... However, I'm starting to get fed up with AOL and terminates my agreement with them. Is there any procedure for me to switch to another IdP? How is this done? Best Regards, Stefan Görling ___ specs mailing list specs@openid.net mailto:specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net mailto: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
RE: Making identities persistent?
I'm afraid I still don't get it. As far as I am concerned the authenticated identifier is the tuple: (Identity-provider-Id, Identifier) If we want to have a single identifier there has to be a mechanism for establishing the scope of authority for each IdP over a specific subset of identifiers. There are only two potential mechanisms I can see for achieving this: 1) A lexigraphical convention 2) A signalling registry -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Pete Rowley Sent: Wednesday, November 01, 2006 1:53 PM To: Rowan Kerr Cc: specs@openid.net Subject: Re: Making identities persistent? Rowan Kerr wrote: On Wed, 2006-11-01 at 11:33 -0500, John Kemp wrote: I think you need the ability for a user to change his identifier at the RP (as George notes below) and also at the IdP. Isn't this was already covered in the spec? You accomplish this by creating an HTML page on some website you control with a http-equiv meta tag in it that points to your IdP. Then you use your own url as your Identity, even though ultimately the data is pulled from the IdP. So if you ever want to change IdP's you simply update your html page with the new server. And your Identifier never needs to change. Except that the spec specifies that it is the derived identifier of the IdP that is used at the RP - which means a delegated identifier actually isn't used as an identifier. That is not quite the same thing. -- Pete ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: [PROPOSAL] Handle http://[EMAIL PROTECTED] Style Identifiers
No, that is the work-arroundThe solution is to have theemail client assign fonts according to who is writing. Messages from Lord Rees-Mogg are written in an elegant Edwardian Copperplate. Paris Hilton uses BroadwayComments from Dick come in this font Sounds right to me. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Dick Hardt Sent: Sunday, October 22, 2006 5:00 PM To: Kaliya Hamlin Cc: specs@openid.net Subject: Re: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style Identifiers On 22-Oct-06, at 12:43 PM, Kaliya Hamlin 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 Kaliya: The easy solution is to have your email program turn all responses to plain text. :-) ___ 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
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: Delegation discussion summary
Title: RE: Delegation discussion summary There is an established vocabulary, it should be used. Sent from my GoodLink Wireless Handheld (www.good.com) -Original Message- From: Recordon, David [mailto:[EMAIL PROTECTED]] Sent: Thursday, October 12, 2006 09:04 PM Pacific Standard Time To: Gabe Wachob; Graves, Michael; specs@openid.net Subject: RE: Delegation discussion summary I'd have to agree with Gabe about this, let's get it done! :) -Original Message- From: Gabe Wachob [mailto:[EMAIL PROTECTED]] Sent: Thursday, October 12, 2006 05:43 PM Pacific Standard Time To: Graves, Michael; specs@openid.net Subject: RE: Delegation discussion summary *If* we are going to open up the terminology discussion, for me the terms authenticating party (formerly the IDP) and accepting party (formerly the relying party) seem more descriptive. The authenticating party issues authentication assertions in the form of special HTTP request/responses with the other party, who then accepts these assertions and decides whether or not they are good enough to let a user do something. As far as Dick's terminology, I'm not sure how membersite makes sense here. Perhaps it's a matter of history or perspective that I haven't been enlightened on. In any case, I'd rather get openid 2.0 out sooner than have a long discussion on terminology, so I won't push this any further unless someone else really thinks its valuable. Gabe -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Graves, Michael Sent: Thursday, October 12, 2006 5:00 PM To: specs@openid.net Subject: RE: Delegation discussion summary Josh, et al, I believe the first of your options -- Both portable and IdP-specific identifiers -- is the superior choice here. It preserves OpenID 1 semantics, and unambiguously makes room for portable identifiers. I don't see the added burden carried by relying party code for this option viz. portable identifiers only as being significant. Recommend we proceed with the both strategy. Also, this may be throwing a wrench in the gears here, but I'd like to toss in the idea of using this point in time to pivot on our terminology and look at adopting Dick Hardt's terminology here. Portable identifiers are a powerful upgrade in and of themselves, and get us off the IDP lock-in hook that I've been hung up with customers on now a couple times. But as we move away from explicit IdP-specific URLs as the only identifier, I think that the Sxip homesite model becomes more important to consider as well. I very much like the idea of entiring in my homesite URL at a participating membersite (OpenID relying party), say http://myidmanager.com and during the authentication process, being able to choose from one of n available personae managed for me by myidmanager.com. So my final identifier may be http://myidmanager.com/73648729 or even http://graves.isnuts.com. I won't delve into where we are with respect to that capability here, but want to suggest that maybe as we move to OpenID 2.0, and now offer portable IDs (as well as run-time chosen IDs selected at auth-time?), we may be wise to just make the jump to using homesite and membersite across the board, rather than IdP and relying party, both of which are technically problematic for our framework. Anyway, that's a bit off topic, but something to consider. In any case, the both option below gets my vote. Good work Josh! -Mike -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Josh Hoyt Sent: Thursday, October 12, 2006 12:29 PM To: specs@openid.net Subject: Delegation discussion summary Hello, list, I'm sure that another message in your inbox with delegation in the title makes most of you cringe, so I'm sorry for that.I hope that this one gets us closer to resolving this issue. I have attempted to summarize the proposed delegation mechanisms, as well as the currently-specified delegation mechanism in a single document. I have glossed over some issues and left out some of the discussion, but I hope that I captured most of the important stuff. After reviewing the discussion, I think that we are actually pretty close to consensus on a course of action. I have added one new thing in this write-up, which is that I have started calling delegation portable identifier support, which gives rise to the term portable identifier for what is currently called a delegated identifier. I think that this terminology is a little easier to understand and less loaded than calling it delegation. My write-up follows. Josh OpenID portable identifier support ## Portable identifier support allows an IdP to do authentication for an identifier that was not issued by that IdP. It has two motivating use cases [1]_: * allow users to use any identifier with any IdP * allow users to move an identifier between IdPs (prevent
RE: Identifier portability: the fundamental issue
Title: RE: Identifier portability: the fundamental issue We must have different understandings of the term sacred then. My understanding of the term is that it refers to a tenet of faith which might cause offense if contradicted. Sent from my GoodLink Wireless Handheld (www.good.com) -Original Message- From: Drummond Reed [mailto:[EMAIL PROTECTED]] Sent: Friday, October 13, 2006 12:58 PM Pacific Standard Time To: specs@openid.net Subject: Identifier portability: the fundamental issue Yesterday we established consensus that with OpenID, identifier portability is sacred. Today I'd like to establish consensus on the following postulate: To achieve identifier portability in OpenID, it MUST be possible for the RP and the IdP to identify the user using two different identifiers: an identifier by which the RP knows the user (the portable identifier), and an identifier by which the IdP knows the user (the IdP-specific identifier). I would submit that if this postulate is true, then OpenID Authentication 2.0 requires two identifier parameters because if the protocol only allows sending one, then: 1) If the RP sends the IdP-specific identifier, the RP must keep state to maintain mapping to the portable identifier (bad), and 2) If the RP sends the portable identifier, an IdP is forced to do a resolution a second time after the RP has already done resolution (bad). OTOH, if the postulate is false, then a case can be made for OpenID Authentication 2.0 having just one identifier parameter. PROOF CASE 1: the protocol supports only IdP-specific identifiers and no portable identifiers. RESULT: IdPs can achieve identifier lockin. Not acceptable. End of Case 1. CASE 2: the protocol supports only portable identifiers and no IdP-specific identifiers. RESULT: IdP is forced to know and store all portable identifiers for a user, including identifiers for which the IdP is not authoritative, and users would be forced to register all their portable identifiers with their IdP, and to update these registrations every time the user adds or deletes a portable identifier. Highly undesirable if not impossible. * Please post if you do not agree with this postulate. =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
