RE: [PROPOSAL] Giving Signatures/Assertions Context
The response message today doesn't include an identifier for the IdP/OP, so this would be a new field that would be added to the message. Like I said, in OpenID's case I don't think there is a reason why this anonymity would be desired, though wanted to mention it in the broader discussion. --David -Original Message- From: Dick Hardt [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 07, 2006 4:15 PM To: Recordon, David Cc: specs@openid.net; [EMAIL PROTECTED] Subject: Re: [PROPOSAL] Giving Signatures/Assertions Context On 7-Nov-06, at 3:42 PM, Recordon, David wrote: > So I know I said no more proposals like a month ago, but this one > helps from a security perspective around the signature on the > response. > > Currently the response must have "return_to", "response_nonce" and > then "disco_id" and "identity" if they are present. I'm proposing > that we add to this requirement the following fields: > - assoc_handle > - URI identifier for the IdPs server endpoint ++1 I would not consider this a proposal, this is a bug fix! > > This helps to: > - Make the signature clearly reflect the request > - Gives the assertion/signature context on its own > - Reduces the potential for replaying responses in differing > contexts, though the nonce takes care of this already > > The main benefit is really helping to make the context of the response > more clear so that a response on its own clearly shows the IdP it is > from, the association handle, along with where the user is being sent, > the nonce, and the identifier. > > The one potential point for objection we see is that there are times > when a signer may wish to remain anonymous, but rather leave it to the > recipient to know who they are. I don't see this as a concern within > OpenID as it stands today, though wanted to mention it for > completeness. side note: Would you explain how the signer can be anonymous? The OP URL in the message must match what is found during discovery. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: [PROPOSAL] Giving Signatures/Assertions Context
On 7-Nov-06, at 3:42 PM, Recordon, David wrote: > So I know I said no more proposals like a month ago, but this one > helps > from a security perspective around the signature on the response. > > Currently the response must have "return_to", "response_nonce" and > then > "disco_id" and "identity" if they are present. I'm proposing that we > add to this requirement the following fields: > - assoc_handle > - URI identifier for the IdPs server endpoint ++1 I would not consider this a proposal, this is a bug fix! > > This helps to: > - Make the signature clearly reflect the request > - Gives the assertion/signature context on its own > - Reduces the potential for replaying responses in differing > contexts, > though the nonce takes care of this already > > The main benefit is really helping to make the context of the response > more clear so that a response on its own clearly shows the IdP it is > from, the association handle, along with where the user is being sent, > the nonce, and the identifier. > > The one potential point for objection we see is that there are times > when a signer may wish to remain anonymous, but rather leave it to the > recipient to know who they are. I don't see this as a concern within > OpenID as it stands today, though wanted to mention it for > completeness. side note: Would you explain how the signer can be anonymous? The OP URL in the message must match what is found during discovery. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
[PROPOSAL] Giving Signatures/Assertions Context
So I know I said no more proposals like a month ago, but this one helps from a security perspective around the signature on the response. Currently the response must have "return_to", "response_nonce" and then "disco_id" and "identity" if they are present. I'm proposing that we add to this requirement the following fields: - assoc_handle - URI identifier for the IdPs server endpoint This helps to: - Make the signature clearly reflect the request - Gives the assertion/signature context on its own - Reduces the potential for replaying responses in differing contexts, though the nonce takes care of this already The main benefit is really helping to make the context of the response more clear so that a response on its own clearly shows the IdP it is from, the association handle, along with where the user is being sent, the nonce, and the identifier. The one potential point for objection we see is that there are times when a signer may wish to remain anonymous, but rather leave it to the recipient to know who they are. I don't see this as a concern within OpenID as it stands today, though wanted to mention it for completeness. Thoughts? Objections? --David ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: OpenID Authentication 2.0 Pre-Draft 11 (Take 2)
Thanks! I remember you mentioning that before though I missed it. Revision 93 corrects it. Thanks, --David -Original Message- From: Johannes Berg [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 07, 2006 2:07 PM To: Recordon, David Subject: Re: OpenID Authentication 2.0 Pre-Draft 11 (Take 2) On Tue, 2006-11-07 at 12:31 -0800, Recordon, David wrote: > (codepoint 10, "/n") Maybe I shouldn't even be pointing this out but I think "\n" was intended here? johannes ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: OpenID.net Service Type Namespaces
I get the hostname aspect for another namespace. w3c[1] uses: http://www.w3.org/ns/sss http://www.w3.org//MM/ I have no strong opinion on it though [1] http://www.w3.org/2005/07/13-nsuri On 7-Nov-06, at 12:07 PM, Recordon, David wrote: > Yeah, that is my concern. Much easier to manage the namespace if this > part is separate, then no matter what software is run for openid.net > anytime down the road we won't have issues. > > --David > > -Original Message- > From: Drummond Reed [mailto:[EMAIL PROTECTED] > Sent: Tuesday, November 07, 2006 11:56 AM > To: 'Dick Hardt'; Recordon, David > Cc: specs@openid.net > Subject: RE: OpenID.net Service Type Namespaces > > My understanding is that the concern is with potential conflicts in > the > actual functioning of openid.net. > > Creating a clean DNS namespace for specs at specs.openid.net does seem > like a good solution to me. > > =Drummond > > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Dick Hardt > Sent: Tuesday, November 07, 2006 8:09 AM > To: Recordon, David > Cc: specs@openid.net > Subject: Re: OpenID.net Service Type Namespaces > > What is the concern? The argument for keeping it the current way is > for > consistency. The URL resolution does not need to be trusted does it? > > On 6-Nov-06, at 5:04 PM, Recordon, David wrote: > >> I'm still concerned with using the "openid.net/" namespace. >> Objections >> to using http://specs.openid.net/authentication/2.0/signon? We don't >> need to change this in legacy stuff, just for 2.0 moving forward. >> >> --David >> >> -Original Message- >> From: Dick Hardt [mailto:[EMAIL PROTECTED] >> Sent: Saturday, October 21, 2006 7:34 PM >> To: Granqvist, Hans >> Cc: Recordon, David; specs@openid.net >> Subject: Re: OpenID.net Service Type Namespaces >> >> I am very supportive of an HTTP GET retrieving the specification. >> >> I think there are some issues with putting the date in the URL: >> >> 1) the URL is unknown until the spec is completed. Any >> implementations > >> being done during the specification then have a moving target. The >> URL > >> is embedded in the Yadis document and I can see it causing some >> headaches for people that it is not fixed until the end. >> >> 2) the grouping is by time instead of by specification. If I want to >> see all versions of a specification, it is not obvious >> >> Currently we have: >> http://openid.net/signon/1.0 >> http://openid.net/signon/1.1 >> http://openid.net/server/2.0 >> http://openid.net/signon/2.0 >> http://openid.net/identifier_select/2.0 >> >> Given that the 1.x ones are already there, I would recommend we keep >> using that scheme. >> >> -- Dick >> >> On 20-Oct-06, at 3:39 PM, Granqvist, Hans wrote: >> >>> It has had some voices against it, but how about considering this >>> template (used in for example W3C xmldsig and >>> xmlenc): >>> >>> http://openid.net/[year]/[month]/[project]#[type] >>> >>> Time-dependent (rather than version--dependent) namespaces can >>> evolve > >>> freely and will not be tied down to specific versioning numbers. >>> >>> Example: >>> http://openid.net/2006/10/authentication >>> http://openid.net/2006/10/authentication#signon >>> >>> >>> It's cool if an HTTP GET on these links returns the specification. >>> >>> Once a spec is finalized, the then current year/month becomes that >>> spec's namespace. For example, xmlenc's namespace is >>> http://www.w3.org/2001/04/xmlenc >>> >>> Hans >>> >>> -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Recordon, David Sent: Friday, October 20, 2006 3:09 PM To: specs@openid.net Subject: OpenID.net Service Type Namespaces Right now we have things like http://openid.net/signon/1.1, http://openid.net/sreg/1.0, etc. This doesn't really seem to scale, > populating the main http://openid.net namespace. Could we do something like http://specs.openid.net/authentication/2.0/signon or http://specs.openid.net/authentication/2.0/identifier_select as well as then http://specs.openid.net/sreg/1.0? This would give all the specs their own namespaces, as well as make it so we can do smart redirection from each of these "type" urls to the correct anchor in the individual spec. --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 >>> >>> >> >> >> > > ___ > specs mailing list > specs@openid.net > http://openid.net/mailman/listinfo/specs > > > ___ specs mailing list specs@openid.net http://openid.net/mailma
Re: IdP vs OP (WAS: RE: "Editors" Conference Call)
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
RE: IdP's Advertising Both http and https
Moving this to the list, I really should have started it there in the first place. --David -Original Message- From: Recordon, David Sent: Monday, November 06, 2006 2:06 PM To: 'Dick Hardt'; Josh Hoyt Subject: RE: IdP's Advertising Both http and https Hey Dick, But the security warnings will still exist: - RP redirects me to http on IdP - IdP redirects me to https on IdP for login page (warning) - I interact with IdP for "trust request" via https - I submit HTTPS form - IdP redirects me back to RP via http (warning) Am I missing something here? The only way to remove all of the warnings is adding additional redirects to itself in these steps to remove the warnings. I guess I'm not sure what I think we should do, though don't think this is a simple problem. --David -Original Message- From: Dick Hardt [mailto:[EMAIL PROTECTED] Sent: Saturday, November 04, 2006 6:49 PM To: Recordon, David Cc: Josh Hoyt Subject: Re: IdP's Advertising Both http and https Hi David If the RP is only using HTTP, then then the request and response are in the clear between the RP and user-agent, and using SSL between the user-agent and OP has nominal benefit. In case it was not clear, the OP SHOULD switch to HTTPS for all other transactions between the user- agent and the OP, so user authentication is secure and any other personal data transported while the user is deciding what to do is secure. I think many RPs will only be using HTTP, so this will be a usability issue if they are seeing the browser warning. ... but perhaps I am not clear on what you were thinking you wanted to do? -- Dick On 30-Oct-06, at 4:55 PM, Recordon, David wrote: > So I was writing this one up for the notes and it just doesn't seem to > be sitting well with me as I think about it more: > > - An IdP can already advertise both http and https endpoints in their > Yadis files. A RP should use the same schema when redirecting the > user to the IdP as it uses for its endpoints, though if this is not > possible can decide to not continue the transaction. This is desired > due to browsers showing a security warning when redirecting from https > to http and vice-versa. > > So if the RP is HTTP, I think the security benefits of using SSL for > the request (if the IdP offers a https endpoint) outweigh the fact > that the user will be shown a warning on the response. I guess I have > a hard time making this recommendation when instead I personally would > recommend an IdP not advertise a HTTP endpoint if it has a HTTPS one. > I think the reality is that anyone doing anything but testing with > OpenID really should be using SSL, though certainly also don't believe > that 100% of IdPs and RPs will do so. > > Thoughts? > > --David > > ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
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
RE: OpenID.net Service Type Namespaces
Yeah, that is my concern. Much easier to manage the namespace if this part is separate, then no matter what software is run for openid.net anytime down the road we won't have issues. --David -Original Message- From: Drummond Reed [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 07, 2006 11:56 AM To: 'Dick Hardt'; Recordon, David Cc: specs@openid.net Subject: RE: OpenID.net Service Type Namespaces My understanding is that the concern is with potential conflicts in the actual functioning of openid.net. Creating a clean DNS namespace for specs at specs.openid.net does seem like a good solution to me. =Drummond -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dick Hardt Sent: Tuesday, November 07, 2006 8:09 AM To: Recordon, David Cc: specs@openid.net Subject: Re: OpenID.net Service Type Namespaces What is the concern? The argument for keeping it the current way is for consistency. The URL resolution does not need to be trusted does it? On 6-Nov-06, at 5:04 PM, Recordon, David wrote: > I'm still concerned with using the "openid.net/" namespace. > Objections > to using http://specs.openid.net/authentication/2.0/signon? We don't > need to change this in legacy stuff, just for 2.0 moving forward. > > --David > > -Original Message- > From: Dick Hardt [mailto:[EMAIL PROTECTED] > Sent: Saturday, October 21, 2006 7:34 PM > To: Granqvist, Hans > Cc: Recordon, David; specs@openid.net > Subject: Re: OpenID.net Service Type Namespaces > > I am very supportive of an HTTP GET retrieving the specification. > > I think there are some issues with putting the date in the URL: > > 1) the URL is unknown until the spec is completed. Any implementations > being done during the specification then have a moving target. The URL > is embedded in the Yadis document and I can see it causing some > headaches for people that it is not fixed until the end. > > 2) the grouping is by time instead of by specification. If I want to > see all versions of a specification, it is not obvious > > Currently we have: > http://openid.net/signon/1.0 > http://openid.net/signon/1.1 > http://openid.net/server/2.0 > http://openid.net/signon/2.0 > http://openid.net/identifier_select/2.0 > > Given that the 1.x ones are already there, I would recommend we keep > using that scheme. > > -- Dick > > On 20-Oct-06, at 3:39 PM, Granqvist, Hans wrote: > >> It has had some voices against it, but how about considering this >> template (used in for example W3C xmldsig and >> xmlenc): >> >> http://openid.net/[year]/[month]/[project]#[type] >> >> Time-dependent (rather than version--dependent) namespaces can evolve >> freely and will not be tied down to specific versioning numbers. >> >> Example: >> http://openid.net/2006/10/authentication >> http://openid.net/2006/10/authentication#signon >> >> >> It's cool if an HTTP GET on these links returns the specification. >> >> Once a spec is finalized, the then current year/month becomes that >> spec's namespace. For example, xmlenc's namespace is >> http://www.w3.org/2001/04/xmlenc >> >> Hans >> >> >>> -Original Message- >>> From: [EMAIL PROTECTED] >>> [mailto:[EMAIL PROTECTED] On Behalf Of Recordon, David >>> Sent: Friday, October 20, 2006 3:09 PM >>> To: specs@openid.net >>> Subject: OpenID.net Service Type Namespaces >>> >>> Right now we have things like http://openid.net/signon/1.1, >>> http://openid.net/sreg/1.0, etc. This doesn't really seem to scale, >>> populating the main http://openid.net namespace. >>> >>> Could we do something like >>> http://specs.openid.net/authentication/2.0/signon or >>> http://specs.openid.net/authentication/2.0/identifier_select >>> as well as then http://specs.openid.net/sreg/1.0? >>> >>> This would give all the specs their own namespaces, as well as make >>> it so we can do smart redirection from each of these "type" urls to >>> the correct anchor in the individual spec. >>> >>> --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 >> >> > > > ___ 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: OpenID.net Service Type Namespaces
My understanding is that the concern is with potential conflicts in the actual functioning of openid.net. Creating a clean DNS namespace for specs at specs.openid.net does seem like a good solution to me. =Drummond -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dick Hardt Sent: Tuesday, November 07, 2006 8:09 AM To: Recordon, David Cc: specs@openid.net Subject: Re: OpenID.net Service Type Namespaces What is the concern? The argument for keeping it the current way is for consistency. The URL resolution does not need to be trusted does it? On 6-Nov-06, at 5:04 PM, Recordon, David wrote: > I'm still concerned with using the "openid.net/" namespace. > Objections > to using http://specs.openid.net/authentication/2.0/signon? We don't > need to change this in legacy stuff, just for 2.0 moving forward. > > --David > > -Original Message- > From: Dick Hardt [mailto:[EMAIL PROTECTED] > Sent: Saturday, October 21, 2006 7:34 PM > To: Granqvist, Hans > Cc: Recordon, David; specs@openid.net > Subject: Re: OpenID.net Service Type Namespaces > > I am very supportive of an HTTP GET retrieving the specification. > > I think there are some issues with putting the date in the URL: > > 1) the URL is unknown until the spec is completed. Any implementations > being done during the specification then have a moving target. The URL > is embedded in the Yadis document and I can see it causing some > headaches for people that it is not fixed until the end. > > 2) the grouping is by time instead of by specification. If I want > to see > all versions of a specification, it is not obvious > > Currently we have: > http://openid.net/signon/1.0 > http://openid.net/signon/1.1 > http://openid.net/server/2.0 > http://openid.net/signon/2.0 > http://openid.net/identifier_select/2.0 > > Given that the 1.x ones are already there, I would recommend we keep > using that scheme. > > -- Dick > > On 20-Oct-06, at 3:39 PM, Granqvist, Hans wrote: > >> It has had some voices against it, but how about considering this >> template (used in for example W3C xmldsig and >> xmlenc): >> >> http://openid.net/[year]/[month]/[project]#[type] >> >> Time-dependent (rather than version--dependent) namespaces can evolve >> freely and will not be tied down to specific versioning numbers. >> >> Example: >> http://openid.net/2006/10/authentication >> http://openid.net/2006/10/authentication#signon >> >> >> It's cool if an HTTP GET on these links returns the specification. >> >> Once a spec is finalized, the then current year/month becomes that >> spec's namespace. For example, xmlenc's namespace is >> http://www.w3.org/2001/04/xmlenc >> >> Hans >> >> >>> -Original Message- >>> From: [EMAIL PROTECTED] >>> [mailto:[EMAIL PROTECTED] On Behalf Of Recordon, David >>> Sent: Friday, October 20, 2006 3:09 PM >>> To: specs@openid.net >>> Subject: OpenID.net Service Type Namespaces >>> >>> Right now we have things like http://openid.net/signon/1.1, >>> http://openid.net/sreg/1.0, etc. This doesn't really seem to scale, >>> populating the main http://openid.net namespace. >>> >>> Could we do something like >>> http://specs.openid.net/authentication/2.0/signon or >>> http://specs.openid.net/authentication/2.0/identifier_select >>> as well as then http://specs.openid.net/sreg/1.0? >>> >>> This would give all the specs their own namespaces, as well as make >>> it so we can do smart redirection from each of these "type" urls to >>> the correct anchor in the individual spec. >>> >>> --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 >> >> > > > ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ 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
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
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 nee
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)
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)
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 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
Re: OpenID.net Service Type Namespaces
What is the concern? The argument for keeping it the current way is for consistency. The URL resolution does not need to be trusted does it? On 6-Nov-06, at 5:04 PM, Recordon, David wrote: > I'm still concerned with using the "openid.net/" namespace. > Objections > to using http://specs.openid.net/authentication/2.0/signon? We don't > need to change this in legacy stuff, just for 2.0 moving forward. > > --David > > -Original Message- > From: Dick Hardt [mailto:[EMAIL PROTECTED] > Sent: Saturday, October 21, 2006 7:34 PM > To: Granqvist, Hans > Cc: Recordon, David; specs@openid.net > Subject: Re: OpenID.net Service Type Namespaces > > I am very supportive of an HTTP GET retrieving the specification. > > I think there are some issues with putting the date in the URL: > > 1) the URL is unknown until the spec is completed. Any implementations > being done during the specification then have a moving target. The URL > is embedded in the Yadis document and I can see it causing some > headaches for people that it is not fixed until the end. > > 2) the grouping is by time instead of by specification. If I want > to see > all versions of a specification, it is not obvious > > Currently we have: > http://openid.net/signon/1.0 > http://openid.net/signon/1.1 > http://openid.net/server/2.0 > http://openid.net/signon/2.0 > http://openid.net/identifier_select/2.0 > > Given that the 1.x ones are already there, I would recommend we keep > using that scheme. > > -- Dick > > On 20-Oct-06, at 3:39 PM, Granqvist, Hans wrote: > >> It has had some voices against it, but how about considering this >> template (used in for example W3C xmldsig and >> xmlenc): >> >> http://openid.net/[year]/[month]/[project]#[type] >> >> Time-dependent (rather than version--dependent) namespaces can evolve >> freely and will not be tied down to specific versioning numbers. >> >> Example: >> http://openid.net/2006/10/authentication >> http://openid.net/2006/10/authentication#signon >> >> >> It's cool if an HTTP GET on these links returns the specification. >> >> Once a spec is finalized, the then current year/month becomes that >> spec's namespace. For example, xmlenc's namespace is >> http://www.w3.org/2001/04/xmlenc >> >> Hans >> >> >>> -Original Message- >>> From: [EMAIL PROTECTED] >>> [mailto:[EMAIL PROTECTED] On Behalf Of Recordon, David >>> Sent: Friday, October 20, 2006 3:09 PM >>> To: specs@openid.net >>> Subject: OpenID.net Service Type Namespaces >>> >>> Right now we have things like http://openid.net/signon/1.1, >>> http://openid.net/sreg/1.0, etc. This doesn't really seem to scale, >>> populating the main http://openid.net namespace. >>> >>> Could we do something like >>> http://specs.openid.net/authentication/2.0/signon or >>> http://specs.openid.net/authentication/2.0/identifier_select >>> as well as then http://specs.openid.net/sreg/1.0? >>> >>> This would give all the specs their own namespaces, as well as make >>> it so we can do smart redirection from each of these "type" urls to >>> the correct anchor in the individual spec. >>> >>> --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 >> >> > > > ___ 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: Making return_to Optional
http://openid.net/pipermail/specs/2006-September/63.html On 6-Nov-06, at 8:10 PM, Johannes Ernst wrote: > Is there a use case somewhere you can point me to? > > On Nov 6, 2006, at 20:03, Recordon, David wrote: > >> 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=specifications&path=&compare% >> 5B%5 >> D=%2Fauthentication%2F2.0%2Ftrunk%2Fopenid- >> [EMAIL PROTECTED]&compare >> %5B%5D=%2Fauthentication%2F2.0%2Ftrunk%2Fopenid- >> [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 > > ___ > 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)
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 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. Regards, - John ___ 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 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)
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 dynami
