RE: IDMML (was RE: Using email address as OpenID identifier)

[Drummond Reed]

> >> George Fletcher wrote:
> >>
> >> I think relying party sites that support OpenID could do more to make
> it
> >> clear on their home pages that they support OpenID (as often it's
> hidden
> >> behind another click). This could be as simple as some  tags that
> >> advertise support for OpenID. Maybe a  to the XRDS doc describing
> >> the services of the site. Then the identity agent can discover the
> >> relying party OpenID return_to endpoint and log the user in directly.
> >> Can be used to solve a phishing problem and makes the experience easy
> >> for the user.
> >>
> >> Some related thoughts 
> >>http://practicalid.blogspot.com/2007/06/clients-to-rescue.html
> >>
> >> http://practicalid.blogspot.com/2007/06/passive-identity-meta-system-
> >> markup.html
> >>
> > Drummond wrote:
> > George, I read your two posts with great interest...and then noticed
> that
> > they were last summer!
> >
> > You are a man ahead of your time.
> >
> > Where has discussion of your "IDMML" gone since your posts?
> >
> George wrote:
> Unfortunately, not as far as I'd like :(  I've not been able to get back
> to the ideas and take them farther. With the other things that have
> happened in the last 6 months there are needed revisions. Maybe this
> could be a discussion at IIW (if there is enough interest)?
> 
> At the time there was less consensus around XRDS as a service
> "description/meta-data" markup. With that changing, the time is better
> to move this forward. I suspect there are significant synergies with
> what Peter hinted at in the work with XRDS, IDP Discovery, and SAML. It
> would be great if identity agents could be the glue that binds the
> different identity systems together for the user (until we on the
> technology side get closer to real convergence:).

George, I agree that several things have evolved which could make an IDMML
practical now. Seems like a very good topic for IIW. I just put it on the
list of proposed sessions:

http://iiw.idcommons.net/index.php/Proposed_Topics_2008a 

=Drummond 

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

RE: IDMML (was RE: Using email address as OpenID identifier)

[Drummond Reed]

Chris, I remember that well, and I agree that it makes a lot of sense. I
think when this is combined with George's concept of the other ways in which
a local identity agent can assist the use, then IDMML really starts to gain
some legs.

See also my reply to George.

=Drummond 

> -Original Message-
> From: Chris Drake [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, April 02, 2008 1:30 PM
> To: Drummond Reed
> Cc: 'George Fletcher'; 'Dick Hardt'; specs@openid.net
> Subject: Re: IDMML (was RE: Using email address as OpenID identifier)
> 
> Hi Drummond,
> 
> I pushed hard for RP identification for 2 or 3 months back around
> October 2006.  If anyone wants to go back through the archives,
> there's a pile of other important reasons to have some way that an IdP
> and/or browser agent can identify an OpenID-enabled site.  The antique
> thread below lists a few.  My proposal too was a  tag.
> 
> Kind Regards,
> Chris Drake
> 
> 
> Tuesday, November 7, 2006, 12:51:15 I, you wrote:
> 
> CD> Hi Johannes,
> 
> CD> I proposed a solution to the "single sign out" problem a month or two
> CD> ago.
> 
> CD> In fact - a whole range of solutions have been proposed, and relative
> CD> merits of all discussed already - does anyone have the free time to go
> CD> back over the postings, extract all the knowledge & contributions, and
> CD> document them all?
> 
> CD> To summarize my proposal - I was seeking a standardized OpenID RP
> CD> endpoint interface into which I (as an IdP) or a software agent (eg: a
> CD> browser plugin) could "post" user information - be this a login
> CD> request, email change request, log-out request, account signup,
> CD> account cancelation, or whatever.  My preferred implementation was a
> CD>  tag placed on (and thus identifying) a login page, and within
> CD> the link tag, the endpoint of the RP for accepting IdP(OP/agent)
> CD> input.
> 
> CD> Kind Regards,
> CD> Chris Drake
> 
> 
> CD> Tuesday, November 7, 2006, 1:04:44 PM, you wrote:
> 
> JE>> I continue to believe that we need single-sign-out
> JE>> functionality, in particular once OpenID moves up the stack for
> JE>> higher-value transactions.
> 
> 
> JE>> Some people have made the case that that is undesirable
> JE>> and/or impossible; I beg to differ.
> 
> 
> JE>> Having automatic authentication against the IdP is quite
> JE>> similar to not having a password on the identity at all, in that
> JE>> it reduces the confidence that we know the real-world identity of
> JE>> the entity/user at the other end. In my view, there's nothing
> JE>> wrong with that, but we do need to be able to convey that to
> JE>> relying parties in a way that cannot be easily attacked.
> 
> 
> 
> 
> 
> JE>> On Nov 6, 2006, at 16:41, Joshua Viney wrote:
> 
> JE>> One question re: User Experience and single-sign-on comes to mind:
> 
> 
> JE>> How do we treat users who are accessing their IdP and
> JE>> Relying Parties via public computers?
> 
> 
> JE>> Use Case:
> JE>> Good User at public library wants to leave a comment on Blog X
> JE>> Blog X requires the person to authenticate via OpenID
> JE>> Good User enters their OpenID and successfully authenticates
> JE>> via email and password (or whatever) (and authorizes the RP
> JE>> ('realm' in 2.0) if necessary) at their IdP
> JE>> Good User is redirected to Blog X signed in
> JE>> Good User leaves comment
> JE>> Good User signs out of Blog X (if sign out is even an option)
> JE>> Good User then leaves the public library and goes shopping
> JE>> Evil User jumps on computer and proceeds to leave comments at
> JE>> any number of OpenID enabled blogs using Good User's OpenID (he
> JE>> saw it while looking over Good User's shoulder, or he checks any
> JE>> sites that Good User did NOT sign out of that might display his
> JE>> OpenID)
> JE>> Evil User, uses Good User's signed in IdP session to sign into any
> number of sites, etc
> 
> 
> JE>> Outcome: Good User's reputation is ruined and his/her OpenID
> JE>> is banned from a whole list of Relying Parties. Good User then
> JE>> blames their IdP, the Relying Parties and OpenID as a technology
> JE>> and tells everyone he/she knows not to use it blogs about it and
> JE>> initiates a press release.
> 
> 
> JE>> It may be easy to pass this off as an implementation specific
> JE>> issue or as "user error", but this use case is somewhat likely for
> JE>> 2 reasons:
> 
> 
> JE>> 1. A user's OpenID URI is not necessarily a private thing
> JE>> (obscurity is not security anyway)
> JE>> 2. Users will be at least 1 site removed from their IdP while
> JE>> accessing a Relying Party, and no one is use to signing out twice
> JE>> 3. It is very very likely that IdP's will use some type of "remember
> me" functionality
> 
> 
> JE>> One solution to consider would be a global sign-out feature
> JE>> on relying party sites that signs users out of their IdP as well.
> JE>> Another solution would be to make very specific recommendations
> JE>> about messaging users who may be using publi

Re: IDMML (was RE: Using email address as OpenID identifier)

[Chris Drake]

Hi Drummond,

I pushed hard for RP identification for 2 or 3 months back around
October 2006.  If anyone wants to go back through the archives,
there's a pile of other important reasons to have some way that an IdP
and/or browser agent can identify an OpenID-enabled site.  The antique
thread below lists a few.  My proposal too was a  tag.

Kind Regards,
Chris Drake


Tuesday, November 7, 2006, 12:51:15 I, you wrote:

CD> Hi Johannes,

CD> I proposed a solution to the "single sign out" problem a month or two
CD> ago.

CD> In fact - a whole range of solutions have been proposed, and relative
CD> merits of all discussed already - does anyone have the free time to go
CD> back over the postings, extract all the knowledge & contributions, and
CD> document them all?

CD> To summarize my proposal - I was seeking a standardized OpenID RP
CD> endpoint interface into which I (as an IdP) or a software agent (eg: a
CD> browser plugin) could "post" user information - be this a login
CD> request, email change request, log-out request, account signup,
CD> account cancelation, or whatever.  My preferred implementation was a
CD>  tag placed on (and thus identifying) a login page, and within
CD> the link tag, the endpoint of the RP for accepting IdP(OP/agent)
CD> input.

CD> Kind Regards,
CD> Chris Drake


CD> Tuesday, November 7, 2006, 1:04:44 PM, you wrote:

JE>> I continue to believe that we need single-sign-out
JE>> functionality, in particular once OpenID moves up the stack for
JE>> higher-value transactions.


JE>> Some people have made the case that that is undesirable
JE>> and/or impossible; I beg to differ.


JE>> Having automatic authentication against the IdP is quite
JE>> similar to not having a password on the identity at all, in that
JE>> it reduces the confidence that we know the real-world identity of
JE>> the entity/user at the other end. In my view, there's nothing
JE>> wrong with that, but we do need to be able to convey that to
JE>> relying parties in a way that cannot be easily attacked.





JE>> On Nov 6, 2006, at 16:41, Joshua Viney wrote:

JE>> One question re: User Experience and single-sign-on comes to mind:


JE>> How do we treat users who are accessing their IdP and
JE>> Relying Parties via public computers?


JE>> Use Case:
JE>> Good User at public library wants to leave a comment on Blog X
JE>> Blog X requires the person to authenticate via OpenID
JE>> Good User enters their OpenID and successfully authenticates
JE>> via email and password (or whatever) (and authorizes the RP
JE>> ('realm' in 2.0) if necessary) at their IdP
JE>> Good User is redirected to Blog X signed in
JE>> Good User leaves comment
JE>> Good User signs out of Blog X (if sign out is even an option)
JE>> Good User then leaves the public library and goes shopping
JE>> Evil User jumps on computer and proceeds to leave comments at
JE>> any number of OpenID enabled blogs using Good User's OpenID (he
JE>> saw it while looking over Good User's shoulder, or he checks any
JE>> sites that Good User did NOT sign out of that might display his
JE>> OpenID)
JE>> Evil User, uses Good User's signed in IdP session to sign into any number 
of sites, etc


JE>> Outcome: Good User's reputation is ruined and his/her OpenID
JE>> is banned from a whole list of Relying Parties. Good User then
JE>> blames their IdP, the Relying Parties and OpenID as a technology
JE>> and tells everyone he/she knows not to use it blogs about it and
JE>> initiates a press release.


JE>> It may be easy to pass this off as an implementation specific
JE>> issue or as "user error", but this use case is somewhat likely for
JE>> 2 reasons:


JE>> 1. A user's OpenID URI is not necessarily a private thing
JE>> (obscurity is not security anyway)
JE>> 2. Users will be at least 1 site removed from their IdP while
JE>> accessing a Relying Party, and no one is use to signing out twice
JE>> 3. It is very very likely that IdP's will use some type of "remember me" 
functionality


JE>> One solution to consider would be a global sign-out feature
JE>> on relying party sites that signs users out of their IdP as well.
JE>> Another solution would be to make very specific recommendations
JE>> about messaging users who may be using public computers.






JE>> Josh Viney
JE>> http://www.eastmedia.com -- EastMedia
JE>> http://identity.eastmedia.com -- OpenID, Identity 2.0








JE>> ___
JE>> user-experience mailing list
JE>> [EMAIL PROTECTED]
JE>> http://openid.net/mailman/listinfo/user-experience










Kind Regards,
Chris Drake,
=1id.com


Thursday, April 3, 2008, 4:38:13 AM, you wrote:

>> > Dick Hardt wrote:
>> >
>> > :-) ... that label would be more accurate. There is lots of work to be
>> > done to make OpenID simpler for users. I think that what will be easy
>> > for users is something provided by the browser that lets the user
>> > click to initiate a login or registration. No typing is better then
>> > any typing! Back when we started

Re: IDMML (was RE: Using email address as OpenID identifier)

[George Fletcher]

Drummond Reed wrote:
>>> Dick Hardt wrote:
>>>
>>> :-) ... that label would be more accurate. There is lots of work to be
>>> done to make OpenID simpler for users. I think that what will be easy
>>> for users is something provided by the browser that lets the user
>>> click to initiate a login or registration. No typing is better then
>>> any typing! Back when we started working on the protocols we could not
>>> expect this kind of functionality to be in the browsers. Now that
>>> awareness is higher, having it built into the browser is feasible. I
>>> of course am biased given the work we have done with Sxipper
>>> http://sxipper.com :)
>>>   
>> For the majority of users, this is probably the most likely path of
>> introduction to OpenID. Note that it's not just about allowing the user
>> to do something with one click, but also about being proactive and
>> informing the user that they can login to a site with an identity they
>> already have. This can be as simple as telling the browser "identity
>> agent" (e.g. sxipper) which email addresses the user has and letting the
>> identity agent figure out which OpenID's the user has that they don't
>> even know about.
>>
>> George Fletcher wrote:
>>
>> I think relying party sites that support OpenID could do more to make it
>> clear on their home pages that they support OpenID (as often it's hidden
>> behind another click). This could be as simple as some  tags that
>> advertise support for OpenID. Maybe a  to the XRDS doc describing
>> the services of the site. Then the identity agent can discover the
>> relying party OpenID return_to endpoint and log the user in directly.
>> Can be used to solve a phishing problem and makes the experience easy
>> for the user.
>>
>> Some related thoughts 
>>http://practicalid.blogspot.com/2007/06/clients-to-rescue.html
>>
>> http://practicalid.blogspot.com/2007/06/passive-identity-meta-system-
>> markup.html
>> 
>
> George, I read your two posts with great interest...and then noticed that
> they were last summer!
>
> You are a man ahead of your time.
>
> Where has discussion of your "IDMML" gone since your posts?
>
> =Drummond
Unfortunately, not as far as I'd like :(  I've not been able to get back 
to the ideas and take them farther. With the other things that have 
happened in the last 6 months there are needed revisions. Maybe this 
could be a discussion at IIW (if there is enough interest)?

At the time there was less consensus around XRDS as a service 
"description/meta-data" markup. With that changing, the time is better 
to move this forward. I suspect there are significant synergies with 
what Peter hinted at in the work with XRDS, IDP Discovery, and SAML. It 
would be great if identity agents could be the glue that binds the 
different identity systems together for the user (until we on the 
technology side get closer to real convergence:).

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

IDMML (was RE: Using email address as OpenID identifier)

[Drummond Reed]

> > Dick Hardt wrote:
> >
> > :-) ... that label would be more accurate. There is lots of work to be
> > done to make OpenID simpler for users. I think that what will be easy
> > for users is something provided by the browser that lets the user
> > click to initiate a login or registration. No typing is better then
> > any typing! Back when we started working on the protocols we could not
> > expect this kind of functionality to be in the browsers. Now that
> > awareness is higher, having it built into the browser is feasible. I
> > of course am biased given the work we have done with Sxipper
> > http://sxipper.com :)
> For the majority of users, this is probably the most likely path of
> introduction to OpenID. Note that it's not just about allowing the user
> to do something with one click, but also about being proactive and
> informing the user that they can login to a site with an identity they
> already have. This can be as simple as telling the browser "identity
> agent" (e.g. sxipper) which email addresses the user has and letting the
> identity agent figure out which OpenID's the user has that they don't
> even know about.
> 
> George Fletcher wrote:
>
> I think relying party sites that support OpenID could do more to make it
> clear on their home pages that they support OpenID (as often it's hidden
> behind another click). This could be as simple as some  tags that
> advertise support for OpenID. Maybe a  to the XRDS doc describing
> the services of the site. Then the identity agent can discover the
> relying party OpenID return_to endpoint and log the user in directly.
> Can be used to solve a phishing problem and makes the experience easy
> for the user.
> 
> Some related thoughts 
>http://practicalid.blogspot.com/2007/06/clients-to-rescue.html
> 
> http://practicalid.blogspot.com/2007/06/passive-identity-meta-system-
> markup.html

George, I read your two posts with great interest...and then noticed that
they were last summer!

You are a man ahead of your time.

Where has discussion of your "IDMML" gone since your posts?

=Drummond 

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

RE: Using email address as OpenID identifier

[Paul E. Jones]

Joseph,

 

That argument was given to me yesterday, but I don't think you really need
to worry with your DNS provider unless you're also trying to operate your
own OP.

 

Suppose, for example, you have an ID assigned by myopenid.com.  I don't know
what URI format they'll use, but let's say it is
https://myopenid.com/joseph.  Or, perhaps it's https://joseph.myopenid.com.
Whatever the format, there is always a user component to it.  So, it would
be quite simply to take the user component and put it into an e-mail ID
style like [EMAIL PROTECTED]  This does not necessarily mean you have an
e-mail address, but it could be an e-mail address.

 

The conversion from that form to a URI form is easily achieved via NAPTR
records similar to the one I show below.  So, before any XRDS query is
performed, the RP would see if the ID provided is an e-mail-style ID.  If
so, query for the NAPTR record and then perform the conversion from the
e-mail-style to a URL.  From there, it all works the same.  It's just a
"make it simple" enhancement that requires no changes to the core Open ID
specs.

 

Paul

 

From: Joseph Holsten [mailto:[EMAIL PROTECTED] On Behalf Of Joseph
Anthony Pasquale Holsten
Sent: Wednesday, April 02, 2008 4:52 AM
To: Paul E. Jones
Cc: specs@openid.net
Subject: Re: Using email address as OpenID identifier

 

Does anyone have the time to write an email -> xrds discovery spec so we can
formally ignore it? And so people can argue with their dns providers instead
of on list?

 

http:// Joseph Holsten .com

 

 

On 02008:04:01, at 9:30CDT, Paul E. Jones wrote:





Folks,

 

I've seen discussion here and there on the use of the e-mail address as the
OpenID identifier.  Perhaps this one says it best:

http://www.majordojo.com/2007/02/what-openid-needs.php

 

I share many of same opinions.  If OpenID is going to be practically usable
by the average person, we cannot require the person to remember some very
complex identifier.  When I signed up for Yahoo's OpenID service, it
presented me with a hideously ugly URL that looked similar to a
base64-encoded string.  I could not begin to tell you what it was.
Fortunately, Yahoo allowed me to define my own, friendlier name.  Still, the
ID is not one that the average user will remember or get right.

 

While the e-mail address does not have to be the one's ID, it can certainly
serve as an alias.  Suppose, for example, that the DNS records at Yahoo
contained the following entry:

 

  yahoo.com. IN NAPTR 100 10 "U" "OpenID2"
"^(.+)@(.*)$!https://me.yahoo.com/\1!i  "

 

This would allow a Relaying Party to accept an e-mail address and perform a
simple transformation to get the "real" URL identifier.  Of course, this
does not mean that the existing URL or XRI identifiers are invalid, nor does
it mean that the "email address" has to be a real e-mail address.  But, this
form would certainly be far simpler for most people to deal use.

 

If something like this has been discussed and rejected, what was the reason?

 

Thanks,

Paul

 

___

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: OpenID and Yahoo

[Dick Hardt]

On 2-Apr-08, at 6:28 AM, McGovern, James F (HTSC, IT) wrote:
> Does anyone have a perspective on Yahoo and AOL and their weak support
> for OpenID? It is good that they are a provider, but shouldn't they
> really also allow access based on an OpenID issued by signon.com,
> myvidoop.com and others...

I would be much more interested in them supporting Attribute Exchange  
so that their users data could easily be consumed by other sites.

This topic was recently covered by TechCrunch[1] and I responded [2]

-- Dick

[1] 
http://www.techcrunch.com/2008/03/24/is-openid-being-exploited-by-the-big-internet-companies/

[2] http://identity20.com/?p=147



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

OpenID and Yahoo

[McGovern, James F (HTSC, IT)]

 Does anyone have a perspective on Yahoo and AOL and their weak support
for OpenID? It is good that they are a provider, but shouldn't they
really also allow access based on an OpenID issued by signon.com,
myvidoop.com and others...


*
This communication, including attachments, is
for the exclusive use of addressee and may contain proprietary,
confidential and/or privileged information.  If you are not the intended
recipient, any use, copying, disclosure, dissemination or distribution is
strictly prohibited.  If you are not the intended recipient, please notify
the sender immediately by return e-mail, delete this communication and
destroy all copies.
*

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

Re: Using email address as OpenID identifier

[George Fletcher]

Dick Hardt wrote:
>
> On 1-Apr-08, at 11:15 PM, Paul E. Jones wrote:
>> Dick,
>>  
>> I’ll give you that one: that’s certainly easier.  But, does not cause 
>> some confusion?  After all, one’s identity is not yahoo.com, but that 
>> is the identity provider.  Perhaps the prompts around the Internet 
>> ought to Say “OpenID Provider:” instead? :-)
>
> :-) ... that label would be more accurate. There is lots of work to be 
> done to make OpenID simpler for users. I think that what will be easy 
> for users is something provided by the browser that lets the user 
> click to initiate a login or registration. No typing is better then 
> any typing! Back when we started working on the protocols we could not 
> expect this kind of functionality to be in the browsers. Now that 
> awareness is higher, having it built into the browser is feasible. I 
> of course am biased given the work we have done with Sxipper 
> http://sxipper.com :)
For the majority of users, this is probably the most likely path of 
introduction to OpenID. Note that it's not just about allowing the user 
to do something with one click, but also about being proactive and 
informing the user that they can login to a site with an identity they 
already have. This can be as simple as telling the browser "identity 
agent" (e.g. sxipper) which email addresses the user has and letting the 
identity agent figure out which OpenID's the user has that they don't 
even know about.

I think relying party sites that support OpenID could do more to make it 
clear on their home pages that they support OpenID (as often it's hidden 
behind another click). This could be as simple as some  tags that 
advertise support for OpenID. Maybe a  to the XRDS doc describing 
the services of the site. Then the identity agent can discover the 
relying party OpenID return_to endpoint and log the user in directly. 
Can be used to solve a phishing problem and makes the experience easy 
for the user.

Some related thoughts 
   http://practicalid.blogspot.com/2007/06/clients-to-rescue.html
   
http://practicalid.blogspot.com/2007/06/passive-identity-meta-system-markup.html

Thanks,
George

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

Re: Using email address as OpenID identifier

[Joseph Anthony Pasquale Holsten]

Does anyone have the time to write an email -> xrds discovery spec so  
we can formally ignore it? And so people can argue with their dns  
providers instead of on list?


http:// Joseph Holsten .com


On 02008:04:01, at 9:30CDT, Paul E. Jones wrote:


Folks,



I’ve seen discussion here and there on the use of the e-mail  
address as the OpenID identifier.  Perhaps this one says it best:


http://www.majordojo.com/2007/02/what-openid-needs.php



I share many of same opinions.  If OpenID is going to be  
practically usable by the average person, we cannot require the  
person to remember some very complex identifier.  When I signed up  
for Yahoo’s OpenID service, it presented me with a hideously ugly  
URL that looked similar to a base64-encoded string.  I could not  
begin to tell you what it was.  Fortunately, Yahoo allowed me to  
define my own, friendlier name.  Still, the ID is not one that the  
average user will remember or get right.




While the e-mail address does not have to be the one’s ID, it can  
certainly serve as an alias.  Suppose, for example, that the DNS  
records at Yahoo contained the following entry:




  yahoo.com. IN NAPTR 100 10 "U" "OpenID2" "^(.+)@(.*)$!https:// 
me.yahoo.com/\1!i"




This would allow a Relaying Party to accept an e-mail address and  
perform a simple transformation to get the “real” URL identifier.   
Of course, this does not mean that the existing URL or XRI  
identifiers are invalid, nor does it mean that the “email address”  
has to be a real e-mail address.  But, this form would certainly be  
far simpler for most people to deal use.




If something like this has been discussed and rejected, what was  
the reason?




Thanks,

Paul



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


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