RE: Delegation discussion summary

2006-10-12 Thread Drummond Reed
+1. Josh, you did a great job of not just distilling it down to the essence,
but also nailing the right semantics for the underlying feature, which is
identifier portability.

Nice work.

=Drummond 

-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 identifiers
--

Include both the portable identifier and the IdP-specific identifier
in the request and response ([4]_ and
[5]_)::

  openid.identity = 

RE: [PROPOSAL] request nonce and name

2006-10-12 Thread Recordon, David
Title: RE: [PROPOSAL] request nonce and name






Josh and I chatted a good deal about this and don't believe a request nonce is actually needed. The main motivation for a request nonce is allowing a RP to retain state within the transaction.

A stateful RP however already has the means to store the needed data for the response, which really isn't more than the association handle to validate the returned signature. All other state decisions by an RP are made from the data returned in the response from the IdP.

A stateless RP is then unable to validate a nonce it generated since it wouldn't have been able to retain information about its own nonce.

We thought about having the RP generate a nonce in the request for the IdP to verify it hasn't received the request previously, though do not see security implications with a request being replayed. As the protocol depends on browser redirections, there is not unique information within the request which should not be replayed. This is seen today if a RP redirects you to your IdP, you go to login, but refresh the page instead which works flawlessly. Adding a request nonce would break this with no anticipated benefit.

We thus believe that any state tracking needed by a stateless RP must be maintained as GET parameters within the return_to argument. In the case of a stateful RP, it can either do the same thing, or store state via other means such as using a session id within a cookie to reference database data.

--David


-Original Message-
From: [EMAIL PROTECTED] on behalf of Dick Hardt
Sent: Sat 9/30/2006 4:57 PM
To: specs@openid.net
Subject: [PROPOSAL] request nonce and name

Motivating Use Case

It is useful for an RP to know that a response to a request has
already been processed and is not stale.
A standard way to do this that can be incorporated into the Libraries
would simplify things for the RP implementor


Proposed Implementation
---
1) Allow the RP to OPTIONALLY include a nonce in the request. The
nonce would be of the same format as the nonce in the response from
the IdP. The IdP will include the nonce from the RP in its response.

2) rename openid.nonce to openid.response_id and name the request
nonce openid.request_id

Alternate: call them openid.response_stamp and openid.request_stamp

naming comments:
+ openid.nonce is not in use at this time, so easy to rename
+ id or stamp may make more sense to the average developer (mainly
crypto and security people know what a nonce is, I have to explain to
most developers)


___
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: [PROPOSAL] request nonce and name

2006-10-12 Thread Martin Atkins
Recordon, David wrote:
 
 We thus believe that any state tracking needed by a stateless RP must be 
 maintained as GET parameters within the return_to argument.  In the case 
 of a stateful RP, it can either do the same thing, or store state via 
 other means such as using a session id within a cookie to reference 
 database data.
 

Sounds good to me.
+1.

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


off topic: IETF ID on extending protocols

2006-10-12 Thread Dick Hardt
This draft has good discussion about what a good protocol is and the  
issues in extending protocols:

http://www.ietf.org/internet-drafts/draft-carpenter-extension- 
recs-00.txt

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


Re: [PROPOSAL] request nonce and name

2006-10-12 Thread Marius Scurtescu
On 12-Oct-06, at 12:10 PM, Recordon, David wrote:
 We thus believe that any state tracking needed by a stateless RP  
 must be maintained as GET parameters within the return_to  
 argument.  In the case of a stateful RP, it can either do the same  
 thing, or store state via other means such as using a session id  
 within a cookie to reference database data.
So basically the query string of the return_to parameter is used to  
implement pass through parameters.

Why not require that unknown parameters be passed through? This way  
the return_url is clean and it can be persisted (for bookmarking for  
example) and there are no size limitations.

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.

Marius

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


Re: [PROPOSAL] request nonce and name

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

Josh

1. http://developer.yahoo.com/auth/
2. http://developer.yahoo.com/auth/user.html
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs


RE: Delegation discussion summary

2006-10-12 Thread Graves, Michael
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 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 

RE: Delegation discussion summary

2006-10-12 Thread Gabe Wachob
*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 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

Re: Delegation discussion summary

2006-10-12 Thread Marius Scurtescu
On 12-Oct-06, at 10:29 AM, Josh Hoyt wrote:

 Both portable and IdP-specific identifiers
 --

 Include both the portable identifier and the IdP-specific identifier
 in the request and response ([4]_ and
 [5]_)::

   openid.identity = http://my.idp.specific.url/
   openid.portable = http://my.portable.url/

 The relying party is still responsible for checking to make sure that
 the IdP-specific identifier that is returned matches what is
 discovered from the portable identifier, but since it is included in
 the authentication response, it is not necessary for the relying party
 to maintain this state, and an authentication response is meaningful
 without the context of the request.

 The messages in this proposal are very explicit about what is going
 on. The only way in which this differs from OpenID 1 is that the
 portable identifier is also included in the response. The meaning of
 the openid.identity parameter is identical to its meaning in the
 OpenID 1 protocol (the IdP-specific identifier).

Not sure why are both identifiers needed? The RP cares only about the  
portable one, right?

Is backwards compatibility the only reason?



 Portable identifier only
 

This option makes sense to me.

The protocol does not need to touch on IdP-specific identifiers (aka  
delegated identifiers) at all IMO. This is really an IdP  
implementation detail. The only important point seems to be the fact  
that identifiers are portable and IdPs should allow users to move  
them around.


Marius

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


Re: [PROPOSAL] request nonce and name

2006-10-12 Thread Marius Scurtescu
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.

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


Re: Delegation discussion summary

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


RE: Delegation discussion summary

2006-10-12 Thread Recordon, David
Title: 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 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 

Re: Consolidated Delegate Proposal

2006-10-12 Thread Dick Hardt

On 10-Oct-06, at 2:08 PM, Drummond Reed wrote:

 On 10/10/06, Dick Hardt wrote:
 [openid.rpuserid is the identifier] that the user gave the RP?

 Josh Hoyt wrote:
 For URL identifiers, it is the supplied identifer, normalized, after
 following redirects. In essence, it's the user's chosen identifier.

 For XRI identifers, it's the canonical ID (i-number).

 Dick Hardt wrote:

 This comment led me to want to make sure I understand the
 requirements of XRI.

 Q: why would the RP not want the i-name to come back rather then the
 i-number?

 The i-number can be derived from the i-name. The i-name is what is
 user visible. The IdP will make sure the i-name the user is
 presenting resolves to the i-number the user has presented in the  
 past.

 Am I missing something?

 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).

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.



 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.

 If the RP can only send one
 identifier to the IdP, it's stuck with a dilemma:

 * If the RP sends the identifier-the-RP-stores, then it forces the  
 IdP to
 redo discovery, slowing performance.

It would seem to me that the IdP still has to do discovery as it  
can't trust what the RP did, or that the RP even did it.

Summary: sending both parameters does not save anything as both RP  
and IdP need to resolve the user presented Identifier to who is  
authoritative for it.

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?


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


RE: Delegation discussion summary

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


RE: Delegation discussion summary

2006-10-12 Thread Drummond Reed
Title: RE: Delegation discussion summary








+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 
Sxips pioneering work in this area, I dont 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.



=Drummond 











From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Recordon, David
Sent: Thursday, October 12, 2006
9:04 PM
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