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

2006-11-10 Thread David Fuelling
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
> Behalf Of Martin Atkins
> Sent: Friday, November 10, 2006 2:41 AM
> To: [EMAIL PROTECTED]
> Subject: Re: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style
Identifiers
>
> I provide email addresses to some of my friends, but I don't provide
> them with corresponding OpenID identities. By an unfortunate twist of
> fate, the domain I provide these addresses in is also my website, and
> since my site doesn't require authentication the WWW-Authenticate header
> is ignored. Consequently, http://[EMAIL PROTECTED]/ will end up
> at *my* website, not the website of the person who uses
> [EMAIL PROTECTED]
>

Ok, so (just to clarify) in your example we're talking about an email
address '[EMAIL PROTECTED]' that maps to a url at an IdP, such that
the mapped URL includes the username ('http://[EMAIL PROTECTED]')
[** just to be clear, this is David R's proposal...my proposal ignores the
userid in the email address **]

So, in your example, if you have given someone an email address with a
domain 'mydomain.com', and you choose not to offer OpenId services, then
emails in your domain can't be used with OpenId.  I don't see the problem,
-- you own the domain, after all, and should control that decision.

Additionally, your scenario is also true in the case of a regular Identity
URL that you give out.  If you provide an Identity URL
'http://someuser.mydomain.com', but you happen to support some other User
Centric Identity standard (i.e., not OpenId), and your user tries to use
the URL that you provided (with an OpenId RP), he'd get the same result.


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


Re: XRDS vs. DNS level identity (was RE: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style Identifiers)

2006-11-09 Thread Johannes Ernst

On Nov 8, 2006, at 23:42, Hallam-Baker, Phillip wrote:

> What you are calling discovery is what I would term location.
>
> URL - Uniform Resource Locator
>
> The locator is completely self contained, no discovery necessary,  
> all the information you need to resolve is there.

Gotta nitpick here, sorry about that:

I don't think it does. For example, the URL does not tell me:
  - what HTTP version the server can speak
  - what representations of the resource it can return, e.g. MIME types
  - what HTTP methods it understands (e.g. WebDav)
etc.etc. All the stuff that is in the HTTP headers beyond the URLs.

One way of looking at XRDS is to add more meta-data to URLs just like  
certain HTTP fields add more meta-data. Theoretically, one could pack  
all of that meta-data into HTTP header extensions, but that's ...  
well, not so good. So the header adds a level of indirection from  
where that info can be retrieved.

There's another problem with using DNS for this: DNS would have a  
very hard time returning 1000 different XRDS files (or equivalent)  
from 1000 different URLs hosted on the same server. Just think of  
identity-related services that the IdP/OP charges for: some users on  
the host will have bought other packages (e.g. voice auth vs. fob)  
than others, and thus their XRDS file changes -- and rather quickly,  
e.g. when they don't pay on time.

>> -Original Message-
>> From: Dick Hardt [mailto:[EMAIL PROTECTED]
>> Sent: Thursday, November 09, 2006 2:05 AM
>> To: Johannes Ernst
>> Cc: Hallam-Baker, Phillip; specs@openid.net; general
>> Subject: Re: XRDS vs. DNS level identity (was RE: [PROPOSAL]
>> Handle "http://[EMAIL PROTECTED]" Style Identifiers)
>>
>> I agree with Johannes here. DNS is not user accessible (for
>> good reason) Documents on a web server are relatively more  
>> accessible.
>>
>> wrt. DNS, I think DNSSEC could have a significant role in
>> providing server to server discovery, specifically of key key
>> material.
>>
>> -- Dick
>>
>> On 8-Nov-06, at 8:00 PM, Johannes Ernst wrote:
>>
>>> Just commenting on the XRDS discovery from HTTP URLs bit.
>>>
>>> Using DNS as a mechanism, given a URL, to discover the
>> location of, or
>>> obtain the content or equivalent of, the XRDS file, was
>> proposed back
>>> then in Yadis 0.x days, and rejected. The reason being that
>> any such
>>> mechanism would require the system administrator in charge
>> of the DNS
>>> system to "configure XRDS" for any and all users in that domain. It
>>> would give that system administrator an effective veto
>> (exercised by
>>> being lazy, for example) over whether or not users could
>> use OpenID on
>>> that domain, and in particular which services to reference
>> from that
>>> file (e.g. competitive services). There was general
>> consensus that for
>>> a "user-centric" identity system, that was not desirable,
>> and that's
>>> why we decided in favor of the HTTP header extension, its HTML
>>> equivalent, and the shortcut via the MIME type.
>>>
>>> We felt on safe ground with respect to naming design, because it's
>>> very much the same approach as, say, the reference of
>> embedded GIFs or
>>> CSS in HTML, or the use of URLs to identify DTDs in XML.
>>>
>>>
>>> On Nov 8, 2006, at 17:19, Hallam-Baker, Phillip wrote:
>>>
>>>> Quite a few years went into the design of DNS.
>>>>
>>>> The concern I have here is that to influence the wider
>> network is a
>>>> very serious challenge.
>>>>
>>>> Innovation in naming is the single hardest thing to do in
>> a network
>>>> protocol. I have seen UDDI, Realnames, X.500, so many proposals.
>>>>
>>>>
>>>> When someone tells me a simple thing is too complex and
>> then proposes
>>>> to do the single hardest, most complex thing in computer
>> networking I
>>>> have concerns.
>>>>
>>>>> -Original Message-
>>>>> From: Drummond Reed [mailto:[EMAIL PROTECTED]
>>>>> Sent: Wednesday, November 08, 2006 7:42 PM
>>>>> To: Hallam-Baker, Phillip; Recordon, David; 'David Fuelling'
>>>>> Cc: specs@openid.net; [EMAIL PROTECTED]
>>>>> Subject: XRDS vs. DNS level identity (was RE: [PROPOSAL] Handle
>>>>> "http://[EMAIL PROTECTED]" Style Identifiers)
>>>>>
>>>>> Phillip,
>>>>&

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

2006-11-09 Thread David Fuelling
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
> Behalf Of Martin Atkins
> Sent: Thursday, November 09, 2006 5:36 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style Identifiers
> 
> Sometimes these things will be character-for-character identical to a
> given email address by coincidence, but there's no way to enforce this
> nor any guarantee that the user controlling http://[EMAIL PROTECTED]/ is
> the same user that controls mailto:[EMAIL PROTECTED]
>

Can you provide an example (real or otherwise) of such a scenario?  Do you
really envision any domain owner giving 'http://[EMAIL PROTECTED]' to one
person, whilst giving 'mailto:[EMAIL PROTECTED]' to a different user?

 

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


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

2006-11-09 Thread Peter Watkins
On Wed, Nov 08, 2006 at 11:16:41PM -0500, David Fuelling wrote:

> Couldn't one make the opposite argument -- that most people's email address
> NOT working when they plug it into the OpenId login field could actually be
> a good thing? (especially in the beginning of OpenID)

> Scenario #2 (WITH email allowed in the OpenId login form):  User encounters
> an "openid enabled" site, and decides they are curious about the new "way"
> to login.  If their email domain supports OpenId, then there's really no
> reason for a novice user NOT to use OpenId -- it works with the email
> address.
> 
> On the other hand, if the RP determines that the specified email address
> doesn't support OpenId, it (the RP) then comes back to the User with an
> educational page explaining why the email doesn't work, perhaps with a "call
> your email provider and encourage them to adopt openid...and here's why".  

This makes a lot of sense to me.

What's appealing to me about OpenID is that it's a very easy (user- and admin-
friendly) system for ad-hoc federation/assertions. Relying Parties don't need
any special out-of-band pre-authentication setup with IdPs. Nor is there a need
for new PKI infrastructures -- the PKI behind https suffices. For users, no
special client software is needed.

Why try to teach users this homesite/unique OpenID identifier "URL" concept
when OpenID could use an identifier the user already understands & has, 
like an email address, for locating the user's IdP?

-Peter

> > -Original Message-
> > From: Dick Hardt [mailto:[EMAIL PROTECTED]
> > Sent: Wednesday, November 08, 2006 5:06 PM
> > To: David Fuelling
> > Cc: specs@openid.net
> > Subject: Re: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style Identifiers

> > A Homesite is a new concept for users, so when they see a prompt for
> > it, they will know they have one or not. They are not just typing in
> > a random URL.
> > 
> > Pretty much every user has an email address, so a prompt asking for
> > an email would suggest to user that their email will work -- which of
> > course hardly any will.
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs


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

2006-11-09 Thread David Fuelling
Hi Martin,

This is interesting.

I guess your suggestion (see your msg below) deals with a sub-topic of the
whole "should email be allowed in the OpenId login form" debate, which is
this: 

"If email is allowed in the OpenId login form, should the
mapping/normalization include the email Userid...OR, should OpenId ignore
the email address userid, and map/normalize an email address to a specific
IdP URL, allowing the IdP more flexibility in determining how to do login"?

1.) I'm not convinced that OpenId specifying a mapping/normalization scheme
that maps email addresses to IdP/OP URL's is really so bad.  We're already
mapping/normalizing www.cnn.com to its correct http scheme equivalent
(http://www.cnn.com).

2.) In Mozilla 2.0, if I type [EMAIL PROTECTED] into the URL bar, it
normalizes that (behind the scenes) to
http://beth:@google.com.  Because google.com doesn't require
user auth, I'm then redirected to http://google.com, which redirects to
http://www.google.com.

3.) The voice-activated OpenId thread on these lists comes to mind - a
Userid component of an email address may not be required, nor necessary in
many cases if a user is identified on the IdP/OP by his/her voice (for
example).

I'm curious to hear yours (and everyone else's) thoughts on this.  I don't
think we want to couple OpenId too tightly (if at all) to an email address
-- just provide an easy-to-use bridge between the two.

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
> Behalf Of Martin Atkins
> Sent: Thursday, November 09, 2006 12:05 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style Identifiers
>
> One idea we came up with before was to specify that [EMAIL PROTECTED]
> becomes http://[EMAIL PROTECTED]/ and the RP should try sending an
> authenticate header for basic auth with base64 of "blah:" (empty password)
> 
> This way it's (kinda) true to the meaning of that portion of the URL
> scheme and it allows the IdP to distinguish between different users.
> 
> We'd have to check to make sure that this never conflicts with Basic
> auth implementations built into servers/frameworks, of course.
> 
> 
> ___
> general mailing list
> [EMAIL PROTECTED]
> http://openid.net/mailman/listinfo/general

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


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

2006-11-09 Thread David Fuelling
Phillip,

Ok, now I understand what you're saying about "not using Http in this way".

However, I'm not advocating doing anything with the username part of an
email (this might be where we're missing each other).  I'm saying that we
just take the  +  of an email, normalize it per the OpenId
spec, and use that Http URL that we get as the URL of our IdP.   

Let me elaborate.

In a previous message, you wrote:

> > > There are two issues here:
> > >
> > > 1) The user presentation of the identifier
> > > 2) The machine presentation
> > >
> > > The two do not need to be the same. www.cnn.com works
> > perfectly well
> > > as a way to locate CNN. That is a perfectly acceptable user
> > > presentation. It is not an acceptable machine presentation and
> > > browsers SHOULD NOT accept href="www.cnn.com".

If the "user presentation" value is an email (e.g., '[EMAIL PROTECTED]'),
then what is wrong with the machine presentation (wrt OpenId) being
'http://example.com'?

The OpenId spec is already doing this with URL's in section 8.2
(Normalization).  We're mapping/normalizing 'www.cnn.com' to
'http://www.cnn.com', even though www.cnn.com is not (technically) a validly
schemed Http url.  Why not do the same with email addresses?

> -Original Message-
> From: Hallam-Baker, Phillip [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, November 08, 2006 4:37 PM
> To: David Fuelling
> Cc: specs@openid.net; [EMAIL PROTECTED]
> Subject: RE: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style Identifiers
> 
> Please don't map to Http this way.
> 
> It would be fine to define a fixed mapping from a user identifier to http.
> But it has to respect the http scheme design and be crafted to avoid
> operability concerns.
> 
> http://example.com/user would be acceptable as meeting the scheme design.
> It is absolutely critical to maintain left/right hierarchy.
> 
> The username/password pieces in http were not well thought out and may
> have to be eliminated.

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


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

2006-11-09 Thread Rich Thornberg
[re-sending in plain-text]

Many sites allow users to register for services using an e-mail address. 
  Often such sites require the user to verify ownership of the e-mail 
address by sending an e-mail to the just registered address, but not 
always.  When a site allows such a registration they also request the 
user to create a password.  So users can access "service" by providing 
e-mail/password -- my guess is that many users use the same password as 
required for their actual e-mail account, but I have no idea how many. 
People do this all the time.  I know of at least one pretty large portal 
that allows it.

If e-mail addresses could be used, sites could lookup the domain using 
whatever method is described by OpenId, find the OP and let that collect 
the id/password.  If the domain isn't an OP, the site could handle it 
locally as a registered e-mail address/identity.

Rich

On 11/8/06 5:06 PM, Dick Hardt wrote the following:
> Hi David
> 
> A Homesite is a new concept for users, so when they see a prompt for  
> it, they will know they have one or not. They are not just typing in  
> a random URL.
> 
> Pretty much every user has an email address, so a prompt asking for  
> an email would suggest to user that their email will work -- which of  
> course hardly any will.
> 
> -- Dick
> 
> On 8-Nov-06, at 10:51 AM, David Fuelling wrote:
> 
>> Dick,
>>
>> It seems like the same problem exists if a user types an IdP URL.   
>> If that
>> URL (e.g., example.com) isn't a valid OpenId IdP, then the user  
>> will still
>> encounter a problem.
>>
>> Shouldn't the RP show an "educational page" if a
>> Homesite/i-name/OpenId/email doesn't resolve to something that  
>> OpenID can
>> use?
>>
>> David Fuelling
>>
>>> -Original Message-
>>> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]  
>>> On Behalf
>>> Of Dick Hardt
>>> Sent: Sunday, October 22, 2006 12:26 PM
>>> To: John Panzer
>>> Cc: Kaliya *; specs@openid.net
>>> Subject: Re: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style  
>>> Identifiers
>>>
>>> ...
>>>
>>> If we support email addresses, then the prompt may look something
>>> like this:
>>>
>>>  "email | Homesite | i-name | OpenID"
>>>
>>> Now any user with an email address thinks they can type it into the
>>> box and login. This of course is not going to be the case.
>>>
>>
> 
> ___
> 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: XRDS vs. DNS level identity (was RE: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style Identifiers)

2006-11-08 Thread Hallam-Baker, Phillip
What you are calling discovery is what I would term location.

URL - Uniform Resource Locator

The locator is completely self contained, no discovery necessary, all the 
information you need to resolve is there. 

> -Original Message-
> From: Dick Hardt [mailto:[EMAIL PROTECTED] 
> Sent: Thursday, November 09, 2006 2:05 AM
> To: Johannes Ernst
> Cc: Hallam-Baker, Phillip; specs@openid.net; general
> Subject: Re: XRDS vs. DNS level identity (was RE: [PROPOSAL] 
> Handle "http://[EMAIL PROTECTED]" Style Identifiers)
> 
> I agree with Johannes here. DNS is not user accessible (for 
> good reason) Documents on a web server are relatively more accessible.
> 
> wrt. DNS, I think DNSSEC could have a significant role in 
> providing server to server discovery, specifically of key key 
> material.
> 
> -- Dick
> 
> On 8-Nov-06, at 8:00 PM, Johannes Ernst wrote:
> 
> > Just commenting on the XRDS discovery from HTTP URLs bit.
> >
> > Using DNS as a mechanism, given a URL, to discover the 
> location of, or 
> > obtain the content or equivalent of, the XRDS file, was 
> proposed back 
> > then in Yadis 0.x days, and rejected. The reason being that 
> any such 
> > mechanism would require the system administrator in charge 
> of the DNS 
> > system to "configure XRDS" for any and all users in that domain. It 
> > would give that system administrator an effective veto 
> (exercised by 
> > being lazy, for example) over whether or not users could 
> use OpenID on 
> > that domain, and in particular which services to reference 
> from that 
> > file (e.g. competitive services). There was general 
> consensus that for 
> > a "user-centric" identity system, that was not desirable, 
> and that's 
> > why we decided in favor of the HTTP header extension, its HTML 
> > equivalent, and the shortcut via the MIME type.
> >
> > We felt on safe ground with respect to naming design, because it's 
> > very much the same approach as, say, the reference of 
> embedded GIFs or 
> > CSS in HTML, or the use of URLs to identify DTDs in XML.
> >
> >
> > On Nov 8, 2006, at 17:19, Hallam-Baker, Phillip wrote:
> >
> >> Quite a few years went into the design of DNS.
> >>
> >> The concern I have here is that to influence the wider 
> network is a 
> >> very serious challenge.
> >>
> >> Innovation in naming is the single hardest thing to do in 
> a network 
> >> protocol. I have seen UDDI, Realnames, X.500, so many proposals.
> >>
> >>
> >> When someone tells me a simple thing is too complex and 
> then proposes 
> >> to do the single hardest, most complex thing in computer 
> networking I 
> >> have concerns.
> >>
> >>> -Original Message-
> >>> From: Drummond Reed [mailto:[EMAIL PROTECTED]
> >>> Sent: Wednesday, November 08, 2006 7:42 PM
> >>> To: Hallam-Baker, Phillip; Recordon, David; 'David Fuelling'
> >>> Cc: specs@openid.net; [EMAIL PROTECTED]
> >>> Subject: XRDS vs. DNS level identity (was RE: [PROPOSAL] Handle 
> >>> "http://[EMAIL PROTECTED]" Style Identifiers)
> >>>
> >>> Phillip,
> >>>
> >>> Please don't shoot me -- I am just the messenger -- but a 
> year-long 
> >>> effort
> >>> (Yadis) went into the design and deployment of XRDS 
> documents as the 
> >>> discovery infrastructure for OpenID.
> >>>
> >>> There are numerous reasons for this, but they boil down to
> >>> this: the XRDS layer of identity is rooted at a higher layer than 
> >>> that of DNS. Users don't just have DNS names in OpenID; they have 
> >>> URLs or XRIs. Those URLs or XRIs resolve to XRDS documents, which 
> >>> perform mapping of URLs/XRIs to URI-identified service endpoints. 
> >>> These service endpoint URIs in turn map down to services 
> resolvable 
> >>> at the DNS layer (which then of course map down to 
> machine addresses 
> >>> at the IP layer).
> >>>
> >>> I fully understand that you "have seen so many attempts 
> to reinvent 
> >>> it" (the DNS). OpenID and URL/XRI-based identity is not 
> an attempt 
> >>> to reinvent it. It is the emergence of identity 
> infrastructure at a 
> >>> higher layer designed to take advantage of the abstractions 
> >>> available at that layer, including:
> >>>
> >>> * URI and XRI syntax (much rich

Re: XRDS vs. DNS level identity (was RE: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style Identifiers)

2006-11-08 Thread Dick Hardt
I agree with Johannes here. DNS is not user accessible (for good reason)
Documents on a web server are relatively more accessible.

wrt. DNS, I think DNSSEC could have a significant role in providing  
server to server discovery, specifically of key key material.

-- Dick

On 8-Nov-06, at 8:00 PM, Johannes Ernst wrote:

> Just commenting on the XRDS discovery from HTTP URLs bit.
>
> Using DNS as a mechanism, given a URL, to discover the location of,
> or obtain the content or equivalent of, the XRDS file, was proposed
> back then in Yadis 0.x days, and rejected. The reason being that any
> such mechanism would require the system administrator in charge of
> the DNS system to "configure XRDS" for any and all users in that
> domain. It would give that system administrator an effective veto
> (exercised by being lazy, for example) over whether or not users
> could use OpenID on that domain, and in particular which services to
> reference from that file (e.g. competitive services). There was
> general consensus that for a "user-centric" identity system, that was
> not desirable, and that's why we decided in favor of the HTTP header
> extension, its HTML equivalent, and the shortcut via the MIME type.
>
> We felt on safe ground with respect to naming design, because it's
> very much the same approach as, say, the reference of embedded GIFs
> or CSS in HTML, or the use of URLs to identify DTDs in XML.
>
>
> On Nov 8, 2006, at 17:19, Hallam-Baker, Phillip wrote:
>
>> Quite a few years went into the design of DNS.
>>
>> The concern I have here is that to influence the wider network is a
>> very serious challenge.
>>
>> Innovation in naming is the single hardest thing to do in a network
>> protocol. I have seen UDDI, Realnames, X.500, so many proposals.
>>
>>
>> When someone tells me a simple thing is too complex and then
>> proposes to do the single hardest, most complex thing in computer
>> networking I have concerns.
>>
>>> -Original Message-
>>> From: Drummond Reed [mailto:[EMAIL PROTECTED]
>>> Sent: Wednesday, November 08, 2006 7:42 PM
>>> To: Hallam-Baker, Phillip; Recordon, David; 'David Fuelling'
>>> Cc: specs@openid.net; [EMAIL PROTECTED]
>>> Subject: XRDS vs. DNS level identity (was RE: [PROPOSAL]
>>> Handle "http://[EMAIL PROTECTED]" Style Identifiers)
>>>
>>> Phillip,
>>>
>>> Please don't shoot me -- I am just the messenger -- but a
>>> year-long effort
>>> (Yadis) went into the design and deployment of XRDS documents
>>> as the discovery infrastructure for OpenID.
>>>
>>> There are numerous reasons for this, but they boil down to
>>> this: the XRDS layer of identity is rooted at a higher layer
>>> than that of DNS. Users don't just have DNS names in OpenID;
>>> they have URLs or XRIs. Those URLs or XRIs resolve to XRDS
>>> documents, which perform mapping of URLs/XRIs to
>>> URI-identified service endpoints. These service endpoint URIs
>>> in turn map down to services resolvable at the DNS layer
>>> (which then of course map down to machine addresses at the IP  
>>> layer).
>>>
>>> I fully understand that you "have seen so many attempts to
>>> reinvent it" (the DNS). OpenID and URL/XRI-based identity is
>>> not an attempt to reinvent it. It is the emergence of
>>> identity infrastructure at a higher layer designed to take
>>> advantage of the abstractions available at that layer, including:
>>>
>>> * URI and XRI syntax (much richer than DNS)
>>> * HTTP and HTTPS protocols for discovery
>>> * Extensible, XML-encoded resource description metadata
>>> * Mapping of reassignable and persistent identifiers for
>>> persistent identity
>>> * Discovery of typed service endpoints
>>>
>>> I know you know my personal bias (anyone who would push the
>>> XRI boulder this long uphill has got to have a few screws
>>> loose), but at this point it seems like trying to push the
>>> XRDS layer back down into DNS would be like trying to put the
>>> genie back in the bottle.
>>>
>>> =Drummond
>>>
>>> -Original Message-
>>> From: [EMAIL PROTECTED]
>>> [mailto:[EMAIL PROTECTED] On Behalf Of Hallam-Baker, Phillip
>>> Sent: Wednesday, November 08, 2006 3:01 PM
>>> To: Recordon, David; David Fuelling
>>> Cc: specs@openid.net; [EMAIL PROTECTED]
>>> Subject: RE: [PROPOSAL] Handle "http://[EMAIL PROTECTED]"
>>&g

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

2006-11-08 Thread David Fuelling
Hey Dick,

Couldn't one make the opposite argument -- that most people's email address
NOT working when they plug it into the OpenId login field could actually be
a good thing? (especially in the beginning of OpenID)

I say this because such scenarios (user enters email, and RP fails because
the email doesn't yet support open id) might actually be a catalyst for more
people to use OpenId, especially if users start barking at their ISP/email
providers to support OpenId because their email isn't working correctly with
certain sites they want to use.

For example, consider the following two potential scenarios that might go
through a new user's mind when they first encounter OpenId:

Scenario #1 (WITHOUT email allowed in the OpenId login form):
User encounters an "openid enabled" site (RP ==> example.com), and decides
they are curious about this new "way" to login (simplifying, I know -- but
we're talking about a simple user).  The user pretty quickly realizes that
they need to somehow secure an Identity URL.  The typical user (my parents,
e.g.) might be inclined to say: "all my other (non-openid) sites require my
email address (usually) as a username.  Plus, since example.com still
supports email address based username+passwords anyway, why not just
continue to use that?"  Thus, the novice user who fails to see the benefits
of OpenId might just decide against OpenId because of the perceived
difficulties in using it, especially in the beginning when OpenId adoption
will be gaining traction, but not the majority method used for site login.  

Scenario #2 (WITH email allowed in the OpenId login form):  User encounters
an "openid enabled" site, and decides they are curious about the new "way"
to login.  If their email domain supports OpenId, then there's really no
reason for a novice user NOT to use OpenId -- it works with the email
address.

On the other hand, if the RP determines that the specified email address
doesn't support OpenId, it (the RP) then comes back to the User with an
educational page explaining why the email doesn't work, perhaps with a "call
your email provider and encourage them to adopt openid...and here's why".  

Anyway, this might be a different perspective on whether or not the ["oops,
your login didn't work"] is a bad thing.


> -Original Message-
> From: Dick Hardt [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, November 08, 2006 5:06 PM
> To: David Fuelling
> Cc: specs@openid.net
> Subject: Re: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style Identifiers
> 
> Hi David
> 
> A Homesite is a new concept for users, so when they see a prompt for
> it, they will know they have one or not. They are not just typing in
> a random URL.
> 
> Pretty much every user has an email address, so a prompt asking for
> an email would suggest to user that their email will work -- which of
> course hardly any will.
> 
> -- Dick
> 

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


Re: XRDS vs. DNS level identity (was RE: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style Identifiers)

2006-11-08 Thread Johannes Ernst
Just commenting on the XRDS discovery from HTTP URLs bit.

Using DNS as a mechanism, given a URL, to discover the location of,  
or obtain the content or equivalent of, the XRDS file, was proposed  
back then in Yadis 0.x days, and rejected. The reason being that any  
such mechanism would require the system administrator in charge of  
the DNS system to "configure XRDS" for any and all users in that  
domain. It would give that system administrator an effective veto  
(exercised by being lazy, for example) over whether or not users  
could use OpenID on that domain, and in particular which services to  
reference from that file (e.g. competitive services). There was  
general consensus that for a "user-centric" identity system, that was  
not desirable, and that's why we decided in favor of the HTTP header  
extension, its HTML equivalent, and the shortcut via the MIME type.

We felt on safe ground with respect to naming design, because it's  
very much the same approach as, say, the reference of embedded GIFs  
or CSS in HTML, or the use of URLs to identify DTDs in XML.


On Nov 8, 2006, at 17:19, Hallam-Baker, Phillip wrote:

> Quite a few years went into the design of DNS.
>
> The concern I have here is that to influence the wider network is a  
> very serious challenge.
>
> Innovation in naming is the single hardest thing to do in a network  
> protocol. I have seen UDDI, Realnames, X.500, so many proposals.
>
>
> When someone tells me a simple thing is too complex and then  
> proposes to do the single hardest, most complex thing in computer  
> networking I have concerns.
>
>> -Original Message-
>> From: Drummond Reed [mailto:[EMAIL PROTECTED]
>> Sent: Wednesday, November 08, 2006 7:42 PM
>> To: Hallam-Baker, Phillip; Recordon, David; 'David Fuelling'
>> Cc: specs@openid.net; [EMAIL PROTECTED]
>> Subject: XRDS vs. DNS level identity (was RE: [PROPOSAL]
>> Handle "http://[EMAIL PROTECTED]" Style Identifiers)
>>
>> Phillip,
>>
>> Please don't shoot me -- I am just the messenger -- but a
>> year-long effort
>> (Yadis) went into the design and deployment of XRDS documents
>> as the discovery infrastructure for OpenID.
>>
>> There are numerous reasons for this, but they boil down to
>> this: the XRDS layer of identity is rooted at a higher layer
>> than that of DNS. Users don't just have DNS names in OpenID;
>> they have URLs or XRIs. Those URLs or XRIs resolve to XRDS
>> documents, which perform mapping of URLs/XRIs to
>> URI-identified service endpoints. These service endpoint URIs
>> in turn map down to services resolvable at the DNS layer
>> (which then of course map down to machine addresses at the IP layer).
>>
>> I fully understand that you "have seen so many attempts to
>> reinvent it" (the DNS). OpenID and URL/XRI-based identity is
>> not an attempt to reinvent it. It is the emergence of
>> identity infrastructure at a higher layer designed to take
>> advantage of the abstractions available at that layer, including:
>>
>> * URI and XRI syntax (much richer than DNS)
>> * HTTP and HTTPS protocols for discovery
>> * Extensible, XML-encoded resource description metadata
>> * Mapping of reassignable and persistent identifiers for
>> persistent identity
>> * Discovery of typed service endpoints
>>
>> I know you know my personal bias (anyone who would push the
>> XRI boulder this long uphill has got to have a few screws
>> loose), but at this point it seems like trying to push the
>> XRDS layer back down into DNS would be like trying to put the
>> genie back in the bottle.
>>
>> =Drummond
>>
>> -Original Message-
>> From: [EMAIL PROTECTED]
>> [mailto:[EMAIL PROTECTED] On Behalf Of Hallam-Baker, Phillip
>> Sent: Wednesday, November 08, 2006 3:01 PM
>> To: Recordon, David; David Fuelling
>> Cc: specs@openid.net; [EMAIL PROTECTED]
>> Subject: RE: [PROPOSAL] Handle "http://[EMAIL PROTECTED]"
>> Style Identifiers
>>
>> You can make things complex in two ways, one is by adding too
>> many curlicues to a design, another is by refusing to use the
>> deployed infrastructure for its intended purpose.
>>
>> The signaling and discovery infrastructure of the Internet is the  
>> DNS.
>>
>> I have seen so many attempts to reinvent it.
>>
>>> -Original Message-
>>> From: Recordon, David
>>> Sent: Wednesday, November 08, 2006 4:50 PM
>>> To: Hallam-Baker, Phillip; David Fuelling
>>> Cc: specs@openid.net; [EMAIL PROTECTED]
>>> Subject: RE: [PROPO

RE: XRDS vs. DNS level identity (was RE: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style Identifiers)

2006-11-08 Thread Hallam-Baker, Phillip
Quite a few years went into the design of DNS.

The concern I have here is that to influence the wider network is a very 
serious challenge.

Innovation in naming is the single hardest thing to do in a network protocol. I 
have seen UDDI, Realnames, X.500, so many proposals.


When someone tells me a simple thing is too complex and then proposes to do the 
single hardest, most complex thing in computer networking I have concerns.

> -Original Message-
> From: Drummond Reed [mailto:[EMAIL PROTECTED] 
> Sent: Wednesday, November 08, 2006 7:42 PM
> To: Hallam-Baker, Phillip; Recordon, David; 'David Fuelling'
> Cc: specs@openid.net; [EMAIL PROTECTED]
> Subject: XRDS vs. DNS level identity (was RE: [PROPOSAL] 
> Handle "http://[EMAIL PROTECTED]" Style Identifiers)
> 
> Phillip,
> 
> Please don't shoot me -- I am just the messenger -- but a 
> year-long effort
> (Yadis) went into the design and deployment of XRDS documents 
> as the discovery infrastructure for OpenID. 
> 
> There are numerous reasons for this, but they boil down to 
> this: the XRDS layer of identity is rooted at a higher layer 
> than that of DNS. Users don't just have DNS names in OpenID; 
> they have URLs or XRIs. Those URLs or XRIs resolve to XRDS 
> documents, which perform mapping of URLs/XRIs to 
> URI-identified service endpoints. These service endpoint URIs 
> in turn map down to services resolvable at the DNS layer 
> (which then of course map down to machine addresses at the IP layer).
> 
> I fully understand that you "have seen so many attempts to 
> reinvent it" (the DNS). OpenID and URL/XRI-based identity is 
> not an attempt to reinvent it. It is the emergence of 
> identity infrastructure at a higher layer designed to take 
> advantage of the abstractions available at that layer, including:
> 
> * URI and XRI syntax (much richer than DNS)
> * HTTP and HTTPS protocols for discovery
> * Extensible, XML-encoded resource description metadata
> * Mapping of reassignable and persistent identifiers for 
> persistent identity
> * Discovery of typed service endpoints
> 
> I know you know my personal bias (anyone who would push the 
> XRI boulder this long uphill has got to have a few screws 
> loose), but at this point it seems like trying to push the 
> XRDS layer back down into DNS would be like trying to put the 
> genie back in the bottle.
> 
> =Drummond 
> 
> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf Of Hallam-Baker, Phillip
> Sent: Wednesday, November 08, 2006 3:01 PM
> To: Recordon, David; David Fuelling
> Cc: specs@openid.net; [EMAIL PROTECTED]
> Subject: RE: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" 
> Style Identifiers
> 
> You can make things complex in two ways, one is by adding too 
> many curlicues to a design, another is by refusing to use the 
> deployed infrastructure for its intended purpose.
> 
> The signaling and discovery infrastructure of the Internet is the DNS.
> 
> I have seen so many attempts to reinvent it.
> 
> > -Original Message-
> > From: Recordon, David
> > Sent: Wednesday, November 08, 2006 4:50 PM
> > To: Hallam-Baker, Phillip; David Fuelling
> > Cc: specs@openid.net; [EMAIL PROTECTED]
> > Subject: RE: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" 
> > Style Identifiers
> > 
> > Involving DNS seems to make this too complex.  If we're going to 
> > involve DNS, we might as well re-architect Yadis to use it as yet 
> > another discovery option.
> > 
> > --David
> > 
> > -Original Message-
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED] On Behalf Of Hallam-Baker, Phillip
> > Sent: Wednesday, November 08, 2006 1:37 PM
> > To: David Fuelling
> > Cc: specs@openid.net; [EMAIL PROTECTED]
> > Subject: RE: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" 
> > Style Identifiers
> > 
> > Please don't map to Http this way.
> > 
> > It would be fine to define a fixed mapping from a user 
> identifier to 
> > http. But it has to respect the http scheme design and be 
> crafted to 
> > avoid operability concerns.
> > 
> > http://example.com/user would be acceptable as meeting the scheme 
> > design. It is absolutely critical to maintain left/right hierarchy.
> > 
> > The username/password pieces in http were not well thought 
> out and may 
> > have to be eliminated.
> > 
> > 
> > The scheme I would propose would incorporate a policy 
> lookup so that 
> > it is possible to overide this mapping. The mapping to http 
> is fine as 
>

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

2006-11-08 Thread Drummond Reed

>-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Peter Watkins
Sent: Wednesday, November 08, 2006 4:21 PM
To: [EMAIL PROTECTED]
Cc: specs@openid.net
Subject: Re: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style Identifiers
>
>Recordon, David wrote:
>> Involving DNS seems to make this too complex.  If we're going to involve
>> DNS, we might as well re-architect Yadis to use it as yet another
>> discovery option.
>
>Yes, the TXT proposal seems complex. I prefer Phillip's second
>suggestion, but I think something more unique would be advisable, e.g.
>
>http://openid.example.com/openid/user
>
>so that organizations can more easily separate the OpenID IdP systems
>(hostname openid.MAILDOMAIN, web path /openid/) from any regular
>http/https offerings.
>
>It would be nice (see my 'concerns about each user having a unique
>"URL"' thread in the general openid list) if this could handle empty
>usernames, e.g. if users could claim an identifier like
>  @example.com
>to identify the IdP but let the IdP determine the user's identifier.

Peter, as I mentioned in my reply on the General list, this is how the
directed identity feature in OpenID Authentication 2.0 works. That was
David's original suggestion as I remember -- have OpenID RPs treat an email
address as simply an IdP name and execute the protocol from there.

Since the XRI TC is now working on specifying the email form of an XRI
(called an MXRI -- mailto XRI), this could work for both ordinary email
addresses and MXRI addresses. But that's only if we decide that using an
email address as an OpenID identifier makes sense, or if it just adds a new
layer of confusion (as others have noted).

=Drummond 

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


XRDS vs. DNS level identity (was RE: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style Identifiers)

2006-11-08 Thread Drummond Reed
Phillip,

Please don't shoot me -- I am just the messenger -- but a year-long effort
(Yadis) went into the design and deployment of XRDS documents as the
discovery infrastructure for OpenID. 

There are numerous reasons for this, but they boil down to this: the XRDS
layer of identity is rooted at a higher layer than that of DNS. Users don't
just have DNS names in OpenID; they have URLs or XRIs. Those URLs or XRIs
resolve to XRDS documents, which perform mapping of URLs/XRIs to
URI-identified service endpoints. These service endpoint URIs in turn map
down to services resolvable at the DNS layer (which then of course map down
to machine addresses at the IP layer).

I fully understand that you "have seen so many attempts to reinvent it" (the
DNS). OpenID and URL/XRI-based identity is not an attempt to reinvent it. It
is the emergence of identity infrastructure at a higher layer designed to
take advantage of the abstractions available at that layer, including:

* URI and XRI syntax (much richer than DNS)
* HTTP and HTTPS protocols for discovery
* Extensible, XML-encoded resource description metadata
* Mapping of reassignable and persistent identifiers for persistent identity
* Discovery of typed service endpoints

I know you know my personal bias (anyone who would push the XRI boulder this
long uphill has got to have a few screws loose), but at this point it seems
like trying to push the XRDS layer back down into DNS would be like trying
to put the genie back in the bottle.

=Drummond 

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of Hallam-Baker, Phillip
Sent: Wednesday, November 08, 2006 3:01 PM
To: Recordon, David; David Fuelling
Cc: specs@openid.net; [EMAIL PROTECTED]
Subject: RE: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style Identifiers

You can make things complex in two ways, one is by adding too many
curlicues to a design, another is by refusing to use the deployed
infrastructure for its intended purpose.

The signaling and discovery infrastructure of the Internet is the DNS.

I have seen so many attempts to reinvent it.

> -Original Message-
> From: Recordon, David 
> Sent: Wednesday, November 08, 2006 4:50 PM
> To: Hallam-Baker, Phillip; David Fuelling
> Cc: specs@openid.net; [EMAIL PROTECTED]
> Subject: RE: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" 
> Style Identifiers
> 
> Involving DNS seems to make this too complex.  If we're going 
> to involve DNS, we might as well re-architect Yadis to use it 
> as yet another discovery option.
> 
> --David 
> 
> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf Of Hallam-Baker, Phillip
> Sent: Wednesday, November 08, 2006 1:37 PM
> To: David Fuelling
> Cc: specs@openid.net; [EMAIL PROTECTED]
> Subject: RE: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" 
> Style Identifiers
> 
> Please don't map to Http this way.
> 
> It would be fine to define a fixed mapping from a user 
> identifier to http. But it has to respect the http scheme 
> design and be crafted to avoid operability concerns.
> 
> http://example.com/user would be acceptable as meeting the 
> scheme design. It is absolutely critical to maintain 
> left/right hierarchy.
> 
> The username/password pieces in http were not well thought 
> out and may have to be eliminated.
> 
> 
> The scheme I would propose would incorporate a policy lookup 
> so that it is possible to overide this mapping. The mapping 
> to http is fine as a last resort but making it the first 
> resort means we cannot ever change it.
> 
> What I would suggest is that we resolve [EMAIL PROTECTED] as follows
> 
> 1) Perform a DNS lookup for a TXT record at _openid.example.com
>   if found perform policy processing
> 
> 2) map the uri to http://example.com/user, do OpenID
> 
> 
> Policy processing:
> 
> The TXT record consists of a sequence of tag=value pairs that 
> list the authentication protocols that are supported. This 
> allows the relying party to choose the most appropriate 
> protocol for its needs.
> 
> For example:
> 
> "SAML=saml.example.com SAMLLite=saml.outsourced.com OPENID"
> 
> This says that the identity provider supports three different 
> authentication protocols, SAML, a reduced SAML and OPENID.
> 
> 
> > -Original Message-
> > From: David Fuelling [mailto:[EMAIL PROTECTED]
> > Sent: Wednesday, November 08, 2006 1:56 PM
> > To: Hallam-Baker, Phillip
> > Cc: specs@openid.net; [EMAIL PROTECTED]
> > Subject: RE: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" 
> > Style Identifiers
> > 
> > Hi Philip,
> > 
> > I'm not sure I understand "Please don't use H

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

2006-11-08 Thread Peter Watkins
Recordon, David wrote:
> Involving DNS seems to make this too complex.  If we're going to involve
> DNS, we might as well re-architect Yadis to use it as yet another
> discovery option.

Yes, the TXT proposal seems complex. I prefer Phillip's second
suggestion, but I think something more unique would be advisable, e.g.

http://openid.example.com/openid/user

so that organizations can more easily separate the OpenID IdP systems
(hostname openid.MAILDOMAIN, web path /openid/) from any regular
http/https offerings.

It would be nice (see my 'concerns about each user having a unique
"URL"' thread in the general openid list) if this could handle empty
usernames, e.g. if users could claim an identifier like
  @example.com
to identify the IdP but let the IdP determine the user's identifier.

-Peter

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
> Behalf Of Hallam-Baker, Phillip
> Sent: Wednesday, November 08, 2006 1:37 PM
> To: David Fuelling
> Cc: specs@openid.net; [EMAIL PROTECTED]
> Subject: RE: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style
> Identifiers

> It would be fine to define a fixed mapping from a user identifier to
> http. But it has to respect the http scheme design and be crafted to
> avoid operability concerns.
> 
> http://example.com/user would be acceptable as meeting the scheme
> design. It is absolutely critical to maintain left/right hierarchy.

> What I would suggest is that we resolve [EMAIL PROTECTED] as follows
> 
> 1) Perform a DNS lookup for a TXT record at _openid.example.com
>   if found perform policy processing
> 
> 2) map the uri to http://example.com/user, do OpenID
> 
> 
> Policy processing:
> 
> The TXT record consists of a sequence of tag=value pairs that list the
> authentication protocols that are supported. This allows the relying
> party to choose the most appropriate protocol for its needs.
> 
> For example:
> 
> "SAML=saml.example.com SAMLLite=saml.outsourced.com OPENID"
> 
> This says that the identity provider supports three different
> authentication protocols, SAML, a reduced SAML and OPENID.
> 
> 
>> -Original Message-
>> From: David Fuelling [mailto:[EMAIL PROTECTED]
>> Sent: Wednesday, November 08, 2006 1:56 PM
>> To: Hallam-Baker, Phillip
>> Cc: specs@openid.net; [EMAIL PROTECTED]
>> Subject: RE: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" 
>> Style Identifiers
>>
>> Hi Philip,
>>
>> I'm not sure I understand "Please don't use HTTP this way".  
>>
>> I was suggesting that the user enter an email address.  The RP then 
>> maps the email address to a URL (which would be in the proper scheme).
>>
>>
>>> -Original Message-
>>> From: Hallam-Baker, Phillip [mailto:[EMAIL PROTECTED]
>>> Sent: Wednesday, November 08, 2006 1:45 PM
>>> To: David Fuelling; specs@openid.net
>>> Subject: RE: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style 
>>> Identifiers
>>>
>>> Please don't use HTTP this way. That is not the semantics 
>> for http URLs.
>>> A better scheme would be to use mailto:[EMAIL PROTECTED] or 
>> to define 
>>> openid:[EMAIL PROTECTED]
>>>
>>>
>>> There are two issues here:
>>>
>>> 1) The user presentation of the identifier
>>> 2) The machine presentation
>>>
>>> The two do not need to be the same. www.cnn.com works 
>> perfectly well 
>>> as a way to locate CNN. That is a perfectly acceptable user 
>>> presentation. It is not an acceptable machine presentation and 
>>> browsers SHOULD NOT accept href="www.cnn.com".
>>>
>>>
>>>
>>>
>>>> -Original Message-
>>>> From: [EMAIL PROTECTED]
>>>> [mailto:[EMAIL PROTECTED] On Behalf Of David Fuelling
>>>> Sent: Wednesday, November 08, 2006 1:40 PM
>>>> To: specs@openid.net
>>>> Subject: RE: [PROPOSAL] Handle "http://[EMAIL PROTECTED]"
>>>> Style Identifiers
>>>>
>>>> Please see my questions/ideas enclosed...
>>>>
>>>> Thanks!
>>>>
>>>> David Fuelling
>>>>
>>>>> -Original Message-
>>>>> From: [EMAIL PROTECTED] 
>> [mailto:[EMAIL PROTECTED] 
>>>>> On Behalf Of Drummond Reed
>>>>> Sent: Friday, October 20, 2006 1:04 AM
>>>>> To: 'Recordon, David'; specs@openid.net
>>>>> Subject: RE: [PROPOSAL] Handle "

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

2006-11-08 Thread Rich Thornberg




Many sites allow users to register for services using an e-mail
address.  Often such sites require the user to verify ownership of the
e-mail address by sending an e-mail to the just registered address, but
not always.  When a site allows such a registration they also request
the user to create a password.  So users can access "service" by
providing e-mail/password -- my guess is that many users use the same
password as required for their actual e-mail account, but I have no
idea how many.  People do this all the time.  I know of at least one
pretty large portal that allows it.

If e-mail addresses could be used, sites could lookup the domain using
whatever method is described by OpenId, find the OP and let that
collect the id/password.  If the domain isn't an OP, the site could
handle it locally as a registered e-mail address/identity.

Rich


On 11/8/06 5:06 PM, Dick Hardt wrote the following:

  Hi David

A Homesite is a new concept for users, so when they see a prompt for  
it, they will know they have one or not. They are not just typing in  
a random URL.

Pretty much every user has an email address, so a prompt asking for  
an email would suggest to user that their email will work -- which of  
course hardly any will.

-- Dick

On 8-Nov-06, at 10:51 AM, David Fuelling wrote:

  
  
Dick,

It seems like the same problem exists if a user types an IdP URL.   
If that
URL (e.g., example.com) isn't a valid OpenId IdP, then the user  
will still
encounter a problem.

Shouldn't the RP show an "educational page" if a
Homesite/i-name/OpenId/email doesn't resolve to something that  
OpenID can
use?

David Fuelling



  -Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]  
On Behalf
Of Dick Hardt
Sent: Sunday, October 22, 2006 12:26 PM
To: John Panzer
Cc: Kaliya *; specs@openid.net
Subject: Re: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style  
Identifiers

...

If we support email addresses, then the prompt may look something
like this:

 "email | Homesite | i-name | OpenID"

Now any user with an email address thinks they can type it into the
box and login. This of course is not going to be the case.

  



  
  
___
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

2006-11-08 Thread Hallam-Baker, Phillip
You can make things complex in two ways, one is by adding too many
curlicues to a design, another is by refusing to use the deployed
infrastructure for its intended purpose.

The signaling and discovery infrastructure of the Internet is the DNS.

I have seen so many attempts to reinvent it.

> -Original Message-
> From: Recordon, David 
> Sent: Wednesday, November 08, 2006 4:50 PM
> To: Hallam-Baker, Phillip; David Fuelling
> Cc: specs@openid.net; [EMAIL PROTECTED]
> Subject: RE: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" 
> Style Identifiers
> 
> Involving DNS seems to make this too complex.  If we're going 
> to involve DNS, we might as well re-architect Yadis to use it 
> as yet another discovery option.
> 
> --David 
> 
> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf Of Hallam-Baker, Phillip
> Sent: Wednesday, November 08, 2006 1:37 PM
> To: David Fuelling
> Cc: specs@openid.net; [EMAIL PROTECTED]
> Subject: RE: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" 
> Style Identifiers
> 
> Please don't map to Http this way.
> 
> It would be fine to define a fixed mapping from a user 
> identifier to http. But it has to respect the http scheme 
> design and be crafted to avoid operability concerns.
> 
> http://example.com/user would be acceptable as meeting the 
> scheme design. It is absolutely critical to maintain 
> left/right hierarchy.
> 
> The username/password pieces in http were not well thought 
> out and may have to be eliminated.
> 
> 
> The scheme I would propose would incorporate a policy lookup 
> so that it is possible to overide this mapping. The mapping 
> to http is fine as a last resort but making it the first 
> resort means we cannot ever change it.
> 
> What I would suggest is that we resolve [EMAIL PROTECTED] as follows
> 
> 1) Perform a DNS lookup for a TXT record at _openid.example.com
>   if found perform policy processing
> 
> 2) map the uri to http://example.com/user, do OpenID
> 
> 
> Policy processing:
> 
> The TXT record consists of a sequence of tag=value pairs that 
> list the authentication protocols that are supported. This 
> allows the relying party to choose the most appropriate 
> protocol for its needs.
> 
> For example:
> 
> "SAML=saml.example.com SAMLLite=saml.outsourced.com OPENID"
> 
> This says that the identity provider supports three different 
> authentication protocols, SAML, a reduced SAML and OPENID.
> 
> 
> > -----Original Message-
> > From: David Fuelling [mailto:[EMAIL PROTECTED]
> > Sent: Wednesday, November 08, 2006 1:56 PM
> > To: Hallam-Baker, Phillip
> > Cc: specs@openid.net; [EMAIL PROTECTED]
> > Subject: RE: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" 
> > Style Identifiers
> > 
> > Hi Philip,
> > 
> > I'm not sure I understand "Please don't use HTTP this way".  
> > 
> > I was suggesting that the user enter an email address.  The RP then 
> > maps the email address to a URL (which would be in the 
> proper scheme).
> > 
> > 
> > > -Original Message-
> > > From: Hallam-Baker, Phillip [mailto:[EMAIL PROTECTED]
> > > Sent: Wednesday, November 08, 2006 1:45 PM
> > > To: David Fuelling; specs@openid.net
> > > Subject: RE: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style 
> > > Identifiers
> > > 
> > > Please don't use HTTP this way. That is not the semantics
> > for http URLs.
> > > 
> > > A better scheme would be to use mailto:[EMAIL PROTECTED] or
> > to define
> > > openid:[EMAIL PROTECTED]
> > > 
> > > 
> > > There are two issues here:
> > > 
> > > 1) The user presentation of the identifier
> > > 2) The machine presentation
> > > 
> > > The two do not need to be the same. www.cnn.com works
> > perfectly well
> > > as a way to locate CNN. That is a perfectly acceptable user 
> > > presentation. It is not an acceptable machine presentation and 
> > > browsers SHOULD NOT accept href="www.cnn.com".
> > > 
> > > 
> > > 
> > > 
> > > > -Original Message-
> > > > From: [EMAIL PROTECTED]
> > > > [mailto:[EMAIL PROTECTED] On Behalf Of David Fuelling
> > > > Sent: Wednesday, November 08, 2006 1:40 PM
> > > > To: specs@openid.net
> > > > Subject: RE: [PROPOSAL] Handle "http://[EMAIL PROTECTED]"
> > > > Style Identifiers
> > > >
> > > > 

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

2006-11-08 Thread Dick Hardt
Hi David

A Homesite is a new concept for users, so when they see a prompt for  
it, they will know they have one or not. They are not just typing in  
a random URL.

Pretty much every user has an email address, so a prompt asking for  
an email would suggest to user that their email will work -- which of  
course hardly any will.

-- Dick

On 8-Nov-06, at 10:51 AM, David Fuelling wrote:

> Dick,
>
> It seems like the same problem exists if a user types an IdP URL.   
> If that
> URL (e.g., example.com) isn't a valid OpenId IdP, then the user  
> will still
> encounter a problem.
>
> Shouldn't the RP show an "educational page" if a
> Homesite/i-name/OpenId/email doesn't resolve to something that  
> OpenID can
> use?
>
> David Fuelling
>
>> -Original Message-
>> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]  
>> On Behalf
>> Of Dick Hardt
>> Sent: Sunday, October 22, 2006 12:26 PM
>> To: John Panzer
>> Cc: Kaliya *; specs@openid.net
>> Subject: Re: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style  
>> Identifiers
>>
>> ...
>>
>> If we support email addresses, then the prompt may look something
>> like this:
>>
>>  "email | Homesite | i-name | OpenID"
>>
>> Now any user with an email address thinks they can type it into the
>> box and login. This of course is not going to be the case.
>>
>
>

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


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

2006-11-08 Thread Recordon, David
Involving DNS seems to make this too complex.  If we're going to involve
DNS, we might as well re-architect Yadis to use it as yet another
discovery option.

--David 

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Hallam-Baker, Phillip
Sent: Wednesday, November 08, 2006 1:37 PM
To: David Fuelling
Cc: specs@openid.net; [EMAIL PROTECTED]
Subject: RE: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style
Identifiers

Please don't map to Http this way.

It would be fine to define a fixed mapping from a user identifier to
http. But it has to respect the http scheme design and be crafted to
avoid operability concerns.

http://example.com/user would be acceptable as meeting the scheme
design. It is absolutely critical to maintain left/right hierarchy.

The username/password pieces in http were not well thought out and may
have to be eliminated.


The scheme I would propose would incorporate a policy lookup so that it
is possible to overide this mapping. The mapping to http is fine as a
last resort but making it the first resort means we cannot ever change
it.

What I would suggest is that we resolve [EMAIL PROTECTED] as follows

1) Perform a DNS lookup for a TXT record at _openid.example.com
if found perform policy processing

2) map the uri to http://example.com/user, do OpenID


Policy processing:

The TXT record consists of a sequence of tag=value pairs that list the
authentication protocols that are supported. This allows the relying
party to choose the most appropriate protocol for its needs.

For example:

"SAML=saml.example.com SAMLLite=saml.outsourced.com OPENID"

This says that the identity provider supports three different
authentication protocols, SAML, a reduced SAML and OPENID.


> -Original Message-
> From: David Fuelling [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, November 08, 2006 1:56 PM
> To: Hallam-Baker, Phillip
> Cc: specs@openid.net; [EMAIL PROTECTED]
> Subject: RE: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" 
> Style Identifiers
> 
> Hi Philip,
> 
> I'm not sure I understand "Please don't use HTTP this way".  
> 
> I was suggesting that the user enter an email address.  The RP then 
> maps the email address to a URL (which would be in the proper scheme).
> 
> 
> > -Original Message-
> > From: Hallam-Baker, Phillip [mailto:[EMAIL PROTECTED]
> > Sent: Wednesday, November 08, 2006 1:45 PM
> > To: David Fuelling; specs@openid.net
> > Subject: RE: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style 
> > Identifiers
> > 
> > Please don't use HTTP this way. That is not the semantics 
> for http URLs.
> > 
> > A better scheme would be to use mailto:[EMAIL PROTECTED] or 
> to define 
> > openid:[EMAIL PROTECTED]
> > 
> > 
> > There are two issues here:
> > 
> > 1) The user presentation of the identifier
> > 2) The machine presentation
> > 
> > The two do not need to be the same. www.cnn.com works 
> perfectly well 
> > as a way to locate CNN. That is a perfectly acceptable user 
> > presentation. It is not an acceptable machine presentation and 
> > browsers SHOULD NOT accept href="www.cnn.com".
> > 
> > 
> > 
> > 
> > > -Original Message-
> > > From: [EMAIL PROTECTED]
> > > [mailto:[EMAIL PROTECTED] On Behalf Of David Fuelling
> > > Sent: Wednesday, November 08, 2006 1:40 PM
> > > To: specs@openid.net
> > > Subject: RE: [PROPOSAL] Handle "http://[EMAIL PROTECTED]"
> > > Style Identifiers
> > >
> > > Please see my questions/ideas enclosed...
> > >
> > > Thanks!
> > >
> > > David Fuelling
> > >
> > > > -Original Message-
> > > > From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] 
> > > > On Behalf Of Drummond Reed
> > > > 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.
> > >
> > > This seems reasonable at first glance.  However, almost every 
> > > website I have a login

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

2006-11-08 Thread Hallam-Baker, Phillip
Please don't map to Http this way.

It would be fine to define a fixed mapping from a user identifier to http. But 
it has to respect the http scheme design and be crafted to avoid operability 
concerns.

http://example.com/user would be acceptable as meeting the scheme design. It is 
absolutely critical to maintain left/right hierarchy.

The username/password pieces in http were not well thought out and may have to 
be eliminated.


The scheme I would propose would incorporate a policy lookup so that it is 
possible to overide this mapping. The mapping to http is fine as a last resort 
but making it the first resort means we cannot ever change it.

What I would suggest is that we resolve [EMAIL PROTECTED] as follows

1) Perform a DNS lookup for a TXT record at _openid.example.com
if found perform policy processing

2) map the uri to http://example.com/user, do OpenID


Policy processing:

The TXT record consists of a sequence of tag=value pairs that list the 
authentication protocols that are supported. This allows the relying party to 
choose the most appropriate protocol for its needs.

For example:

"SAML=saml.example.com SAMLLite=saml.outsourced.com OPENID"

This says that the identity provider supports three different authentication 
protocols, SAML, a reduced SAML and OPENID.


> -Original Message-
> From: David Fuelling [mailto:[EMAIL PROTECTED] 
> Sent: Wednesday, November 08, 2006 1:56 PM
> To: Hallam-Baker, Phillip
> Cc: specs@openid.net; [EMAIL PROTECTED]
> Subject: RE: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" 
> Style Identifiers
> 
> Hi Philip,
> 
> I'm not sure I understand "Please don't use HTTP this way".  
> 
> I was suggesting that the user enter an email address.  The 
> RP then maps the email address to a URL (which would be in 
> the proper scheme).
> 
> 
> > -Original Message-
> > From: Hallam-Baker, Phillip [mailto:[EMAIL PROTECTED]
> > Sent: Wednesday, November 08, 2006 1:45 PM
> > To: David Fuelling; specs@openid.net
> > Subject: RE: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style 
> > Identifiers
> > 
> > Please don't use HTTP this way. That is not the semantics 
> for http URLs.
> > 
> > A better scheme would be to use mailto:[EMAIL PROTECTED] or 
> to define 
> > openid:[EMAIL PROTECTED]
> > 
> > 
> > There are two issues here:
> > 
> > 1) The user presentation of the identifier
> > 2) The machine presentation
> > 
> > The two do not need to be the same. www.cnn.com works 
> perfectly well 
> > as a way to locate CNN. That is a perfectly acceptable user 
> > presentation. It is not an acceptable machine presentation and 
> > browsers SHOULD NOT accept href="www.cnn.com".
> > 
> > 
> > 
> > 
> > > -Original Message-
> > > From: [EMAIL PROTECTED]
> > > [mailto:[EMAIL PROTECTED] On Behalf Of David Fuelling
> > > Sent: Wednesday, November 08, 2006 1:40 PM
> > > To: specs@openid.net
> > > Subject: RE: [PROPOSAL] Handle "http://[EMAIL PROTECTED]"
> > > Style Identifiers
> > >
> > > Please see my questions/ideas enclosed...
> > >
> > > Thanks!
> > >
> > > David Fuelling
> > >
> > > > -Original Message-
> > > > From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] 
> > > > On Behalf Of Drummond Reed
> > > > 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.
> > >
> > > This seems reasonable at first glance.  However, almost every 
> > > website I have a login with (today) requests my email address so 
> > > that the site can communicate with me electronically.
> > >
> > > So, if email addresses WERE used as an additional "login 
> input" for 
> > > OpenId, a user who didn't want to use his/her email 
> address to login 
> > > could always just use an IdP URL or XRI instead (as they 
> can today).
> > >
> > > Am I missing the 

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

2006-11-08 Thread David Fuelling
I wonder if it would help our discussion to clarify what is meant when we
say that an email address is an "identifier".  

While an email address does technically identify SOMETHING, here I'm using
it more as a "mapping".

So, the way I'm conceiving of things is that the email is in fact a REAL
email address.  It's just that OpenId has a procedure for using it to
forward a user to a proper IdP.

A good parallel would be the Identity URL itself.  A common user might think
of this URL as something to be clicked on, and resolvable -- A Location.
However, OpenID is instead/additionally using this URL in a slightly
different way -- to map to an identity.  Are not these two instances (email
and Claimed Identity URL) "misleading" in the same way?

(I'm actually not convinced that either is misleading, but I could be
swayed).

> -Original Message-
> From: Jonathan Daugherty [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, November 08, 2006 1:45 PM
> To: David Fuelling
> Cc: specs@openid.net
> Subject: Re: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style Identifiers
> 
> # So, if in a hypothetical world where we have 4 potential OpenId
> # "values" that a user could enter, AND the goal is to reduce
> # confusion, then does it really make sense to cut out the most common
> # "value" (which is an email address)?
> 
> IMHO, because using identifiers that look like email addresses would
> be misleading.
> 
> --
>   Jonathan Daugherty
>   JanRain, Inc.

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


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

2006-11-08 Thread David Fuelling
Hi Philip,

I'm not sure I understand "Please don't use HTTP this way".  

I was suggesting that the user enter an email address.  The RP then maps the
email address to a URL (which would be in the proper scheme).


> -Original Message-
> From: Hallam-Baker, Phillip [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, November 08, 2006 1:45 PM
> To: David Fuelling; specs@openid.net
> Subject: RE: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style Identifiers
> 
> Please don't use HTTP this way. That is not the semantics for http URLs.
> 
> A better scheme would be to use mailto:[EMAIL PROTECTED] or to define
> openid:[EMAIL PROTECTED]
> 
> 
> There are two issues here:
> 
> 1) The user presentation of the identifier
> 2) The machine presentation
> 
> The two do not need to be the same. www.cnn.com works perfectly well as a
> way to locate CNN. That is a perfectly acceptable user presentation. It is
> not an acceptable machine presentation and browsers SHOULD NOT accept
> href="www.cnn.com".
> 
> 
> 
> 
> > -Original Message-
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED] On Behalf Of David Fuelling
> > Sent: Wednesday, November 08, 2006 1:40 PM
> > To: specs@openid.net
> > Subject: RE: [PROPOSAL] Handle "http://[EMAIL PROTECTED]"
> > Style Identifiers
> >
> > Please see my questions/ideas enclosed...
> >
> > Thanks!
> >
> > David Fuelling
> >
> > > -----Original Message-
> > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
> > > Behalf Of Drummond Reed
> > > 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.
> >
> > This seems reasonable at first glance.  However, almost every
> > website I have a login with (today) requests my email address
> > so that the site can communicate with me electronically.
> >
> > So, if email addresses WERE used as an additional "login
> > input" for OpenId, a user who didn't want to use his/her
> > email address to login could always just use an IdP URL or
> > XRI instead (as they can today).
> >
> > Am I missing the privacy concern here?
> >
> > > * Reassignability: email addresses are not only
> > reassignable, but for
> > > some domains, they are notoriously short-lived identifiers.
> >
> > Is this really such a problem?  It seems to exist for URL's
> > in the current protocol proposal anyway.  For instance, most
> > people don't own a Domain, which means they'll be using
> > OpenID URL's that somebody else owns.  Thus, URL's are
> > reassignable too, and suffer from this in the same way
> > (although I don't really see this as a problem).
> >
> > > * Non-portability: unless you own the top-level domain, they aren't
> > > portable.
> >
> > Again, is this a problem if the email isn't the actual
> > identifier?  If we have a means of mapping an email to an
> > OpenID Identity URL, then if the email goes away (is
> > transferred or otherwise not in the control of the original
> > user), then what's the problem?
> >
> > Point 1.) Losing an email address is no different than the
> > case where a URL is lost/transferred/goes away.
> >
> > Point 2.) If a user "lost" his email address, theoretically
> > the owner of the email address (example.com, e.g.) would
> > remove the mapping from [EMAIL PROTECTED] to beth's Identity
> > Provider URL.
> >
> > Point 3.) Even if the email address domain owner failed to
> > remove this mapping, only the end-user (beth in this case)
> > would be using the email to login.  Presumably, if she
> > switched email addresses, she would use her new address to
> > login, and it wouldn't matter.  Somebody else trying to use
> > her email address would need to login to the IdP, and
> > presumably be stopped there.
> >
> > > Food for thought...
> > >
> > > =Drummond
> >
> >
> > ___
> > specs mailing list
> > specs@openid.net
> > http://openid.net/mailman/listinfo/specs
> >
> >

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


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

2006-11-08 Thread David Fuelling
Dick,

It seems like the same problem exists if a user types an IdP URL.  If that
URL (e.g., example.com) isn't a valid OpenId IdP, then the user will still
encounter a problem.

Shouldn't the RP show an "educational page" if a
Homesite/i-name/OpenId/email doesn't resolve to something that OpenID can
use?

David Fuelling

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
> Of Dick Hardt
> Sent: Sunday, October 22, 2006 12:26 PM
> To: John Panzer
> Cc: Kaliya *; specs@openid.net
> Subject: Re: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style Identifiers
> 
> ...
>
> If we support email addresses, then the prompt may look something
> like this:
> 
>   "email | Homesite | i-name | OpenID"
> 
> Now any user with an email address thinks they can type it into the
> box and login. This of course is not going to be the case.
> 

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


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

2006-11-08 Thread Hallam-Baker, Phillip
Please don't use HTTP this way. That is not the semantics for http URLs.

A better scheme would be to use mailto:[EMAIL PROTECTED] or to define 
openid:[EMAIL PROTECTED]


There are two issues here:

1) The user presentation of the identifier
2) The machine presentation

The two do not need to be the same. www.cnn.com works perfectly well as a way 
to locate CNN. That is a perfectly acceptable user presentation. It is not an 
acceptable machine presentation and browsers SHOULD NOT accept 
href="www.cnn.com".


 

> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf Of David Fuelling
> Sent: Wednesday, November 08, 2006 1:40 PM
> To: specs@openid.net
> Subject: RE: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" 
> Style Identifiers
> 
> Please see my questions/ideas enclosed...
> 
> Thanks!
> 
> David Fuelling
> 
> > -Original Message-
> > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On 
> > Behalf Of Drummond Reed
> > 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.
> 
> This seems reasonable at first glance.  However, almost every 
> website I have a login with (today) requests my email address 
> so that the site can communicate with me electronically.  
> 
> So, if email addresses WERE used as an additional "login 
> input" for OpenId, a user who didn't want to use his/her 
> email address to login could always just use an IdP URL or 
> XRI instead (as they can today).
> 
> Am I missing the privacy concern here?  
> 
> > * Reassignability: email addresses are not only 
> reassignable, but for 
> > some domains, they are notoriously short-lived identifiers.
> 
> Is this really such a problem?  It seems to exist for URL's 
> in the current protocol proposal anyway.  For instance, most 
> people don't own a Domain, which means they'll be using 
> OpenID URL's that somebody else owns.  Thus, URL's are 
> reassignable too, and suffer from this in the same way 
> (although I don't really see this as a problem).
> 
> > * Non-portability: unless you own the top-level domain, they aren't 
> > portable.
> 
> Again, is this a problem if the email isn't the actual 
> identifier?  If we have a means of mapping an email to an 
> OpenID Identity URL, then if the email goes away (is 
> transferred or otherwise not in the control of the original 
> user), then what's the problem?
> 
> Point 1.) Losing an email address is no different than the 
> case where a URL is lost/transferred/goes away.
> 
> Point 2.) If a user "lost" his email address, theoretically 
> the owner of the email address (example.com, e.g.) would 
> remove the mapping from [EMAIL PROTECTED] to beth's Identity 
> Provider URL.
> 
> Point 3.) Even if the email address domain owner failed to 
> remove this mapping, only the end-user (beth in this case) 
> would be using the email to login.  Presumably, if she 
> switched email addresses, she would use her new address to 
> login, and it wouldn't matter.  Somebody else trying to use 
> her email address would need to login to the IdP, and 
> presumably be stopped there.
> 
> > Food for thought...
> > 
> > =Drummond
> 
> 
> ___
> specs mailing list
> specs@openid.net
> http://openid.net/mailman/listinfo/specs
> 
> 
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs


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

2006-11-08 Thread Jonathan Daugherty
# So, if in a hypothetical world where we have 4 potential OpenId
# "values" that a user could enter, AND the goal is to reduce
# confusion, then does it really make sense to cut out the most common
# "value" (which is an email address)?

IMHO, because using identifiers that look like email addresses would
be misleading.

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


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

2006-11-08 Thread David Fuelling
I agree.  In fact, given that most people don't know what an XRI is, we
might say there will be 3.5 times as much confusion.  

;)

So, if in a hypothetical world where we have 4 potential OpenId "values"
that a user could enter, AND the goal is to reduce confusion, then does it
really make sense to cut out the most common "value" (which is an email
address)?

> -Original Message-
> From: Jonathan Daugherty [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, November 08, 2006 1:30 PM
> To: David Fuelling
> Cc: specs@openid.net
> Subject: Re: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style Identifiers
> 
> # SIDE NOTE: For those who argue against email addresses in the OpenId
> # login form on the grounds of confusion, these 2 email proposals
> # should be no less "confusing" than trying to educate a user that the
> # Identity URL they type in (e.g., http://aol.com) is not their
> # identity.  Both will/would take some education.
> 
> Except that with this new feature, there would be twice as much
> confusion.
> 
> And except that an openid works both as a normal URL and as an OpenID,
> whereas an email-like-thing may work as an OpenID, but is not always
> going to work as an email even though it looks like one.
> 
> So maybe 2.5 times as much 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

2006-11-08 Thread David Fuelling
Please see my questions/ideas enclosed...

Thanks!

David Fuelling

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
> Of Drummond Reed
> 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.

This seems reasonable at first glance.  However, almost every website I have
a login with (today) requests my email address so that the site can
communicate with me electronically.  

So, if email addresses WERE used as an additional "login input" for OpenId,
a user who didn't want to use his/her email address to login could always
just use an IdP URL or XRI instead (as they can today).

Am I missing the privacy concern here?  

> * Reassignability: email addresses are not only reassignable, but for some
> domains, they are notoriously short-lived identifiers.

Is this really such a problem?  It seems to exist for URL's in the current
protocol proposal anyway.  For instance, most people don't own a Domain,
which means they'll be using OpenID URL's that somebody else owns.  Thus,
URL's are reassignable too, and suffer from this in the same way (although I
don't really see this as a problem).

> * Non-portability: unless you own the top-level domain, they aren't
> portable.

Again, is this a problem if the email isn't the actual identifier?  If we
have a means of mapping an email to an OpenID Identity URL, then if the
email goes away (is transferred or otherwise not in the control of the
original user), then what's the problem?

Point 1.) Losing an email address is no different than the case where a URL
is lost/transferred/goes away.

Point 2.) If a user "lost" his email address, theoretically the owner of the
email address (example.com, e.g.) would remove the mapping from
[EMAIL PROTECTED] to beth's Identity Provider URL.

Point 3.) Even if the email address domain owner failed to remove this
mapping, only the end-user (beth in this case) would be using the email to
login.  Presumably, if she switched email addresses, she would use her new
address to login, and it wouldn't matter.  Somebody else trying to use her
email address would need to login to the IdP, and presumably be stopped
there.

> Food for thought...
> 
> =Drummond


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


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

2006-11-08 Thread Jonathan Daugherty
# SIDE NOTE: For those who argue against email addresses in the OpenId
# login form on the grounds of confusion, these 2 email proposals
# should be no less "confusing" than trying to educate a user that the
# Identity URL they type in (e.g., http://aol.com) is not their
# identity.  Both will/would take some education.

Except that with this new feature, there would be twice as much
confusion.

And except that an openid works both as a normal URL and as an OpenID,
whereas an email-like-thing may work as an OpenID, but is not always
going to work as an email even though it looks like one.

So maybe 2.5 times as much 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

2006-11-08 Thread David Fuelling
Hi All,

Sorry to re-open this can of worms, but I'm just getting a chance to chime
in.  I actually think David Recordan's idea re: email address to URL
resolution would be a great idea!  

My vote would also be to allow an Email address to map to an Identity
Provider URL.   NOTE:  The email address does not map to a Claimed
Identity nor to a Verified Identity  (This is key!) 

Assuming I'm reading David R's proposal correctly, I think the only
difference between the two proposals is that in mine, the IdP doesn't need
to know what email address was entered (remember, the email is NOT the
identity -- it's just a mapping).

Here it is



1.) User enters an email address into an RP's OpenId login box.
2.) Behind the scenes, the RP resolves the email address to an OpenId URL
via [Resolution Procedure] below.
3.) If the email address resolves to an Identity Provider URL, then the RP
continues the OpenId protocol as if the user had entered the Identity
Provider URL.
4.) If the email address does NOT resolve to an Identity Provider URL, then
the RP SHOULD display a page that says something like: "We're sorry, your
email address doesn't not yet support Open ID.  Please try a different
identifier type."  On the same page should be some verbiage to help educate
the user about what OpenID identifiers are, and possibly how email addresses
map to them.  Additionally, this could be a page to educate the user about
XRI's, and the other parts of OpenId that are appropriate.

###
[Resolution Procedure]:  An email address resolves to a valid OpenId IdP
URL, per the following procedure.

A1.) For a given email address of the form '[EMAIL PROTECTED]' and a
corresponding domain of the form 'http(s)://domain.tld/, a RP SHOULD attempt
OpenID URL discovery (See OpenId Auth 2.0 section 7.3 - Discovery) on the
following URL's that are resolved out of the specified email address:

1.) http://.
2.) http://www..

The above URL's MUST be resolved by replacing the  and  values
with corresponding values from the specified email address' 'domain' and
'tld' parameters.  In addition, resolution of the above 2 alternate URL's
should be done via a HEAD request to all of the URL's first, followed by a
GET request to all of the URL's if no URL produces a valid Yadis Resource
URL via the HEAD method.

A2.) Per the OpenId spec, if URL Discovery fails, then HTML-based discovery
should be attempted on the same URL's, in the same manner as above.




SIDE NOTE: For those who argue against email addresses in the OpenId login
form on the grounds of confusion, these 2 email proposals should be no less
"confusing" than trying to educate a user that the Identity URL they type in
(e.g., http://aol.com) is not their identity.  Both will/would take some
education.

Thanks!

David Fuelling
[EMAIL PROTECTED]

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

_

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

2006-10-23 Thread Hallam-Baker, Phillip



No, that is the work-arroundThe solution is 
to have the email client assign fonts according to who 
is writing. 
Messages from Lord 
Rees-Mogg are written in an elegant Edwardian Copperplate. 
Paris Hilton uses 
BroadwayComments from Dick come in this 
font
Sounds right to 
me.
> -Original Message-> From: 
[EMAIL PROTECTED]> [mailto:[EMAIL PROTECTED]] On 
Behalf Of Dick Hardt> Sent: Sunday, October 22, 2006 5:00 PM> To: 
Kaliya Hamlin> Cc: specs@openid.net> Subject: Re: [PROPOSAL] 
Handle "http://[EMAIL PROTECTED]"> 
Style Identifiers>>> On 22-Oct-06, at 12:43 PM, Kaliya 
Hamlin wrote:>> > For starters please don't use Comic Sans in 
professional> > correspondence. it is very hard to read (or take 
seriously)>  http://> > 
bancomicsans.com/home.html>> Kaliya: The easy solution is to have 
your email program turn> all responses to plain text. :-)> 
___> 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

2006-10-22 Thread Dick Hardt

On 22-Oct-06, at 9:04 PM, George Fletcher wrote:

>
>
> Dick Hardt wrote:
>>
>> On 22-Oct-06, at 7:00 PM, George Fletcher wrote:
>>
>>>
>>>
>>> Dick Hardt wrote:
 With OpenID, there is a presumption the user has selected a trust
 worthy IdP that  will only present the user's identifiers when it
 really is the user.

>>> Doesn't this imply that both the user and RP have to know which  
>>> IdP's
>>> are "trust worthy"?
>>
>> It is a choice by the user. Just like the user chooses with ISP to  
>> move their data, which browser to run, which OS to run. IN  
>> general, those are not dictated by the RP.
> I agree it is the user's choice to pick a "trust worthy" IDP.   
> However, if "un-trust worthy" IDPs exist, and users choose them,  
> then the RP (in order to protect itself) has to determine which  
> IDPs it considers "trust worthy".  Hence both the user and the RP  
> "have to know" which IDPs are "trust worthy" and which are not.

What is the RP needing to protect itself from?
How does the RP protect itself from users that pick bad passwords or  
post them on sticky notes on their computer or walk away from their  
computer while logged in?

>>
 Actually, idp.spammers.com cannot do that. The URL has metadata  
 that
 states which IdP(s) are authoritative. What idp.spammers.com can  
 do is
 flood an RP with a bunch of identifiers. But this is no  
 different then
 a script creating new accounts on a system and is defended using  
 the
 same mechanisms such as throttling and captchas.

>>> So why can't idp.spammers.com allow anyone to enter a URI of
>>> http://idp.spammers.com/ that resolves to a valid XRDS  
>>> document.
>>> The RP then follows the IdP service link back to
>>> https://idp.spammers.com and does the association exchange.  Now  
>>> the RP
>>> re-directs the user to https://idp.spammers.com for the login page,
>>> which just re-directs the user back to the RP with the valid  
>>> "assertion"
>>> fields. idp.spammers.com does not have to ask the user for
>>> authentication credentials (that is out of scope for the spec).  For
>>> commenting on blogs this would be similar to "bugmenot" for web
>>> subscription services.
>>>
>>> So of course, the RP just needs to "blacklist" idp.spammers.com.   
>>> But
>>> now we are back in the same situation we have today where its a race
>>> between spammers setting up "IdPs" and RPs "black-listing" them.
>>
>> I don't understand why the RP needs to do that ... is the RP  
>> wanting to do something it can't do today?
> No, not really.  Though in most cases today the RP is also the IDP  
> so relying on "some other party" to do the authentication doesn't  
> happen too often (except within certain closely related services).   
> There is nothing stopping the RP from looking at the URI for the  
> IDP and not accepting it as a valid IDP.

agreed, just  like an RP can look at an IP address and decide not to  
accept it.

>>
>>>
>>> Fundamentally, "trust worthiness" is paramount to making the system
>>> work.  For now, this means RPs will likely have some sort of ACL  
>>> (black
>>> or white) for the IdPs that they deal with.
>>
>> The "trust" I am referring to is the user "trusting" the IdP to  
>> not let someone else impersonate them.
> I believe that there is also a need for the RP to "trust" the IdP  
> to not allow impersonation.
>>
>> George: would you explain what problem you are wanting to solve so  
>> that we can deal with a concrete example? There are use cases  
>> OpenID solves today, and others require additional features that  
>> currently are not in the specification.
> A RP provides a personal finance service that allows users to  
> manage portfolio information online.  It also supports online bill  
> pay services.  This RP requires a set of information for the  
> "account" to be created at the RP.  With the current specs that RP  
> can accept the authenticated OpenID URI and request the additional  
> required information.  Nothing different here. The issue come in  
> the form of liability for the RP.  Is the RP liable if someone gets  
> access to someone else's information?  In today's world this is the  
> case partly because the RP is doing its own authentication.  If the  
> RP is "trusting" an IDP to do the authentication (plain, strong,  
> second factor, etc) then who is liable?  I suspect the RP is,  
> though they might be able to "go after" the IdP.  Thus the RP needs  
> to know which IdPs are "trust worthy" in order to protect its  
> liability exposure.

One of the key innovations of user-centric identity is that the RP  
and IdP do not need to trust each other. This is initially a tough  
concept to accept for people that have worked in the security industry.

If an RP wants strong authentication, then the RP will request a  
strong authentication claim, and yes, the RP will need to trust the  
entity that made that claim. Note that the strong authentication ma

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

2006-10-22 Thread George Fletcher


Dick Hardt wrote:
>
> On 22-Oct-06, at 7:00 PM, George Fletcher wrote:
>
>>
>>
>> Dick Hardt wrote:
>>> With OpenID, there is a presumption the user has selected a trust
>>> worthy IdP that  will only present the user's identifiers when it
>>> really is the user.
>>>
>> Doesn't this imply that both the user and RP have to know which IdP's
>> are "trust worthy"?
>
> It is a choice by the user. Just like the user chooses with ISP to 
> move their data, which browser to run, which OS to run. IN general, 
> those are not dictated by the RP.
I agree it is the user's choice to pick a "trust worthy" IDP.  However, 
if "un-trust worthy" IDPs exist, and users choose them, then the RP (in 
order to protect itself) has to determine which IDPs it considers "trust 
worthy".  Hence both the user and the RP "have to know" which IDPs are 
"trust worthy" and which are not.
>
>>> Actually, idp.spammers.com cannot do that. The URL has metadata that
>>> states which IdP(s) are authoritative. What idp.spammers.com can do is
>>> flood an RP with a bunch of identifiers. But this is no different then
>>> a script creating new accounts on a system and is defended using the
>>> same mechanisms such as throttling and captchas.
>>>
>> So why can't idp.spammers.com allow anyone to enter a URI of
>> http://idp.spammers.com/ that resolves to a valid XRDS document.
>> The RP then follows the IdP service link back to
>> https://idp.spammers.com and does the association exchange.  Now the RP
>> re-directs the user to https://idp.spammers.com for the login page,
>> which just re-directs the user back to the RP with the valid "assertion"
>> fields. idp.spammers.com does not have to ask the user for
>> authentication credentials (that is out of scope for the spec).  For
>> commenting on blogs this would be similar to "bugmenot" for web
>> subscription services.
>>
>> So of course, the RP just needs to "blacklist" idp.spammers.com.  But
>> now we are back in the same situation we have today where its a race
>> between spammers setting up "IdPs" and RPs "black-listing" them.
>
> I don't understand why the RP needs to do that ... is the RP wanting 
> to do something it can't do today?
No, not really.  Though in most cases today the RP is also the IDP so 
relying on "some other party" to do the authentication doesn't happen 
too often (except within certain closely related services).  There is 
nothing stopping the RP from looking at the URI for the IDP and not 
accepting it as a valid IDP.
>
>>
>> Fundamentally, "trust worthiness" is paramount to making the system
>> work.  For now, this means RPs will likely have some sort of ACL (black
>> or white) for the IdPs that they deal with.
>
> The "trust" I am referring to is the user "trusting" the IdP to not 
> let someone else impersonate them.
I believe that there is also a need for the RP to "trust" the IdP to not 
allow impersonation.
>
> George: would you explain what problem you are wanting to solve so 
> that we can deal with a concrete example? There are use cases OpenID 
> solves today, and others require additional features that currently 
> are not in the specification.
A RP provides a personal finance service that allows users to manage 
portfolio information online.  It also supports online bill pay 
services.  This RP requires a set of information for the "account" to be 
created at the RP.  With the current specs that RP can accept the 
authenticated OpenID URI and request the additional required 
information.  Nothing different here. The issue come in the form of 
liability for the RP.  Is the RP liable if someone gets access to 
someone else's information?  In today's world this is the case partly 
because the RP is doing its own authentication.  If the RP is "trusting" 
an IDP to do the authentication (plain, strong, second factor, etc) then 
who is liable?  I suspect the RP is, though they might be able to "go 
after" the IdP.  Thus the RP needs to know which IdPs are "trust worthy" 
in order to protect its liability exposure.

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


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

2006-10-22 Thread Hallam-Baker, Phillip
Wouldn't it be nice if we could just bypass all the stupid email callback stuff 
that we usually have to put up with?

Its easy to do, the only constraint being that the IdP has to be able to 
advertise an SRV record.

IdP advertises 

_openid.example.com  SRV 1 100 80 openid1.example.com


Given an identifier [EMAIL PROTECTED] the RP looks for the _openid service, 
resolves this works out where to resolve the URI. 

This does not have to be the only mode of resolution but it is certainly a very 
very useful one and something that can be used transparently inline with 
existing practice. Many sites already use the email address form as an 
identifier.

Of course there is a spam issue, there is a spam issue with every contact 
identifier. That's why you use the IdP account and don't muck up your email 
account.



> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf Of Dick Hardt
> Sent: Sunday, October 22, 2006 11:14 PM
> To: George Fletcher
> Cc: specs@openid.net
> Subject: Re: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" 
> Style Identifiers
> 
> 
> On 22-Oct-06, at 7:00 PM, George Fletcher wrote:
> 
> >
> >
> > Dick Hardt wrote:
> >> With OpenID, there is a presumption the user has selected a trust 
> >> worthy IdP that  will only present the user's identifiers when it 
> >> really is the user.
> >>
> > Doesn't this imply that both the user and RP have to know 
> which IdP's 
> > are "trust worthy"?
> 
> It is a choice by the user. Just like the user chooses with 
> ISP to move their data, which browser to run, which OS to 
> run. IN general, those are not dictated by the RP.
> 
> >> Actually, idp.spammers.com cannot do that. The URL has 
> metadata that 
> >> states which IdP(s) are authoritative. What 
> idp.spammers.com can do 
> >> is flood an RP with a bunch of identifiers. But this is no 
> different 
> >> then a script creating new accounts on a system and is 
> defended using 
> >> the same mechanisms such as throttling and captchas.
> >>
> > So why can't idp.spammers.com allow anyone to enter a URI of 
> > http://idp.spammers.com/ that resolves to a valid 
> XRDS document.
> > The RP then follows the IdP service link back to 
> > https://idp.spammers.com and does the association exchange. 
>  Now the 
> > RP re-directs the user to https://idp.spammers.com for the 
> login page, 
> > which just re-directs the user back to the RP with the valid 
> > "assertion"
> > fields. idp.spammers.com does not have to ask the user for 
> > authentication credentials (that is out of scope for the 
> spec).  For 
> > commenting on blogs this would be similar to "bugmenot" for web 
> > subscription services.
> >
> > So of course, the RP just needs to "blacklist" 
> idp.spammers.com.  But 
> > now we are back in the same situation we have today where 
> its a race 
> > between spammers setting up "IdPs" and RPs "black-listing" them.
> 
> I don't understand why the RP needs to do that ... is the RP 
> wanting to do something it can't do today?
> 
> >
> > Fundamentally, "trust worthiness" is paramount to making the system
> > work.  For now, this means RPs will likely have some sort of ACL  
> > (black
> > or white) for the IdPs that they deal with.
> 
> The "trust" I am referring to is the user "trusting" the IdP to not  
> let someone else impersonate them.
> 
> George: would you explain what problem you are wanting to solve so  
> that we can deal with a concrete example? There are use cases OpenID  
> solves today, and others require additional features that currently  
> are not in the specification.
> 
> -- Dick
> 
> ___
> 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

2006-10-22 Thread Dick Hardt

On 22-Oct-06, at 7:00 PM, George Fletcher wrote:

>
>
> Dick Hardt wrote:
>> With OpenID, there is a presumption the user has selected a trust
>> worthy IdP that  will only present the user's identifiers when it
>> really is the user.
>>
> Doesn't this imply that both the user and RP have to know which IdP's
> are "trust worthy"?

It is a choice by the user. Just like the user chooses with ISP to  
move their data, which browser to run, which OS to run. IN general,  
those are not dictated by the RP.

>> Actually, idp.spammers.com cannot do that. The URL has metadata that
>> states which IdP(s) are authoritative. What idp.spammers.com can  
>> do is
>> flood an RP with a bunch of identifiers. But this is no different  
>> then
>> a script creating new accounts on a system and is defended using the
>> same mechanisms such as throttling and captchas.
>>
> So why can't idp.spammers.com allow anyone to enter a URI of
> http://idp.spammers.com/ that resolves to a valid XRDS document.
> The RP then follows the IdP service link back to
> https://idp.spammers.com and does the association exchange.  Now  
> the RP
> re-directs the user to https://idp.spammers.com for the login page,
> which just re-directs the user back to the RP with the valid  
> "assertion"
> fields. idp.spammers.com does not have to ask the user for
> authentication credentials (that is out of scope for the spec).  For
> commenting on blogs this would be similar to "bugmenot" for web
> subscription services.
>
> So of course, the RP just needs to "blacklist" idp.spammers.com.  But
> now we are back in the same situation we have today where its a race
> between spammers setting up "IdPs" and RPs "black-listing" them.

I don't understand why the RP needs to do that ... is the RP wanting  
to do something it can't do today?

>
> Fundamentally, "trust worthiness" is paramount to making the system
> work.  For now, this means RPs will likely have some sort of ACL  
> (black
> or white) for the IdPs that they deal with.

The "trust" I am referring to is the user "trusting" the IdP to not  
let someone else impersonate them.

George: would you explain what problem you are wanting to solve so  
that we can deal with a concrete example? There are use cases OpenID  
solves today, and others require additional features that currently  
are not in the specification.

-- Dick

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


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

2006-10-22 Thread George Fletcher


Dick Hardt wrote:
> With OpenID, there is a presumption the user has selected a trust 
> worthy IdP that  will only present the user's identifiers when it 
> really is the user.
>
Doesn't this imply that both the user and RP have to know which IdP's 
are "trust worthy"?
> Actually, idp.spammers.com cannot do that. The URL has metadata that 
> states which IdP(s) are authoritative. What idp.spammers.com can do is 
> flood an RP with a bunch of identifiers. But this is no different then 
> a script creating new accounts on a system and is defended using the 
> same mechanisms such as throttling and captchas.
>
So why can't idp.spammers.com allow anyone to enter a URI of 
http://idp.spammers.com/ that resolves to a valid XRDS document.  
The RP then follows the IdP service link back to 
https://idp.spammers.com and does the association exchange.  Now the RP 
re-directs the user to https://idp.spammers.com for the login page, 
which just re-directs the user back to the RP with the valid "assertion" 
fields. idp.spammers.com does not have to ask the user for 
authentication credentials (that is out of scope for the spec).  For 
commenting on blogs this would be similar to "bugmenot" for web 
subscription services.

So of course, the RP just needs to "blacklist" idp.spammers.com.  But 
now we are back in the same situation we have today where its a race 
between spammers setting up "IdPs" and RPs "black-listing" them.

Fundamentally, "trust worthiness" is paramount to making the system 
work.  For now, this means RPs will likely have some sort of ACL (black 
or white) for the IdPs that they deal with.

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


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

2006-10-22 Thread Dick Hardt
On 22-Oct-06, at 5:05 PM, George Fletcher wrote:

>
> Dick Hardt wrote:
>> What is different with OpenID vs email is that there is certainty   
>> that the user actually is the user.
> I'm a little confused.  How is there certainty that "the user  
> actually is the user"?  The viability of the identifier  
> representing the same user is dependent on the OpenID provider not  
> recycling identifiers. Or did you just mean that in email,  
> authentication is not always required for someone to use an email  
> identifier?

With SMTP,  a bad guy can forge the headers.

With OpenID, there is a presumption the user has selected a trust  
worthy IdP that  will only present the user's identifiers when it  
really is the user.


>
> Note that the OpenID protocol does not prevent idp.spammers.com  
> from allowing any identifier to be used and "authenticated"  
> regardless of whether it's the same user or not.  It is incumbent  
> on the relying parties to determine if they will allow identifiers  
> authenticated by a particular idp.

Actually, idp.spammers.com cannot do that. The URL has metadata that  
states which IdP(s) are authoritative. What idp.spammers.com can do  
is flood an RP with a bunch of identifiers. But this is no different  
then a script creating new accounts on a system and is defended using  
the same mechanisms such as throttling and captchas.

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


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

2006-10-22 Thread Dick Hardt

On 22-Oct-06, at 2:28 PM, Praveen Alavilli wrote:

>
>
> [EMAIL PROTECTED] wrote:
>> For starters please don't use Comic Sans in professional  
>> correspondence. it is very hard to read (or take seriously)   
>> http://bancomicsans.com/home.html
>>
>>
>> On Oct 22, 2006, at 11:44 AM, Praveen Alavilli wrote:
>>>
>>>
>>> It's more of a problem with how we can accept 3rd party OpenId  
>>> users at AOL (we as an RP). Obviously for simple use cases like  
>>> leaving comments on blogs it wouldn't really matter as long as  
>>> the user is identified by someone (and someone doing rate  
>>> limiting or something else to prevent spamming - otherwise I  
>>> still can't see how it reduces spam anyway) - but when we want to  
>>> take it to the next level - provide more services to these users  
>>> (photos/calendar/etc.. ) we want to limit it to only a few IDPs  
>>> whom we trust. (due to both security and business reasons).
>>
>> This doesn't really work in the model.  The goal is to let anyone  
>> set up their own OpenID and that basically across the OpenID  
>> universe it works.  You limiting it to only like verisign or other  
>> 'big' IdP's is not really part of the vision of what we are trying  
>> to build.  Obviously behind this whole network needs to be  
>> reputation for IdPs and individual OpenID addresses.
> I understand it's not the vision of OpenId, but accepting  
> identities from everyone else in the world is not going to happen  
> in "reality".

It will in my "reality" :-)

> Obviously there is no reputation service built by trusted vendors  
> (similar to CAs) yet. We need a short term solution atleast (though  
> we all hate short term solutions) if we really want OpenId to be  
> supported by big players  - isn't it ?
>>
>>> So this is the problem we are trying to figure out how we can  
>>> message the users that we support OpenIds from certain providers  
>>> (say Verisign PIP) but not from all.
>>
>> This is one way to approach it and I hope you don't do it this way  
>> because it breaks what OpenID is about.
> Well, it really depends on what else OpenIds are going to be used  
> for. As I said, if it's just the blogging domain I don't think  
> there are any issues. If we want to start pushing OpenId into a  
> trusted and secure authentication domain (I really think it  
> should), some changes need to happen.  Although "Reputation" is a  
> good solution but unfortunately Reputation for IDPs or user URI's  
> is not going to build over night. It changes the way how web apps  
> and users got used to traditionally. Today as an example, I can  
> goto AOL Personal Finance, create an account, setup my financial  
> accounts, bill pay, etc.. with in few mins.

And they could do the same thing with OpenID. The difference would be  
they would not need to create a password, and could click buttons to  
provide a bunch of the profile data. There really is little  
difference except for the automation.


>>>
>>> Another area where we want some more clarification (if it already  
>>> exists) or support is about how we can have a persistent handler  
>>> (apart from URI) for a given user so it would help in cases when  
>>> a user's account gets reclaimed by someone else.
>>
>> ahh...that is where further reading of what i-names and i-numbers  
>> are about would help.  Because there is another level of  
>> indirection built in, when an i-name is reassigned the i-number  
>> below it is not.   This helps users not have the 'reclaiming by  
>> someone else problem' when depending on URLs.
> Actually there were 2 things I was trying to point on in my  
> previous mail (sorry I was not clear). One is the persistent id,  
> which would probably be satisfied with i-numbers (even though I was  
> looking more for optimization by including it as part of the  
> authentication response itself) and second is the PPID (or LUID or  
> SUID or whatever people refer to them in different protocols/ 
> specs), which is not just an i-number but it's an id that's  
> different for each RP such that users cannot be tracked across  
> different sites.

There are "portable identifiers". URLs that the user controls that  
they can point to whichever IdP they want.

There are also "directed identifiers". URLs generated by the IdP and  
managed by the IdP for each RP. In other words, there is a separate  
identifier for each RP so that RPs cannot correlate data.

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


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

2006-10-22 Thread George Fletcher


Dick Hardt wrote:
>
> On 20-Oct-06, at 10:14 AM, George Fletcher wrote:
>>
>> 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.
>
> My understanding of the proposal from David was that this was a way to 
> discover the user's IdP, not that the email was an identifier.
>
> -- Dick
>
Sorry to imply that email should be a valid identifier.  That wasn't my 
intent.  I'm fine with where this discussion is headed (and has headed 
in the past; after reading the old threads).  For wide spread adoption 
it will be very important to have a "If you're not sure what to enter, 
click here" link on the login form to try and explain to users what they 
might be able to try as identifiers.

My comment was really trying to speak to the issue of identifier 
portability.  Is there an OpenID definition for this?

If I have an OpenID provided by SomeSite as http://george.somesite.com, 
then how is that identifier portable?  For it to be portable, 
somesite.com would have to allow me to either (a) change the HTML code 
of my "public page" (though if I read the draft 2.0 spec correctly, the 
HTML method is deprecated) or (b) provide some mechanism where I could 
change the IDP service URL returned in the XRDS document.  If 
somesite.com does not provide either of these mechanisms, then this 
identifier is not "portable".  Also, the viability of my identifier may 
be dependent on the service. For instance, somesite.com may have a rule 
that says if I delete my SomeSite "account", then they will no longer 
authenticate my identifier. Of course, user choice always enters in and 
I can choose to not use that service as my OpenID identifier provider.

The "i-names" infrastructure does solve some of this by focusing on the 
identity management issues.  Though here I'm paying explicitly for this 
"portability" service (along with others).

Thanks,
George

P.S. Should this discussion get moved to the "general" list?
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs


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

2006-10-22 Thread Praveen Alavilli






[EMAIL PROTECTED] wrote:

  For starters please don't use Comic Sans in professional
correspondence. it is very hard to read (or take seriously)  http://bancomicsans.com/home.html
  
  
  
  
  On Oct 22, 2006, at 11:44 AM, Praveen Alavilli wrote:
  

It's more of a problem with how we can accept 3rd party OpenId users at
AOL (we as an RP). Obviously for simple use cases like leaving comments
on blogs it wouldn't really matter as long as the user is identified by
someone (and someone doing rate limiting or something else to prevent
spamming - otherwise I still can't see how it reduces spam anyway) -
but when we want to take it to the next level - provide more services
to these users (photos/calendar/etc.. ) we want to limit it to only a
few IDPs whom we trust. (due to both security and business reasons).

  
  
  This doesn't really work in the model.  The goal is to let
anyone set up their own OpenID and that basically across the
OpenID universe it works.  You limiting it to only like verisign or
other 'big' IdP's is not really part of the vision of what we are
trying to build.  Obviously behind this whole network needs to be
reputation for IdPs and individual OpenID addresses.  
  
  

I understand it's not the vision of OpenId, but accepting identities
from everyone else in the world is not going to happen in "reality".
Obviously there is no reputation service built by trusted vendors
(similar to CAs) yet. We need a short term solution atleast (though we
all hate short term solutions) if we really want OpenId to be supported
by big players  - isn't it ?

  
   So this is
the problem we are trying to figure out how we can message the users
that we support OpenIds from certain providers (say Verisign PIP) but
not from all. 

  
  
  This is one way to approach it and I hope you don't do it this
way because it breaks what OpenID is about. 
  
  

Well, it really depends on what else OpenIds are going to be used for.
As I said, if it's just the blogging domain I don't think there are any
issues. If we want to start pushing OpenId into a trusted and secure
authentication domain (I really think it should), some changes need to
happen.  Although "Reputation" is a good solution but unfortunately
Reputation for IDPs or user URI's is not going to build over night. It
changes the way how web apps and users got used to traditionally. Today
as an example, I can goto AOL Personal Finance, create an account,
setup my financial accounts, bill pay, etc.. with in few mins. If we
are going to start providing the services to the user based on their
Reputation scores, it changes the complete model - as a user do I need
to wait for a long time before I can actually use all the cool features
provided by AOL Personal Finance and do I constantly need to worry
about someone mistakenly causing negative reputation on my account? 
May be I am over complicating but that doesn't sound easy and can be
built quickly.

  
  
Another area where we want some more clarification (if it already
exists) or support is about how we can have a persistent handler (apart
from URI) for a given user so it would help in cases when a user's
account gets reclaimed by someone else. 

  
  
  ahh...that is where further reading of what i-names and
i-numbers are about would help.  Because there is another level of
indirection built in, when an i-name is reassigned the i-number below
it is not.   This helps users not have the 'reclaiming by someone else
problem' when depending on URLs. 
  
  

Actually there were 2 things I was trying to point on in my previous
mail (sorry I was not clear). One is the persistent id, which would
probably be satisfied with i-numbers (even though I was looking more
for optimization by including it as part of the authentication response
itself) and second is the PPID (or LUID or SUID or whatever people
refer to them in different protocols/specs), which is not just an
i-number but it's an id that's different for each RP such that users
cannot be tracked across different sites. 

thx
Praveen


  
  
 


  
  
  
   
  __
  
  
  Identity Woman: Saving the world with user-centric identity. 
www.identitywoman.net
   
  
=
  

___
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

2006-10-22 Thread George Fletcher


Dick Hardt wrote:
> What is different with OpenID vs email is that there is certainty  
> that the user actually is the user. 
>   
I'm a little confused.  How is there certainty that "the user actually 
is the user"?  The viability of the identifier representing the same 
user is dependent on the OpenID provider not recycling identifiers. Or 
did you just mean that in email, authentication is not always required 
for someone to use an email identifier?

Note that the OpenID protocol does not prevent idp.spammers.com from 
allowing any identifier to be used and "authenticated" regardless of 
whether it's the same user or not.  It is incumbent on the relying 
parties to determine if they will allow identifiers authenticated by a 
particular idp.

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


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

2006-10-22 Thread Kaliya Hamlin
For starters please don't use Comic Sans in professional correspondence. it is very hard to read (or take seriously)  http://bancomicsans.com/home.htmlOn Oct 22, 2006, at 11:44 AM, Praveen Alavilli wrote:  It's more of a problem with how we can accept 3rd party OpenId users at AOL (we as an RP). Obviously for simple use cases like leaving comments on blogs it wouldn't really matter as long as the user is identified by someone (and someone doing rate limiting or something else to prevent spamming - otherwise I still can't see how it reduces spam anyway) - but when we want to take it to the next level - provide more services to these users (photos/calendar/etc.. ) we want to limit it to only a few IDPs whom we trust. (due to both security and business reasons).This doesn't really work in the model.  The goal is to let anyone set up their own OpenID and that basically across the OpenID universe it works.  You limiting it to only like verisign or other 'big' IdP's is not really part of the vision of what we are trying to build.  Obviously behind this whole network needs to be reputation for IdPs and individual OpenID addresses.   So this is the problem we are trying to figure out how we can message the users that we support OpenIds from certain providers (say Verisign PIP) but not from all. This is one way to approach it and I hope you don't do it this way because it breaks what OpenID is about.  Another area where we want some more clarification (if it already exists) or support is about how we can have a persistent handler (apart from URI) for a given user so it would help in cases when a user's account gets reclaimed by someone else. ahh...that is where further reading of what i-names and i-numbers are about would help.  Because there is another level of indirection built in, when an i-name is reassigned the i-number below it is not.   This helps users not have the 'reclaiming by someone else problem' when depending on URLs. __Identity Woman: Saving the world with user-centric identity. www.identitywoman.net ___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs


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

2006-10-22 Thread Praveen Alavilli




[Please pardon me if I am spamming
the spec mailing list with general comments/issues that might have been
discussed before]

It's not the problem of just making AOL users OpenId enabled, so they
can access 3rd party RPs (use http://www.aol.com/ or
http://aimpages.com/ or
http://journals.aol.com/, etc) - as someone else
said it's a matter of educating the users (even if it takes long time
based on user's geek level - because pretty much every IDP out there
today tries to educate users about how to make sure they are not
entering their credentials at a phishing site, but it still happens). 

It's more of a problem with how we can accept 3rd party OpenId users at
AOL (we as an RP). Obviously for simple use cases like leaving comments
on blogs it wouldn't really matter as long as the user is identified by
someone (and someone doing rate limiting or something else to prevent
spamming - otherwise I still can't see how it reduces spam anyway) -
but when we want to take it to the next level - provide more services
to these users (photos/calendar/etc.. ) we want to limit it to only a
few IDPs whom we trust. (due to both security and business reasons). So
this is the problem we are trying to figure out how we can message the
users that we support OpenIds from certain providers (say Verisign PIP)
but not from all. Obviously we can just follow the existing model of a
free form field that says "Enter your OpenId" but most of the time we
will end up failing the users saying "we don't accept your OpenId".
Just bad user experience in our opinion. So instead we want to somehow
message the user saying these are the only IDPs we trust - whether
showing a drop down list of IDPs on the login form or something else,
we want to see a standard way of doing it so user's don't feel like
they are in an alien world from one RP to another (ofcourse keeping
aside the phishing issues). We totally agree that adding another option
to the already confusing list of account types is a bad idea. 

Another area where we want some more clarification (if it already
exists) or support is about how we can have a persistent handler (apart
from URI) for a given user so it would help in cases when a user's
account gets reclaimed by someone else. Instead of it being an
additional attribute that IDP can advertise as supported (which an RP
can get via the Attribute Exchange protocol), if it can be baked into
the "authentication" response, itself as a required field, it would
help in having a common way of doing a locally stored identity
discovery. If it can be generated similar to how PPID (Private Personal
Identifier) is generated dynamically by Infocard it would be a great
addition to OpenId IMO.

thx
=Praveen.alavilli



[EMAIL PROTECTED] wrote:

  On 20-Oct-06, at 12:17 PM, John Panzer 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.


  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.

  
  
I empathize with your problem John, but I agree with Kaliya and others.

Lets take another step back and envision what the login box prompt  
will say. In OpenID 1.x it was:

"Enter your OpenID"

With some text to explain what an OpenID was.

With OpenID 2.0, we have something like:

"Homesite | i-name | OpenID"

(Homesite being more user friendly then 

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

2006-10-22 Thread Dick Hardt
On 22-Oct-06, at 11:44 AM, Praveen Alavilli wrote:
> It's more of a problem with how we can accept 3rd party OpenId  
> users at AOL (we as an RP). Obviously for simple use cases like  
> leaving comments on blogs it wouldn't really matter as long as the  
> user is identified by someone (and someone doing rate limiting or  
> something else to prevent spamming - otherwise I still can't see  
> how it reduces spam anyway) - but when we want to take it to the  
> next level - provide more services to these users (photos/calendar/ 
> etc.. ) we want to limit it to only a few IDPs whom we trust. (due  
> to both security and business reasons). So this is the problem we  
> are trying to figure out how we can message the users that we  
> support OpenIds from certain providers (say Verisign PIP) but not  
> from all. Obviously we can just follow the existing model of a free  
> form field that says "Enter your OpenId" but most of the time we  
> will end up failing the users saying "we don't accept your OpenId".  
> Just bad user experience in our opinion. So instead we want to  
> somehow message the user saying these are the only IDPs we trust -  
> whether showing a drop down list of IDPs on the login form or  
> something else, we want to see a standard way of doing it so user's  
> don't feel like they are in an alien world from one RP to another  
> (ofcourse keeping aside the phishing issues). We totally agree that  
> adding another option to the already confusing list of account  
> types is a bad idea.

OpenID Authentication allows you to know it is the same user that you  
saw last time. In many ways, it is an automated mechanism for public  
sites that allow anyone to create an account by selecting a username  
and a password. Limiting users to come from only a small set of IdPs  
is like limiting which ISPs can connect to your website -- it is not  
the user-centric model.

For example, if you have not seen an identifier before, you may  
require them to enter a captcha. When you see them again, and if they  
did not do something *bad*, then you may not need to prompt them for  
the *captcha* again.

What is different with OpenID vs email is that there is certainty  
that the user actually is the user. With email, there is no certainty  
that the from: field really is who sent the message, which is what a  
number of protocols in the SMTP world are working to resolve.. Just  
like in the battle with spam, once you have the identity of the user,  
then you can have 3rd party assertions from someone you trust (if  
needed) to have more data about the user.

For example, there may be a service provider that asserts that a  
given identifier belongs to a user that has a *good* reputation.

-- Dick



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


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

2006-10-22 Thread Dick Hardt

On 22-Oct-06, at 12:43 PM, Kaliya Hamlin wrote:

> For starters please don't use Comic Sans in professional  
> correspondence. it is very hard to read (or take seriously)  http:// 
> bancomicsans.com/home.html

Kaliya: The easy solution is to have your email program turn all  
responses to plain text. :-)
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs


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

2006-10-22 Thread Recordon, David
While I'd certainly agree that a goal is letting anyone setup and IdP
and have it work on any RP, I see that as utopia.  The protocol should
certainly support that, as well as not do anything to actively thwart
it.  With that said, OpenID as a protocol can be used in cases where
this may not be desired.
 
I agree that the best way to look at this is by creating a distributed
trust/reputation network.  This thus allows a RP to intelligently make a
decision of if it should accept a given identifier, or the IdP it is
hosted on.  Right now I see this as needed to really bootstrap large
scale adoption.
 
Any word from Karmasphere about something like this Meng?
 
--David
 
P.S. Plain-text kills all fonts. :)



From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Kaliya Hamlin
Sent: Sunday, October 22, 2006 3:43 PM
To: specs@openid.net
Subject: Re: [PROPOSAL] Handle "http://[EMAIL PROTECTED]" Style
Identifiers


For starters please don't use Comic Sans in professional correspondence.
it is very hard to read (or take seriously)
http://bancomicsans.com/home.html


On Oct 22, 2006, at 11:44 AM, Praveen Alavilli wrote:



It's more of a problem with how we can accept 3rd party OpenId
users at AOL (we as an RP). Obviously for simple use cases like leaving
comments on blogs it wouldn't really matter as long as the user is
identified by someone (and someone doing rate limiting or something else
to prevent spamming - otherwise I still can't see how it reduces spam
anyway) - but when we want to take it to the next level - provide more
services to these users (photos/calendar/etc.. ) we want to limit it to
only a few IDPs whom we trust. (due to both security and business
reasons).



This doesn't really work in the model.  The goal is to let anyone set up
their own OpenID and that basically across the OpenID universe it works.
You limiting it to only like verisign or other 'big' IdP's is not really
part of the vision of what we are trying to build.  Obviously behind
this whole network needs to be reputation for IdPs and individual OpenID
addresses.  


So this is the problem we are trying to figure out how we can
message the users that we support OpenIds from certain providers (say
Verisign PIP) but not from all. 



This is one way to approach it and I hope you don't do it this way
because it breaks what OpenID is about. 


Another area where we want some more clarification (if it
already exists) or support is about how we can have a persistent handler
(apart from URI) for a given user so it would help in cases when a
user's account gets reclaimed by someone else. 



ahh...that is where further reading of what i-names and i-numbers are
about would help.  Because there is another level of indirection built
in, when an i-name is reassigned the i-number below it is not.   This
helps users not have the 'reclaiming by someone else problem' when
depending on URLs. 







__

Identity Woman: Saving the world with user-centric identity. 
www.identitywoman.net


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


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

2006-10-22 Thread Dick Hardt

On 20-Oct-06, at 10:14 AM, George Fletcher wrote:

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

See email to John. I think the user is already familiar with typing  
in a domain name to get to a site. They can type in yahoo.com,  
google.com or aol.com to get to their prospective homesite.

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

LOL ... and who would determine who the "common IdPs" are? :-) ... I  
can envision many enterprises managing their employees identity.

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

My understanding of the proposal from David was that this was a way  
to discover the user's IdP, not that the email was an identifier.

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


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

2006-10-22 Thread Dick Hardt

On 20-Oct-06, at 12:17 PM, John Panzer 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.
>> 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.

I empathize with your problem John, but I agree with Kaliya and others.

Lets take another step back and envision what the login box prompt  
will say. In OpenID 1.x it was:

"Enter your OpenID"

With some text to explain what an OpenID was.

With OpenID 2.0, we have something like:

"Homesite | i-name | OpenID"

(Homesite being more user friendly then IdP)

All of these items are new things to users, and the user either has  
one or does not.

If we support email addresses, then the prompt may look something  
like this:

"email | Homesite | i-name | OpenID"

Now any user with an email address thinks they can type it into the  
box and login. This of course is not going to be the case.

I think the most straightforward method for your users is to educate  
them that AOL is now a homesite, and they can type in aol.com into  
the box. This user experience then is very similar to the user typing  
in aol.com into the address bar. They get sent to aol.com which will  
then prompt them for [EMAIL PROTECTED]

Given that you need to educate them that they can do something new to  
begin with, this seems to be the most straightforward path.

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


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

2006-10-20 Thread 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

2006-10-20 Thread 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

2006-10-20 Thread 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

2006-10-20 Thread 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

2006-10-20 Thread 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

2006-10-20 Thread 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

2006-10-20 Thread 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

2006-10-20 Thread 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

2006-10-20 Thread 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

2006-10-20 Thread 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

2006-10-20 Thread 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

2006-10-20 Thread 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

2006-10-20 Thread 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

2006-10-20 Thread 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


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

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


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

2006-10-19 Thread Hallam-Baker, Phillip
Back at the dawn of the Web I made the mistake of thinking that the address bar 
was the place you type a URI.

We now know that it is the place you type a search term that may be a URL in 
canonical form or may be a domain name or may be a search term to be thrown at 
a search engine. It was one of the principle innovations in Netscape over 
Mosaic.

Any identifier can be represented as a URI. Just stick SCHEME: in front.


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