RE: Delegation discussion summary

2006-10-13 Thread Marius Scurtescu
On Thu, 2006-12-10 at 22:47 -0700, Drummond Reed wrote:
 +1 to Josh's point. IMHO identifier portability is sacred. If anyone
 disagrees, please post, can we assume we have consensus on this?

Yes, portability is sacred.

I was suggesting that portability can be resolved between the user and
the IdP. I cannot see how the protocol can help this by passing two
identifiers. And if only the portable identifier is passed then there is
no need to mention the IdP-specific identifier.

Marius

 
 =Drummond 
 
 -Original Message-
 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
 Of Josh Hoyt
 Sent: Thursday, October 12, 2006 8:56 PM
 To: Marius Scurtescu
 Cc: specs@openid.net
 Subject: Re: Delegation discussion summary
 
 On 10/12/06, Marius Scurtescu [EMAIL PROTECTED] wrote:
  The protocol does not need to touch on IdP-specific identifiers (aka
  delegated identifiers) at all IMO.
 
 If there is a specified mechanism that must be supported for using a
 portable identifier, all IdPs will support it, so identifiers will
 actually be portable. You'd have a very difficult time trying to get
 people here to remove portable identifier support from the OpenID
 protocol.
 
 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: Consolidated Delegate Proposal

2006-10-13 Thread Martin Atkins
Dick Hardt wrote:
 
 Won't the IdP will still have to resolve the i-name? The IdP can't  
 trust the RP, or know that the i-name and i-number are really linked  
 unless it checks itself.
 

The IdP is only authenticating the i-number. The i-name is for display 
to the user and possibly to allow the user to choose that as the display 
identity to send back to the RP. The only attacks possible are:

* RP tries to fool the user into authenticating as a different 
i-number by sending a false i-name. I'm not sure what the benefit of 
this attack would be for the RP.

* The RP tries to convince the IdP to send back an incorrect display 
identity back in the response. But then the RP is just fooling itself!

The spec should probably contain some words to say that the IdP should 
not do any processing on the public identifier (whether it be a 
delegated HTTP URL or an XRI) that relies on the i-name to i-number 
mapping without first ensuring that the mapping is correct; any such 
processing would be outside of what is required for the Auth spec, though.

Assuming for the moment that we've conceptually separated the public 
identifier from the IdP token per my proposal, the public (delegate) 
identifier or i-name is for the RP (it checks the mapping), and the IdP 
token (which is some URI that doesn't necessarily even have to be 
resolvable) is for the IdP. Both parties validate their own token; if 
either party doesn't validate its own token, it opens itself up to the 
other party telling lies. However, they do not have to authenticate 
*each-other*'s tokens.

The RP's validation of its own token is defined by the spec. The IdP's 
authentication is not defined by the spec; the IdP doesn't necessarily 
even have to resolve its own tokens, but it can do if it wishes.

 Lastly, in the case where the identifier-the-RP-stores and the
 identifier-the-IdP-stores are different, if the RP has already  
 discovered
 the latter, then the RP can be stateless by sending both to the  
 IdP, knowing
 it will receive both back in the response.
 
 Then the RP is trusting the IdP will send back a correct mapping.

This one bothers me too. Unless the RP can sign its initial request 
parameters to stop the IdP from tampering with them, I don't see how the 
RP can trust the IdP to return a correct mapping.

My old stateless RP demo implementation just re-resolved this stuff when 
it got back the response to make sure that the IdP was telling the 
truth. I'd love to hear that this was unnecessary, since it did double 
the identity resolving overhead.


 This discussion has me wondering about XRI resolution though. Given  
 that multiple i-names can resolve to the same i-number, just as  
 multiple domain names can resolve to the same IP address, and that  
 the i-name is the identifier the user sees, it would seem tht the i- 
 name is what should be stored by the RP, otherwise there is no  
 difference between using any of the i-names that resolve to the same  
 i-number, or is that the idea?

I think this is the intention, though it does show an interesting 
inconsistency between the use of XRIs and the use of i-numbers. I 
currently have three URL-based identifiers all pointing at the same 
server and the same Yadis document, yet those identifiers are distinct. 
However, in the comparable XRI case, it would appear that those 
identifiers would all be considered to be the same.

I wonder how easy it is to get hold of new i-numbers. If they are 
basically throw-away cheap, then I'm able to decide for myself how to 
distribute my mappings to separate them. However, if these i-numbers are 
going to be expensive (for some sense of the word) to aquire, I've got 
less freedom in this respect. Drummond?



___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs


Re: Delegation discussion summary

2006-10-13 Thread Martin Atkins
Drummond Reed wrote:
 +1 to getting it done. This area of terminology is more a 
 usability/marketing issue at this point. I agree we need to converge on 
 good, simple user-facing terms for describing OpenID in ways ordinary 
 Web users can easily understand. Although I have great respect for Dick 
  Sxip’s pioneering work in this area, I don’t believe terms that use 
 the word “site” are the right metaphor, and the concept of “membersite”, 
 while good for the context Sxip originally used it, would send the wrong 
 message about OpenID.
 
  
 
 But I suggest we move that terminology discussion to the marketing list.
 

What marketing list?

___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs


Re: [PROPOSAL] request nonce and name

2006-10-13 Thread Martin Atkins
Marius Scurtescu wrote:
 On 12-Oct-06, at 5:07 PM, Josh Hoyt wrote:
 
 On 10/12/06, Marius Scurtescu [EMAIL PROTECTED] wrote:
 If passing through all unrecognized parameters can cause problems
 then there could be a special namespace for this purpose. For
 example, all parameters with names starting with openid.pass. should
 be ignored by the IdP and passed back to the RP.
 Yahoo Browser-based authentication [1] has a single parameter called
 appdata (that you can find in [2]) that is used for this purpose.
 This seems general enough to me.
 
 True, even one single pass through parameter should do.

This causes the minor inconvenience that the RP will probably now have 
to implement its own parsing, rather than using the framework's 
pre-supplied functions for dealing with urlencoded query strings.

Not a major deal, but I'd guess that this is where the idea to use 
return_to args came from in the first place.


___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs


Re[2]: [PROPOSAL] request nonce and name

2006-10-13 Thread Chris Drake
Hi All,

Just so everyone remembers:  GET encoded http://; URLs usually
appear en-mass in public lists (from proxy cache logs).  If you don't
want to POST data anyplace, remember to expect replay attacks
often. 

Kind Regards,
Chris Drake


Friday, October 13, 2006, 7:48:31 PM, you wrote:

JH On 10/13/06, Martin Atkins [EMAIL PROTECTED] wrote:
  True, even one single pass through parameter should do.

 This causes the minor inconvenience that the RP will probably now have
 to implement its own parsing, rather than using the framework's
 pre-supplied functions for dealing with urlencoded query strings.

 Not a major deal, but I'd guess that this is where the idea to use
 return_to args came from in the first place.

JH return_to arguments can only be trusted if they are taken from the
JH signed return_to parameter, which means parsing the signed return_to
JH parameter anyway. So it's at least no worse.

JH It's better in that the parameters do not now appear twice in the
JH response (once double-encoded)

JH Example of a response with parameter in the return_to:

JH 
http://a.url/?drink=0xC0FFEE%21openid.return_to=http%3A//a.url/%3Fdrink%3D0xC0FFEE%2521;...

JH Example of a response with hypothetical openid.appdata field:

JH 
http://a.url/?openid.appdata=drink%3D0xC0FFEE%21openid.return_to=http%3A//a.url/;...

JH Josh
JH ___
JH specs mailing list
JH specs@openid.net
JH http://openid.net/mailman/listinfo/specs



___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs


RE: Delegation discussion summary

2006-10-13 Thread Hallam-Baker, Phillip
Title: RE: Delegation discussion summary






There is an established vocabulary, it should be used.

Sent from my GoodLink Wireless Handheld (www.good.com)

-Original Message-
From:  Recordon, David [mailto:[EMAIL PROTECTED]]
Sent: Thursday, October 12, 2006 09:04 PM Pacific Standard Time
To: Gabe Wachob; Graves, Michael; specs@openid.net
Subject: RE: Delegation discussion summary

I'd have to agree with Gabe about this, let's get it done! :)


-Original Message-
From:  Gabe Wachob [mailto:[EMAIL PROTECTED]]
Sent: Thursday, October 12, 2006 05:43 PM Pacific Standard Time
To: Graves, Michael; specs@openid.net
Subject: RE: Delegation discussion summary

*If* we are going to open up the terminology discussion, for me the terms
authenticating party (formerly the IDP) and accepting party (formerly
the relying party) seem more descriptive. The authenticating party issues
authentication assertions in the form of special HTTP request/responses with
the other party, who then accepts these assertions and decides whether or
not they are good enough to let a user do something.

As far as Dick's terminology, I'm not sure how membersite makes sense
here. Perhaps it's a matter of history or perspective that I haven't been
enlightened on.

In any case, I'd rather get openid 2.0 out sooner than have a long
discussion on terminology, so I won't push this any further unless someone
else really thinks its valuable.

 Gabe

 -Original Message-
 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf
 Of Graves, Michael
 Sent: Thursday, October 12, 2006 5:00 PM
 To: specs@openid.net
 Subject: RE: Delegation discussion summary

 Josh, et al,

 I believe the first of your options -- Both portable and IdP-specific
 identifiers -- is the superior choice here. It preserves OpenID 1
 semantics, and unambiguously makes room for portable identifiers. I
 don't see the added burden carried by relying party code for this option
 viz. portable identifiers only as being significant. Recommend we
 proceed with the both strategy.

 Also, this may be throwing a wrench in the gears here, but I'd like to
 toss in the idea of using this point in time to pivot on our terminology
 and look at adopting Dick Hardt's terminology here. Portable identifiers
 are a powerful upgrade in and of themselves, and get us off the IDP
 lock-in hook that I've been hung up with customers on now a couple
 times. But as we move away from explicit IdP-specific URLs as the only
 identifier, I think that the Sxip homesite model becomes more
 important to consider as well. I very much like the idea of entiring in
 my homesite URL at a participating membersite (OpenID relying
 party), say http://myidmanager.com and during the authentication
 process, being able to choose from one of n available personae managed
 for me by myidmanager.com. So my final identifier may be
 http://myidmanager.com/73648729 or even http://graves.isnuts.com.

 I won't delve into where we are with respect to that capability here,
 but want to suggest that maybe as we move to OpenID 2.0, and now offer
 portable IDs (as well as run-time chosen IDs selected at auth-time?), we
 may be wise to just make the jump to using homesite and membersite
 across the board, rather than IdP and relying party, both of which
 are technically problematic for our framework.

 Anyway, that's a bit off topic, but something to consider.

 In any case, the both option below gets my vote.

 Good work Josh!

 -Mike


 -Original Message-
 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On
 Behalf Of Josh Hoyt
 Sent: Thursday, October 12, 2006 12:29 PM
 To: specs@openid.net
 Subject: Delegation discussion summary

 Hello, list,

 I'm sure that another message in your inbox with delegation in the
 title makes most of you cringe, so I'm sorry for that.I hope that this
 one gets us closer to resolving this issue.

 I have attempted to summarize the proposed delegation mechanisms, as
 well as the currently-specified delegation mechanism in a single
 document. I have glossed over some issues and left out some of the
 discussion, but I hope that I captured most of the important stuff.
 After reviewing the discussion, I think that we are actually pretty
 close to consensus on a course of action.

 I have added one new thing in this write-up, which is that I have
 started calling delegation portable identifier support, which gives
 rise to the term portable identifier for what is currently called a
 delegated identifier. I think that this terminology is a little easier
 to understand and less loaded than calling it delegation.

 My write-up follows.

 Josh

 OpenID portable identifier support
 ##

 Portable identifier support allows an IdP to do authentication for an
 identifier that was not issued by that IdP. It has two motivating use
 cases [1]_:

 * allow users to use any identifier with any IdP

 * allow users to move an identifier between IdPs (prevent 

RE: Delegation discussion summary

2006-10-13 Thread Recordon, David
Title: RE: Delegation discussion summary






+1


-Original Message-
From:  Drummond Reed [mailto:[EMAIL PROTECTED]]
Sent: Thursday, October 12, 2006 10:46 PM Pacific Standard Time
To: 'Josh Hoyt'; 'Marius Scurtescu'
Cc: specs@openid.net
Subject: RE: Delegation discussion summary

+1 to Josh's point. IMHO identifier portability is sacred. If anyone
disagrees, please post, can we assume we have consensus on this?

=Drummond

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf
Of Josh Hoyt
Sent: Thursday, October 12, 2006 8:56 PM
To: Marius Scurtescu
Cc: specs@openid.net
Subject: Re: Delegation discussion summary

On 10/12/06, Marius Scurtescu [EMAIL PROTECTED] wrote:
 The protocol does not need to touch on IdP-specific identifiers (aka
 delegated identifiers) at all IMO.

If there is a specified mechanism that must be supported for using a
portable identifier, all IdPs will support it, so identifiers will
actually be portable. You'd have a very difficult time trying to get
people here to remove portable identifier support from the OpenID
protocol.

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





___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs


RE: Delegation discussion summary

2006-10-13 Thread Granqvist, Hans
I can see potential use-cases where Alice doesn't want the 
idp to know what her portable URL is.  This would not work
if the protocol requires both as per below.  Can it be
solved by sending a hash of the portable identifier?


 -Original Message-
 From: [EMAIL PROTECTED] 
 [mailto:[EMAIL PROTECTED] On Behalf Of Josh Hoyt
 Sent: Thursday, October 12, 2006 10:29 AM
 To: specs@openid.net
 Subject: Delegation discussion summary
 
 Hello, list,
 
 I'm sure that another message in your inbox with delegation 
 in the title makes most of you cringe, so I'm sorry for 
 that.I hope that this one gets us closer to resolving this issue.
 
 I have attempted to summarize the proposed delegation 
 mechanisms, as well as the currently-specified delegation 
 mechanism in a single document. I have glossed over some 
 issues and left out some of the discussion, but I hope that I 
 captured most of the important stuff.
 After reviewing the discussion, I think that we are actually 
 pretty close to consensus on a course of action.
 
 I have added one new thing in this write-up, which is that I 
 have started calling delegation portable identifier 
 support, which gives rise to the term portable identifier 
 for what is currently called a delegated identifier. I 
 think that this terminology is a little easier to understand 
 and less loaded than calling it delegation.
 
 My write-up follows.
 
 Josh
 
 OpenID portable identifier support
 ##
 
 Portable identifier support allows an IdP to do 
 authentication for an identifier that was not issued by that 
 IdP. It has two motivating use cases [1]_:
 
   * allow users to use any identifier with any IdP
 
   * allow users to move an identifier between IdPs (prevent 
 IdP lock-in)
 
 Each portable identifiers has an IdP-specific identifier tied 
 to it. This identifier allows the IdP to know what 
 credentials to require before issuing an authentication 
 response even though the IdP does not control the portable identifier.
 
 Throughout this discussion, I will assume that there is a 
 portable identifier called http://my.portable.url/; that 
 uses an IdP-specific identifier called http://my.idp.specific.url/;.
 
 
 Current implementation
 ==
 
 OpenID 1 [2]_ calls portable identifier support delegation. 
 In this implementation, the IdP-specific identifier is the 
 only identifier that is communicated between the relying 
 party and the IdP. When a relying party discovers that it is 
 requesting authentication for a portable identifier, it must 
 keep that state available for processing the response, since 
 the response message does not contain the portable identifier at all.
 
 Request and response messages for this mechanism both use the 
 following field::
 
   openid.identity = http://my.idp.specific.url/
 
 This mechanism has a few drawbacks:
 
  * The relying party must manage state information for the duration of
the transaction.
 
  * The authentication messages are potentially confusing, since the
authentication response is not meaningful without the context of
the initiation, and the IdP-specific identifier does not even have
to be a valid OpenID identifier.
 
   * The IdP *cannot* be aware that it is using a portable identifier,
so the IdP cannot assist the user in making decisions for different
identifiers. For example, a user might wish to be prompted for
confirmation each time he used one identifier, but allow automatic
approval for another.
 
   * IdP-driven identifier selection in the OpenID 2.0 
 specification (up
to draft 9) cannot return assertions for portable identifiers,
because the verification algorithm will fail.
 
   * Portable identifiers must be treated differently from IdP-issued
identifiers by the code running on the relying party
 
 
 Proposed changes
 
 
 All of the changes to delegation that have been proposed 
 retain the important features of portable identifier support. 
 Additionally, they all retain the same basic structure, where 
 the IdP-specific identifier is available from the standard 
 discovery process. Primarily, the proposals change what data 
 is available in the protocol messages, the relationship of 
 the request to the response, and/or the party who is 
 responsible for discovering the IdP-specific identifier for 
 the portable identifier.
 
 Both of the proposed changes to the response messages include 
 the portable identifier in the authentication response. 
 Changing the response to contain the portable identifier 
 removes the burden of maintaining that state from the relying 
 party. Removing this dependency on transaction state enables 
 portable identifiers to be used in both IdP-driven identifier 
 selection and IdP-initiated authentication (bare response) [3]_.
 
 Neither proposal outlined here changes the protocol unless a 
 portable identifier is used.
 
 
 Both portable and IdP-specific 

RE: Delegation discussion summary

2006-10-13 Thread Drummond Reed
Hans,

This has come up a few times and the mapping between the portable identifier
and the IdP-specific identifier is available in public XRDS documents. So
there's no point in trying to hide that information from the IdP -- and it
may even be misleading to suggest to end-users that they could try to do so.

=Drummond  

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of Granqvist, Hans
Sent: Friday, October 13, 2006 8:52 AM
To: Josh Hoyt; specs@openid.net
Subject: RE: Delegation discussion summary

I can see potential use-cases where Alice doesn't want the 
idp to know what her portable URL is.  This would not work
if the protocol requires both as per below.  Can it be
solved by sending a hash of the portable identifier?


 -Original Message-
 From: [EMAIL PROTECTED] 
 [mailto:[EMAIL PROTECTED] On Behalf Of Josh Hoyt
 Sent: Thursday, October 12, 2006 10:29 AM
 To: specs@openid.net
 Subject: Delegation discussion summary
 
 Hello, list,
 
 I'm sure that another message in your inbox with delegation 
 in the title makes most of you cringe, so I'm sorry for 
 that.I hope that this one gets us closer to resolving this issue.
 
 I have attempted to summarize the proposed delegation 
 mechanisms, as well as the currently-specified delegation 
 mechanism in a single document. I have glossed over some 
 issues and left out some of the discussion, but I hope that I 
 captured most of the important stuff.
 After reviewing the discussion, I think that we are actually 
 pretty close to consensus on a course of action.
 
 I have added one new thing in this write-up, which is that I 
 have started calling delegation portable identifier 
 support, which gives rise to the term portable identifier 
 for what is currently called a delegated identifier. I 
 think that this terminology is a little easier to understand 
 and less loaded than calling it delegation.
 
 My write-up follows.
 
 Josh
 
 OpenID portable identifier support
 ##
 
 Portable identifier support allows an IdP to do 
 authentication for an identifier that was not issued by that 
 IdP. It has two motivating use cases [1]_:
 
   * allow users to use any identifier with any IdP
 
   * allow users to move an identifier between IdPs (prevent 
 IdP lock-in)
 
 Each portable identifiers has an IdP-specific identifier tied 
 to it. This identifier allows the IdP to know what 
 credentials to require before issuing an authentication 
 response even though the IdP does not control the portable identifier.
 
 Throughout this discussion, I will assume that there is a 
 portable identifier called http://my.portable.url/; that 
 uses an IdP-specific identifier called http://my.idp.specific.url/;.
 
 
 Current implementation
 ==
 
 OpenID 1 [2]_ calls portable identifier support delegation. 
 In this implementation, the IdP-specific identifier is the 
 only identifier that is communicated between the relying 
 party and the IdP. When a relying party discovers that it is 
 requesting authentication for a portable identifier, it must 
 keep that state available for processing the response, since 
 the response message does not contain the portable identifier at all.
 
 Request and response messages for this mechanism both use the 
 following field::
 
   openid.identity = http://my.idp.specific.url/
 
 This mechanism has a few drawbacks:
 
  * The relying party must manage state information for the duration of
the transaction.
 
  * The authentication messages are potentially confusing, since the
authentication response is not meaningful without the context of
the initiation, and the IdP-specific identifier does not even have
to be a valid OpenID identifier.
 
   * The IdP *cannot* be aware that it is using a portable identifier,
so the IdP cannot assist the user in making decisions for different
identifiers. For example, a user might wish to be prompted for
confirmation each time he used one identifier, but allow automatic
approval for another.
 
   * IdP-driven identifier selection in the OpenID 2.0 
 specification (up
to draft 9) cannot return assertions for portable identifiers,
because the verification algorithm will fail.
 
   * Portable identifiers must be treated differently from IdP-issued
identifiers by the code running on the relying party
 
 
 Proposed changes
 
 
 All of the changes to delegation that have been proposed 
 retain the important features of portable identifier support. 
 Additionally, they all retain the same basic structure, where 
 the IdP-specific identifier is available from the standard 
 discovery process. Primarily, the proposals change what data 
 is available in the protocol messages, the relationship of 
 the request to the response, and/or the party who is 
 responsible for discovering the IdP-specific identifier for 
 the portable identifier.
 
 Both of the proposed changes 

RE: Delegation discussion summary

2006-10-13 Thread Drummond Reed
 But I suggest we move that terminology discussion to the marketing list.
 

 What marketing list?

http://lists.iwantmyopenid.org/mailman/listinfo/marketing.

=Drummond 

___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs


RE: Delegation discussion summary

2006-10-13 Thread Granqvist, Hans
Makes sense, but do you *have* to put delegation info in an XRDS 
document? 

I'd like to think if I were to use an RP that I trust not
to 'collude' with the IDP, there would be no reason for the
IDP to know potential delegation?

That gives me true identity portability and an open choice of
IDPs. Once an IDP knows of and starts tracking my vanity 
identifier (bound to happen) I cannot easily give up that 
identifier. 


 -Original Message-
 From: Drummond Reed [mailto:[EMAIL PROTECTED] 
 Sent: Friday, October 13, 2006 9:11 AM
 To: Granqvist, Hans; 'Josh Hoyt'; specs@openid.net
 Subject: RE: Delegation discussion summary
 
 Hans,
 
 This has come up a few times and the mapping between the 
 portable identifier and the IdP-specific identifier is 
 available in public XRDS documents. So there's no point in 
 trying to hide that information from the IdP -- and it may 
 even be misleading to suggest to end-users that they could 
 try to do so.
 
 =Drummond  
 
 -Original Message-
 From: [EMAIL PROTECTED] 
 [mailto:[EMAIL PROTECTED] On Behalf Of Granqvist, Hans
 Sent: Friday, October 13, 2006 8:52 AM
 To: Josh Hoyt; specs@openid.net
 Subject: RE: Delegation discussion summary
 
 I can see potential use-cases where Alice doesn't want the 
 idp to know what her portable URL is.  This would not work if 
 the protocol requires both as per below.  Can it be solved 
 by sending a hash of the portable identifier?
 
 
  -Original Message-
  From: [EMAIL PROTECTED] 
  [mailto:[EMAIL PROTECTED] On Behalf Of Josh Hoyt
  Sent: Thursday, October 12, 2006 10:29 AM
  To: specs@openid.net
  Subject: Delegation discussion summary
  
  Hello, list,
  
  I'm sure that another message in your inbox with delegation 
  in the title makes most of you cringe, so I'm sorry for 
  that.I hope that this one gets us closer to resolving this issue.
  
  I have attempted to summarize the proposed delegation 
  mechanisms, as well as the currently-specified delegation 
  mechanism in a single document. I have glossed over some 
  issues and left out some of the discussion, but I hope that I 
  captured most of the important stuff.
  After reviewing the discussion, I think that we are actually 
  pretty close to consensus on a course of action.
  
  I have added one new thing in this write-up, which is that I 
  have started calling delegation portable identifier 
  support, which gives rise to the term portable identifier 
  for what is currently called a delegated identifier. I 
  think that this terminology is a little easier to understand 
  and less loaded than calling it delegation.
  
  My write-up follows.
  
  Josh
  
  OpenID portable identifier support
  ##
  
  Portable identifier support allows an IdP to do 
  authentication for an identifier that was not issued by that 
  IdP. It has two motivating use cases [1]_:
  
* allow users to use any identifier with any IdP
  
* allow users to move an identifier between IdPs (prevent 
  IdP lock-in)
  
  Each portable identifiers has an IdP-specific identifier tied 
  to it. This identifier allows the IdP to know what 
  credentials to require before issuing an authentication 
  response even though the IdP does not control the portable 
 identifier.
  
  Throughout this discussion, I will assume that there is a 
  portable identifier called http://my.portable.url/; that 
  uses an IdP-specific identifier called 
 http://my.idp.specific.url/;.
  
  
  Current implementation
  ==
  
  OpenID 1 [2]_ calls portable identifier support delegation. 
  In this implementation, the IdP-specific identifier is the 
  only identifier that is communicated between the relying 
  party and the IdP. When a relying party discovers that it is 
  requesting authentication for a portable identifier, it must 
  keep that state available for processing the response, since 
  the response message does not contain the portable 
 identifier at all.
  
  Request and response messages for this mechanism both use the 
  following field::
  
openid.identity = http://my.idp.specific.url/
  
  This mechanism has a few drawbacks:
  
   * The relying party must manage state information for the 
 duration of
 the transaction.
  
   * The authentication messages are potentially confusing, since the
 authentication response is not meaningful without the context of
 the initiation, and the IdP-specific identifier does not 
 even have
 to be a valid OpenID identifier.
  
* The IdP *cannot* be aware that it is using a portable 
 identifier,
 so the IdP cannot assist the user in making decisions 
 for different
 identifiers. For example, a user might wish to be prompted for
 confirmation each time he used one identifier, but allow 
 automatic
 approval for another.
  
* IdP-driven identifier selection in the OpenID 2.0 
  specification (up
 to draft 9) cannot return assertions for portable 

Use of i-numbers (was RE: Consolidated Delegate Proposal)

2006-10-13 Thread Drummond Reed
Martin wrote:

I think this is the intention, though it does show an interesting 
inconsistency between the use of XRIs and the use of i-numbers. I 
currently have three URL-based identifiers all pointing at the same 
server and the same Yadis document, yet those identifiers are distinct. 
However, in the comparable XRI case, it would appear that those 
identifiers would all be considered to be the same.

If they point to the exact same XRDS document with the same i-number as the
CanonicalID, that would establish all three URLs and the CanonicalID
i-number as synonyms (yes, it is possible to have URLs and XRIs that are
synonyms). In XRI Resolution 2.0 Working Draft 11 we are adding a new
BackRef element that will enable an XRDS document to back reference any type
of identifier that points to it, such as a URL, so you can machine-verify
the back reference if you want.

If you wanted to keep the three URLs as distinct, separate identities, point
them at three different XRDS documents with different i-numbers.

I wonder how easy it is to get hold of new i-numbers. If they are 
basically throw-away cheap, then I'm able to decide for myself how to 
distribute my mappings to separate them. However, if these i-numbers are 
going to be expensive (for some sense of the word) to aquire, I've got 
less freedom in this respect. Drummond?

The short answer is that delegated i-numbers (and this is the federated
identifier meaning of the term delegation) are as throw-away cheap as
URL (at the path level), third-level DNS names, or any other form of
delegated identifier. The cost is all in resolution, i.e., someone
somewhere maintaining a registry that will point you to the XRDS document if
you resolve it. 

=Drummond 

___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs


RE: Delegation discussion summary

2006-10-13 Thread Drummond Reed
 Marius wrote:

 I was suggesting that portability can be resolved between the user  
 and
 the IdP. I cannot see how the protocol can help this by passing two
 identifiers. And if only the portable identifier is passed then  
 there is
 no need to mention the IdP-specific identifier.

 Marius, see the analysis at
 http://www.lifewiki.net/openid/ConsolidatedDelegationProposal, now  
 updated
 to include Josh's lastest thinking from
 http://openid.net/pipermail/specs/2006-October/000357.html.

 In sum, not being able to send the IdP-specific identifier: a)  
 forces the
 IdP to redo resolution, which is unnecessary and slows performance,  
 and

Not necessarily. When you register with the IdP most likely you will  
claim all your portable identifiers with this IdP, so the IdP knows  
about them.

With XRI i-name/i-number infrastructure that's neither practical nor
desirable. With XRIs, users control their own synonyms, i.e., I can register
a delegated i-name within a specific community (for example, at
@example.community I could register @example.community*drummond) and then
point that at my personal i-name (=drummond.reed) and the IdP for
=drummond.reed will never know -- and doesn't need to know. I could go to
any RP and login in as @example.community*drummond, the RP will resolve this
to =drummond.reed (through the way XRI resolution automatically handles
reference processing -- let me know if you want more info about this), and
end out storing the CanonicalID i-number for =drummond.reed (which is
=!F83.62B1.44F.2813).

 b) prevents the protocol from being stateless.

How? The RP deals only with the portable identifier and this is the  
only thing the IdP sends back. Why do you need state?

It follows from the above. But this is so important that I'm going to send a
separate message about it.

=Drummond 

___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs


Identifier portability: the fundamental issue

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


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: Delegation discussion summary

2006-10-13 Thread Marius Scurtescu
On 13-Oct-06, at 12:20 PM, Drummond Reed wrote:

 Marius wrote:

 I was suggesting that portability can be resolved between the user
 and
 the IdP. I cannot see how the protocol can help this by passing two
 identifiers. And if only the portable identifier is passed then
 there is
 no need to mention the IdP-specific identifier.

 Marius, see the analysis at
 http://www.lifewiki.net/openid/ConsolidatedDelegationProposal, now
 updated
 to include Josh's lastest thinking from
 http://openid.net/pipermail/specs/2006-October/000357.html.

 In sum, not being able to send the IdP-specific identifier: a)
 forces the
 IdP to redo resolution, which is unnecessary and slows performance,
 and

 Not necessarily. When you register with the IdP most likely you will
 claim all your portable identifiers with this IdP, so the IdP knows
 about them.

 With XRI i-name/i-number infrastructure that's neither practical nor
 desirable. With XRIs, users control their own synonyms, i.e., I can  
 register
 a delegated i-name within a specific community (for example, at
 @example.community I could register @example.community*drummond)  
 and then
 point that at my personal i-name (=drummond.reed) and the IdP for
 =drummond.reed will never know -- and doesn't need to know. I could  
 go to
 any RP and login in as @example.community*drummond, the RP will  
 resolve this
 to =drummond.reed (through the way XRI resolution automatically  
 handles
 reference processing -- let me know if you want more info about  
 this), and
 end out storing the CanonicalID i-number for =drummond.reed (which is
 =!F83.62B1.44F.2813).

I don't see the point if hiding some of your portable identifiers  
(@example.community*drumond) from your IdP and at the same time  
disclose it to all the RPs you deal with.

If you are using a portable identifier and you have an IdP then it  
seems normal to me to trust your IdP to know your portable  
identifier. I would be more nervous about all the RP knowing my IdP  
issued identifier.

What is not practical about registering your portable identifier with  
your IdP?



 b) prevents the protocol from being stateless.

 How? The RP deals only with the portable identifier and this is the
 only thing the IdP sends back. Why do you need state?

 It follows from the above. But this is so important that I'm going  
 to send a
 separate message about it.

I can't see it, sorry.

If the RP is indexing your account based on your i-number then it  
could send your i-number to your IdP for authentication, but it can  
also send your i-name. I don't think it matters. The IdP should know  
both and it can lookup your account with any of them. What state must  
the RP save? The RP has both your i-name and i-number as well (unless  
you are registering), so when the response comes back it can look you  
up with any.

Marius

___
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: Consolidated Delegate Proposal

2006-10-13 Thread Marius Scurtescu
On 12-Oct-06, at 11:40 PM, Drummond Reed wrote:

 Drummond wrote:
 Since the RP has to do discovery on the i-name, the RP already  
 has the
 i-number (CanonicalID). Further, as explained in previous  
 threads, the
 CanonicalID is the primary key the RP wants to store for the user,
 not the
 i-name, because the i-number is forever while the i-name could  
 change.

 The RP is also motivated to send the i-number to the IdP for the
 same reason
 that the RP is motivated to send the delegate URL (if available): to
 increase performance by saving the IdP from having to re-resolve
 the i-name
 (in the XRI case) or original URL (in the URL case).

 Dick wrote:

 Won't the IdP will still have to resolve the i-name? The IdP can't
 trust the RP, or know that the i-name and i-number are really linked
 unless it checks itself.

 There are no trust issues involved with the IdP using the  
 identifiers sent
 by the RP. The RP is relying on the IdP, not vice versa. If the  
 RP sends
 the wrong identifiers, it's fooling no one but itself. Thus the IdP  
 has no
 reason to re-resolve (and good performance reasons not to).

The IdP is issuing a signed assertion about these identifiers, I  
would assume the IdP to check the link between these identifiers.

What if a bad RP sends an auth request with a mismatched set and then  
re-posts the response to some other RP? I am sure someone will figure  
a way to exploit this.

Marius

___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs


Re: Consolidated Delegate Proposal

2006-10-13 Thread Josh Hoyt
On 10/13/06, Marius Scurtescu [EMAIL PROTECTED] wrote:
 The IdP is issuing a signed assertion about these identifiers, I
 would assume the IdP to check the link between these identifiers.

Sending two identifiers does not *prevent* the IdP from checking to
make sure they match.

 What if a bad RP sends an auth request with a mismatched set and then
 re-posts the response to some other RP? I am sure someone will figure
 a way to exploit this.

It is, and must be, the relying party's responsibility to ensure that
the information in the response matches what is discovered. This is
true regardless when portable identifiers are used and when they are
not. It is true for all of the proposed delegation mechanisms. It is
really one of the fundamental elements of OpenID.

A response from an IdP is meaningless until it is compared with the
discovered information for the identifier in question.

Josh
___
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