Making return_to Optional
From the call last week and the proposal at http://openid.net/pipermail/specs/2006-October/000430.html, return_to is not an optional parameter in the authentication request. The idea being that a RP not sending it signals the IdP to not redirect the user back; rather an extension will be doing something useful. I've checked in this change, though would like it reviewed since I am not completely happy with all the wording. http://openid.net/svn/comp.php?repname=specificationspath=compare%5B%5 [EMAIL PROTECTED]compare [EMAIL PROTECTED]ma nualorder=1 Thanks, --David ___ 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: Making return_to Optional
David, in the message below, I assume you meant to say return_to is NOW an optional parameter... instead of return_to is NOT an optional parameter That's the only way I can make sense of it. Am I right? =Drummond -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Recordon, David Sent: Monday, November 06, 2006 11:10 AM To: specs@openid.net Subject: Making return_to Optional From the call last week and the proposal at http://openid.net/pipermail/specs/2006-October/000430.html, return_to is not an optional parameter in the authentication request. The idea being that a RP not sending it signals the IdP to not redirect the user back; rather an extension will be doing something useful. I've checked in this change, though would like it reviewed since I am not completely happy with all the wording. http://openid.net/svn/comp.php?repname=specificationspath=compare%5B%5 [EMAIL PROTECTED]compare [EMAIL PROTECTED]ma nualorder=1 Thanks, --David ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Making return_to Optional
Yep... -Original Message- From: Drummond Reed [mailto:[EMAIL PROTECTED] Sent: Monday, November 06, 2006 7:54 PM To: Recordon, David; specs@openid.net Subject: RE: Making return_to Optional David, in the message below, I assume you meant to say return_to is NOW an optional parameter... instead of return_to is NOT an optional parameter That's the only way I can make sense of it. Am I right? =Drummond -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Recordon, David Sent: Monday, November 06, 2006 11:10 AM To: specs@openid.net Subject: Making return_to Optional From the call last week and the proposal at http://openid.net/pipermail/specs/2006-October/000430.html, return_to is not an optional parameter in the authentication request. The idea being that a RP not sending it signals the IdP to not redirect the user back; rather an extension will be doing something useful. I've checked in this change, though would like it reviewed since I am not completely happy with all the wording. http://openid.net/svn/comp.php?repname=specificationspath=compare%5B%5 [EMAIL PROTECTED]compare [EMAIL PROTECTED]ma nualorder=1 Thanks, --David ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: 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
