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:
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 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 invol
Went Through it With Brad
So I spent tonight running through the spec with Brad Fitzpatrick. Checked in the changes as revision 97, though mainly wording changes. Few open issues: 1) 9.1 in the openid.ns parameter talks about using this value in regards to compare with a lower version number of the protocol. Looking at things such as Jabber, it is nearly impossible to deal with version comparisons in any sane way. I'm not sure what the best way is to resolve this. 2) 7.3.3 basically deprecates HTML-based discovery, saying that it is a way to know that the IdP is using Auth 1.1. While I know we believe Yadis will be used in most applications, I hypothesize that the simplicity of HTML-based discovery will have it continue to prevail. I thus would propose we remove the sentence saying that this is a way to know that an IdP is running version 1.1. 3) Also in 7.3.3, we describe "" tags for use in HTML-based discovery. The PingBack spec (http://hixie.ch/specs/pingback/pingback#TOC2.2) is more stringent in its requirements than ours. It seems we quote parts of the spec, but it would be good to look at it again in terms of if we can be more verbose. --David ___ 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
Re: XRDS vs. DNS level identity (was RE: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style Identifiers)
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 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]" >>> St
Re: Authentication Authority (was RE: IdP vs OP (WAS: RE: "Editors" Conference Call))
Hi Drummond, If what we're trying to express is merely that an OpenID can provide an authentication assertion, then I agree that "authentication authority" is quite appropriate. I would note that in SAML at least (as I understand it - correct me if I'm wrong Eve!), an authentication authority is not (in that role at least) being requested to actually authenticate the user (ie. to actually perform the authentication at that moment) - the request is only asking whether the authority can make an authentication assertion (ie. it's a query for authentication assertions, rather than an authentication request - which may have already been fulfilled). I don't know if that rather subtle difference is of any interest in OpenID? - John Drummond Reed wrote: > Eve, > > Welcome, and thanks for "delurking" ;-) > > I'm fascinated by your suggestion that the SAML vocabulary includes the term > "authentication authority". I'd vote for the OpenID Authentication 2.0 > specification (and the community at large) to adopt that term in a heartbeat > because: > > a) I've many times thought that "authentication authority" was PRECISELY the > role that the IdP/OP played in OpenID Authentication. > > b) I'm all for consistency with the SAML glossary because I know it was > intended to be specification-neutral and I'm a big supporter of harmonizing > vocabularies in a problem space (that's why we spent so long on the XRI > glossary in the identifier problem space -- see appendix C of > http://www.oasis-open.org/committees/download.php/15377). > > c) It allows us to step around all the semantic issues around whether an > OpenID IdP is really "providing an identity" or not (and also whether OpenID > is using classic "identity federation" or not.) > > =Drummond > > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf > Of Eve L. Maler > Sent: Tuesday, November 07, 2006 8:16 AM > To: specs@openid.net > Subject: Re: IdP vs OP (WAS: RE: "Editors" Conference Call) > > Delurking for the first time on this list: :-) > > Drummond and I are on the same page about many things, but John is > right that SAML is agnostic as to the strength/significance of the > service being provided and so the two cases are much more similar > than different. On balance I prefer "identity provider" because > it's intuitive in an English sense, it's used in several technology > contexts (not just SAML and OpenID), and it avoids a terminological > "branding" that would otherwise seem to suggest a conceptual > divergence that doesn't -- to my mind -- exist. > > (By the way, there's another term SAML defines that seems to fit the > bill of what Drummond is going for here: "authentication authority". > This is not quite synonymous with "identity provider" in > SAML-land, but it's close -- much the way that "relying party" and > "service provider" are often close to the same thing. I'm not > seriously advocating using it -- just noting that the same software > component in an actual deployment can be seen in various lights and > have multiple names (roles!).) > > FWIW, > > Eve > > John Kemp wrote: >> Hi Drummond, >> >> Drummond Reed wrote: >>> So why, indeed, is there so much interest in OpenID? I believe it's > because >>> of the trust model. To the best of my knowledge, it is radically > different >>> than the trust model assumed by the majority of use cases which led to > SAML >>> and the Liberty Alliance specs. As Eve Maler of Sun puts it, OpenID > supports >>> "promiscuous federation" -- RPs and OPs that don't know anything at all >>> about each other. >> At http://www.openidp.org you'll find a promiscuous SAML IdP. >> >> While I agree with you that OpenID has been focused on this use-case, >> with an eye to the use-cases satisfied by SAML, I'd say that SAML has >> been developed with federated use-cases, but also with an eye to >> promiscuity. >> >> But to put it another way, the trust model used with SAML is >> out-of-scope for development of the SSO protocol itself. >> >> Just like it is for OpenID. >> >>> And it doesn't stop there. OpenID also supports OPs that >>> ***have zero control over the user's OpenID identifier***. The OP simply >>> provides a service for authenticating that a user has control of the > OpenID >>> identifier about which the OP is being queried. >> And how does one authenticate that the user has control over an >> identifier? Is it not by having the OpenID IdP having some secret shared >> with the user - maybe a password, say? >> >> A SAML IdP also authenticates that an identifier (issued by the IdP in >> the SAML case) is bound to a particular user. >> >>> This is a big deal. In fact, the closer you get to it, the bigger it is. >>> >>> As a result, even though an OP seems to fit the SAML definition of an IdP > -- >>> and many technical folks will be very comfortable treating the two as >>> synonymous -- getting the semantics right to stress who really is in
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
RE: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style Identifiers
>-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Peter Watkins Sent: Wednesday, November 08, 2006 4:21 PM To: [EMAIL PROTECTED] Cc: specs@openid.net Subject: Re: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style Identifiers > >Recordon, David wrote: >> 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. > >Yes, the TXT proposal seems complex. I prefer Phillip's second >suggestion, but I think something more unique would be advisable, e.g. > >http://openid.example.com/openid/user > >so that organizations can more easily separate the OpenID IdP systems >(hostname openid.MAILDOMAIN, web path /openid/) from any regular >http/https offerings. > >It would be nice (see my 'concerns about each user having a unique >"URL"' thread in the general openid list) if this could handle empty >usernames, e.g. if users could claim an identifier like > @example.com >to identify the IdP but let the IdP determine the user's identifier. Peter, as I mentioned in my reply on the General list, this is how the directed identity feature in OpenID Authentication 2.0 works. That was David's original suggestion as I remember -- have OpenID RPs treat an email address as simply an IdP name and execute the protocol from there. Since the XRI TC is now working on specifying the email form of an XRI (called an MXRI -- mailto XRI), this could work for both ordinary email addresses and MXRI addresses. But that's only if we decide that using an email address as an OpenID identifier makes sense, or if it just adds a new layer of confusion (as others have noted). =Drummond ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
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 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
Re: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style Identifiers
Recordon, David wrote: > 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. Yes, the TXT proposal seems complex. I prefer Phillip's second suggestion, but I think something more unique would be advisable, e.g. http://openid.example.com/openid/user so that organizations can more easily separate the OpenID IdP systems (hostname openid.MAILDOMAIN, web path /openid/) from any regular http/https offerings. It would be nice (see my 'concerns about each user having a unique "URL"' thread in the general openid list) if this could handle empty usernames, e.g. if users could claim an identifier like @example.com to identify the IdP but let the IdP determine the user's identifier. -Peter > -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 > 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. > 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
Re: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style Identifiers
Many sites allow users to register for services using an e-mail address. Often such sites require the user to verify ownership of the e-mail address by sending an e-mail to the just registered address, but not always. When a site allows such a registration they also request the user to create a password. So users can access "service" by providing e-mail/password -- my guess is that many users use the same password as required for their actual e-mail account, but I have no idea how many. People do this all the time. I know of at least one pretty large portal that allows it. If e-mail addresses could be used, sites could lookup the domain using whatever method is described by OpenId, find the OP and let that collect the id/password. If the domain isn't an OP, the site could handle it locally as a registered e-mail address/identity. Rich On 11/8/06 5:06 PM, Dick Hardt wrote the following: 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 On 8-Nov-06, at 10:51 AM, David Fuelling wrote: Dick, It seems like the same problem exists if a user types an IdP URL. If that URL (e.g., example.com) isn't a valid OpenId IdP, then the user will still encounter a problem. Shouldn't the RP show an "educational page" if a Homesite/i-name/OpenId/email doesn't resolve to something that OpenID can use? David Fuelling -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Dick Hardt Sent: Sunday, October 22, 2006 12:26 PM To: John Panzer Cc: Kaliya *; specs@openid.net Subject: Re: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style Identifiers ... If we support email addresses, then the prompt may look something like this: "email | Homesite | i-name | OpenID" Now any user with an email address thinks they can type it into the box and login. This of course is not going to be the case. ___ 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
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 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
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 On 8-Nov-06, at 10:51 AM, David Fuelling wrote: > Dick, > > It seems like the same problem exists if a user types an IdP URL. > If that > URL (e.g., example.com) isn't a valid OpenId IdP, then the user > will still > encounter a problem. > > Shouldn't the RP show an "educational page" if a > Homesite/i-name/OpenId/email doesn't resolve to something that > OpenID can > use? > > David Fuelling > >> -Original Message- >> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] >> On Behalf >> Of Dick Hardt >> Sent: Sunday, October 22, 2006 12:26 PM >> To: John Panzer >> Cc: Kaliya *; specs@openid.net >> Subject: Re: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style >> Identifiers >> >> ... >> >> If we support email addresses, then the prompt may look something >> like this: >> >> "email | Homesite | i-name | OpenID" >> >> Now any user with an email address thinks they can type it into the >> box and login. This of course is not going to be the case. >> > > ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
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 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
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?
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
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
Dick, It seems like the same problem exists if a user types an IdP URL. If that URL (e.g., example.com) isn't a valid OpenId IdP, then the user will still encounter a problem. Shouldn't the RP show an "educational page" if a Homesite/i-name/OpenId/email doesn't resolve to something that OpenID can use? David Fuelling > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf > Of Dick Hardt > Sent: Sunday, October 22, 2006 12:26 PM > To: John Panzer > Cc: Kaliya *; specs@openid.net > Subject: Re: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style Identifiers > > ... > > If we support email addresses, then the prompt may look something > like this: > > "email | Homesite | i-name | OpenID" > > Now any user with an email address thinks they can type it into the > box and login. This of course is not going to be the case. > ___ 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
# 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
I agree. In fact, given that most people don't know what an XRI is, we might say there will be 3.5 times as much confusion. ;) 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)? > -Original Message- > From: Jonathan Daugherty [mailto:[EMAIL PROTECTED] > Sent: Wednesday, November 08, 2006 1:30 PM > To: David Fuelling > Cc: specs@openid.net > Subject: Re: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style Identifiers > > # 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. > > Except that with this new feature, there would be twice as much > confusion. > > And except that an openid works both as a normal URL and as an OpenID, > whereas an email-like-thing may work as an OpenID, but is not always > going to work as an email even though it looks like one. > > So maybe 2.5 times as much confusion. :) > > -- > Jonathan Daugherty > JanRain, Inc. ___ 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
# 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. Except that with this new feature, there would be twice as much confusion. And except that an openid works both as a normal URL and as an OpenID, whereas an email-like-thing may work as an OpenID, but is not always going to work as an email even though it looks like one. So maybe 2.5 times as much confusion. :) -- Jonathan Daugherty JanRain, Inc. ___ 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 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://. 2.) http://www.. The above URL's MUST be resolved by replacing the and 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. 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: IdP vs OP (WAS: RE: "Editors" Conference Call)
Just to be clear, "identity provider" in SAML isn't intended to mean that this system entity is providing an identity to a digital subject -- it means that this system entity is providing identity information (specifically verification/authentication info) to a relying party/service provider. From the SAML glossary (now in HTML...): http://www.oasis-open.org/committees/download.php/21053/saml-glossary-2.0-os.html#Identity Provider http://www.oasis-open.org/committees/download.php/21053/saml-glossary-2.0-os.html#Relying Party Often, but not always, a SAML authentication authority also serves as an attribute authority: http://www.oasis-open.org/committees/download.php/21053/saml-glossary-2.0-os.html#Attribute Authority Eve John Kemp wrote: > Hi Pete, > > We're in agreement - I was just noting that a SAML IdP is asserting the > link between an identifier and a user/subject/principal, which is the > same as OpenID. > > As you say, in SAML, the identifier is often (but doesn't have to be) > created by the IdP. And, as you say, in OpenID, the identifier is often > (but doesn't have to be) created by the user. > > Regards, > > - John > > Pete Rowley wrote: >> John Kemp wrote: >>> Drummond Reed wrote: >>> And it doesn't stop there. OpenID also supports OPs that ***have zero control over the user's OpenID identifier***. The OP simply provides a service for authenticating that a user has control of the OpenID identifier about which the OP is being queried. >>> And how does one authenticate that the user has control over an >>> identifier? Is it not by having the OpenID IdP having some secret shared >>> with the user - maybe a password, say? >>> >>> A SAML IdP also authenticates that an identifier (issued by the IdP in >>> the SAML case) is bound to a particular user. >>> >> "issued by the IdP in the SAML case" is really the point. While an >> identifier /may/ be issued by an OpenID provider (IdP, AA, etc.) that is >> really the users choice, the user chooses their identifier and the user >> chooses who is authorized to provide authentication for the identifier. >> So really the OP, IdP, AA etc. isn't providing an identifier or an >> identity. It is providing an identifier ownership assertion service that >> may or may not be backed up by some form of authentication, and that >> service provider may be changed. >> >> > > ___ > specs mailing list > specs@openid.net > http://openid.net/mailman/listinfo/specs > -- Eve Maler +1 425 947 4522 Technology Director eve.maler @ sun.com CTO Business Alliances groupSun Microsystems, Inc. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: IdP's Advertising Both http and https
that's correct - you can use an auto submit form with GET or use _javascript_ (document.location.replace) or META redirect tag to make the browser do a GET. We are doing this for a very very long time too - mainly the _javascript_ method as it helps in restoring the back button functionality (better UE). - Praveen [EMAIL PROTECTED] wrote: On 7-Nov-06, at 12:34 PM, Recordon, David wrote: Moving this to the list, I really should have started it there in the first place. --David -Original Message- From: Recordon, David Sent: Monday, November 06, 2006 2:06 PM To: 'Dick Hardt'; Josh Hoyt Subject: RE: IdP's Advertising Both http and https Hey Dick, But the security warnings will still exist: - RP redirects me to http on IdP - IdP redirects me to https on IdP for login page (warning) no warning on GET redirects - I interact with IdP for "trust request" via https - I submit HTTPS form - IdP redirects me back to RP via http (warning) not if you do a GET redirect Am I missing something here? redirected POSTs produce a warning, redirected GETs do not I guess I'm not sure what I think we should do, though don't think this is a simple problem. We built this out with our SXIP 2.0 code. Worked fine. No warnings. -- 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
Re: IdP's Advertising Both http and https
On 7-Nov-06, at 12:34 PM, Recordon, David wrote: > Moving this to the list, I really should have started it there in the > first place. > > --David > > -Original Message- > From: Recordon, David > Sent: Monday, November 06, 2006 2:06 PM > To: 'Dick Hardt'; Josh Hoyt > Subject: RE: IdP's Advertising Both http and https > > Hey Dick, > But the security warnings will still exist: > - RP redirects me to http on IdP > - IdP redirects me to https on IdP for login page (warning) no warning on GET redirects > - I interact with IdP for "trust request" via https > - I submit HTTPS form > - IdP redirects me back to RP via http (warning) not if you do a GET redirect > > Am I missing something here? redirected POSTs produce a warning, redirected GETs do not > > I guess I'm not sure what I think we should do, though don't think > this > is a simple problem. We built this out with our SXIP 2.0 code. Worked fine. No warnings. -- Dick ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
