Re: Identifier portability: the fundamental issue

2006-10-17 Thread Dick Hardt

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

2006-10-17 Thread Hans Granqvist
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

2006-10-16 Thread Hans Granqvist
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

2006-10-16 Thread Martin Atkins
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

2006-10-16 Thread Josh Hoyt
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

2006-10-16 Thread Drummond Reed
+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

2006-10-14 Thread Josh Hoyt
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

2006-10-14 Thread Josh Hoyt
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 LINK).  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

2006-10-14 Thread Martin Atkins
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

2006-10-14 Thread Drummond Reed
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 LINK).  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

2006-10-13 Thread Johannes Ernst

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


Re: Identifier portability: the fundamental issue

2006-10-13 Thread Johannes Ernst

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

2006-10-13 Thread Granqvist, Hans
 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

2006-10-13 Thread Brad Fitzpatrick
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/head/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

2006-10-13 Thread Marius Scurtescu

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

2006-10-13 Thread Hallam-Baker, Phillip
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

2006-10-13 Thread Drummond Reed
  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/head/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