Re: Discussion: RP Yadis URL?
Recordon, David wrote: I'm torn if this parameter should be added to the spec at this time or not. Adding the parameter is conceptually simple, though I don't think there is agreement on what the RP should be publishing in their Yadis file. There is the section http://openid.net/specs/openid-authentication-2_0-10.html#anchor42 which has the RP publish a return_to URL, though the section was meant to be removed as that URL may not be the right entry point to start a transaction. I would say that what's inside the Yadis document is outside the scope of OpenID Auth. It's simply a hook to enable extensions that must be instrumented at the RP side. In other words, OpenID auth just needs to specify how to find an RP's Yadis document. The rest is for other people to figure out. That is the point of Yadis, after all. (and then this IdP-initiated login thing could be an extension built upon this ability, and thus not hold up Auth 2.0.) ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Re[2]: [PROPOSAL] request nonce and name
On 10/14/06, Dick Hardt [EMAIL PROTECTED] wrote: Also note that URL parameters are not secured by TLS in HTTPS. -- Dick URL parameters are sent with the path in the GET line of the HTTP request after the TLS handshake, so URL parameters ARE secured. -- Grant Monroe JanRain, Inc. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Identifier portability: the fundamental issue
Chris Drake wrote: There seem to be a lot of people on this list who want to hate and loathe the IdP, and grant all power to the RP. I do not understand this reasoning: our users will select the IdP they trust and like, then they will be using a multitude of possibly hostile RPs thereafter: the reverse is simply not true. My assumption (which I am careful to not proclaim as truth) is that there won't be many IDPs around once the OpenID dust settles. Sure, there will be the run-in-the-basement ones, but for business-critical needs an IDP must spend a lot of money: maintain provable privacy of data, keep uptime, supply enriched services related to stored data, etc. Today's main internet companies can afford to invest in that, and they will also probably compete by adding OpenID access to their existing user base. Furthermore, many RPs will require a user to have an account with one or a few of these mega-IDPs. If there's money at stake, the RP would want to minimize risk. It's all about RP peace of mind. So few small IDPs will survive. Feel free to compare search engines and how a few big companies have all but obliterated the market. Hostile RPs are easy to handle. You just take your business elsewhere. But if an IDP decides to boot you when you're no longer indirectly promoting them using their identity URLs, you could stand to lose quite a lot. Hans ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Summarizing Where We're At
Here are my reactions to what's outstanding: On 10/15/06, Recordon, David [EMAIL PROTECTED] wrote: * Request Nonce and Name - Has been partially implemented, openid.nonce - openid.response_nonce, no agreement on the need of a request nonce specifically, rather discussion has evolved into allowing a RP to pass appdata like in Yahoo's BBAuth. No formal proposal on the table yet, thus will not be included in this version. Take no action * Authentication Age - Re-proposed today adding clarity in motivation, general consensus is needed to add to specification. -1 * Remove setup_url - Little discussion and no general consensus to do so. Rather seems asking for feedback from checkid_immediate implementers on the parameter would be beneficial at this time. +1 * Consolidated Delegation Proposal - Very active discussion, the only proposal I'm willing to stall the spec for. Seems very important a strong conceptual model is created at this time. -0 on status quo (draft 10) +0 on single-identifier +1 on two-identifier * Change Default session_type - Proposed, no discussion yet. Will address in separate message * Bare Request - Proposed, no discussion yet. -0 (YAGNI) Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Identifier portability: the fundamental issue
Chris Drake wrote: There seem to be a lot of people on this list who want to hate and loathe the IdP, and grant all power to the RP. I do not understand this reasoning: our users will select the IdP they trust and like, then they will be using a multitude of possibly hostile RPs thereafter: the reverse is simply not true. If I'm using one IdP to assert my primary public identity, they can hypothetically develop quite a profile about me. I probably don't mind too much in most cases, because I researched them and found that they are a good provider and won't sell my data out to the bad guys. However, there might be some things I want to do (for example, posting locally-prohibited speech on a public forum) that I don't want attached in any way, shape or form to my public identity. The trust relationship I have with that IdP probably isn't enough for this; if there is any record at all of any association between these two identities, as friendly as my IdP may be, there is a chance that it will be ceased by court order, or leaked by an insider, which might lead to me getting in serious legal trouble. This is just one (perhaps extreme) example of why my trust in my IdP is not universal and all-encompassing. Trust is not a boolean. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Identifier portability: the fundamental issue
On 10/16/06, Marius Scurtescu [EMAIL PROTECTED] wrote: In this case you are better off opening a separate account with this or some other IdP. The current delegation model will not protect you at all. The delegate tag is in a publicly accessible Yadis document. I agree that anonymity is an important feature, but the current solution gives you only a false sense of security. What's the current solution that you're talking about? As far as I know, no one is suggesting portable identifiers as a way to achieve anonymity. I also do not think anyone is suggesting that IdP-driven identifier selection will make you anonymous *to the IdP.* You are correct that in order to avoid anyone knowing the identifiers that you use, you have to have separate accounts on different IdPs. I can't come up with any way that the protocol can help (or impede!) the user with achieving this. Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Notes From Draft 10
While I've already incorporated many of the things I found in draft 9 into 10, there were a few things which I didn't either have the right answer to or feel that I could make the change on my own. I tried reading through the draft as if I was reading it for the first time. 4.2 Integer Representations It seems that this section should have some sort of normative reference, though I'm unsure what document should be referenced. 5.1 Direct Communication A new term IdP endpoint URL is introduced, is this something that needs to be defined? 5.1.2 Direct Response The content-type of the response SHOULD be text/plain. Is there a case when the response is valid and it isn't text/plain? 5.1.2.1 A server receiving a properly formed request MUST send a response with an HTTP status code of 200. I trust server is referring to an IdP given the setup in 5.1, it seems this will become clearer along with a definition to IdP endpoint URL. Do we need to say anything more than a properly formed request? Seems like a forward reference may make sense here. 6.1 Signed List Algorithm 1. Iterate through the list of keys to be signed in the order they appear. I spoke with the guys up at JanRain about this Friday in terms of if we'd like to be more explicit in the ordering of the arguments being signed. Right now the algorithm works as in 1.1, where the data is signed per the order in the openid.signed argument. I'm worried that this works more out of convention rather than a conscious decision that this is the right way to do it. While it would change signature generation from 1.1, I'm thinking it would make sense to change this algorithm to first alphabetically sort the arguments to make it very clear in terms of ordering. 7.1 Procedure I added forward references in draft 10, though am wondering if we should expand on each bullet in this overview. 9.1 Initiation Do we wish to recommend a value for the id attribute on the form tag that the RP presents to the EU? We already recommend the field be named openid_identifier, though I'm thinking adding the same sort of recommendation to the form itself will better enable browser extensions. 9.3.2 XRDS-Based Discovery It seems we have no normative, or even non-normative, references to describe the XRDS document. What is the correct OASIS spec to reference? 3.2 Unsuccessful Response Parameters If no association is established, the Relying Party MAY continue the authentication process in stateless mode. It doesn't seem we ever define stateless mode or have a good place in the document to reference here. 11.1 Request Parameters Note: If this is set to the special value http://openid.net/identifier_select/2.0;, the IdP MAY choose an identifier that belongs to the End User. Seems like this could be reworded. 12 Responding to Authentication Requests If the association is missing or expired, the IdP SHOULD send the openid.invalidate_handle parameter of the response to the requests openid.assoc_handle, and SHOULD proceed as if no association handle was specified. Seems like this should be reworded. 13.2.2.2 Response Parameters An IdP MUST NOT verify signatures for associations that have shared MAC keys. Seems like the definition of a shared MAC key should be given at this point. 14 OpenID Authentication 1.1 Compatibility Should this section be combined with A.C Changes from Previous OpenID Authentication Specification. I think keeping them separate is good, 14 speaks to things that affect implementers while A.C speaks to motivations and general changes. Just seems like a forward reference may be useful. Thoughts? 16 Discovering OpenID Authentication Relying Parties I think this section was meant to have been removed in a prior draft.?. In any case, I think removing it now makes sense given the recent discussion of having the RP advertise the location of their XRDS document as a request parameter. Thoughts? --David ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Identifier portability: the fundamental issue
+1. Trust is not a boolean. Martin, that's very quotable. Can I attribute it to you? =Drummond -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Martin Atkins Sent: Monday, October 16, 2006 12:25 PM To: specs@openid.net Subject: Re: Identifier portability: the fundamental issue Chris Drake wrote: There seem to be a lot of people on this list who want to hate and loathe the IdP, and grant all power to the RP. I do not understand this reasoning: our users will select the IdP they trust and like, then they will be using a multitude of possibly hostile RPs thereafter: the reverse is simply not true. If I'm using one IdP to assert my primary public identity, they can hypothetically develop quite a profile about me. I probably don't mind too much in most cases, because I researched them and found that they are a good provider and won't sell my data out to the bad guys. However, there might be some things I want to do (for example, posting locally-prohibited speech on a public forum) that I don't want attached in any way, shape or form to my public identity. The trust relationship I have with that IdP probably isn't enough for this; if there is any record at all of any association between these two identities, as friendly as my IdP may be, there is a chance that it will be ceased by court order, or leaked by an insider, which might lead to me getting in serious legal trouble. This is just one (perhaps extreme) example of why my trust in my IdP is not universal and all-encompassing. Trust is not a boolean. ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Notes From Draft 10
On 16-Oct-06, at 2:44 PM, Josh Hoyt wrote: On 10/16/06, Recordon, David [EMAIL PROTECTED] wrote: 6.1 Signed List Algorithm [...] I'm thinking it would make sense to change this algorithm to first alphabetically sort the arguments to make it very clear in terms of ordering. I think it's a good idea to say that the signed list MUST be generated by the IdP in that order. Then signature *verification* is compatible with OpenID 1's algorithm. Unless there is objection, I'll do this. Sorting of unicode strings while not terrible hard it is not trivial either. Why bother? The list of signed fields gives an explicit ordering, this is good enough IMO. Why would be an alphabetically sorted list better? Marius ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Notes From Draft 10
On 10/16/06, Marius Scurtescu [EMAIL PROTECTED] wrote: Sorting of unicode strings while not terrible hard it is not trivial either. Why bother? The list of signed fields gives an explicit ordering, this is good enough IMO. Sorting by UTF-8-encoded octet sequence is easy. Why would be an alphabetically sorted list better? Just so that there is an obvious one way to do it, so that it's easier to get right, if I understand David's motivation. It's also easier to make clear in the spec. Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Summarizing Where We're At
And here are my votes: Request nonce and name * Take no action Authentication age * -1, write as an extension first Remove setup_url * 0 for removing, +1 for asking feedback from implementers Consolidated Delegation Proposal * -1 on status quo (draft 10) * 0 on single-identifier * +1 on two-identifier Change default session type * +1 Bare request * 0 --David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Josh Hoyt Sent: Monday, October 16, 2006 11:21 AM To: Recordon, David Cc: specs@openid.net Subject: Re: Summarizing Where We're At Here are my reactions to what's outstanding: On 10/15/06, Recordon, David [EMAIL PROTECTED] wrote: * Request Nonce and Name - Has been partially implemented, openid.nonce - openid.response_nonce, no agreement on the need of a request nonce specifically, rather discussion has evolved into allowing a RP to pass appdata like in Yahoo's BBAuth. No formal proposal on the table yet, thus will not be included in this version. Take no action * Authentication Age - Re-proposed today adding clarity in motivation, general consensus is needed to add to specification. -1 * Remove setup_url - Little discussion and no general consensus to do so. Rather seems asking for feedback from checkid_immediate implementers on the parameter would be beneficial at this time. +1 * Consolidated Delegation Proposal - Very active discussion, the only proposal I'm willing to stall the spec for. Seems very important a strong conceptual model is created at this time. -0 on status quo (draft 10) +0 on single-identifier +1 on two-identifier * Change Default session_type - Proposed, no discussion yet. Will address in separate message * Bare Request - Proposed, no discussion yet. -0 (YAGNI) Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Notes From Draft 10
Marius Scurtescu wrote: On 16-Oct-06, at 2:44 PM, Josh Hoyt wrote: On 10/16/06, Recordon, David [EMAIL PROTECTED] wrote: 6.1 Signed List Algorithm [...] I'm thinking it would make sense to change this algorithm to first alphabetically sort the arguments to make it very clear in terms of ordering. I think it's a good idea to say that the signed list MUST be generated by the IdP in that order. Then signature *verification* is compatible with OpenID 1's algorithm. Unless there is objection, I'll do this. Sorting of unicode strings while not terrible hard it is not trivial either. Why bother? The list of signed fields gives an explicit ordering, this is good enough IMO. Why would be an alphabetically sorted list better? I agree. What's the security benefit of forcing the protocol to use a specific order? The signed list has an inherent order that can change should attacks come to light in the future. Why remove that possibility? Hans ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Notes From Draft 10
On 16-Oct-06, at 3:13 PM, Josh Hoyt wrote: On 10/16/06, Marius Scurtescu [EMAIL PROTECTED] wrote: Sorting of unicode strings while not terrible hard it is not trivial either. Why bother? The list of signed fields gives an explicit ordering, this is good enough IMO. Sorting by UTF-8-encoded octet sequence is easy. This is not the same as alphabetical ordering though. It could be the same in most cases, and probably it is for the current set of defined open id parameter names. For alphabetical ordering you have to get into locales and collations. Why would be an alphabetically sorted list better? Just so that there is an obvious one way to do it, so that it's easier to get right, if I understand David's motivation. It's also easier to make clear in the spec. If ordering is not important then you are guaranteed to get it right. The spec could recommend alphabetical ordering, but I don't see the need for a must. Marius ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Summarizing Where We're At
I want to avoid the wait-I-thought-we-decided-something-else or ahh-yes-seems-we-forgot-it-had-an-impact-there delays . . . Spec work gain tremendously by unambiguous up-front definitions of what *exactly* is voted on. A good way to do this is to force the vote to be on an explicit diff against current draft. What ye say? Hans ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Notes From Draft 10
On 10/16/06, Marius Scurtescu [EMAIL PROTECTED] wrote: Just so that there is an obvious one way to do it, so that it's easier to get right, if I understand David's motivation. It's also easier to make clear in the spec. If ordering is not important then you are guaranteed to get it right. But ordering *is* important whether a specific order is prescribed or not. The same ordering has to be used when the signature is generated and when it is checked. The spec could recommend alphabetical ordering, but I don't see the need for a must. If it's not a MUST, then it doesn't clarify or simplify the procedure, because it could still be any order. Again, I don't care very much about making this change. Unless David stands up for it, I'm going to drop it. Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re[2]: Identifier portability: the fundamental issue
Hi Drummond, DR ... if there is any record at all of any association between these DR two identities, ... double-blind anonymous authentication solves this problem. The RP knows nothing more about you besides: A) you're authenticated, and/or B) you've been here before (eg: have signed up for an account) The IdP knows merely C) That you wanted to log in somewhere The RP does not know your ID or even your IdP, and your IdP does not know what site you logged in to. I have a working proof-of-concept that I demonstrated to a few people some months back, let me know if you've not seen it, and I'll send over the URL In a nutshell - this relies on uniform nonce formats and asymmetric cryptography (so the RP and IdP can talk between one another without making any actual contact - the browser and/or user carry the authentication payloads forth and back without referrer URLs or any other info that can link the 2 sites (RP/IdP) together). Besides all that - the normal use case for an IdP in OpenID world (remember: decentralized) will be someone running some open-source code on their own server, so trust in this instance *is* boolean: at least in so far as if there's anything for someone to not be trustworthy about themselves for - it won't be the fault of their IdP code PROVIDING their IdP has provided them with IdP-initiated logins in order to allow this user to protect their own privacy in the first place. Court orders are what I termed 3.5. Authorized exploitation in my threat list, and insider leaks I called 1.3.6. physical attack of server resources (eg: server/hosting-facility compromise) - there's another 98 other threats to keep in mind here as well:- http://chrisdrake.com/Comprehensive_list_of_Threats_to_Authentication_Procedures_and_Data.html While your example might seem extreme, the consequences are also extreme (or fatal, if you live someplace like China) - which is why I take privacy so seriously. Stick Himalayas video into google news if you want to watch what Chinese do to their own people when found trying to visit the Dalai Lama. Now - how comfortable are you with the idea of letting 1.5 billion Chinese people use OpenID without making it easy to help them protect their own privacy ? There's a big picture here, and it's not about meeting some arbitrary deadline or saving a day or two of coding work - it's about producing something that works, and can be deployed ethically. Take a long hard look at that Nun lying dead in the snow, then tell me you still believe there's no need for IdP-initiated privacy protection in OpenID. Kind Regards, Chris Drake, =1id.com Tuesday, October 17, 2006, 7:29:00 AM, you wrote: DR +1. Trust is not a boolean. Martin, that's very quotable. Can I attribute DR it to you? DR =Drummond DR -Original Message- DR From: [EMAIL PROTECTED] DR [mailto:[EMAIL PROTECTED] On Behalf DR Of Martin Atkins DR Sent: Monday, October 16, 2006 12:25 PM DR To: specs@openid.net DR Subject: Re: Identifier portability: the fundamental issue DR Chris Drake wrote: There seem to be a lot of people on this list who want to hate and loathe the IdP, and grant all power to the RP. I do not understand this reasoning: our users will select the IdP they trust and like, then they will be using a multitude of possibly hostile RPs thereafter: the reverse is simply not true. DR If I'm using one IdP to assert my primary public identity, they can DR hypothetically develop quite a profile about me. I probably don't mind DR too much in most cases, because I researched them and found that they DR are a good provider and won't sell my data out to the bad guys. DR However, there might be some things I want to do (for example, posting DR locally-prohibited speech on a public forum) that I don't want attached DR in any way, shape or form to my public identity. The trust relationship DR I have with that IdP probably isn't enough for this; if there is any DR record at all of any association between these two identities, as DR friendly as my IdP may be, there is a chance that it will be ceased by DR court order, or leaked by an insider, which might lead to me getting in DR serious legal trouble. DR This is just one (perhaps extreme) example of why my trust in my IdP is DR not universal and all-encompassing. Trust is not a boolean. DR ___ DR specs mailing list DR specs@openid.net DR http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Summarizing Where We're At
My votes on three issues (0 on everything else): Consolidated Delegation Proposal * -1 on status quo (draft 10) * +1 on two-identifier Change default session type * +1 Bare request * +1 =Drummond -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Recordon, David Sent: Monday, October 16, 2006 3:24 PM To: Josh Hoyt; specs@openid.net Subject: RE: Summarizing Where We're At And here are my votes: Request nonce and name * Take no action Authentication age * -1, write as an extension first Remove setup_url * 0 for removing, +1 for asking feedback from implementers Consolidated Delegation Proposal * -1 on status quo (draft 10) * 0 on single-identifier * +1 on two-identifier Change default session type * +1 Bare request * 0 --David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Josh Hoyt Sent: Monday, October 16, 2006 11:21 AM To: Recordon, David Cc: specs@openid.net Subject: Re: Summarizing Where We're At Here are my reactions to what's outstanding: On 10/15/06, Recordon, David [EMAIL PROTECTED] wrote: * Request Nonce and Name - Has been partially implemented, openid.nonce - openid.response_nonce, no agreement on the need of a request nonce specifically, rather discussion has evolved into allowing a RP to pass appdata like in Yahoo's BBAuth. No formal proposal on the table yet, thus will not be included in this version. Take no action * Authentication Age - Re-proposed today adding clarity in motivation, general consensus is needed to add to specification. -1 * Remove setup_url - Little discussion and no general consensus to do so. Rather seems asking for feedback from checkid_immediate implementers on the parameter would be beneficial at this time. +1 * Consolidated Delegation Proposal - Very active discussion, the only proposal I'm willing to stall the spec for. Seems very important a strong conceptual model is created at this time. -0 on status quo (draft 10) +0 on single-identifier +1 on two-identifier * Change Default session_type - Proposed, no discussion yet. Will address in separate message * Bare Request - Proposed, no discussion yet. -0 (YAGNI) Josh ___ 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: Re[2]: Identifier portability: the fundamental issue
Chris, I think you may have me mistaken for somebody else on the list (DR is also David Recordon). I'm a big fan of IdP-initiated login and privacy protection in OpenID. However as much as I think that's an important use case, there's also many use cases around using a public, omnidirectional identifier. So OpenID should accommodate both. =Drummond -Original Message- From: Chris Drake [mailto:[EMAIL PROTECTED] Sent: Monday, October 16, 2006 8:29 PM To: Drummond Reed Cc: 'Martin Atkins'; specs@openid.net Subject: Re[2]: Identifier portability: the fundamental issue Hi Drummond, DR ... if there is any record at all of any association between these DR two identities, ... double-blind anonymous authentication solves this problem. The RP knows nothing more about you besides: A) you're authenticated, and/or B) you've been here before (eg: have signed up for an account) The IdP knows merely C) That you wanted to log in somewhere The RP does not know your ID or even your IdP, and your IdP does not know what site you logged in to. I have a working proof-of-concept that I demonstrated to a few people some months back, let me know if you've not seen it, and I'll send over the URL In a nutshell - this relies on uniform nonce formats and asymmetric cryptography (so the RP and IdP can talk between one another without making any actual contact - the browser and/or user carry the authentication payloads forth and back without referrer URLs or any other info that can link the 2 sites (RP/IdP) together). Besides all that - the normal use case for an IdP in OpenID world (remember: decentralized) will be someone running some open-source code on their own server, so trust in this instance *is* boolean: at least in so far as if there's anything for someone to not be trustworthy about themselves for - it won't be the fault of their IdP code PROVIDING their IdP has provided them with IdP-initiated logins in order to allow this user to protect their own privacy in the first place. Court orders are what I termed 3.5. Authorized exploitation in my threat list, and insider leaks I called 1.3.6. physical attack of server resources (eg: server/hosting-facility compromise) - there's another 98 other threats to keep in mind here as well:- http://chrisdrake.com/Comprehensive_list_of_Threats_to_Authentication_Proced ures_and_Data.html While your example might seem extreme, the consequences are also extreme (or fatal, if you live someplace like China) - which is why I take privacy so seriously. Stick Himalayas video into google news if you want to watch what Chinese do to their own people when found trying to visit the Dalai Lama. Now - how comfortable are you with the idea of letting 1.5 billion Chinese people use OpenID without making it easy to help them protect their own privacy ? There's a big picture here, and it's not about meeting some arbitrary deadline or saving a day or two of coding work - it's about producing something that works, and can be deployed ethically. Take a long hard look at that Nun lying dead in the snow, then tell me you still believe there's no need for IdP-initiated privacy protection in OpenID. Kind Regards, Chris Drake, =1id.com Tuesday, October 17, 2006, 7:29:00 AM, you wrote: DR +1. Trust is not a boolean. Martin, that's very quotable. Can I attribute DR it to you? DR =Drummond DR -Original Message- DR From: [EMAIL PROTECTED] DR [mailto:[EMAIL PROTECTED] On Behalf DR Of Martin Atkins DR Sent: Monday, October 16, 2006 12:25 PM DR To: specs@openid.net DR Subject: Re: Identifier portability: the fundamental issue DR Chris Drake wrote: There seem to be a lot of people on this list who want to hate and loathe the IdP, and grant all power to the RP. I do not understand this reasoning: our users will select the IdP they trust and like, then they will be using a multitude of possibly hostile RPs thereafter: the reverse is simply not true. DR If I'm using one IdP to assert my primary public identity, they can DR hypothetically develop quite a profile about me. I probably don't mind DR too much in most cases, because I researched them and found that they DR are a good provider and won't sell my data out to the bad guys. DR However, there might be some things I want to do (for example, posting DR locally-prohibited speech on a public forum) that I don't want attached DR in any way, shape or form to my public identity. The trust relationship DR I have with that IdP probably isn't enough for this; if there is any DR record at all of any association between these two identities, as DR friendly as my IdP may be, there is a chance that it will be ceased by DR court order, or leaked by an insider, which might lead to me getting in DR serious legal trouble. DR This is just one (perhaps extreme) example of why my trust in my IdP is DR not universal and all-encompassing. Trust is not a boolean. DR ___ DR specs mailing list
