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: 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 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
Re: IdP vs OP (WAS: RE: Editors Conference Call)
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 of these technologies. Regards, - John =Drummond -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Recordon, David Sent: Monday, November 06, 2006 11:46 AM To: Dick Hardt; John Kemp; Patrick Harding Cc: specs@openid.net Subject: IdP vs OP (WAS: RE: Editors Conference Call) I see both sides of this discussion. I think John is correct that the role of an OP really is not that different than that of SAML's IdP. The difference comes down to the trust model. I certainly think reputation networks will exist which rate OPs, RPs, users, etc and will ultimately be needed for a technologies with promiscuous trust models to thrive in a large scale. I guess reading more of this is making me question if renaming IdP really is the best thing to do in OpenID. I think if anything we all, as a larger community, should be working to bring OpenID and SAML closer together versus driving them further apart. --David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dick Hardt Sent: Wednesday, November 01, 2006 2:20 PM To: John Kemp Cc: specs@openid.net Subject: Re: Editors Conference Call On 1-Nov-06, at 12:28 PM, John Kemp wrote: OK. Just checking. So an IdP/OP can choose whether or not to trust a particular RP, based on some out-of-ban criteria. And an RP can choose whether or not to trust the assertions of a particular IdP/OP? OK good. Technically possible, yes for the RP to decide on an IdP/OP. Currently, there is no verified RP identity, so the IdP/OP cannot make that decision. I have not had a chance to wade into that discussion. I'd highly recommend it when you get the chance. in my queue :) I suspect the latter case will be unlikely, if OpenID is to be successful. And I do not. And that is the big driver why it should be OP instead of IdP. I think what you're trying to say is that OpenID won't depend on static trust relationships (like business contracts) between RPs and IdP/ OPs - is that right? In which case, sure, I get that. But I do think OpenID will depend on there emerging a way of some RP trusting (or not) some IdP (and vice-versa). Whitelists and blacklists seem like a scalable and dynamic way of doing that, and would seem to be a reasonable way of minimizing the presence of rogue IdPs. Don't take my
Re: IdP vs OP (WAS: RE: Editors Conference Call)
On 6-Nov-06, at 11:46 AM, Recordon, David wrote: I see both sides of this discussion. I think John is correct that the role of an OP really is not that different than that of SAML's IdP. The difference comes down to the trust model. I certainly think reputation networks will exist which rate OPs, RPs, users, etc and will ultimately be needed for a technologies with promiscuous trust models to thrive in a large scale. I guess reading more of this is making me question if renaming IdP really is the best thing to do in OpenID. I think if anything we all, as a larger community, should be working to bring OpenID and SAML closer together versus driving them further apart. I don't see this as driving SAML apart from OpenID. I see it as differentiating OpenID as being user-centric vs federated. The IdP has specific meaning in the federated world. A key differentiator with OpenID is that trust is not needed between the OP and the RP. It is implied and perhaps needed in the IdP / RP relationship. -- Dick ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: IdP vs OP (WAS: RE: Editors Conference Call)
On 6-Nov-06, at 10:25 PM, Drummond Reed wrote: Why? It's because in a user-centric identity, the OP is fundamentally NOT (that enough stars for you? ;-) the provider of anyone's identity. It is providing the OpenID protocol service though, correct? Not sure if you are wanting to suggest a different name ... are you? Let me elaborate. In the last 2 months, I've had numerous conversations with SAML proponents asking me, Why is there so much interest in OpenID? It's just reinventing SAML without a lot of the complexity. And each time I admit that, to the best of my knowledge, this is largely true. Just like SMTP was reinventing X.400 and LDAP was reinventing X.500. ;-) Seriously, SAML is a bunch of things: an abstract message specification (SAML 2.0) a collection of bindings of the message specification to various protocols The big difference is: + the simplicity of the message, + a lower bar to entry both from a technical and a trust point of view, and + a complete description system description that can be deployed It is likely that a future OpenID extension/version uses the SAML message format as more complexity is required in the message. -- Dick ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: IdP vs OP (WAS: RE: Editors Conference Call)
On 7-Nov-06, at 7:59 AM, John Kemp wrote: Dick Hardt wrote: On 6-Nov-06, at 11:46 AM, Recordon, David wrote: I see both sides of this discussion. I think John is correct that the role of an OP really is not that different than that of SAML's IdP. The difference comes down to the trust model. I certainly think reputation networks will exist which rate OPs, RPs, users, etc and will ultimately be needed for a technologies with promiscuous trust models to thrive in a large scale. I guess reading more of this is making me question if renaming IdP really is the best thing to do in OpenID. I think if anything we all, as a larger community, should be working to bring OpenID and SAML closer together versus driving them further apart. I don't see this as driving SAML apart from OpenID. I see it as differentiating OpenID as being user-centric vs federated. The IdP has specific meaning in the federated world. A key differentiator with OpenID is that trust is not needed between the OP and the RP. It is implied and perhaps needed in the IdP / RP relationship. I don't believe that trust is a differentiator between SAML specifications and OpenID Authentication specifications. It is AFAICT, in both cases, simply out of scope. I should have been more clear, IdP is a Federation term and implies trust between the IdP and the RP. That is the definition that many people have about an IdP Since trust is NOT required between an OP and an RP in OpenID, a different term helps clarify that important point I would hope that whatever ends up being the actual technical definition of an OpenID Identity Provider (how about OIdP? ;) does not limit that entity to /only/ doing untrusted identity provision. If the entity being an OP is ALSO making trusted statements about the user, ie. the RP does have a trust relationship, then the OP entity has a different role at that time, which needs a different name. Authoritative Party? -- Dick ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: IdP vs OP (WAS: RE: Editors Conference Call)
Dick Hardt wrote: On 7-Nov-06, at 7:59 AM, John Kemp wrote: I don't believe that trust is a differentiator between SAML specifications and OpenID Authentication specifications. It is AFAICT, in both cases, simply out of scope. I should have been more clear, IdP is a Federation term and implies trust between the IdP and the RP. That is the definition that many people have about an IdP Since trust is NOT required between an OP and an RP in OpenID, a different term helps clarify that important point I'll quit repeating myself after this go around, but: It [trust] is AFAICT, in both cases, simply out of scope. Cheers, - John ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: IdP vs OP (WAS: RE: Editors Conference Call)
On 7-Nov-06, at 8:17 AM, John Kemp wrote: Dick Hardt wrote: On 7-Nov-06, at 7:59 AM, John Kemp wrote: I don't believe that trust is a differentiator between SAML specifications and OpenID Authentication specifications. It is AFAICT, in both cases, simply out of scope. I should have been more clear, IdP is a Federation term and implies trust between the IdP and the RP. That is the definition that many people have about an IdP Since trust is NOT required between an OP and an RP in OpenID, a different term helps clarify that important point I'll quit repeating myself after this go around, but: It [trust] is AFAICT, in both cases, simply out of scope. Trust is not out of scope for Federation. I am contrasting OpenID with Federation. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: IdP vs OP (WAS: RE: Editors Conference Call)
Why are the Liberty people so keen to keep the term IdP in OpenID? :-) We are changing the name because people were confusing what role IdP played in OpenID. They presumed it was the same role as in federation where trust was required. -- Dick On 7-Nov-06, at 8:15 AM, Eve L. Maler wrote: 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 of these technologies. Regards, - John =Drummond -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Recordon, David Sent: Monday, November 06, 2006 11:46 AM To: Dick Hardt; John Kemp; Patrick Harding Cc: specs@openid.net Subject: IdP vs OP (WAS: RE: Editors Conference Call) I see both sides of this discussion. I think John is correct that the role of an OP really is not that different than that of SAML's IdP. The difference comes down to the trust model. I certainly think reputation networks will exist which rate OPs, RPs, users, etc and will ultimately be needed for a technologies with promiscuous trust models to thrive in a large scale. I guess reading more of this is making me question if renaming IdP really is the best thing to do in OpenID. I think if anything we all, as a larger community, should be working to bring OpenID and SAML
Re: IdP vs OP (WAS: RE: Editors Conference Call)
Eve L. Maler wrote: 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. I agree. - John ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
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 of these technologies. Regards, - John =Drummond -Original Message- From: [EMAIL
Re: IdP vs OP (WAS: RE: Editors Conference Call)
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. -- Pete smime.p7s Description: S/MIME Cryptographic Signature ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
IdP vs OP (WAS: RE: Editors Conference Call)
I see both sides of this discussion. I think John is correct that the role of an OP really is not that different than that of SAML's IdP. The difference comes down to the trust model. I certainly think reputation networks will exist which rate OPs, RPs, users, etc and will ultimately be needed for a technologies with promiscuous trust models to thrive in a large scale. I guess reading more of this is making me question if renaming IdP really is the best thing to do in OpenID. I think if anything we all, as a larger community, should be working to bring OpenID and SAML closer together versus driving them further apart. --David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dick Hardt Sent: Wednesday, November 01, 2006 2:20 PM To: John Kemp Cc: specs@openid.net Subject: Re: Editors Conference Call On 1-Nov-06, at 12:28 PM, John Kemp wrote: OK. Just checking. So an IdP/OP can choose whether or not to trust a particular RP, based on some out-of-ban criteria. And an RP can choose whether or not to trust the assertions of a particular IdP/OP? OK good. Technically possible, yes for the RP to decide on an IdP/OP. Currently, there is no verified RP identity, so the IdP/OP cannot make that decision. I have not had a chance to wade into that discussion. I'd highly recommend it when you get the chance. in my queue :) I suspect the latter case will be unlikely, if OpenID is to be successful. And I do not. And that is the big driver why it should be OP instead of IdP. I think what you're trying to say is that OpenID won't depend on static trust relationships (like business contracts) between RPs and IdP/ OPs - is that right? In which case, sure, I get that. But I do think OpenID will depend on there emerging a way of some RP trusting (or not) some IdP (and vice-versa). Whitelists and blacklists seem like a scalable and dynamic way of doing that, and would seem to be a reasonable way of minimizing the presence of rogue IdPs. Don't take my word for it though - look at the discussion on [EMAIL PROTECTED] I don't think there should be an OP reputation. I will wade into the security@ list to discuss. asserted data. The OP is not verifying the accuracy of any of the attributes in attribute exchange. A claim by my IdP/OP /might/ be a claim by a third-party, no? And if the IdP/OP makes such a claim on my behalf (and is not under my direct control), won't it at least want to verify that the subject of the claim is also the user whose identifier it asserted in OpenID Authentication? If the OP is making a separate claim about you, then it is not being an OP at that time. Perhaps I am missing your point here though. In OpenID Authentication, there is no trust relationship requirement between the IdP and RP., and the only thing the IdP asserts is a binding between the user and an identifier (OpenID URL or i-name). And on what basis does the OP assert this binding to an RP? Doesn't the OP typically authenticate that binding, or does it simply take the users identifier on blind faith, and assert away? The OP authenticates the user (how the OP authenticates the user is out of scope of the spec). OK - so the user probably maintains an account with the OP, very much like a user would with an IdP? Unless the user runs her own OP. The OP has a mechanism to determine which user it is interacting with. If the user is running her own OP, then there is still an authentication process of some kind such as access to the machine. -- 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 vs OP (WAS: RE: Editors Conference Call)
I want to clear up what I believe are two misconceptions about the proposed terminology change (both in the specs and across all the OpenID educational/marketing materials) from Identity Provider (IdP) to OpenID Provider (OP). (Note that these are my personal views and may not be shared by others on the list -- the are offered to help propel the discussion towards a community consensus.) 1) I don't personally believe there is much difference at all between identity provider (IdP) and OpenID provider (OP) -- certainly not enough to debate. We might even just agree that an OP is what SAML calls an IdP that uses the OpenID protocol for authentication. That's not at all the reason why I support the terminology change. The real reason... 2) ...is that in the context of user-centric identity, I have always felt that the term identity provider -- though I fully understand that it goes back to the start of SAML -- is at least inappropriate and perhaps even downright misleading. Why? It's because in a user-centric identity, the OP is fundamentally NOT (that enough stars for you? ;-) the provider of anyone's identity. This might look like a little thing, but on such little things entire worldviews rest. Let me elaborate. In the last 2 months, I've had numerous conversations with SAML proponents asking me, Why is there so much interest in OpenID? It's just reinventing SAML without a lot of the complexity. And each time I admit that, to the best of my knowledge, this is largely true. 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. 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. 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. 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. =Drummond -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Recordon, David Sent: Monday, November 06, 2006 11:46 AM To: Dick Hardt; John Kemp; Patrick Harding Cc: specs@openid.net Subject: IdP vs OP (WAS: RE: Editors Conference Call) I see both sides of this discussion. I think John is correct that the role of an OP really is not that different than that of SAML's IdP. The difference comes down to the trust model. I certainly think reputation networks will exist which rate OPs, RPs, users, etc and will ultimately be needed for a technologies with promiscuous trust models to thrive in a large scale. I guess reading more of this is making me question if renaming IdP really is the best thing to do in OpenID. I think if anything we all, as a larger community, should be working to bring OpenID and SAML closer together versus driving them further apart. --David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dick Hardt Sent: Wednesday, November 01, 2006 2:20 PM To: John Kemp Cc: specs@openid.net Subject: Re: Editors Conference Call On 1-Nov-06, at 12:28 PM, John Kemp wrote: OK. Just checking. So an IdP/OP can choose whether or not to trust a particular RP, based on some out-of-ban criteria. And an RP can choose whether or not to trust the assertions of a particular IdP/OP? OK good. Technically possible, yes for the RP to decide on an IdP/OP. Currently, there is no verified RP identity, so the IdP/OP cannot make that decision. I have not had a chance to wade into that discussion. I'd highly recommend it when you get the chance. in my queue :) I suspect the latter case will be unlikely, if OpenID is to be successful. And I do not. And that is the big driver why it should be OP instead of IdP. I think what you're trying to say is that OpenID won't depend on static trust relationships (like business contracts) between RPs and IdP/ OPs - is that right? In which case, sure, I get that. But I do think OpenID will depend on there emerging a way of some RP trusting (or not) some
Re: Editors Conference Call
Thanks David! ;-) Patrick, as you point out, Identity Provider is a well understood term in SAML and WS-*. Here is the definition from SAML 2.0 [1] Identity Provider: A kind of service provider that creates, maintains, and manages identity information for principals and provides principal authentication to other service providers within a federation, such as with web browser profiles. Per the definition, Identity Provider implies a federation or trust relationship between the IdP and RP. Additionally, IdPs often provide other assertions about the user. In OpenID Authentication, there is no trust relationship requirement between the IdP and RP, and the only thing the IdP asserts is a binding between the user and an identifier (OpenID URL or i-name). As people familiar with SAML / WS-* review the OpenID Authentication specification, there has been some confusion on exactly what the IdP does in OpenID. To make it clear that an IdP in OpenID is not the same as typical deployments in SAML, we decided to call it the OpenID Provider, which is more precise, and reduces ambiguity. -- Dick [1] http://www.oasis-open.org/committees/download.php/11886/saml- glossary-2.0-os.pdf On 30-Oct-06, at 10:27 PM, Recordon, David wrote: I'll let Dick explain since it was his proposal and I didn't really care about if we changed the name or not. ;) --David From: Patrick Harding [mailto:[EMAIL PROTECTED] Sent: Monday, October 30, 2006 7:47 PM To: Recordon, David; specs@openid.net Subject: RE: Editors Conference Call Dave, Can you please clarify how an OpenID Provider is 'very' different from the role of Identity Provider as defined in SAML or WS-*. Thanks - Patrick Rename Identity Provider to OpenID Provider (IdP - OP) to add clarity to the term since IdP has a very different meaning in the SAML and WS-* worlds -Original Message- From: [EMAIL PROTECTED] on behalf of Recordon, David Sent: Mon 10/30/2006 7:51 PM To: specs@openid.net Subject: Editors Conference Call This morning Dick, Josh, and I got on Skype for 2.5 hours to try and hash through all the remaining proposals. Unfortunately Brad couldn't join us, though I did talk to him about some of this stuff as well beforehand. - Authentication Age will be developed as an extension due to questions around what is the best way for it to work, what features does it need, etc - The field setup_url will be removed from a checkid_immediate response, rather the RP should fallback to a checkid_setup request to complete the transaction. It has been found that in the, albeit few, implementations of checkid_immediate this is the behavior for the setup_url anyway. - Support bare requests by having the field openid.return_to as optional in checkid_* requests. There is a worry of user's not knowing when they'll be redirected back and when they won't, though that will only be worked out by allowing this functionality. - Clarify that the openid.realm parameter should be used to uniquely identifier relying parties - There are some places where it could be clear in step-by-step instructions of what an IdP needs to do in various parts of the protocol, like is done in section 12 for rp's. Sxip will provide pointers to where this clarity can be added. - Rename Identity Provider to OpenID Provider (IdP - OP) to add clarity to the term since IdP has a very different meaning in the SAML and WS-* worlds - The spec won't speak to what a RP should do if it has an identifier like [EMAIL PROTECTED], worried about setting a confusing precedent of allowing this form of identifier for discovery. Users are used to entering, example.com in their URL bar to goto the site, so entering the same to login doesn't seem like to far of a stretch. All of OpenID has a user education challenge and this doesn't seem very different. - Spec will say in essence, RP's SHOULD give the text field a user enters their OpenID Identifier a name attribute with a value of 'openid_identifier', though if a RP wishes to support rich clients it MUST do so. - Dick will be writing a separate document discussing how RPs can advertise services, logos, etc - There cannot be parameters with the same name, make sure spec says this, we think it does. - Josh will be updating his delegation proposal patch to specify two identifiers for all transactions. This will create a consistent paradigm when dealing with delegation or when not. Goal is to have all of these changes made by end of day Wednesday. I doubt I've added enough detail in all places, so feel free to ask for clarifications or wait to comment on the next draft. --David ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Editors Conference Call
Hi Dick, It would be nice to see a clear definition of an OP in order to determine the exact differences between such an entity and an IdP, but, in the absence of such, some questions: Dick Hardt wrote: Thanks David! ;-) Patrick, as you point out, Identity Provider is a well understood term in SAML and WS-*. Here is the definition from SAML 2.0 [1] Identity Provider: A kind of service provider that creates, maintains, and manages identity information for principals and provides principal authentication to other service providers within a federation, such as with web browser profiles. Per the definition, Identity Provider implies a federation or trust relationship between the IdP and RP. And I guess there is no similar concept in OpenID? Like perhaps an RP adds a particular (I hate to use the word) trusted IdP to a whitelist of IdPs from whom it accepts assertions? Or vice-versa? Admittedly, such federations might not be as linked to static business agreements perhaps as in a typical SAML deployment, but it seems they would be necessary unless you base trust on public key-based mechanisms, or decide that you'll accept assertions from no-password.com (to quote from a discussion on [EMAIL PROTECTED]) and anyone else. I suspect the latter case will be unlikely, if OpenID is to be successful. Additionally, IdPs often provide other assertions about the user. This is sometimes called attribute exchange. In OpenID, is it then not possible for an OP to exchange attributes related to a particular OpenID with an RP? There seems to be an attribute exchange specification (http://openid.net/specs/openid-attribute-exchange-1_0-02.html) where it says (for example, in section 2) Fetch retrieves attribute information from an Identity Provider, while store saves or updates attribute information on the Identity Provider.. In OpenID Authentication, there is no trust relationship requirement between the IdP and RP., and the only thing the IdP asserts is a binding between the user and an identifier (OpenID URL or i-name). And on what basis does the OP assert this binding to an RP? Doesn't the OP typically authenticate that binding, or does it simply take the users identifier on blind faith, and assert away? As people familiar with SAML / WS-* review the OpenID Authentication specification, there has been some confusion on exactly what the IdP does in OpenID. To make it clear that an IdP in OpenID is not the same as typical deployments in SAML, we decided to call it the OpenID Provider, which is more precise, and reduces ambiguity. I guess until we see this precise definition, we won't be able to see the precise differences. From what I can tell so far, it seems to me that the differences between an OP and an IdP are not significant. - John -- Dick [1] http://www.oasis-open.org/committees/download.php/11886/saml- glossary-2.0-os.pdf On 30-Oct-06, at 10:27 PM, Recordon, David wrote: I'll let Dick explain since it was his proposal and I didn't really care about if we changed the name or not. ;) --David From: Patrick Harding [mailto:[EMAIL PROTECTED] Sent: Monday, October 30, 2006 7:47 PM To: Recordon, David; specs@openid.net Subject: RE: Editors Conference Call Dave, Can you please clarify how an OpenID Provider is 'very' different from the role of Identity Provider as defined in SAML or WS-*. Thanks - Patrick Rename Identity Provider to OpenID Provider (IdP - OP) to add clarity to the term since IdP has a very different meaning in the SAML and WS-* worlds -Original Message- From: [EMAIL PROTECTED] on behalf of Recordon, David Sent: Mon 10/30/2006 7:51 PM To: specs@openid.net Subject: Editors Conference Call This morning Dick, Josh, and I got on Skype for 2.5 hours to try and hash through all the remaining proposals. Unfortunately Brad couldn't join us, though I did talk to him about some of this stuff as well beforehand. - Authentication Age will be developed as an extension due to questions around what is the best way for it to work, what features does it need, etc - The field setup_url will be removed from a checkid_immediate response, rather the RP should fallback to a checkid_setup request to complete the transaction. It has been found that in the, albeit few, implementations of checkid_immediate this is the behavior for the setup_url anyway. - Support bare requests by having the field openid.return_to as optional in checkid_* requests. There is a worry of user's not knowing when they'll be redirected back and when they won't, though that will only be worked out by allowing this functionality. - Clarify that the openid.realm parameter should be used to uniquely identifier relying parties - There are some places where it could be clear in step-by-step instructions of what an IdP needs to do in various parts of the protocol, like is done in section 12 for rp's. Sxip
Re: Editors Conference Call
Dick Hardt wrote: It would be nice to see a clear definition of an OP in order to determine the exact differences between such an entity and an IdP, but, in the absence of such, some questions: Dick Hardt wrote: Thanks David! ;-) Patrick, as you point out, Identity Provider is a well understood term in SAML and WS-*. Here is the definition from SAML 2.0 [1] Identity Provider: A kind of service provider that creates, maintains, and manages identity information for principals and provides principal authentication to other service providers within a federation, such as with web browser profiles. Per the definition, Identity Provider implies a federation or trust relationship between the IdP and RP. And I guess there is no similar concept in OpenID? Like perhaps an RP adds a particular (I hate to use the word) trusted IdP to a whitelist of IdPs from whom it accepts assertions? Or vice-versa? Is it technically possible? OK. Just checking. So an IdP/OP can choose whether or not to trust a particular RP, based on some out-of-ban criteria. And an RP can choose whether or not to trust the assertions of a particular IdP/OP? OK good. Yes. Just like it is technically possible for SAML to be user-centric. :-) Admittedly, such federations might not be as linked to static business agreements perhaps as in a typical SAML deployment, but it seems they would be necessary unless you base trust on public key-based mechanisms, or decide that you'll accept assertions from no-password.com (to quote from a discussion on [EMAIL PROTECTED]) and anyone else. I have not had a chance to wade into that discussion. I'd highly recommend it when you get the chance. I suspect the latter case will be unlikely, if OpenID is to be successful. And I do not. And that is the big driver why it should be OP instead of IdP. I think what you're trying to say is that OpenID won't depend on static trust relationships (like business contracts) between RPs and IdP/OPs - is that right? In which case, sure, I get that. But I do think OpenID will depend on there emerging a way of some RP trusting (or not) some IdP (and vice-versa). Whitelists and blacklists seem like a scalable and dynamic way of doing that, and would seem to be a reasonable way of minimizing the presence of rogue IdPs. Don't take my word for it though - look at the discussion on [EMAIL PROTECTED] Additionally, IdPs often provide other assertions about the user. This is sometimes called attribute exchange. In OpenID, is it then not possible for an OP to exchange attributes related to a particular OpenID with an RP? There seems to be an attribute exchange specification (http://openid.net/specs/openid-attribute-exchange-1_0-02.html) where it says (for example, in section 2) Fetch retrieves attribute information from an Identity Provider, while store saves or updates attribute information on the Identity Provider.. When I talk about assertions, I mean third party claims, not self asserted data. The OP is not verifying the accuracy of any of the attributes in attribute exchange. A claim by my IdP/OP /might/ be a claim by a third-party, no? And if the IdP/OP makes such a claim on my behalf (and is not under my direct control), won't it at least want to verify that the subject of the claim is also the user whose identifier it asserted in OpenID Authentication? In OpenID Authentication, there is no trust relationship requirement between the IdP and RP., and the only thing the IdP asserts is a binding between the user and an identifier (OpenID URL or i-name). And on what basis does the OP assert this binding to an RP? Doesn't the OP typically authenticate that binding, or does it simply take the users identifier on blind faith, and assert away? The OP authenticates the user (how the OP authenticates the user is out of scope of the spec). OK - so the user probably maintains an account with the OP, very much like a user would with an IdP? Unless the user runs her own OP. As people familiar with SAML / WS-* review the OpenID Authentication specification, there has been some confusion on exactly what the IdP does in OpenID. To make it clear that an IdP in OpenID is not the same as typical deployments in SAML, we decided to call it the OpenID Provider, which is more precise, and reduces ambiguity. I guess until we see this precise definition, we won't be able to see the precise differences. How about: An OpenID Provider acts on behalf of the user in responding to OpenID Authentication requests from a Relying Party. What more do we need in the spec then that? What about: An OpenID Identity Provider acts on behalf of the user in responding to OpenID Authentication requests from a Relying Party.? I guess you might want to add something about such an entity typically authenticating the binding between an OpenID and some subject/principal/user. - John
Editors Conference Call
This morning Dick, Josh, and I got on Skype for 2.5 hours to try and hash through all the remaining proposals. Unfortunately Brad couldn't join us, though I did talk to him about some of this stuff as well beforehand. - Authentication Age will be developed as an extension due to questions around what is the best way for it to work, what features does it need, etc - The field setup_url will be removed from a checkid_immediate response, rather the RP should fallback to a checkid_setup request to complete the transaction. It has been found that in the, albeit few, implementations of checkid_immediate this is the behavior for the setup_url anyway. - Support bare requests by having the field openid.return_to as optional in checkid_* requests. There is a worry of user's not knowing when they'll be redirected back and when they won't, though that will only be worked out by allowing this functionality. - Clarify that the openid.realm parameter should be used to uniquely identifier relying parties - There are some places where it could be clear in step-by-step instructions of what an IdP needs to do in various parts of the protocol, like is done in section 12 for rp's. Sxip will provide pointers to where this clarity can be added. - Rename Identity Provider to OpenID Provider (IdP - OP) to add clarity to the term since IdP has a very different meaning in the SAML and WS-* worlds - The spec won't speak to what a RP should do if it has an identifier like [EMAIL PROTECTED], worried about setting a confusing precedent of allowing this form of identifier for discovery. Users are used to entering, example.com in their URL bar to goto the site, so entering the same to login doesn't seem like to far of a stretch. All of OpenID has a user education challenge and this doesn't seem very different. - Spec will say in essence, RP's SHOULD give the text field a user enters their OpenID Identifier a name attribute with a value of 'openid_identifier', though if a RP wishes to support rich clients it MUST do so. - Dick will be writing a separate document discussing how RPs can advertise services, logos, etc - There cannot be parameters with the same name, make sure spec says this, we think it does. - Josh will be updating his delegation proposal patch to specify two identifiers for all transactions. This will create a consistent paradigm when dealing with delegation or when not. Goal is to have all of these changes made by end of day Wednesday. I doubt I've added enough detail in all places, so feel free to ask for clarifications or wait to comment on the next draft. --David ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
