RE: OpenID.net Service Type Namespaces

[Recordon, David]

Works for me. :)

--David 

-Original Message-
From: Granqvist, Hans 
Sent: Friday, October 20, 2006 6:40 PM
To: Recordon, David; specs@openid.net
Subject: RE: OpenID.net Service Type Namespaces

It has had some voices against it, but how about considering this
template (used in for example W3C xmldsig and
xmlenc):

http://openid.net/[year]/[month]/[project]#[type]

Time-dependent (rather than version--dependent) namespaces can evolve
freely and will not be tied down to specific versioning numbers. 

Example:
http://openid.net/2006/10/authentication
http://openid.net/2006/10/authentication#signon 


It's cool if an HTTP GET on these links returns the specification.

Once a spec is finalized, the then current year/month becomes that
spec's namespace. For example, xmlenc's namespace is
http://www.w3.org/2001/04/xmlenc 

Hans


> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Recordon, David
> Sent: Friday, October 20, 2006 3:09 PM
> To: specs@openid.net
> Subject: OpenID.net Service Type Namespaces
> 
> Right now we have things like http://openid.net/signon/1.1, 
> http://openid.net/sreg/1.0, etc.  This doesn't really seem to scale, 
> populating the main http://openid.net namespace.
> 
> Could we do something like
> http://specs.openid.net/authentication/2.0/signon or 
> http://specs.openid.net/authentication/2.0/identifier_select
> as well as then http://specs.openid.net/sreg/1.0?
> 
> This would give all the specs their own namespaces, as well as make it

> so we can do smart redirection from each of these "type" urls to the 
> correct anchor in the individual spec.
> 
> --David
> ___
> 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: [VOTE] Portable Identifier Support Proposal (patch)

[Recordon, David]

+1, though thinking we should define IdP-Specific Identifier and
Portable Identifier in the terminology section.

Thanks for doing this!

--David

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Josh Hoyt
Sent: Friday, October 20, 2006 7:31 PM
To: specs@openid.net
Subject: Portable Identifier Support Proposal (patch)

As requested [1], I have made a patch to the specification [2] that
specifies the "two-identifier" mechanism for portable identifier
support. It's attached to this message. The net effect is adding one
line to the source XML file.

I hope this proves useful in evaluating the proposal.

Josh

1. http://openid.net/pipermail/specs/2006-October/000478.html
2. http://openid.net/svn/listing.php?repname=specifications&rev=70&sc=1
   (openid.net specifications svn trunk, revision 70)
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Portable Identifier Support Proposal (patch)

[Josh Hoyt]

As requested [1], I have made a patch to the specification [2] that
specifies the "two-identifier" mechanism for portable identifier
support. It's attached to this message. The net effect is adding one
line to the source XML file.

I hope this proves useful in evaluating the proposal.

Josh

1. http://openid.net/pipermail/specs/2006-October/000478.html
2. http://openid.net/svn/listing.php?repname=specifications&rev=70&sc=1
  (openid.net specifications svn trunk, revision 70)
--- svn-track/openid-authentication.xml	2006-10-20 16:08:15.0 -0700
+++ work/openid-authentication.xml	2006-10-20 16:13:05.0 -0700
@@ -132,8 +132,8 @@
 referred to as a "URL" within this document, or http://www.oasis-open.org/committees/download.php/15376";
 >XRI.  An "Identifier" may be a Claimed Identifier,
-Delegate Identifier, IdP Identifier, or Verified Identifier,
-depending on context.
+IdP-Specific Identifier, IdP Identifier, or Verified
+Identifier, depending on context.
   
 
   
@@ -154,7 +154,7 @@
 that they own.
   
 
-  
+  
 An alternate Identifier that can be included in the discovery
 response.
   
@@ -751,21 +751,17 @@
   
 
   
-(optional) The normalized Identifier upon which
-discovery was performed. The Claimed Identifier is
-present unless the End User entered an IdP Identifier
-during initiation.
+(optional) The identifier that is the subject of this
+authentication request. This is the identifier upon
+which discovery was performed.
   
 
-  
-(optional)
- 
-The Identifier that the Relying Party SHOULD perform
-authentication using.  Upon successful authentication,
-the Relying Party SHOULD recognize the End User using
-the Claimed Identifier.  The Delegate Identifier can
-only be present when the End User enters a Claimed
-Identifier.
+  
+(optional) An identifier that allows an IdP to
+identify the user of a portable identifier. If no
+IdP-specific identifier is present in the discovered
+information, the Claimed Identifier is also the
+IdP-Specific Identifier.
   
 
   
@@ -820,8 +816,8 @@
   
 
   
-An  tag (optional) whose
-		text content is the Delegate Identifier.
+An  tag (optional) whose text
+content is the IdP-Specific Identifier.
   
 
   
@@ -928,7 +924,7 @@
   
 A  tag MAY be included with attributes
 "rel" set to "openid.delegate" and "href" set to the
-End User's Delegate Identifier
+End User's IdP-Specific Identifier
   
 
   
@@ -1362,11 +1358,24 @@
 
 
 
+  openid.portable
+  
+
+  Value: (optional) The Claimed Identifier.
+
+
+  Note: If the portable identifier is not specified,
+  it is assumed to be the same as the IdP-specific
+  identifier.
+
+  
+
+
+
   openid.identity
   
 
-  Value: (optional) Delegate Identifier when
-  available, otherwise the Claimed Identifier
+  Value: (optional) The IdP-Specific Identifier.
 
 
   Note: If this is set to the special value
@@ -1574,11 +1583,25 @@
 
 
 
+  openid.portable
+  
+
+  
+Value: (optional) The Claimed Identifier
+  
+  
+Note: If this value is absent, it defaults to the
+value of "openid.identity".
+  
+
+  
+
+
+
   openid.identity
   
 
-  Value: (optional) The Identifier about which the IdP
-  is making a positive authentication assertion.
+  Value: (optional) The IdP-Specific Identifier
 
 
   Note: The Identifier MAY be omitted if an extension
@@ -1664,13 +1687,12 @@
   Value: Comma-separated list of signed fields.
 
 
-  Note: This entry consists of the

RE: OpenID.net Service Type Namespaces

[Granqvist, Hans]

It has had some voices against it, but how about considering 
this template (used in for example W3C xmldsig and 
xmlenc):

http://openid.net/[year]/[month]/[project]#[type]

Time-dependent (rather than version--dependent) namespaces
can evolve freely and will not be tied down to specific
versioning numbers. 

Example:
http://openid.net/2006/10/authentication
http://openid.net/2006/10/authentication#signon 


It's cool if an HTTP GET on these links returns the
specification.

Once a spec is finalized, the then current year/month 
becomes that spec's namespace. For example, xmlenc's 
namespace is http://www.w3.org/2001/04/xmlenc 

Hans


> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf Of Recordon, David
> Sent: Friday, October 20, 2006 3:09 PM
> To: specs@openid.net
> Subject: OpenID.net Service Type Namespaces
> 
> Right now we have things like http://openid.net/signon/1.1, 
> http://openid.net/sreg/1.0, etc.  This doesn't really seem to 
> scale, populating the main http://openid.net namespace.
> 
> Could we do something like
> http://specs.openid.net/authentication/2.0/signon or 
> http://specs.openid.net/authentication/2.0/identifier_select 
> as well as then http://specs.openid.net/sreg/1.0?
> 
> This would give all the specs their own namespaces, as well 
> as make it so we can do smart redirection from each of these 
> "type" urls to the correct anchor in the individual spec.
> 
> --David
> ___
> specs mailing list
> specs@openid.net
> http://openid.net/mailman/listinfo/specs
> 
> 
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

OpenID.net Service Type Namespaces

[Recordon, David]

Right now we have things like http://openid.net/signon/1.1,
http://openid.net/sreg/1.0, etc.  This doesn't really seem to scale,
populating the main http://openid.net namespace.

Could we do something like
http://specs.openid.net/authentication/2.0/signon or
http://specs.openid.net/authentication/2.0/identifier_select as well as
then http://specs.openid.net/sreg/1.0?

This would give all the specs their own namespaces, as well as make it
so we can do smart redirection from each of these "type" urls to the
correct anchor in the individual spec.

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

RE: OpenID version 1.2 instead of 2.0 (Re: off topic - how many peopleuse OpenID ?)

[Recordon, David]

I also like this idea. :)  Removes a lot of the pressure to put
everything under the kitchen sink in it since it is marked as "2.0".

--David 

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Josh Hoyt
Sent: Friday, October 20, 2006 5:38 PM
To: Granqvist, Hans
Cc: specs@openid.net
Subject: OpenID version 1.2 instead of 2.0 (Re: off topic - how many
peopleuse OpenID ?)

On 10/20/06, Granqvist, Hans <[EMAIL PROTECTED]> wrote:
> I propose renaming the existing OpenID 2.0 work to be OpenID 1.2.

(moved over to the specs list, since it hasn't had enough traffic
lately)

I think it'd be great to put what we have out as OpenID 1.2. That way,
the debate and proposals here can continue, while we can start
implementing the features that we already know we want and are already
specified.

This should be good for the people (like me) who want to get a better
revision out to users and the community as soon as possible. It should
also be good for the people who have changes that they want to make,
since changes could be debated solely on their merits and not on how
late it is in the specification process.

Also, it reserves the number 2.0 for the "final" version of the 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

OpenID version 1.2 instead of 2.0 (Re: off topic - how many people use OpenID ?)

[Josh Hoyt]

On 10/20/06, Granqvist, Hans <[EMAIL PROTECTED]> wrote:
> I propose renaming the existing OpenID 2.0 work to be OpenID 1.2.

(moved over to the specs list, since it hasn't had enough traffic lately)

I think it'd be great to put what we have out as OpenID 1.2. That way,
the debate and proposals here can continue, while we can start
implementing the features that we already know we want and are already
specified.

This should be good for the people (like me) who want to get a better
revision out to users and the community as soon as possible. It should
also be good for the people who have changes that they want to make,
since changes could be debated solely on their merits and not on how
late it is in the specification process.

Also, it reserves the number 2.0 for the "final" version of the protocol 

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

Re: [PROPOSAL] Handle "[EMAIL PROTECTED]" For Discovery Only

[Recordon, David]

Title: Re: [PROPOSAL] Handle "[EMAIL PROTECTED]" For Discovery Only






I guess I shouldn't have said http://[EMAIL PROTECTED].

All that is being suggested is the following language (on my Treo):
If a string in the format of "[EMAIL PROTECTED]" at a RP, the RP MUST treat the domain after "@" as the IdP Identifier.  The protocol continues down the normal directed identity flow.

--David

 -Original Message-
From:   Johannes Ernst [mailto:[EMAIL PROTECTED]]
Sent:   Friday, October 20, 2006 02:07 PM Pacific Standard Time
To: specs@openid.net
Subject:    Re: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style Identifiers

We actually built some code some time ago to explore this. The basic 
insight was:

if we can do Yadis discovery on XRIs (which aren't rooted in DNS), 
then we can do Yadis discovery on any other kind of identifier, 
whether it's an e-mail address or an ISBN number or what have you -- 
and once we have a Yadis file for a given identifier, we are home 
free because it essentially maps that identifier into HTTP. We 
considered three or four different ways of doing Yadis resolution 
from e-mail addresses and the like, including the http://
[EMAIL PROTECTED]/ idea that David mentions; under the hood they are 
different, but what the user sees is the same.

Usability is the key problem here:
  - we confuse the user because suddenly it's not URL-based identity 
any more
  - we confuse the user because users aren't clickable any more 
(except for a mailto: tag, which is confusing in its own right it 
most identities pop up a blog or home page)
  - we confuse the user because if I type the identifier into by 
browser's address bar, it pops up a phishing warning (!) instead of 
the user's home page.

We decided that for the time being, it was going to be much easier to 
educate users on the need to use URLs as identifiers, than to educate 
users to not be confused by the above behaviors.

The situation would change if, say, Mozilla and MSFT were performing 
Yadis discovery on e-mail-style identifiers, and directed the user to 
their (http) home page from a given e-mail address. Not impossible to 
imagine, but certainly not something to expect any century from now.


On Oct 20, 2006, at 13:44, Jonathan Daugherty wrote:

> # I'm not actually proposing the IdP make an assertion about
> # [EMAIL PROTECTED]  It would only be used during the discovery phase
> # and then an assertion for a URL be returned.
>
> Ok, I misunderstood.  But even in the case where the IdP makes an
> assertion about a different identifier, that's confusing, too; you
> enter something that looks like an email (and maybe your provider
> tells you it even is), but you log into the site as something else,
> right?
>
> --
>   Jonathan Daugherty
>   JanRain, Inc.
> ___
> 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: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style Identifiers

[Johannes Ernst]

We actually built some code some time ago to explore this. The basic  
insight was:


if we can do Yadis discovery on XRIs (which aren't rooted in DNS),  
then we can do Yadis discovery on any other kind of identifier,  
whether it's an e-mail address or an ISBN number or what have you --  
and once we have a Yadis file for a given identifier, we are home  
free because it essentially maps that identifier into HTTP. We  
considered three or four different ways of doing Yadis resolution  
from e-mail addresses and the like, including the http:// 
[EMAIL PROTECTED]/ idea that David mentions; under the hood they are  
different, but what the user sees is the same.


Usability is the key problem here:
 - we confuse the user because suddenly it's not URL-based identity  
any more
 - we confuse the user because users aren't clickable any more  
(except for a mailto: tag, which is confusing in its own right it  
most identities pop up a blog or home page)
 - we confuse the user because if I type the identifier into by  
browser's address bar, it pops up a phishing warning (!) instead of  
the user's home page.


We decided that for the time being, it was going to be much easier to  
educate users on the need to use URLs as identifiers, than to educate  
users to not be confused by the above behaviors.


The situation would change if, say, Mozilla and MSFT were performing  
Yadis discovery on e-mail-style identifiers, and directed the user to  
their (http) home page from a given e-mail address. Not impossible to  
imagine, but certainly not something to expect any century from now.



On Oct 20, 2006, at 13:44, Jonathan Daugherty wrote:


# I'm not actually proposing the IdP make an assertion about
# [EMAIL PROTECTED]  It would only be used during the discovery phase
# and then an assertion for a URL be returned.

Ok, I misunderstood.  But even in the case where the IdP makes an
assertion about a different identifier, that's confusing, too; you
enter something that looks like an email (and maybe your provider
tells you it even is), but you log into the site as something else,
right?

--
  Jonathan Daugherty
  JanRain, Inc.
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs


Johannes Ernst
NetMesh Inc.



 http://netmesh.info/jernst




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

Re: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style Identifiers

[Jonathan Daugherty]

# I'm not actually proposing the IdP make an assertion about
# [EMAIL PROTECTED]  It would only be used during the discovery phase
# and then an assertion for a URL be returned.

Ok, I misunderstood.  But even in the case where the IdP makes an
assertion about a different identifier, that's confusing, too; you
enter something that looks like an email (and maybe your provider
tells you it even is), but you log into the site as something else,
right?

-- 
  Jonathan Daugherty
  JanRain, Inc.
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

RE: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style Identifiers

[Recordon, David]

I'm not actually proposing the IdP make an assertion about
[EMAIL PROTECTED]  It would only be used during the discovery phase and
then an assertion for a URL be returned.

--David 

-Original Message-
From: Jonathan Daugherty [mailto:[EMAIL PROTECTED] 
Sent: Friday, October 20, 2006 2:57 PM
To: George Fletcher
Cc: Recordon, David; specs@openid.net
Subject: Re: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style
Identifiers

# It might create some confusion depending on the audience.  For the #
audience that doesn't run their own web server, or have their own #
blog, it might be confusing to enter a URI.

By confusion, I mean entering something that looks like an email but
probably isn't, and trying to figure out just what the relationship
between email-looking things and email addresses really is.  And seeing
an RP render an email-like thing with "http://"; on the front and "/" on
the end.  The biggest subset of our prospective audience is the one that
is not going to readily understand this, and that is going to create a
lot of confusion.

--
  Jonathan Daugherty
  JanRain, Inc.

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

RE: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style Identifiers

[Hallam-Baker, Phillip]

This all depends on whether OpenIDs are going to be used 
exclusively as hooks for attributes or as a contact 
mechanism.
 
I think that there will inevitably be demand to use the 
identifiers as contact addresses. The question is how this need is going to be 
met in a way that prevents people being spammed to death.
 
I don't see how anyone is going to pay to be =drummond if 
they are the only person who is ever going to type the text in. The idea makes 
no sense since anyone who cares about what they type in can get a plug in that 
provides a pretty name for free.
 
 
Ergo we are talking about contact addresses and on the 
Internet that means email addresses. I am willing to watch people spend 
large amounts of money attempting to prove otherwise. I am not going to throw 
roadblocks in their way to the tar pit. 
 
All I want is the ability to say to people 'I told you so' 
afterwards. 
 
And to offer email addresses on an equal basis with XRIs. 
In other words I am quite happy for others to jump into what I believe to be a 
tar pit and splash around. What I object to is being tied to 
them.
 

  
  
  From: [EMAIL PROTECTED] 
  [mailto:[EMAIL PROTECTED] On Behalf Of John 
  PanzerSent: Friday, October 20, 2006 3:17 PMTo: Kaliya 
  *Cc: specs@openid.netSubject: Re: [PROPOSAL] Handle 
  "http://[EMAIL PROTECTED]" Style Identifiers
  Kaliya * 
  wrote on 10/20/2006, 11:57 AM: 
  
  I think it is a terrible 
idea.1) If you put something out into the market that looks like an 
e-mail it will be used like an e-mail. I have personal experience with this. 
I had a AIM handle for the Mac part of the universe [EMAIL PROTECTED] (it was not an e-mail 
address) but because it looked like one people used it like one and I 
basically had to go to .mac and pay for an account so that the wires did not 
cross. This came 
  out of the discussions we have about a smooth migration path for our users at 
  AOL.  In our case the [EMAIL PROTECTED] nickname is also a 
  resolvable email address, though it may not be the primary mail account of the 
  user.  I'd suggest that as a best practice, anywhere that a [EMAIL PROTECTED] nickname is used, it 
  should also be a resolvable email address.  And there should always be an 
  option to not use something that looks like an email 
address.
  2) I think OpenID is new and 
needs a new way to identify folks. And it is our job to teach people about 
this new way.  Lots of services give people homepages within their 
spaces...myspace, AIMpages etc.  so they can use those URL's if they 
don't have one yet they can get one. There's a bootstrapping problem here.  It's very, 
  very hard to promote the use of something that requires a more complex login 
  flow to replace something that is very simple (albeit limited and in its own 
  silo).  How can we cross this chasm?  Our suggestion is to support 
  existing practice of [EMAIL PROTECTED] in a standard way, while 
  being open to new practices.  Once we can support both we can gain 
  experience and start gradually migrating people over to the new world.  
  At least that's my take.-- John PanzerSystem Architecthttp://abstractioneer.org
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style Identifiers

[Josh Hoyt]

On 10/19/06, Recordon, David <[EMAIL PROTECTED]> wrote:
> The proposal we came up with was within the spec describing what to do
> if someone were to enter "[EMAIL PROTECTED]" in a Relying Party's OpenID
> login form.

Here are the past threads that I could find about this issue:

1. http://lists.danga.com/pipermail/yadis/2005-May/000412.html
2. http://lists.danga.com/pipermail/yadis/2005-June/000501.html
3. http://lists.danga.com/pipermail/yadis/2005-July/001113.html
4. http://lists.danga.com/pipermail/yadis/2005-November/001589.html

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

Re: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style Identifiers

[Kaliya *]

On 10/20/06, John Panzer <[EMAIL PROTECTED]> wrote:



  


Kaliya *
wrote on 10/20/2006, 11:57 AM:


I think it is a terrible idea.
  
1) If you put something out into the market that looks like an e-mail
it will be used like an e-mail. I have personal experience with this. 
  
I had a AIM handle for the Mac part of the universe [EMAIL PROTECTED] (it was not an e-mail
address) but because it looked like one people used it like one and I
basically had to go to .mac and pay for an account so that the wires
did not cross.
  
This came out of the
discussions we have about a smooth migration path for our users at
AOL.  In our case the [EMAIL PROTECTED] nickname is also a resolvable
email address, though it may not be the primary mail account of the
user.  I'd suggest that as a best practice, anywhere that a
[EMAIL PROTECTED] nickname is used, it should also be a resolvable email
address.  And there should always be an option to not use something
that looks like an email address.Why not just give them @aol*username.  or http://www.aol.com/username.  Both are valid openID and it is NOT and e-mail address. I bet you have a tone of users who simply have AOL handles for IM and don't want to activiate or deal with e-mail systems. 
I get that your users are 'naive' and don't get new things and some don't know how to scroll.  BUT YOU CAN EDUCATE THEM.  at one point e-mail didn't exist and we had to teach people about that.  I explain this stuff to normal folks all the time these days. I think regular folks are willing to learn this stuff to make the web safer and more convenient for them. 
 
2) I think OpenID is new and needs a
new way to identify folks. And it is our job to teach people about this
new way.  Lots of services give people homepages within their
spaces...myspace, AIMpages etc.  so they can use those URL's if they
don't have one yet they can get one. 
There's a bootstrapping
problem here.  It's very, very hard to promote the use of something
that requires a more complex login flow to replace something that is
very simple (albeit limited and in its own silo).  How can we cross
this chasm?  Our suggestion is to support existing practice of
[EMAIL PROTECTED] in a standard way, This "e-mail is the standards way" is false. It really is not user fridnely. I resent sites asking me for my e-mail and requiring me to use it as a login. I have at least 4 e-mails. I use different ones a different sites and can't remember which one I use were. I am all for figuring out Bootstrapping but I think approach is miss guided. 

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

Re: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style Identifiers

[John Panzer]

Kaliya *
wrote on 10/20/2006, 11:57 AM:


I think it is a terrible idea.
  
1) If you put something out into the market that looks like an e-mail
it will be used like an e-mail. I have personal experience with this. 
  
I had a AIM handle for the Mac part of the universe [EMAIL PROTECTED] (it was not an e-mail
address) but because it looked like one people used it like one and I
basically had to go to .mac and pay for an account so that the wires
did not cross.
  
This came out of the
discussions we have about a smooth migration path for our users at
AOL.  In our case the [EMAIL PROTECTED] nickname is also a resolvable
email address, though it may not be the primary mail account of the
user.  I'd suggest that as a best practice, anywhere that a
[EMAIL PROTECTED] nickname is used, it should also be a resolvable email
address.  And there should always be an option to not use something
that looks like an email address.
2) I think OpenID is new and needs a
new way to identify folks. And it is our job to teach people about this
new way.  Lots of services give people homepages within their
spaces...myspace, AIMpages etc.  so they can use those URL's if they
don't have one yet they can get one. 
There's a bootstrapping
problem here.  It's very, very hard to promote the use of something
that requires a more complex login flow to replace something that is
very simple (albeit limited and in its own silo).  How can we cross
this chasm?  Our suggestion is to support existing practice of
[EMAIL PROTECTED] in a standard way, while being open to new practices. 
Once we can support both we can gain experience and start gradually
migrating people over to the new world.  At least that's my take.

-- 
John
Panzer
System Architect
http://abstractioneer.org




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

Re: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style Identifiers

[Kaliya *]

I think it is a terrible idea.1) If you put something out into the market that looks like an e-mail it will be used like an e-mail. I have personal experience with this. I had a AIM handle for the Mac part of the universe 
[EMAIL PROTECTED] (it was not an e-mail address) but because it looked like one people used it like one and I basically had to go to .mac and pay for an account so that the wires did not cross.
2) I think OpenID is new and needs a new way to identify folks. And it is our job to teach people about this new way.  Lots of services give people homepages within their spaces...myspace, AIMpages etc.  so they can use those URL's if they don't have one yet they can get one. 
3) Giving folks i-names is an option too.  URLs do certain things well...XRI alows people to migrate from @AOL*julie to =julie and basically maintain the same identifier (The i-number behind it).4) We need to follow the creative commons lead and have lots of different ways of explaining the new way to people. It is not that complex. I explain it to normal people all the time. We are getting the right metaphors and ways to talk about them. We should do some little videos adn comic strips to explaing this new way. I think it is the task of the OpenID Community Org to produce such things. 
=Kaliya
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style Identifiers

[Jonathan Daugherty]

# It might create some confusion depending on the audience.  For the
# audience that doesn't run their own web server, or have their own
# blog, it might be confusing to enter a URI.

By confusion, I mean entering something that looks like an email but
probably isn't, and trying to figure out just what the relationship
between email-looking things and email addresses really is.  And
seeing an RP render an email-like thing with "http://"; on the front
and "/" on the end.  The biggest subset of our prospective audience is
the one that is not going to readily understand this, and that is
going to create a lot of confusion.

-- 
  Jonathan Daugherty
  JanRain, Inc.
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style Identifiers

[George Fletcher]

It might create some confusion depending on the audience.  For the 
audience that doesn't run their own web server, or have their own blog, 
it might be confusing to enter a URI. 

This approach would help those users make the transition without 
restricting the users who do "get it" from entering URIs.  It also 
provides a simple way for RPs to appeal to a larger set of users (e.g. 
my mother-in-law wouldn't understand what to enter if asked for a URI 
based identifier).

Thanks,
George

P.S. Hopefully I've got Thunderbird sending plain text messages now so 
they don't get "scrubbed" in the archives.  Sorry about that.

Recordon, David wrote:
> Yes, potentially.  It is a bit of a hybrid approach I guess.
>
> --David 
>
> -Original Message-
> From: Jonathan Daugherty [mailto:[EMAIL PROTECTED] 
> Sent: Friday, October 20, 2006 12:59 PM
> To: Recordon, David
> Cc: Drummond Reed; specs@openid.net
> Subject: Re: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style
> Identifiers
>
> # The thing is they aren't really giving them their email address.
> # Rather an identifier which looks like an email address to a user and #
> in some cases may also be an email address.
>
> Isn't that likely to create a lot of confusion?
>
> --
>   Jonathan Daugherty
>   JanRain, 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

Re: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style Identifiers

[George Fletcher]

[Sorry for the strange
posting format.  I got on the list after seeing
the emails. --George]

First, I'm new to the list and don't want to resurface an old and long
debated topic.  

To me this proposal is about how to make finding the
user's IDP simpler using something the customer is already familiar
with. Therefore, the email address format in not an
identifier, but rather a way to hint to the RP both my IDP and an
identifier to use at the IDP.  The desire being to address current user
behavior which doesn't include specifying a URI as a login mechanism. 
I don't use URI's at Flickr, Apple, Yahoo, Google, AOL or Microsoft. 
Trying to educate "the masses" to remember a new identifier, that for
some is meaningless (i.e. the user might not have a blog or other URL
that they are used to remembering or sharing), is difficult.

As another option, the RP could present UI that has a drop down of
"common IDPs" and
then based on the selected "common IDP" provide another text entry for
that IDP's form of identifer. However, that somewhat defeats the
purpose of trying to have a very simple form entry mechanism which
customers can get used to seeing and feel comfortable with.  It also
places a burden on the RP to keep their UI up-to-date.

Of course, my
expectation is that this syntax would be optional; the user can always
specify their full URI identifier.

I agree that this kind of an identifier is not portable, but I'm
guessing that most users wouldn't know how to tweak their blog to add
the necessary OpenID 1.1 HTML code to change their IDP.  Most users,
just use flickr for photos and if flickr supported OpenID, could
potentially use some URI defined for them by flickr as an OpenID
identifier.  This identifier from flickr would not be very easily
portable.

Thanks,
George

  There have been several long threads in the past about using email addresses
as OpenID identifiers. The conclusion each time has been to avoid it. I
don't remember all the arguments, but among them are:

* Privacy: the last thing many users want to give a website is their email
address.
* Reassignability: email addresses are not only reassignable, but for some
domains, they are notoriously short-lived identifiers.
* Non-portability: unless you own the top-level domain, they aren't
portable.

Food for thought...

=Drummond 

-Original Message-
From: specs-bounces at openid.net [mailto:specs-bounces at openid.net] On Behalf
Of Recordon, David
Sent: Thursday, October 19, 2006 6:46 PM
To: specs at openid.net
Subject: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style Identifiers

In meeting with a large service provider this week, an issue around end
user usability came up.  The concern they expressed was that users are
know how to enter usernames or email addresses to initiate the login
process.  While directed identity allows the user to enter
"example.com", they feel that it still is a bit of a stretch at this
time for any major deployment of OpenID.

The proposal we came up with was within the spec describing what to do
if someone were to enter "user at example.com" in a Relying Party's OpenID
login form.  The idea is that the RP splits the string on the "@" and
then treats "example.com" as the IdP Identifier.  This thus doesn't
actually require any changes to the protocol itself.  Any Relying Party
can do this today, but they desire to see this as part of the
specification itself so they wouldn't be doing anything special.

Within the http://www.lifewiki.net/openid/ConsolidatedDelegationProposal
proposal, in case one, openid.identity would be set to
"http://openid.net/identifier_select/2.0" and then instead of
openid.portable being empty, in this case "user at example.com" would be
sent to the IdP.  While not perfectly mapping to the definition of the
openid.portable field, it doesn't seem like that much of a hack to do
this.

While I certainly am not looking to re-kindle the "Why a URI?" debate,
http://[EMAIL PROTECTED] is also technically a valid URI.  It is used in
many cases by browsers to provide a username when making a web request.

So while this is a little funky, I really think the increased usability
offered by describing what a RP should do when a string like this is
entered seems to outweigh the potential conceptual confusion.

Thoughts?

--David




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

RE: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style Identifiers

[Recordon, David]

Yes, potentially.  It is a bit of a hybrid approach I guess.

--David 

-Original Message-
From: Jonathan Daugherty [mailto:[EMAIL PROTECTED] 
Sent: Friday, October 20, 2006 12:59 PM
To: Recordon, David
Cc: Drummond Reed; specs@openid.net
Subject: Re: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style
Identifiers

# The thing is they aren't really giving them their email address.
# Rather an identifier which looks like an email address to a user and #
in some cases may also be an email address.

Isn't that likely to create a lot of confusion?

--
  Jonathan Daugherty
  JanRain, Inc.

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

Re: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style Identifiers

[Jonathan Daugherty]

# The thing is they aren't really giving them their email address.
# Rather an identifier which looks like an email address to a user and
# in some cases may also be an email address.

Isn't that likely to create a lot of confusion?

-- 
  Jonathan Daugherty
  JanRain, Inc.
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

RE: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style Identifiers

[Recordon, David]

The thing is they aren't really giving them their email address.  Rather
an identifier which looks like an email address to a user and in some
cases may also be an email address.

In terms of privacy, if it is known that the OpenID Identifier scheme is
http://example.com/username then it is trivial for a RP to change that
into an email address [EMAIL PROTECTED] even if the user never
entered that directly.

On the response from the IdP, the IdP would not assert that the user
owns [EMAIL PROTECTED]  Rather it would perform the normal directed
identity flow returning an actual URL.  Take this format of identifier
as:
1) Format users already type
2) Easy for RP to start directed identity flow
3) Pass to IdP as a "hint" for who the user needs to authenticate as

--David 

-Original Message-
From: Drummond Reed [mailto:[EMAIL PROTECTED] 
Sent: Friday, October 20, 2006 1:04 AM
To: Recordon, David; specs@openid.net
Subject: RE: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style
Identifiers

There have been several long threads in the past about using email
addresses as OpenID identifiers. The conclusion each time has been to
avoid it. I don't remember all the arguments, but among them are:

* Privacy: the last thing many users want to give a website is their
email address.
* Reassignability: email addresses are not only reassignable, but for
some domains, they are notoriously short-lived identifiers.
* Non-portability: unless you own the top-level domain, they aren't
portable.

Food for thought...

=Drummond 

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Recordon, David
Sent: Thursday, October 19, 2006 6:46 PM
To: specs@openid.net
Subject: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style Identifiers

In meeting with a large service provider this week, an issue around end
user usability came up.  The concern they expressed was that users are
know how to enter usernames or email addresses to initiate the login
process.  While directed identity allows the user to enter
"example.com", they feel that it still is a bit of a stretch at this
time for any major deployment of OpenID.

The proposal we came up with was within the spec describing what to do
if someone were to enter "[EMAIL PROTECTED]" in a Relying Party's OpenID
login form.  The idea is that the RP splits the string on the "@" and
then treats "example.com" as the IdP Identifier.  This thus doesn't
actually require any changes to the protocol itself.  Any Relying Party
can do this today, but they desire to see this as part of the
specification itself so they wouldn't be doing anything special.

Within the http://www.lifewiki.net/openid/ConsolidatedDelegationProposal
proposal, in case one, openid.identity would be set to
"http://openid.net/identifier_select/2.0"; and then instead of
openid.portable being empty, in this case "[EMAIL PROTECTED]" would be
sent to the IdP.  While not perfectly mapping to the definition of the
openid.portable field, it doesn't seem like that much of a hack to do
this.

While I certainly am not looking to re-kindle the "Why a URI?" debate,
http://[EMAIL PROTECTED] is also technically a valid URI.  It is used in
many cases by browsers to provide a username when making a web request.

So while this is a little funky, I really think the increased usability
offered by describing what a RP should do when a string like this is
entered seems to outweigh the potential conceptual confusion.

Thoughts?

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


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

WG: OpenID newbie

[Baier, Tobias]

Erm, it seems that my message was blanked, maybe because of my S/MIME 
signature? I'll try without, then.

Oh, what a good start :)

Cheers,
Toby 

-Ursprüngliche Nachricht-
Von: Baier, Tobias 
Gesendet: Freitag, 20. Oktober 2006 10:51
An: specs@openid.net
Betreff: OpenID newbie

Hello all,
I'm new to the list, so please let me introduce myself: My name is Toby Baier, 
I work for CoreMedia AG, a CMS and DRM company in Hamburg, Germany.
Previous to this job I was at University of Hamburg, where I wrote a 
dissertation on personal identity management (see
https://vsis-www.informatik.uni-hamburg.de/members/info.php/36 for a list of 
publications, http://www.sub.uni-hamburg.de/opus/volltexte/2006/2746/ is the 
dissertation (in german)). It's not the greatest work on identity management 
but hey.

Now I stumbled upon OpenID (via Sxip, Dick, your presentation "Who's that Dick" 
is ingenious!) and I am really exited about it. I'd love to contribute, if I 
can. My main focus during my university time was on decentralization of 
services (which you've got) and decentralization of attribute specification 
(which you've got, if I understand your spec). I also focused on attribute 
translation and privacy.

Now it's quite hard to get into the discussions here, traffic is a little high 
if you didn't get the first message of a thread. The status page on openid.net 
does not really tell me what you're on at the moment. So please let me ask: 
you're about to release a 2.0 spec for OpenID: does that include only the 
authentication part, or is attribute exchange also part of current discussion? 
Are there any thoughts on translations between different attribute lists (I 
called those "part ontologies" in my work)? Do you have anything on automatic 
privacy negotiation (say, P3P)?

Again, hello to everyone!

Cheers,
Toby

--
Dr. Tobias Baier
Software Engineer 

tel +49.40.325587.523
fax +49.40.325587.999
[EMAIL PROTECTED]

CoreMedia AG
Ludwig-Erhard-Str. 18
20459 Hamburg, Germany
www.coremedia.com
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

OpenID newbie

[Baier, Tobias]

smime.p7m
Description: S/MIME encrypted message
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: OpenID Login Page Link Tag

[Martin Atkins]

Drummond Reed wrote:
> I initially agreed as well. But to play devil's advocate, the link-to-XRDS
> option could actually be pretty efficient. Any HTML page could simply
> advertise the availability of its Yadis XRDS file using an XRDS link in the
> header. Assuming that many or all of the pages on a site would be covered by
> the same XRDS file, the browser would only need to download it once to cover
> the entire site. The XRDS would expire (using the same cache control that
> XRI resolvers use) and be refreshed as needed.
> 
> This is the architecture that P3P used
> (http://www.w3.org/TR/P3P/#ref_syntax). 
> 
> The XRDS file could provide discovery of multiple services representing the
> RP, not just the login page.
> 

This is not incredibly different to what happens when you have a 
site-wide CSS stylesheet. In fact, it is possibly *better* than that 
situation since you don't need to delay page rendering while waiting for 
the Yadis document to download.

I wonder, though, whether we are asking too much of browsers' plugin 
interfaces? This is an honest question, as someone who's never written a 
browser chrome plugin before.

I guess IE's ones are just COM objects and can thus do whatever they 
like, but what of Firefox? Chrome overlays? Does that mean that they can 
access the HTTP component somehow to make HTTP requests?

I think Opera's pretty unlikely as it has no real plugin interface to 
speak of. I have no idea at all about Safari.

Anyone care to elaborate? There's no point in speccing something that's 
unimplementable, but it's probably okay as long as IE and Firefox can do 
it; the others can just catch up later.


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