IdP vs OP (WAS: RE: "Editors"Conference Call))
John, Thanks for the clarification. Eve's mail, clarifying the SAML Glossary definition of "identity provider", helped address some of my concerns. Although I feel that "authentication authority" is the single most accurate term for what an OpenID authentication service provider (currently called either an IdP and proposed to be called an OP) is providing, at this point I'm willing to go with the sentiments of the rest of the list if they prefer to either stick with IdP or switch to OP. =Drummond -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John Kemp Sent: Wednesday, November 08, 2006 6:19 PM Cc: specs@openid.net Subject: 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 s
Re: Map/Normalize Email Address to IdP/OP URL (Was [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style Identifiers)
# I think that all this discussion about email userid is moving us off # track. My original proposal was that the email maps/normalizes to a # URL of an IdP (the userid is ignored/not used). # # So, '[EMAIL PROTECTED]' would be treated as if the User had entered # 'http://any.edu' (the URL of their IdP/OP) into the OpenId login # form. Then why not just enter 'http://any.edu' or 'any.edu' instead? -- Jonathan Daugherty JanRain, Inc. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Went Through it With Brad
1) 9.1 in the openid.ns parameter talks about using this value inregards to compare with a lower version number of the protocol. Lookingat things such as Jabber, it is nearly impossible to deal with versioncomparisons in any sane way. I'm not sure what the best way is toresolve this.In my experience, one should use a human-comprehensible versioning scheme, but software should only do equals/does not equal comparisons; no automatic "guesses" whether or not version 4 of something is the same as version 2, or to what degree. Johannes ErnstNetMesh Inc. http://netmesh.info/jernst ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Map/Normalize Email Address to IdP/OP URL (Was [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style Identifiers)
Hey David, Thanks for your ideas. Some more thoughts below. > -Original Message- > From: David Nicol [mailto:[EMAIL PROTECTED] > Sent: Thursday, November 09, 2006 6:49 PM > To: David Fuelling > Cc: Martin Atkins; specs@openid.net; [EMAIL PROTECTED] > Subject: Re: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style Identifiers > > On 11/9/06, David Nicol <[EMAIL PROTECTED]> wrote: > > http://[EMAIL PROTECTED] (cool addy, btw) certainly > won't get anyone to David Fuelling's home page, now or in any likely > future. > True, http://[EMAIL PROTECTED] won't get anyone to my homepage...but it would get me to my IdP (assuming Google was my IdP, and offered such a scheme). > Ideas: > > (1) define a way to include an e-mail address among the things obtainable > with an OpenID authentication, and a transform to provide a default when > none is declared > I think the OpenID Simple Registration Extension will provide for this (If I understand what you're meaning) http://openid.net/specs/openid-simple-registration-extension-1_0.html > (2a) declare that OpenID does not do e-mail based authentication and never > will > I hope this can get some more debate in some form or fashion. :) > (2b) name some other mechanism for e-mail based authentication and include > it by reference, blessing said method by so doing. > I think that all this discussion about email userid is moving us off track. My original proposal was that the email maps/normalizes to a URL of an IdP (the userid is ignored/not used). So, '[EMAIL PROTECTED]' would be treated as if the User had entered 'http://any.edu' (the URL of their IdP/OP) into the OpenId login form. Once the user agent is redirected to the 'any.edu' IdP, the IdP would be responsible for figuring out which user is trying to login to the IdP (this is already allowed by OpenId since we can enter a homesite/IdP/OP URL into the login form). The OP might authenticate me by biometric (voice, fingerprint, DNA Sample, etc), or some other scheme, making the username portion of my email irrelevant. Just to be clear, I'm **not** advocating that an email get transformed into a URL that includes the userid of the email (although, I'd be open to entertaining the notion). ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: XRDS vs. DNS level identity (was RE: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style Identifiers)
On Nov 8, 2006, at 23:42, Hallam-Baker, Phillip wrote: > 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. Gotta nitpick here, sorry about that: I don't think it does. For example, the URL does not tell me: - what HTTP version the server can speak - what representations of the resource it can return, e.g. MIME types - what HTTP methods it understands (e.g. WebDav) etc.etc. All the stuff that is in the HTTP headers beyond the URLs. One way of looking at XRDS is to add more meta-data to URLs just like certain HTTP fields add more meta-data. Theoretically, one could pack all of that meta-data into HTTP header extensions, but that's ... well, not so good. So the header adds a level of indirection from where that info can be retrieved. There's another problem with using DNS for this: DNS would have a very hard time returning 1000 different XRDS files (or equivalent) from 1000 different URLs hosted on the same server. Just think of identity-related services that the IdP/OP charges for: some users on the host will have bought other packages (e.g. voice auth vs. fob) than others, and thus their XRDS file changes -- and rather quickly, e.g. when they don't pay on time. >> -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 man
RE: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style Identifiers
> -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Martin Atkins > Sent: Thursday, November 09, 2006 5:36 PM > To: [EMAIL PROTECTED] > Subject: Re: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style Identifiers > > Sometimes these things will be character-for-character identical to a > given email address by coincidence, but there's no way to enforce this > nor any guarantee that the user controlling http://[EMAIL PROTECTED]/ is > the same user that controls mailto:[EMAIL PROTECTED] > Can you provide an example (real or otherwise) of such a scenario? Do you really envision any domain owner giving 'http://[EMAIL PROTECTED]' to one person, whilst giving 'mailto:[EMAIL PROTECTED]' to a different user? ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style Identifiers
On Wed, Nov 08, 2006 at 11:16:41PM -0500, David Fuelling wrote: > 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) > 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". This makes a lot of sense to me. What's appealing to me about OpenID is that it's a very easy (user- and admin- friendly) system for ad-hoc federation/assertions. Relying Parties don't need any special out-of-band pre-authentication setup with IdPs. Nor is there a need for new PKI infrastructures -- the PKI behind https suffices. For users, no special client software is needed. Why try to teach users this homesite/unique OpenID identifier "URL" concept when OpenID could use an identifier the user already understands & has, like an email address, for locating the user's IdP? -Peter > > -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 > > 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. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style Identifiers
Hi Martin, This is interesting. I guess your suggestion (see your msg below) deals with a sub-topic of the whole "should email be allowed in the OpenId login form" debate, which is this: "If email is allowed in the OpenId login form, should the mapping/normalization include the email Userid...OR, should OpenId ignore the email address userid, and map/normalize an email address to a specific IdP URL, allowing the IdP more flexibility in determining how to do login"? 1.) I'm not convinced that OpenId specifying a mapping/normalization scheme that maps email addresses to IdP/OP URL's is really so bad. We're already mapping/normalizing www.cnn.com to its correct http scheme equivalent (http://www.cnn.com). 2.) In Mozilla 2.0, if I type [EMAIL PROTECTED] into the URL bar, it normalizes that (behind the scenes) to http://beth:@google.com. Because google.com doesn't require user auth, I'm then redirected to http://google.com, which redirects to http://www.google.com. 3.) The voice-activated OpenId thread on these lists comes to mind - a Userid component of an email address may not be required, nor necessary in many cases if a user is identified on the IdP/OP by his/her voice (for example). I'm curious to hear yours (and everyone else's) thoughts on this. I don't think we want to couple OpenId too tightly (if at all) to an email address -- just provide an easy-to-use bridge between the two. > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Martin Atkins > Sent: Thursday, November 09, 2006 12:05 PM > To: [EMAIL PROTECTED] > Subject: Re: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style Identifiers > > One idea we came up with before was to specify that [EMAIL PROTECTED] > becomes http://[EMAIL PROTECTED]/ and the RP should try sending an > authenticate header for basic auth with base64 of "blah:" (empty password) > > This way it's (kinda) true to the meaning of that portion of the URL > scheme and it allows the IdP to distinguish between different users. > > We'd have to check to make sure that this never conflicts with Basic > auth implementations built into servers/frameworks, of course. > > > ___ > general mailing list > [EMAIL PROTECTED] > http://openid.net/mailman/listinfo/general ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: IdP's Advertising Both http and https
On Wed, 2006-11-08 at 00:42 -0800, Dick Hardt wrote: > > -Original Message- > > From: Recordon, David > > > > 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 If GET is going to be an acceptable method for responses, the spec should be updated. Section 5.2.1. HTTP Redirect states: This method is deprecated as of OpenID Authentication version 2.0 though is still required for implementation to aide in backwards compatibility. Yes/no? -Rowan ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style Identifiers
Phillip, Ok, now I understand what you're saying about "not using Http in this way". However, I'm not advocating doing anything with the username part of an email (this might be where we're missing each other). I'm saying that we just take the + of an email, normalize it per the OpenId spec, and use that Http URL that we get as the URL of our IdP. Let me elaborate. In a previous message, you wrote: > > > There are two issues here: > > > > > > 1) The user presentation of the identifier > > > 2) The machine presentation > > > > > > The two do not need to be the same. www.cnn.com works > > perfectly well > > > as a way to locate CNN. That is a perfectly acceptable user > > > presentation. It is not an acceptable machine presentation and > > > browsers SHOULD NOT accept href="www.cnn.com". If the "user presentation" value is an email (e.g., '[EMAIL PROTECTED]'), then what is wrong with the machine presentation (wrt OpenId) being 'http://example.com'? The OpenId spec is already doing this with URL's in section 8.2 (Normalization). We're mapping/normalizing 'www.cnn.com' to 'http://www.cnn.com', even though www.cnn.com is not (technically) a validly schemed Http url. Why not do the same with email addresses? > -Original Message- > From: Hallam-Baker, Phillip [mailto:[EMAIL PROTECTED] > Sent: Wednesday, November 08, 2006 4:37 PM > To: David Fuelling > Cc: specs@openid.net; [EMAIL PROTECTED] > Subject: RE: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style Identifiers > > Please don't map to Http this way. > > It would be fine to define a fixed mapping from a user identifier to http. > But it has to respect the http scheme design and be crafted to avoid > operability concerns. > > http://example.com/user would be acceptable as meeting the scheme design. > It is absolutely critical to maintain left/right hierarchy. > > The username/password pieces in http were not well thought out and may > have to be eliminated. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style Identifiers
[re-sending in plain-text] 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
