. :)
--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
: [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
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
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
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
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
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
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
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
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
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
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
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
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,
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
+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
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.
: 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
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 =
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
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
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
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
23 matches
Mail list logo
