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
Authentication Authority (was RE: IdP vs OP (WAS: RE: "Editors" Conference Call))
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 control >> of the identity ***right down to the identifier*** is very important. >> > > I don't think we need to worry about fitting the SAML glossary > definition of an IdP, but rather we should focus on making an OpenID > glossary definition that makes sense for what OpenID is doing. > >> Whatsmore, I don't think this should or will "drive SAML and OpenID further >> apart". In factit could actually help pave the path to convergence: an OP >> can be defined as being a SAML IdP that provides identifier authentication >> services using the OpenID protocol, which may end out (3.0?) becoming a very >> specific set of SAML capabilities. > > As noted earlier, I think a SAML IdP also provides "identifier > authentication". I don't worry so much about convergence of these > technologies (although that would be nice ;), but more about giving a > converged message to users, developers, and purchasers
