Re: Identifier portability: the fundamental issue
Drummond Reed wrote: > I think you may have me mistaken for somebody else on the list (. . .) Double-blind anonymity in action? ;) -Hans ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Identifier portability: the fundamental issue
On 16-Oct-06, at 12:24 PM, Martin Atkins wrote: > 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. A possible solution is you can use a different IdP when you want to do this activity so there is no link to your primary IdP. -- Dick ___ 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: Identifier portability: the fundamental issue
On 16-Oct-06, at 2:01 PM, Josh Hoyt wrote: > 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 draft 10, the delegate tag in the Yadis document and the RP sending only the delegate id to the IdP > 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.* Right, but many people seem to be under the impression that this delegate tag (or hiding the portable id from the IdP) will give you some security or anonymity. I am not saying that this was the original intent or that this is one of the goals. Marius ___ 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
Re: Identifier portability: the fundamental issue
On 16-Oct-06, at 12:24 PM, Martin Atkins wrote: > 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. 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. Marius ___ 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
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: Identifier portability: the fundamental issue
On 13-Oct-06, at 12:59 PM, Drummond Reed wrote: > Yesterday we established consensus that with OpenID, identifier > portability > is sacred. > > Today I'd like to establish consensus on the following "postulate": > > "To achieve identifier portability in OpenID, it MUST be possible > for the RP > and the IdP to identify the user using two different identifiers: an > identifier by which the RP knows the user (the portable > identifier), and an > identifier by which the IdP knows the user (the IdP-specific > identifier)." No true. The RP knows the IdP is authoritative since there is a reference to the IdP in the document the portable identifier resolves to. How the IdP knows the user owns the portable identifier, and how the user tells the IdP that she wants to use that portable identifier, do not involve the RP, and therefore are out of scope of the protocol, as this is a protocol between the RP and the IdP, not the user and the IdP. -- Dick ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Identifier portability: the fundamental issue
Chris, I totally agree that: a) OpenID Authentication 2.0 should support yours scenario of IdP-initiated login, and b) that this enables a whole range of privacy solutions, many of which can be supported by IdP innovation. If IdP-initiated login were the only use case, then only one identifier would be needed. It's the use cases for RP-initiated login that argue for having a second identifier parameter in the protocol. =Drummond -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Chris Drake Sent: Friday, October 13, 2006 9:19 PM To: specs@openid.net Subject: Re: Identifier portability: the fundamental issue Hi Drummond, DR> CASE 1: the protocol supports only IdP-specific identifiers and no portable DR> identifiers. DR> RESULT: IdPs can achieve identifier lockin. Not acceptable. End of Case 1. Please explain? If I've got an OpenID URL (eg: my vanity domain), I can "transfer" this via DNS (or just update my OpenID ). If I've got an i-name, I can transfer this too. Where's the "lock in" ? I do not believe the RP needs to know the IdP-specific identifier ever (worse: I think it should never be allowed to know it, or even be allowed to see it!). Yes - we need 2 identifiers - but from the point of view of the specs - the OpenID protocol really only needs to deal with one. 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. Can we not adopt my earlier suggestion: just ensure OpenID can permit IdP-initiated logins. This permits every scenario of portability (and privacy) that everyone wants, without us having to continue to debate it ? This really *is* only an hour or two's worth of code: after which, market forces can decide which bells and whistles relating to portability and privacy the IdPs choose to implement - from the OpenID point of view, it's all "just going to work". Kind Regards, Chris Drake, =1id.com Saturday, October 14, 2006, 5:59:23 AM, you wrote: DR> CASE 2: the protocol supports only portable identifiers and no IdP-specific DR> identifiers. DR> RESULT: IdP is forced to know and store all portable identifiers for a user, DR> including identifiers for which the IdP is not authoritative, and users DR> would be forced to register all their portable identifiers with their IdP, DR> and to update these registrations every time the user adds or deletes a DR> portable identifier. Highly undesirable if not impossible. DR> * DR> Please post if you do not agree with this postulate. DR> =Drummond 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 ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Identifier portability: the fundamental issue
Brad Fitzpatrick wrote:
>
> Counter-argument: but OpenID 1.1 does have two parameters: one's just in
> the return_to URL and managed by the client library, arguably in its own
> ugly namespace (not IdP/RP managed, not "openid.", but something else...
> the Perl library uses "oic." or something). So then it's harder to
> document the correct behavior to people ("RPs should verify the mapping
> when you get a signature!") because the parameter names aren't consistent
> between RP clients.
>
Not specifying it gives RPs the freedom to put whatever handle they want
in the return_to, though. If they *are* able to maintain state, they
might have some arg like ?handle=1380a383198bcefd933, which is
completely opaque to everone except the RP.
I'd rather avoid specifying things we don't need to specify, since it
leaves more flexibility for implementors in an area where this
flexibility doesn't do any harm.
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs
Re: Identifier portability: the fundamental issue
On 10/13/06, Chris Drake <[EMAIL PROTECTED]> wrote: > DR> CASE 1: the protocol supports only IdP-specific identifiers and no > portable > DR> identifiers. > > DR> RESULT: IdPs can achieve identifier lockin. Not acceptable. End of Case 1. > > Please explain? If I've got an OpenID URL (eg: my vanity domain), I > can "transfer" this via DNS (or just update my OpenID ). If > I've got an i-name, I can transfer this too. Where's the "lock in" ? This is true assuming that IdPs have uniform support for registering an identifier that it did not issue. OpenID 1 addressed this in its architecture. In OpenID 1, the identifier does not even have to be registered with the IdP. The proposed changes alter this arrangement. In the 2-identifier proposal, the IdP does not need to support registering identifiers, but it can be aware that a third-party identifier is being used. In the one-identifier proposal, the IdP is solely responsible for being aware of the arrangement. I do not think the success of the protocol rides on this decision, but I think it's important to understand, and understand the implications of the choice that is made. In many ways, the spirit of OpenID has been to empower the user above all. OpenID 1's delegation is consistent with that. > I do not believe the RP needs to know the IdP-specific identifier ever > (worse: I think it should never be allowed to know it, or even be > allowed to see it!). Why not? > Yes - we need 2 identifiers - but from the point > of view of the specs - the OpenID protocol really only needs to deal > with one. See above. > 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. Where is power being granted to the RP? It has pretty much none. It *does* have responsibility, but only as much as is necessary to make the protocol work. > Can we not adopt my earlier suggestion: just ensure OpenID can permit > IdP-initiated logins. This permits every scenario of portability (and > privacy) that everyone wants, without us having to continue to debate > it ? Huh? How is IdP-initiated login related to privacy or portability? Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Identifier portability: the fundamental issue
On 10/13/06, Drummond Reed <[EMAIL PROTECTED]> wrote: > >So whether it's in the spec formally or not, I don't really care. But the > >spec MUST contain details on the precautions a RP should take. > > Yup.(Got that, editors?) http://openid.net/specs/openid-authentication-2_0-10.html#anchor38 Josh ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Identifier portability: the fundamental issue
Hi Drummond, DR> CASE 1: the protocol supports only IdP-specific identifiers and no portable DR> identifiers. DR> RESULT: IdPs can achieve identifier lockin. Not acceptable. End of Case 1. Please explain? If I've got an OpenID URL (eg: my vanity domain), I can "transfer" this via DNS (or just update my OpenID ). If I've got an i-name, I can transfer this too. Where's the "lock in" ? I do not believe the RP needs to know the IdP-specific identifier ever (worse: I think it should never be allowed to know it, or even be allowed to see it!). Yes - we need 2 identifiers - but from the point of view of the specs - the OpenID protocol really only needs to deal with one. 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. Can we not adopt my earlier suggestion: just ensure OpenID can permit IdP-initiated logins. This permits every scenario of portability (and privacy) that everyone wants, without us having to continue to debate it ? This really *is* only an hour or two's worth of code: after which, market forces can decide which bells and whistles relating to portability and privacy the IdPs choose to implement - from the OpenID point of view, it's all "just going to work". Kind Regards, Chris Drake, =1id.com Saturday, October 14, 2006, 5:59:23 AM, you wrote: DR> CASE 2: the protocol supports only portable identifiers and no IdP-specific DR> identifiers. DR> RESULT: IdP is forced to know and store all portable identifiers for a user, DR> including identifiers for which the IdP is not authoritative, and users DR> would be forced to register all their portable identifiers with their IdP, DR> and to update these registrations every time the user adds or deletes a DR> portable identifier. Highly undesirable if not impossible. DR> * DR> Please post if you do not agree with this postulate. DR> =Drummond 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: Identifier portability: the fundamental issue
> > Drummond wrote:
>> >
>> > "To achieve identifier portability in OpenID, it MUST be
>> > possible for the RP and the IdP to identify the user using
>> > two different identifiers: an identifier by which the RP
>> > knows the user (the portable identifier), and an identifier
>> > by which the IdP knows the user (the IdP-specific identifier)."
>>
>> Hans wrote:
>>
>> There is no reason why the idp MUST require to know both
>> identifiers for identifier portability to be possible in
>> the system.
>
>Brad wrote:
>
>Existence proof: OpenID 1.1 does identifier portability without two
>identifiers in the spec.
Just to clarify: the "postulate" above did not mean to imply there must be
two different identifiers in the spec/protocol. It was just meant to assert
that the principle of identifier portability (upon which we already have
consensus) requires that it be possible for the RP and IdP to use two
different identifiers.
I was hoping to inch our way towards consensus here by seeing if we had
agreement on this second principle (as some messages have been implying that
IdP-specific identifiers were not needed at all).
>And despite all the "but it can't be stateless without two!" noise, it
>actually can: you put the portable identifier in the return_to URL and
>verify it again when you get the signature back from the IdP. That is,
>verify the mapping from portable -> IdP-specific still holds. Because you
>can't just trust the 1 (or 2) values you get back from the IdP, otherwise
>the IdP (which could be malicious) could be fucking with you, asserting a
>portable identifier which it's not actually permitted to do, according to
>the portable identifer's YADIS//etc.
Good point. I've never figured an attack vector for the RP to send the wrong
identifiers to the IdP, since the RP is just "fooling itself". But I agree
there can be one for a malicious IdP to return the wrong ones to an RP.
>So with 1 or 2, you still need to verify, but that verification doesn't
>have to be painful: you can cache it. "But that's state! omg!" Okay,
>so don't cache it and re-check it. But OpenID's been all about the
>state(caching) vs. roundtrip(slow) for some time, so it's a fair tradeoff.
Agreed.
>Counter-argument: but OpenID 1.1 does have two parameters: one's just in
>the return_to URL and managed by the client library, arguably in its own
>ugly namespace (not IdP/RP managed, not "openid.", but something else...
>the Perl library uses "oic." or something). So then it's harder to
>document the correct behavior to people ("RPs should verify the mapping
>when you get a signature!") because the parameter names aren't consistent
>between RP clients.
Agreed, and you articulated well the reasons for doing it at the spec level.
>So whether it's in the spec formally or not, I don't really care. But the
>spec MUST contain details on the precautions a RP should take.
Yup.(Got that, editors?)
=Drummond
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs
RE: Identifier portability: the fundamental issue
Title: RE: Identifier portability: the fundamental issue We must have different understandings of the term sacred then. My understanding of the term is that it refers to a tenet of faith which might cause offense if contradicted. Sent from my GoodLink Wireless Handheld (www.good.com) -Original Message- From: Drummond Reed [mailto:[EMAIL PROTECTED]] Sent: Friday, October 13, 2006 12:58 PM Pacific Standard Time To: specs@openid.net Subject: Identifier portability: the fundamental issue Yesterday we established consensus that with OpenID, identifier portability is sacred. Today I'd like to establish consensus on the following "postulate": "To achieve identifier portability in OpenID, it MUST be possible for the RP and the IdP to identify the user using two different identifiers: an identifier by which the RP knows the user (the portable identifier), and an identifier by which the IdP knows the user (the IdP-specific identifier)." I would submit that if this postulate is true, then OpenID Authentication 2.0 requires two identifier parameters because if the protocol only allows sending one, then: 1) If the RP sends the IdP-specific identifier, the RP must keep state to maintain mapping to the portable identifier (bad), and 2) If the RP sends the portable identifier, an IdP is forced to do a resolution a second time after the RP has already done resolution (bad). OTOH, if the postulate is false, then a case can be made for OpenID Authentication 2.0 having just one identifier parameter. PROOF CASE 1: the protocol supports only IdP-specific identifiers and no portable identifiers. RESULT: IdPs can achieve identifier lockin. Not acceptable. End of Case 1. CASE 2: the protocol supports only portable identifiers and no IdP-specific identifiers. RESULT: IdP is forced to know and store all portable identifiers for a user, including identifiers for which the IdP is not authoritative, and users would be forced to register all their portable identifiers with their IdP, and to update these registrations every time the user adds or deletes a portable identifier. Highly undesirable if not impossible. * Please post if you do not agree with this postulate. =Drummond ___ 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: Identifier portability: the fundamental issue
On 13-Oct-06, at 12:59 PM, Drummond Reed wrote: > Yesterday we established consensus that with OpenID, identifier > portability > is sacred. > > Today I'd like to establish consensus on the following "postulate": > > "To achieve identifier portability in OpenID, it MUST be possible > for the RP > and the IdP to identify the user using two different identifiers: an > identifier by which the RP knows the user (the portable > identifier), and an > identifier by which the IdP knows the user (the IdP-specific > identifier)." > > I would submit that if this postulate is true, then OpenID > Authentication > 2.0 requires two identifier parameters because if the protocol only > allows > sending one, then: > > 1) If the RP sends the IdP-specific identifier, the RP must keep > state to > maintain mapping to the portable identifier (bad), and I agree with that. > > 2) If the RP sends the portable identifier, an IdP is forced to do a > resolution a second time after the RP has already done resolution > (bad). No, the IdP is not forced to do a resolution. The IdP already knows that. > > OTOH, if the postulate is false, then a case can be made for OpenID > Authentication 2.0 having just one identifier parameter. > > PROOF > > CASE 1: the protocol supports only IdP-specific identifiers and no > portable > identifiers. > > RESULT: IdPs can achieve identifier lockin. Not acceptable. End of > Case 1. Agreed. > > CASE 2: the protocol supports only portable identifiers and no IdP- > specific > identifiers. > > RESULT: IdP is forced to know and store all portable identifiers > for a user, > including identifiers for which the IdP is not authoritative, and > users Why would the IdP need to know identifiers over which it is not authoritative? > would be forced to register all their portable identifiers with > their IdP, > and to update these registrations every time the user adds or > deletes a > portable identifier. Highly undesirable if not impossible. I don't see this as undesirable but as necessary. If I have a portable identifier and I configure it to point to some IdP for authentication it only makes sense for the IdP to know about the identifier as well. Marius ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Identifier portability: the fundamental issue
On Fri, 13 Oct 2006, Granqvist, Hans wrote:
> > "To achieve identifier portability in OpenID, it MUST be
> > possible for the RP and the IdP to identify the user using
> > two different identifiers: an identifier by which the RP
> > knows the user (the portable identifier), and an identifier
> > by which the IdP knows the user (the IdP-specific identifier)."
>
> There is no reason why the idp MUST require to know both
> identifiers for identifier portability to be possible in
> the system.
Existence proof: OpenID 1.1 does identifier portability without two
identifiers in the spec.
And despite all the "but it can't be stateless without two!" noise, it
actually can: you put the portable identifier in the return_to URL and
verify it again when you get the signature back from the IdP. That is,
verify the mapping from portable -> IdP-specific still holds. Because you
can't just trust the 1 (or 2) values you get back from the IdP, otherwise
the IdP (which could be malicious) could be fucking with you, asserting a
portable identifier which it's not actually permitted to do, according to
the portable identifer's YADIS//etc.
So with 1 or 2, you still need to verify, but that verification doesn't
have to be painful: you can cache it. "But that's state! omg!" Okay,
so don't cache it and re-check it. But OpenID's been all about the
state(caching) vs. roundtrip(slow) for some time, so it's a fair tradeoff.
Counter-argument: but OpenID 1.1 does have two parameters: one's just in
the return_to URL and managed by the client library, arguably in its own
ugly namespace (not IdP/RP managed, not "openid.", but something else...
the Perl library uses "oic." or something). So then it's harder to
document the correct behavior to people ("RPs should verify the mapping
when you get a signature!") because the parameter names aren't consistent
between RP clients.
So whether it's in the spec formally or not, I don't really care. But the
spec MUST contain details on the precautions a RP should take.
- Brad
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs
RE: Identifier portability: the fundamental issue
> "To achieve identifier portability in OpenID, it MUST be > possible for the RP and the IdP to identify the user using > two different identifiers: an identifier by which the RP > knows the user (the portable identifier), and an identifier > by which the IdP knows the user (the IdP-specific identifier)." There is no reason why the idp MUST require to know both identifiers for identifier portability to be possible in the system. > I would submit that if this postulate is true, then OpenID > Authentication 2.0 requires two identifier parameters because > if the protocol only allows sending one, then: > > 1) If the RP sends the IdP-specific identifier, the RP must > keep state to maintain mapping to the portable identifier (bad), and Why is it so bad for an RP to be required to maintain such state? (Besides, an RP could advertise whether it is willing to keep that state, and the user would decide what to do.) Keeping such state seems a very slight inconvenience for a much greater goal: true portability of my identifiers. What the idp doesn't know, it cannot take away. > ... ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Identifier portability: the fundamental issue
On Oct 13, 2006, at 12:59, Drummond Reed wrote: 1) If the RP sends the IdP-specific identifier, the RP must keep state to maintain mapping to the portable identifier (bad), and I agree, but I'm not sure that this is a big issue. Won't a simple cookie be sufficient? Johannes Ernst NetMesh Inc. http://netmesh.info/jernst ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Identifier portability: the fundamental issue
On Oct 13, 2006, at 12:59, Drummond Reed wrote: Yesterday we established consensus that with OpenID, identifier portability is sacred. Could somebody please post a succinct definition of "identifier portability" somewhere. If we have a new religion, we might as well agree what it is ;-) Preferably a public web page. Starting a list of "Design principles" comes to mind, I mean "List of sacred cows" or something ;-) Johannes Ernst NetMesh Inc. http://netmesh.info/jernst ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
