Re: Changing Terminology (was RE: IdP term in spec (was RE: Delegation discussion summary))

2006-10-17 Thread Dick Hardt
I think we should be open (pun intended) to making changes.

I really like the OpenID Provider - shortens to OP, and is very  
specific on what it does.
I have always found IdP to be a misnomer, and have mentioned it in  
the past.
Now we have a great candidate, that provides more clarity, and it  
should be a simple search and replace, and does not affect any code.

Agreed the user friendly terms may take some more discussion.

-- Dick

On 15-Oct-06, at 11:58 AM, Recordon, David wrote:

 I'd really prefer not to change terminology in the spec right now.
 Seems like something we should have thought about four months ago  
 versus
 a week after we said it would be final.  There is nothing saying user
 friendly terms that map to spec terms can't be created for the time
 being.  I do however think there will need to be healthy discussion
 around them, that takes longer than a week.  :)

 --David

 -Original Message-
 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
 Behalf Of Drummond Reed
 Sent: Saturday, October 14, 2006 11:43 PM
 To: 'Johannes Ernst'; specs@openid.net
 Subject: IdP term in spec (was RE: Delegation discussion summary)

 Suggestion: sidestep the issue completely and in the spec -- and
 everywhere else -- just call it OpenID provider. It's a simple
 concatenation of OpenID and service provider, so everyone gets it,
 but nobody will associate it with SAML or federation or anything else.

 -Original Message-
 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
 Behalf Of Johannes Ernst
 Sent: Saturday, October 14, 2006 11:37 PM
 To: specs@openid.net
 Subject: Re: Delegation discussion summary

 We call it identity host at NetMesh. It's close enough to identity
 provider so people understand it quickly, but does not have the
 provider part to it (duh).

 On Oct 14, 2006, at 20:46, Scott Kveton wrote:

 I would propose that the term Homesite be used when prompting the
 user to type in their IdP. I think the term Identity Provider is
 overloaded and not user friendly.

 As per my last email I feel the same way about identity provider
 as well
 ... I agree with Dick; too overloaded and not user friendly.

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

 Johannes Ernst
 NetMesh Inc.


 ___
 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


IdP term in spec (was RE: Delegation discussion summary)

2006-10-15 Thread Drummond Reed
Suggestion: sidestep the issue completely and in the spec -- and everywhere
else -- just call it OpenID provider. It's a simple concatenation of
OpenID and service provider, so everyone gets it, but nobody will
associate it with SAML or federation or anything else.

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of Johannes Ernst
Sent: Saturday, October 14, 2006 11:37 PM
To: specs@openid.net
Subject: Re: Delegation discussion summary

We call it identity host at NetMesh. It's close enough to identity  
provider so people understand it quickly, but does not have the  
provider part to it (duh).

On Oct 14, 2006, at 20:46, Scott Kveton wrote:

 I would propose that the term Homesite be used when prompting the
 user to type in their IdP. I think the term Identity Provider is
 overloaded and not user friendly.

 As per my last email I feel the same way about identity provider  
 as well
 ... I agree with Dick; too overloaded and not user friendly.

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

Johannes Ernst
NetMesh Inc.


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


RE: Delegation discussion summary

2006-10-15 Thread Recordon, David
After re-reading this, other messages, and Dick's latest post, I
strongly feel that we should make the change to support both the
portable and IdP-specific identifiers within the protocol.

The two most compelling reasons to me are that it has the fewest
conceptual changes from OpenID Auth 1.x and the messages are very
verbose and explicit in both the request and response.  In addition, I
believe it will grant greater flexibility for extensions being built
atop the protocol as well as it provides useful features when working
with XRIs.

I appreciate the simplicity the one identifier approach presents, though
dislike changing the concept behind the protocol this late in the
drafting process.

--David

-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

Re: Delegation discussion summary

2006-10-14 Thread Dick Hardt
Would you elaborate on those use cases? The current draft does not  
support this.

-- Dick

On 13-Oct-06, at 8:52 AM, Granqvist, Hans wrote:

 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

Re: Delegation discussion summary

2006-10-14 Thread Scott Kveton
 I would propose that the term Homesite be used when prompting the
 user to type in their IdP. I think the term Identity Provider is
 overloaded and not user friendly.

As per my last email I feel the same way about identity provider as well
... I agree with Dick; too overloaded and not user friendly.

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


Re: Delegation discussion summary

2006-10-14 Thread Scott Kveton
 I kinda get homesite, but I don't understand the thinking behind
 membersite: What is this site supposed to be a member of?
 
 It was a member of the network of sites running the protocol.

Membersite sounds too much like you have to join some club to participate.
I feel the same way about homesite.  I'm all for finding more
consumer-friendly terminology for this but I've yet to hear anything that
rings true.

In the case of http you have web server which is served up by a web site
... Instead of http provider and http destination ... Maybe we need to
make this even simpler than we are?  Could it be as simple (and I'm not
really suggesting these) as login server and login site?

What does the wider community think?  How do LiveJournal users refer to this
concept today?

- Scott

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


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

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


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: 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 = http

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

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

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