headers
Francisco Corella | 14 Feb 2012 02:00
Favicon
Gravatar

[OpenID] One-Click OpenID: A Solution to the NASCAR Problem

FYI:

One-Click OpenID: A Solution to the NASCAR Problem, blog post at

Comments welcome.

Francisco

Francisco Corella, PhD
Founder & CTO, Pomcor
Twitter: <at> fcorella
Blog: http://pomcor.com/blog/
Web site: http://pomcor.com
_______________________________________________
general mailing list
general <at> lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-general
Permalink | Reply |
headers
Dick Hardt | 14 Feb 2012 02:12
Picon
Gravatar

Re: [OpenID] One-Click OpenID: A Solution to the NASCAR Problem

Not really a new idea -- but nice to see people are still thinking about things.

Challenges:

How do you deal with the user getting a new machine? Is there a way to sync IDPs or does the user need to log into all the IDPs on a new machine before they can log into sites?

How does this degrade for browsers that do not support storing the IDP (i.e., all the existing browsers out there)?

-- Dick

On Feb 13, 2012, at 6:00 PM, Francisco Corella wrote:

FYI:

One-Click OpenID: A Solution to the NASCAR Problem, blog post at

Comments welcome.

Francisco

Francisco Corella, PhD
Founder & CTO, Pomcor
Twitter: <at> fcorella
Blog: http://pomcor.com/blog/
Web site: http://pomcor.com
_______________________________________________
general mailing list
general <at> lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-general

_______________________________________________
general mailing list
general <at> lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-general
Permalink | Reply |
headers
Chris Messina | 14 Feb 2012 03:52
Picon

Re: [OpenID] One-Click OpenID: A Solution to the NASCAR Problem

You may also be interested in some of the Social Agent work I did with Mozilla around baking identity into the browser:



So long as choice of IDP is something that you want to provide the user, something like the NASCAR, a search box, or an email field will still be necessary to help them get started.

On Mon, Feb 13, 2012 at 5:12 PM, Dick Hardt <dick.hardt <at> gmail.com> wrote:
Not really a new idea -- but nice to see people are still thinking about things.

Challenges:

How do you deal with the user getting a new machine? Is there a way to sync IDPs or does the user need to log into all the IDPs on a new machine before they can log into sites?

How does this degrade for browsers that do not support storing the IDP (i.e., all the existing browsers out there)?

-- Dick

On Feb 13, 2012, at 6:00 PM, Francisco Corella wrote:

FYI:

One-Click OpenID: A Solution to the NASCAR Problem, blog post at

Comments welcome.

Francisco

Francisco Corella, PhD
Founder & CTO, Pomcor
Twitter: <at> fcorella
Blog: http://pomcor.com/blog/
Web site: http://pomcor.com
_______________________________________________
general mailing list
general <at> lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-general


_______________________________________________
general mailing list
general <at> lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-general




--
Chris Messina
User Experience Designer, Google


This email is:   [ ] shareable    [✔] ask first   [ ] private
_______________________________________________
general mailing list
general <at> lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-general
Permalink | Reply |
headers
Francisco Corella | 14 Feb 2012 05:15
Favicon
Gravatar

Re: [OpenID] One-Click OpenID: A Solution to the NASCAR Problem

Chris,

> You may also be interested in some of the Social Agent work I did with
> Mozilla around baking identity into the browser:
>
> http://factoryjoe.com/social-agent/
> http://factoryjoe.com/blog/2010/03/12/the-social-agent-part-2-connect/

Thanks for link.  Interesting.  I agree that there are similarities.
In particular, your Activate step is similar to setting an identity
provider as the default in my scheme.

> So long as choice of IDP is something that you want to provide the
> user, something like the NASCAR, a search box, or an email field will
> still be necessary to help them get started.

No.  A solution based on a cookie set by relying party to remember
what identity provider has been used on a previous visit would need
something to "get started".  But in my solution the <idp> element
tells the relying party what identity provider the user wants to use
even if the user has never visited the relying party before.

Francisco

From: Chris Messina <chris.messina <at> gmail.com>
To: Francisco Corella <fcorella <at> pomcor.com>; Dick Hardt <dick.hardt <at> gmail.com>
Cc: OpenID General <openid-general <at> lists.openid.net>; Karen Lewison <kplewison <at> pomcor.com>
Sent: Monday, February 13, 2012 6:52 PM
Subject: Re: [OpenID] One-Click OpenID: A Solution to the NASCAR Problem

You may also be interested in some of the Social Agent work I did with Mozilla around baking identity into the browser:

http://factoryjoe.com/social-agent/
http://factoryjoe.com/blog/2010/03/12/the-social-agent-part-2-connect/

So long as choice of IDP is something that you want to provide the user, something like the NASCAR, a search box, or an email field will still be necessary to help them get started.

On Mon, Feb 13, 2012 at 5:12 PM, Dick Hardt <dick.hardt <at> gmail.com> wrote:
Not really a new idea -- but nice to see people are still thinking about things.

Challenges:

How do you deal with the user getting a new machine? Is there a way to sync IDPs or does the user need to log into all the IDPs on a new machine before they can log into sites?

How does this degrade for browsers that do not support storing the IDP (i.e., all the existing browsers out there)?

-- Dick

On Feb 13, 2012, at 6:00 PM, Francisco Corella wrote:

FYI:

One-Click OpenID: A Solution to the NASCAR Problem, blog post at
http://pomcor.com/2012/02/13/one-click-openid-a-solution-to-the-nascar-problem/

Comments welcome.

Francisco

Francisco Corella, PhD
Founder & CTO, Pomcor
Twitter: <at> fcorella
Blog: http://pomcor.com/blog/
Web site: http://pomcor.com
_______________________________________________
general mailing list
general <at> lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-general


_______________________________________________
general mailing list
general <at> lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-general




--
Chris Messina
User Experience Designer, Google


This email is:   [ ] shareable    [✔] ask first   [ ] private


_______________________________________________
general mailing list
general <at> lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-general
Permalink | Reply |
headers
Chris Messina | 14 Feb 2012 07:18
Picon

Re: [OpenID] One-Click OpenID: A Solution to the NASCAR Problem



On Monday, February 13, 2012, Francisco Corella <fcorella <at> pomcor.com> wrote:
> Chris,
>
>> You may also be interested in some of the Social Agent work I did with
>> Mozilla around baking identity into the browser:
>>
>> http://factoryjoe.com/social-agent/
>> http://factoryjoe.com/blog/2010/03/12/the-social-agent-part-2-connect/
>
> Thanks for link.  Interesting.  I agree that there are similarities.
> In particular, your Activate step is similar to setting an identity
> provider as the default in my scheme.
>
>> So long as choice of IDP is something that you want to provide the
>> user, something like the NASCAR, a search box, or an email field will
>> still be necessary to help them get started.
>
> No.  A solution based on a cookie set by relying party to remember
> what identity provider has been used on a previous visit would need
> something to "get started". 

Right, I'm asking about the first time visit. Not about a re-visit.

> But in my solution the <idp> element
> tells the relying party what identity provider the user wants to use
> even if the user has never visited the relying party before.

I believe this was a feature of CardSpace/Infocard.


>
> Francisco
>
> ________________________________
> From: Chris Messina <chris.messina <at> gmail.com>
> To: Francisco Corella <fcorella <at> pomcor.com>; Dick Hardt <dick.hardt <at> gmail.com>
> Cc: OpenID General <openid-general <at> lists.openid.net>; Karen Lewison <kplewison <at> pomcor.com>
> Sent: Monday, February 13, 2012 6:52 PM
> Subject: Re: [OpenID] One-Click OpenID: A Solution to the NASCAR Problem
>
> You may also be interested in some of the Social Agent work I did with Mozilla around baking identity into the browser:
> http://factoryjoe.com/social-agent/
> http://factoryjoe.com/blog/2010/03/12/the-social-agent-part-2-connect/
> So long as choice of IDP is something that you want to provide the user, something like the NASCAR, a search box, or an email field will still be necessary to help them get started.
>
> On Mon, Feb 13, 2012 at 5:12 PM, Dick Hardt <dick.hardt <at> gmail.com> wrote:
>
> Not really a new idea -- but nice to see people are still thinking about things.
> Challenges:
> How do you deal with the user getting a new machine? Is there a way to sync IDPs or does the user need to log into all the IDPs on a new machine before they can log into sites?
> How does this degrade for browsers that do not support storing the IDP (i.e., all the existing browsers out there)?
> -- Dick
> On Feb 13, 2012, at 6:00 PM, Francisco Corella wrote:
>
> FYI:
> One-Click OpenID: A Solution to the NASCAR Problem, blog post at
> http://pomcor.com/2012/02/13/one-click-openid-a-solution-to-the-nascar-problem/
> Comments welcome.
>
> Francisco
>
> Francisco Corella, PhD
> Founder & CTO, Pomcor
> Twitter: <at> fcorella
> Blog: http://pomcor.com/blog/
> Web site: http://pomcor.com
> _______________________________________________
> general mailing list
> general <at> lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-general
>
>
> _______________________________________________
> general mailing list
> general <at> lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-general
>
>
>
>
> --
> Chris Messina
> User Experience Designer, Google
>
> //chrismessina.me | + | <at> chrismessina
> This email is:   [ ] shareable    [✔] ask first   [ ] private
>
>
>

--
Chris Messina
User Experience Designer, Google


This email is:   [ ] shareable    [✔] ask first   [ ] private
_______________________________________________
general mailing list
general <at> lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-general
Permalink | Reply |
headers
Francisco Corella | 14 Feb 2012 18:33
Favicon
Gravatar

Re: [OpenID] One-Click OpenID: A Solution to the NASCAR Problem

Chris,

> > Chris,
> >
> >> You may also be interested in some of the Social Agent work I did with
> >> Mozilla around baking identity into the browser:
> >>
> >> http://factoryjoe.com/social-agent/
> >> http://factoryjoe.com/blog/2010/03/12/the-social-agent-part-2-connect/
> >
> > Thanks for link.  Interesting.  I agree that there are similarities.
> > In particular, your Activate step is similar to setting an identity
> > provider as the default in my scheme.
> >
> >> So long as choice of IDP is something that you want to provide the
> >> user, something like the NASCAR, a search box, or an email field will
> >> still be necessary to help them get started.
> >
> > No.  A solution based on a cookie set by relying party to remember
> > what identity provider has been used on a previous visit would need
> > something to "get started".
>
> Right, I'm asking about the first time visit. Not about a re-visit.
>
> > But in my solution the <idp> element
> > tells the relying party what identity provider the user wants to use
> > even if the user has never visited the relying party before.
>
> I believe this was a feature of CardSpace/Infocard.

Really?  I don't have first-hand knowledge of CardSpace/Infocard but
my understanding was that it was based on the Web Services paradigm
and that it relied on a Windows application.  Here I'm talking about
OpenID and the user agent is a browser.

I'm sure similar ideas can be found in many different contexts, but
I'm addressing a very specific problem and proposing a very specific
solution.

Francisco

From: Chris Messina <chris.messina <at> gmail.com>
To: Francisco Corella <fcorella <at> pomcor.com>
Cc: Dick Hardt <dick.hardt <at> gmail.com>; OpenID General <openid-general <at> lists.openid.net>; Karen Lewison <kplewison <at> pomcor.com>
Sent: Monday, February 13, 2012 10:18 PM
Subject: Re: [OpenID] One-Click OpenID: A Solution to the NASCAR Problem



On Monday, February 13, 2012, Francisco Corella <fcorella <at> pomcor.com> wrote:
> Chris,
>
>> You may also be interested in some of the Social Agent work I did with
>> Mozilla around baking identity into the browser:
>>
>> http://factoryjoe.com/social-agent/
>> http://factoryjoe.com/blog/2010/03/12/the-social-agent-part-2-connect/
>
> Thanks for link.  Interesting.  I agree that there are similarities.
> In particular, your Activate step is similar to setting an identity
> provider as the default in my scheme.
>
>> So long as choice of IDP is something that you want to provide the
>> user, something like the NASCAR, a search box, or an email field will
>> still be necessary to help them get started.
>
> No.  A solution based on a cookie set by relying party to remember
> what identity provider has been used on a previous visit would need
> something to "get started". 

Right, I'm asking about the first time visit. Not about a re-visit.

> But in my solution the <idp> element
> tells the relying party what identity provider the user wants to use
> even if the user has never visited the relying party before.

I believe this was a feature of CardSpace/Infocard.


>
> Francisco
>
> ________________________________
> From: Chris Messina <chris.messina <at> gmail.com>
> To: Francisco Corella <fcorella <at> pomcor.com>; Dick Hardt <dick.hardt <at> gmail.com>
> Cc: OpenID General <openid-general <at> lists.openid.net>; Karen Lewison <kplewison <at> pomcor.com>
> Sent: Monday, February 13, 2012 6:52 PM
> Subject: Re: [OpenID] One-Click OpenID: A Solution to the NASCAR Problem
>
> You may also be interested in some of the Social Agent work I did with Mozilla around baking identity into the browser:
> http://factoryjoe.com/social-agent/
> http://factoryjoe.com/blog/2010/03/12/the-social-agent-part-2-connect/
> So long as choice of IDP is something that you want to provide the user, something like the NASCAR, a search box, or an email field will still be necessary to help them get started.
>
> On Mon, Feb 13, 2012 at 5:12 PM, Dick Hardt <dick.hardt <at> gmail.com> wrote:
>
> Not really a new idea -- but nice to see people are still thinking about things.
> Challenges:
> How do you deal with the user getting a new machine? Is there a way to sync IDPs or does the user need to log into all the IDPs on a new machine before they can log into sites?
> How does this degrade for browsers that do not support storing the IDP (i.e., all the existing browsers out there)?
> -- Dick
> On Feb 13, 2012, at 6:00 PM, Francisco Corella wrote:
>
> FYI:
> One-Click OpenID: A Solution to the NASCAR Problem, blog post at
> http://pomcor.com/2012/02/13/one-click-openid-a-solution-to-the-nascar-problem/
> Comments welcome.
>
> Francisco
>
> Francisco Corella, PhD
> Founder & CTO, Pomcor
> Twitter: <at> fcorella
> Blog: http://pomcor.com/blog/
> Web site: http://pomcor.com
> _______________________________________________
> general mailing list
> general <at> lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-general
>
>
> _______________________________________________
> general mailing list
> general <at> lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-general
>
>
>
>
> --
> Chris Messina
> User Experience Designer, Google
>
> //chrismessina.me | + | <at> chrismessina
> This email is:   [ ] shareable    [✔] ask first   [ ] private
>
>
>

--
Chris Messina
User Experience Designer, Google


This email is:   [ ] shareable    [✔] ask first   [ ] private


_______________________________________________
general mailing list
general <at> lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-general
Permalink | Reply |
headers
Markus Sabadello | 14 Feb 2012 23:41
Picon
Gravatar

Re: [OpenID] One-Click OpenID: A Solution to the NASCAR Problem

Yes this has existed before.

At the OpenID Summit in Nov 2009, this was called "OpenID Selector", and then later "Active Client".
Mike Jones did a demo of an OpenID-enabled version of CardSpace that could remember your OpenIDs and allowed one-click login.
And myself, I did a demo of the Higgins equivalent.
Here are some old slides and info:


On Tue, Feb 14, 2012 at 7:18 AM, Chris Messina <chris.messina <at> gmail.com> wrote:


On Monday, February 13, 2012, Francisco Corella <fcorella <at> pomcor.com> wrote:
> Chris,
>
>> You may also be interested in some of the Social Agent work I did with
>> Mozilla around baking identity into the browser:
>>
>> http://factoryjoe.com/social-agent/
>> http://factoryjoe.com/blog/2010/03/12/the-social-agent-part-2-connect/
>
> Thanks for link.  Interesting.  I agree that there are similarities.
> In particular, your Activate step is similar to setting an identity
> provider as the default in my scheme.
>
>> So long as choice of IDP is something that you want to provide the
>> user, something like the NASCAR, a search box, or an email field will
>> still be necessary to help them get started.
>
> No.  A solution based on a cookie set by relying party to remember
> what identity provider has been used on a previous visit would need
> something to "get started". 

Right, I'm asking about the first time visit. Not about a re-visit.

> But in my solution the <idp> element
> tells the relying party what identity provider the user wants to use
> even if the user has never visited the relying party before.

I believe this was a feature of CardSpace/Infocard.


>
> Francisco
>
> ________________________________
> From: Chris Messina <chris.messina <at> gmail.com>
> To: Francisco Corella <fcorella <at> pomcor.com>; Dick Hardt <dick.hardt <at> gmail.com>
> Cc: OpenID General <openid-general <at> lists.openid.net>; Karen Lewison <kplewison <at> pomcor.com>
> Sent: Monday, February 13, 2012 6:52 PM
> Subject: Re: [OpenID] One-Click OpenID: A Solution to the NASCAR Problem
>
> You may also be interested in some of the Social Agent work I did with Mozilla around baking identity into the browser:
> http://factoryjoe.com/social-agent/
> http://factoryjoe.com/blog/2010/03/12/the-social-agent-part-2-connect/
> So long as choice of IDP is something that you want to provide the user, something like the NASCAR, a search box, or an email field will still be necessary to help them get started.
>
> On Mon, Feb 13, 2012 at 5:12 PM, Dick Hardt <dick.hardt <at> gmail.com> wrote:
>
> Not really a new idea -- but nice to see people are still thinking about things.
> Challenges:
> How do you deal with the user getting a new machine? Is there a way to sync IDPs or does the user need to log into all the IDPs on a new machine before they can log into sites?
> How does this degrade for browsers that do not support storing the IDP (i.e., all the existing browsers out there)?
> -- Dick
> On Feb 13, 2012, at 6:00 PM, Francisco Corella wrote:
>
> FYI:
> One-Click OpenID: A Solution to the NASCAR Problem, blog post at
> http://pomcor.com/2012/02/13/one-click-openid-a-solution-to-the-nascar-problem/
> Comments welcome.
>
> Francisco
>
> Francisco Corella, PhD
> Founder & CTO, Pomcor
> Twitter: <at> fcorella
> Blog: http://pomcor.com/blog/
> Web site: http://pomcor.com
> _______________________________________________
> general mailing list
> general <at> lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-general
>
>
> _______________________________________________
> general mailing list
> general <at> lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-general
>
>
>
>
> --
> Chris Messina
> User Experience Designer, Google
>
> //chrismessina.me | + | <at> chrismessina
> This email is:   [ ] shareable    [✔] ask first   [ ] private
>
>
>

--
Chris Messina
User Experience Designer, Google


This email is:   [ ] shareable    [✔] ask first   [ ] private

_______________________________________________
general mailing list
general <at> lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-general





_______________________________________________
general mailing list
general <at> lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-general
Permalink | Reply |
headers
Peter Williams | 15 Feb 2012 00:17
Picon
Favicon
Gravatar

Re: [OpenID] One-Click OpenID: A Solution to the NASCAR Problem


we know that there is precious little that has not already been done before (given the sheer number of years
folks have been at this).

The criteria is that it must not be in the marketplace (and noone is competing over it, for real cash). The
criteria is not whether its an original idea.

If you turn up the end of the airplane wing, despite having built flat wings for 50 years, look at how much fuel
you now save... (but only once the engine's designers have also started applying this or that innovation
in parallel). Now what one or two or three things can be tweaked, so the world of linked data, X.500 ldap
multi-mastering, JSON signatures and modern ciphersuites for SSL are not FIGHTING each other when
compbined with a FIPS 201 card with IBM security domains. Rathe, they alll complement each other - each
adding a feature or two.

The single biggest hangup I have about turning on the openid->microsoft->realty bridge (and locking us in
for several years to its support for 50 million consumers who will then have "expectations") is that I
suspect marketing folks will shortly be denying that it has any "true" value (as the tech companies start
to message how important it is that "everyone" uses the _next_
better/greener/more-efficient/oh-so-much-improved version of the standard). I have not even turned
on, at realty scale, the old one.
Permalink | Reply |
headers
Eric Sachs | 15 Feb 2012 02:59
Picon
Favicon

Re: [OpenID] One-Click OpenID: A Solution to the NASCAR Problem

>> At the OpenID Summit in Nov 2009, this was called "OpenID Selector", and then later "Active Client".
>> Mike Jones did a demo of an OpenID-enabled version of CardSpace that could remember your OpenIDs and allowed one-click login.

For more reading, there are 2 other efforts that were discussed at that same OpenID summit and which are currently active.  One is the Mozilla BrowserID project and the other is the OIDF Account Chooser working group.  The latest version of BrowserID is done as an HTML5 app instead of native code in the browser.  That is the same model the Account Chooser working group has been pursuing for awhile, and that service is very close to being available and you can try it yourself now.

Each of these approaches is a mix of learnings form past attempts, along with a few new ideas.  Both groups are always interested in new ideas, so you might want to track their efforts and consider getting involved with them.


On Tue, Feb 14, 2012 at 2:41 PM, Markus Sabadello <markus.sabadello <at> gmail.com> wrote:
Yes this has existed before.
At the OpenID Summit in Nov 2009, this was called "OpenID Selector", and then later "Active Client".
Mike Jones did a demo of an OpenID-enabled version of CardSpace that could remember your OpenIDs and allowed one-click login.
And myself, I did a demo of the Higgins equivalent.
Here are some old slides and info:


On Tue, Feb 14, 2012 at 7:18 AM, Chris Messina <chris.messina <at> gmail.com> wrote:


On Monday, February 13, 2012, Francisco Corella <fcorella <at> pomcor.com> wrote:
> Chris,
>
>> You may also be interested in some of the Social Agent work I did with
>> Mozilla around baking identity into the browser:
>>
>> http://factoryjoe.com/social-agent/
>> http://factoryjoe.com/blog/2010/03/12/the-social-agent-part-2-connect/
>
> Thanks for link.  Interesting.  I agree that there are similarities.
> In particular, your Activate step is similar to setting an identity
> provider as the default in my scheme.
>
>> So long as choice of IDP is something that you want to provide the
>> user, something like the NASCAR, a search box, or an email field will
>> still be necessary to help them get started.
>
> No.  A solution based on a cookie set by relying party to remember
> what identity provider has been used on a previous visit would need
> something to "get started". 

Right, I'm asking about the first time visit. Not about a re-visit.

> But in my solution the <idp> element
> tells the relying party what identity provider the user wants to use
> even if the user has never visited the relying party before.

I believe this was a feature of CardSpace/Infocard.


>
> Francisco
>
> ________________________________
> From: Chris Messina <chris.messina <at> gmail.com>
> To: Francisco Corella <fcorella <at> pomcor.com>; Dick Hardt <dick.hardt <at> gmail.com>
> Cc: OpenID General <openid-general <at> lists.openid.net>; Karen Lewison <kplewison <at> pomcor.com>
> Sent: Monday, February 13, 2012 6:52 PM
> Subject: Re: [OpenID] One-Click OpenID: A Solution to the NASCAR Problem
>
> You may also be interested in some of the Social Agent work I did with Mozilla around baking identity into the browser:
> http://factoryjoe.com/social-agent/
> http://factoryjoe.com/blog/2010/03/12/the-social-agent-part-2-connect/
> So long as choice of IDP is something that you want to provide the user, something like the NASCAR, a search box, or an email field will still be necessary to help them get started.
>
> On Mon, Feb 13, 2012 at 5:12 PM, Dick Hardt <dick.hardt <at> gmail.com> wrote:
>
> Not really a new idea -- but nice to see people are still thinking about things.
> Challenges:
> How do you deal with the user getting a new machine? Is there a way to sync IDPs or does the user need to log into all the IDPs on a new machine before they can log into sites?
> How does this degrade for browsers that do not support storing the IDP (i.e., all the existing browsers out there)?
> -- Dick
> On Feb 13, 2012, at 6:00 PM, Francisco Corella wrote:
>
> FYI:
> One-Click OpenID: A Solution to the NASCAR Problem, blog post at
> http://pomcor.com/2012/02/13/one-click-openid-a-solution-to-the-nascar-problem/
> Comments welcome.
>
> Francisco
>
> Francisco Corella, PhD
> Founder & CTO, Pomcor
> Twitter: <at> fcorella
> Blog: http://pomcor.com/blog/
> Web site: http://pomcor.com
> _______________________________________________
> general mailing list
> general <at> lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-general
>
>
> _______________________________________________
> general mailing list
> general <at> lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-general
>
>
>
>
> --
> Chris Messina
> User Experience Designer, Google
>
> //chrismessina.me | + | <at> chrismessina
> This email is:   [ ] shareable    [✔] ask first   [ ] private
>
>
>

--
Chris Messina
User Experience Designer, Google


This email is:   [ ] shareable    [✔] ask first   [ ] private

_______________________________________________
general mailing list
general <at> lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-general






_______________________________________________
general mailing list
general <at> lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-general




--
Eric Sachs | Senior Product Manager | esachs <at> google.com  

_______________________________________________
general mailing list
general <at> lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-general
Permalink | Reply |
headers
Peter Williams | 15 Feb 2012 03:25
Picon
Favicon
Gravatar

Re: [OpenID] One-Click OpenID: A Solution to the NASCAR Problem

I think if may be time to bring back your xri server (using hxrns) and Openid protocol endpoint. Perhaps the  server could produce 2 representations : the XML Xrd, and the HTML microdata formats, using the relevant data dictionaries used in the linked data world for such relationships. 

Even if the world has moved beyond native xri, there is plenty to showcase and repupose from that world - that will be required in a national scale program.

Since Openid is all about dynamic Discovery , why not repurpose the server as an Xrd dynamic minting/signing/hosting service (for on premise clouds rather than the current marketplaces world of google/amazon/Msft platform services.)

Rather than the Xrd being for individuals  (with each sep pointing to one of the various Idps that might be authorized to  speak for the identifier), perhaps the same basic mechanism is hosting for a million Idps which sp (endpoints) they have registered, for each (privacy) policy on attribute exchange.



Sent from my iPhone

On Feb 14, 2012, at 2:42 PM, "Markus Sabadello" <markus.sabadello <at> gmail.com> wrote:

Yes this has existed before.
At the OpenID Summit in Nov 2009, this was called "OpenID Selector", and then later "Active Client".
Mike Jones did a demo of an OpenID-enabled version of CardSpace that could remember your OpenIDs and allowed one-click login.
And myself, I did a demo of the Higgins equivalent.
Here are some old slides and info:


On Tue, Feb 14, 2012 at 7:18 AM, Chris Messina <chris.messina <at> gmail.com> wrote:


On Monday, February 13, 2012, Francisco Corella <fcorella <at> pomcor.com> wrote:
> Chris,
>
>> You may also be interested in some of the Social Agent work I did with
>> Mozilla around baking identity into the browser:
>>
>> http://factoryjoe.com/social-agent/
>> http://factoryjoe.com/blog/2010/03/12/the-social-agent-part-2-connect/
>
> Thanks for link.  Interesting.  I agree that there are similarities.
> In particular, your Activate step is similar to setting an identity
> provider as the default in my scheme.
>
>> So long as choice of IDP is something that you want to provide the
>> user, something like the NASCAR, a search box, or an email field will
>> still be necessary to help them get started.
>
> No.  A solution based on a cookie set by relying party to remember
> what identity provider has been used on a previous visit would need
> something to "get started". 

Right, I'm asking about the first time visit. Not about a re-visit.

> But in my solution the <idp> element
> tells the relying party what identity provider the user wants to use
> even if the user has never visited the relying party before.

I believe this was a feature of CardSpace/Infocard.


>
> Francisco
>
> ________________________________
> From: Chris Messina <chris.messina <at> gmail.com>
> To: Francisco Corella <fcorella <at> pomcor.com>; Dick Hardt <dick.hardt <at> gmail.com>
> Cc: OpenID General <openid-general <at> lists.openid.net>; Karen Lewison <kplewison <at> pomcor.com>
> Sent: Monday, February 13, 2012 6:52 PM
> Subject: Re: [OpenID] One-Click OpenID: A Solution to the NASCAR Problem
>
> You may also be interested in some of the Social Agent work I did with Mozilla around baking identity into the browser:
> http://factoryjoe.com/social-agent/
> http://factoryjoe.com/blog/2010/03/12/the-social-agent-part-2-connect/
> So long as choice of IDP is something that you want to provide the user, something like the NASCAR, a search box, or an email field will still be necessary to help them get started.
>
> On Mon, Feb 13, 2012 at 5:12 PM, Dick Hardt <dick.hardt <at> gmail.com> wrote:
>
> Not really a new idea -- but nice to see people are still thinking about things.
> Challenges:
> How do you deal with the user getting a new machine? Is there a way to sync IDPs or does the user need to log into all the IDPs on a new machine before they can log into sites?
> How does this degrade for browsers that do not support storing the IDP (i.e., all the existing browsers out there)?
> -- Dick
> On Feb 13, 2012, at 6:00 PM, Francisco Corella wrote:
>
> FYI:
> One-Click OpenID: A Solution to the NASCAR Problem, blog post at
> http://pomcor.com/2012/02/13/one-click-openid-a-solution-to-the-nascar-problem/
> Comments welcome.
>
> Francisco
>
> Francisco Corella, PhD
> Founder & CTO, Pomcor
> Twitter: <at> fcorella
> Blog: http://pomcor.com/blog/
> Web site: http://pomcor.com
> _______________________________________________
> general mailing list
> general <at> lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-general
>
>
> _______________________________________________
> general mailing list
> general <at> lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-general
>
>
>
>
> --
> Chris Messina
> User Experience Designer, Google
>
> //chrismessina.me | + | <at> chrismessina
> This email is:   [ ] shareable    [✔] ask first   [ ] private
>
>
>

--
Chris Messina
User Experience Designer, Google


This email is:   [ ] shareable    [✔] ask first   [ ] private

_______________________________________________
general mailing list
general <at> lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-general





_______________________________________________
general mailing list
general <at> lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-general
_______________________________________________
general mailing list
general <at> lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-general
Permalink | Reply |
headers
Francisco Corella | 15 Feb 2012 07:01
Favicon
Gravatar

Re: [OpenID] One-Click OpenID: A Solution to the NASCAR Problem

Markus:

OpenID Selector is not a solution to the NASCAR problem, it is the
NASCAR problem itself.  It's a good example of what I'm trying to
avoid.

Everybody:

Before telling me that what I'm proposing has been done before, please
read what I'm proposing.  Or if that takes too much effort, please
consider this: in my solution, the relying party displays a single
button "Login with OpenID".  The user clicks on the button and is
automagically redirected to her preferred OpenID provider, even if the
relying party has never heard of it.

Hint: if you want to criticize this, you could criticize the fact
that it requires an ad-hoc HTTP header, and ad-hoc HTML tag, and new
browser functionality.  Messieurs les Anglais, tirez les premiers.

Francisco

From: Markus Sabadello <markus.sabadello <at> gmail.com>
To: Chris Messina <chris.messina <at> gmail.com>
Cc: Francisco Corella <fcorella <at> pomcor.com>; OpenID General <openid-general <at> lists.openid.net>; Karen Lewison <kplewison <at> pomcor.com>
Sent: Tuesday, February 14, 2012 2:41 PM
Subject: Re: [OpenID] One-Click OpenID: A Solution to the NASCAR Problem

Yes this has existed before.
At the OpenID Summit in Nov 2009, this was called "OpenID Selector", and then later "Active Client".
Mike Jones did a demo of an OpenID-enabled version of CardSpace that could remember your OpenIDs and allowed one-click login.
And myself, I did a demo of the Higgins equivalent.
Here are some old slides and info:
http://wiki.openid.net/w/page/12995207/2009%20OpenID%20Summit 

Markus
-- 
Project Danube: http://projectdanube.org/
PDEC: http://personaldataecosystem.org/

On Tue, Feb 14, 2012 at 7:18 AM, Chris Messina <chris.messina <at> gmail.com> wrote:


On Monday, February 13, 2012, Francisco Corella <fcorella <at> pomcor.com> wrote:
> Chris,
>
>> You may also be interested in some of the Social Agent work I did with
>> Mozilla around baking identity into the browser:
>>
>> http://factoryjoe.com/social-agent/
>> http://factoryjoe.com/blog/2010/03/12/the-social-agent-part-2-connect/
>
> Thanks for link.  Interesting.  I agree that there are similarities.
> In particular, your Activate step is similar to setting an identity
> provider as the default in my scheme.
>
>> So long as choice of IDP is something that you want to provide the
>> user, something like the NASCAR, a search box, or an email field will
>> still be necessary to help them get started.
>
> No.  A solution based on a cookie set by relying party to remember
> what identity provider has been used on a previous visit would need
> something to "get started". 

Right, I'm asking about the first time visit. Not about a re-visit.

> But in my solution the <idp> element
> tells the relying party what identity provider the user wants to use
> even if the user has never visited the relying party before.

I believe this was a feature of CardSpace/Infocard.


>
> Francisco
>
> ________________________________
> From: Chris Messina <chris.messina <at> gmail.com>
> To: Francisco Corella <fcorella <at> pomcor.com>; Dick Hardt <dick.hardt <at> gmail.com>
> Cc: OpenID General <openid-general <at> lists.openid.net>; Karen Lewison <kplewison <at> pomcor.com>
> Sent: Monday, February 13, 2012 6:52 PM
> Subject: Re: [OpenID] One-Click OpenID: A Solution to the NASCAR Problem
>
> You may also be interested in some of the Social Agent work I did with Mozilla around baking identity into the browser:
> http://factoryjoe.com/social-agent/
> http://factoryjoe.com/blog/2010/03/12/the-social-agent-part-2-connect/
> So long as choice of IDP is something that you want to provide the user, something like the NASCAR, a search box, or an email field will still be necessary to help them get started.
>
> On Mon, Feb 13, 2012 at 5:12 PM, Dick Hardt <dick.hardt <at> gmail.com> wrote:
>
> Not really a new idea -- but nice to see people are still thinking about things.
> Challenges:
> How do you deal with the user getting a new machine? Is there a way to sync IDPs or does the user need to log into all the IDPs on a new machine before they can log into sites?
> How does this degrade for browsers that do not support storing the IDP (i.e., all the existing browsers out there)?
> -- Dick
> On Feb 13, 2012, at 6:00 PM, Francisco Corella wrote:
>
> FYI:
> One-Click OpenID: A Solution to the NASCAR Problem, blog post at
> http://pomcor.com/2012/02/13/one-click-openid-a-solution-to-the-nascar-problem/
> Comments welcome.
>
> Francisco
>
> Francisco Corella, PhD
> Founder & CTO, Pomcor
> Twitter: <at> fcorella
> Blog: http://pomcor.com/blog/
> Web site: http://pomcor.com
> _______________________________________________
> general mailing list
> general <at> lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-general
>
>
> _______________________________________________
> general mailing list
> general <at> lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-general
>
>
>
>
> --
> Chris Messina
> User Experience Designer, Google
>
> //chrismessina.me | + | <at> chrismessina
> This email is:   [ ] shareable    [✔] ask first   [ ] private
>
>
>

--
Chris Messina
User Experience Designer, Google


This email is:   [ ] shareable    [✔] ask first   [ ] private

_______________________________________________
general mailing list
general <at> lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-general







_______________________________________________
general mailing list
general <at> lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-general
Permalink | Reply |
headers
Dick Hardt | 15 Feb 2012 08:29
Picon
Gravatar

Re: [OpenID] One-Click OpenID: A Solution to the NASCAR Problem


On Feb 14, 2012, at 11:01 PM, Francisco Corella wrote:
Everybody:

Before telling me that what I'm proposing has been done before, please
read what I'm proposing. 

I did. 

The user clicks on the button and is
automagically redirected to her preferred OpenID provider, even if the
relying party has never heard of it.

got that the first time, see below


Hint: if you want to criticize this, you could criticize the fact
that it requires an ad-hoc HTTP header, and ad-hoc HTML tag, and new
browser functionality. 

The ad-hoc HTTP header and ad-hoc HTML tag are not needed to solve the NASCAR problem. By adding code to the browser, you could work with existing OpenID providers and RPs.

We did this with Sxipper 4 years ago. Sxipper remembered your OPs, detected an OpenID login form, and allowed the user to select which OP to use at the RP. It remembered which OP you had used at that RP last and put it on top. It detected when you logged into an OP to add it to the list of OPs available.

Detecting RP forms and OPs was non-trivial, and some additional HTML markup would have made it easier and more robust.

As I stated before, this does not solve the problem for users without an enhanced browser. 

-- Dick


_______________________________________________
general mailing list
general <at> lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-general
Permalink | Reply |
headers
SitG Admin | 15 Feb 2012 08:37

Re: [OpenID] One-Click OpenID: A Solution to the NASCAR Problem

>As I stated before, this does not solve the problem for users 
>without an enhanced browser.

I'm grasping the idea conveyed by your words, but it seems kind of 
blurry. I think what we want is "user-side": placing that solution in 
my *browser* (with all the complicated hacking such an approach would 
entail) seems like more trouble than it's worth :(

-Shade
Permalink | Reply |
headers
Francisco Corella | 15 Feb 2012 23:23
Favicon
Gravatar

Re: [OpenID] One-Click OpenID: A Solution to the NASCAR Problem

Dick,

> The ad-hoc HTTP header and ad-hoc HTML tag are not needed to solve the
> NASCAR problem. By adding code to the browser, you could work with
> existing OpenID providers and RPs.
>
> We did this with Sxipper 4 years ago. Sxipper remembered your OPs,
> detected an OpenID login form, and allowed the user to select which OP
> to use at the RP. It remembered which OP you had used at that RP last
> and put it on top. It detected when you logged into an OP to add it to
> the list of OPs available.
>
> Detecting RP forms and OPs was non-trivial, and some additional HTML
> markup would have made it easier and more robust.

Our approach doesn't use markup for detection.  The markup we use is
an <idp> element in the RP's login form whose value is the data
associated with the IdP, i.e. the identity provider, a.k.a. OpenID
provider, a.k.a. OP, that the user wants to use for this particular
transaction.  The brower is free to use any method it wants to
determine which OP the user wants to use among those recorded in the
user's preferences.

It's not a good idea to detect an OP automatically, as you seem to say
Sxipper used to do, whether the OP is detected using a heuristic or
using explicit markup in the OP's site.  The user may very well use a
site that offers an identity provider service, and even have an
account at that site, without wanting to use the identity service.
For example the user could use Yahoo as an email service provider
while using Wordpress as an OpenID provider.  It would be wrong to add
Yahoo to the list of identity providers just because the user logs in
to Yahoo to process its email.  In our approach Yahoo has to offer its
identity service to the user, and the user has to accept it explicitly
by clicking on a link or button.  In response to that click Yahoo
downloads identity provider data in an ad-hoc HTTP header, causing the
browser to add Yahoo to the list of identity providers in the user's
preferences, after asking the user's consent.

> As I stated before, this does not solve the problem for users without
> an enhanced browser.

As I said before in response to your earlier statement, the relying
party can easily detect whether the browser is enhanced or not, and
fall back on an ordinary OpenID interface if it isn't.

Francisco

From: Dick Hardt <dick.hardt <at> gmail.com>
To: Francisco Corella <fcorella <at> pomcor.com>
Cc: Markus Sabadello <markus.sabadello <at> gmail.com>; Chris Messina <chris.messina <at> gmail.com>; OpenID General <openid-general <at> lists.openid.net>; Karen Lewison <kplewison <at> pomcor.com>
Sent: Tuesday, February 14, 2012 11:29 PM
Subject: Re: [OpenID] One-Click OpenID: A Solution to the NASCAR Problem


On Feb 14, 2012, at 11:01 PM, Francisco Corella wrote:
Everybody:

Before telling me that what I'm proposing has been done before, please
read what I'm proposing. 

I did. 

The user clicks on the button and is
automagically redirected to her preferred OpenID provider, even if the
relying party has never heard of it.

got that the first time, see below


Hint: if you want to criticize this, you could criticize the fact
that it requires an ad-hoc HTTP header, and ad-hoc HTML tag, and new
browser functionality. 

The ad-hoc HTTP header and ad-hoc HTML tag are not needed to solve the NASCAR problem. By adding code to the browser, you could work with existing OpenID providers and RPs.

We did this with Sxipper 4 years ago. Sxipper remembered your OPs, detected an OpenID login form, and allowed the user to select which OP to use at the RP. It remembered which OP you had used at that RP last and put it on top. It detected when you logged into an OP to add it to the list of OPs available.

Detecting RP forms and OPs was non-trivial, and some additional HTML markup would have made it easier and more robust.

As I stated before, this does not solve the problem for users without an enhanced browser. 

-- Dick




_______________________________________________
general mailing list
general <at> lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-general
Permalink | Reply |
headers
Dick Hardt | 15 Feb 2012 23:32
Picon
Gravatar

Re: [OpenID] One-Click OpenID: A Solution to the NASCAR Problem


On Feb 15, 2012, at 3:23 PM, Francisco Corella wrote:

It's not a good idea to detect an OP automatically, as you seem to say
Sxipper used to do, whether the OP is detected using a heuristic or
using explicit markup in the OP's site. 

We did not add the OP automatically, but we detected that a site supported OpenID as an OP, and then gave the user a choice to add the OP.


As I said before in response to your earlier statement, the relying
party can easily detect whether the browser is enhanced or not, and
fall back on an ordinary OpenID interface if it isn't.

Well, I would say that Sxipper worked better, as the RP did not need to detect anything.

The problem at hand is how to solve the NASCAR problem for un-enhanced browsers. Your title states that you have solved it. Solving it by enhancing the browse is not new.


_______________________________________________
general mailing list
general <at> lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-general
Permalink | Reply |
headers
Francisco Corella | 16 Feb 2012 01:06
Favicon
Gravatar

Re: [OpenID] One-Click OpenID: A Solution to the NASCAR Problem

Dick,

> > It's not a good idea to detect an OP automatically, as you seem to
>   say
> > Sxipper used to do, whether the OP is detected using a heuristic or
> > using explicit markup in the OP's site.  
>
> We did not add the OP automatically, but we detected that a site
> supported OpenID as an OP, and then gave the user a choice to add the
> OP.
>
> >
> > As I said before in response to your earlier statement, the relying
> > party can easily detect whether the browser is enhanced or not, and
> > fall back on an ordinary OpenID interface if it isn't.
>
> Well, I would say that Sxipper worked better, as the RP did not need
> to detect anything.
>
> The problem at hand is how to solve the NASCAR problem for un-enhanced
> browsers. Your title states that you have solved it.

The problem at hand for you when you did Sxipper years ago was to
solve the NASCAR problem for unenhanced browsers.  The problem at hand
for me today is to solve it with an enhanced browser.  I do get to
choose what problem I want to work on.

> Solving it by
> enhancing the browse is not new.

So, who has solved the problem by enhancing the browser?

Francisco

From: Dick Hardt <dick.hardt <at> gmail.com>
To: Francisco Corella <fcorella <at> pomcor.com>
Cc: Dick Hardt <dick.hardt <at> gmail.com>; Markus Sabadello <markus.sabadello <at> gmail.com>; Chris Messina <chris.messina <at> gmail.com>; OpenID General <openid-general <at> lists.openid.net>; Karen Lewison <kplewison <at> pomcor.com>
Sent: Wednesday, February 15, 2012 2:32 PM
Subject: Re: [OpenID] One-Click OpenID: A Solution to the NASCAR Problem


On Feb 15, 2012, at 3:23 PM, Francisco Corella wrote:

It's not a good idea to detect an OP automatically, as you seem to say
Sxipper used to do, whether the OP is detected using a heuristic or
using explicit markup in the OP's site. 

We did not add the OP automatically, but we detected that a site supported OpenID as an OP, and then gave the user a choice to add the OP.


As I said before in response to your earlier statement, the relying
party can easily detect whether the browser is enhanced or not, and
fall back on an ordinary OpenID interface if it isn't.

Well, I would say that Sxipper worked better, as the RP did not need to detect anything.

The problem at hand is how to solve the NASCAR problem for un-enhanced browsers. Your title states that you have solved it. Solving it by enhancing the browse is not new.




_______________________________________________
general mailing list
general <at> lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-general
Permalink | Reply |
headers
Dick Hardt | 16 Feb 2012 01:11
Picon
Gravatar

Re: [OpenID] One-Click OpenID: A Solution to the NASCAR Problem


On Feb 15, 2012, at 5:06 PM, Francisco Corella wrote:

The problem at hand for you when you did Sxipper years ago was to
solve the NASCAR problem for unenhanced browsers.  The problem at hand
for me today is to solve it with an enhanced browser.  I do get to
choose what problem I want to work on.

The subject line of your message says you have "A Solution to the NASCAR Problem"


> Solving it by
> enhancing the browse is not new.

So, who has solved the problem by enhancing the browser?

A user with Sxipper installed is running an enhanced browser. VeriSign had some similar tech. InfoCard also enhanced the browser.

meta point: you seem fairly defensive and not all that interested in learning what has happened before. 

_______________________________________________
general mailing list
general <at> lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-general
Permalink | Reply |
headers
Francisco Corella | 16 Feb 2012 01:30
Favicon
Gravatar

Re: [OpenID] One-Click OpenID: A Solution to the NASCAR Problem

Dick,

> > The problem at hand for you when you did Sxipper years ago was to
> > solve the NASCAR problem for unenhanced browsers.  The problem at
> hand
> > for me today is to solve it with an enhanced browser.  I do get to
> > choose what problem I want to work on.
>
> The subject line of your message says you have "A Solution to the
> NASCAR Problem"
>
> >
> > > Solving it by
> > > enhancing the browse is not new.
> >
> > So, who has solved the problem by enhancing the browser?
>
> A user with Sxipper installed is running an enhanced browser. VeriSign
> had some similar tech. InfoCard also enhanced the browser.
>
> meta point: you seem fairly defensive and not all that interested in
> learning what has happened before.

You're right, I got carried away.  What's new in my proposal is that
I'm enhancing the OP and the RP, not that I'm enhancing the browser.

I'm interested in learning what has happened before, and I've looked
at all the prior work that has been reported.  I spent quite a bit of
time searching for information about Sxipper but couldn't find
anything online.

Yes I am defensive, of course I am.  That's my job.  I've proposed an
idea which I think is new, I'm receiving claims that it is not new,
I'm reviewing them, and if I think they are wrong I'm refuting them.

I still have not seen prior work where the identity provider
explicitly offers its services to the user and explicitly downloads
data including its redirection endpoint to the browser in an HTTP
header, and where the relying party uses an HTML element included in
the login form to learn the user's preferred identity provider for the
transaction at hand.

Francisco

From: Dick Hardt <dick.hardt <at> gmail.com>
To: Francisco Corella <fcorella <at> pomcor.com>
Cc: Dick Hardt <dick.hardt <at> gmail.com>; Markus Sabadello <markus.sabadello <at> gmail.com>; Chris Messina <chris.messina <at> gmail.com>; OpenID General <openid-general <at> lists.openid.net>; Karen Lewison <kplewison <at> pomcor.com>
Sent: Wednesday, February 15, 2012 4:11 PM
Subject: Re: [OpenID] One-Click OpenID: A Solution to the NASCAR Problem


On Feb 15, 2012, at 5:06 PM, Francisco Corella wrote:

The problem at hand for you when you did Sxipper years ago was to
solve the NASCAR problem for unenhanced browsers.  The problem at hand
for me today is to solve it with an enhanced browser.  I do get to
choose what problem I want to work on.

The subject line of your message says you have "A Solution to the NASCAR Problem"


> Solving it by
> enhancing the browse is not new.

So, who has solved the problem by enhancing the browser?

A user with Sxipper installed is running an enhanced browser. VeriSign had some similar tech. InfoCard also enhanced the browser.

meta point: you seem fairly defensive and not all that interested in learning what has happened before. 



_______________________________________________
general mailing list
general <at> lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-general
Permalink | Reply |
headers
Peter Williams | 16 Feb 2012 02:10
Picon
Favicon
Gravatar

Re: [OpenID] One-Click OpenID: A Solution to the NASCAR Problem


In terms of the orginal question concerning NSTIC opportunities specific to a mix of https + openid +
discovery : is there a discovery problem? And, is the NSTIC opportunity amenable to a pitch on the need for a
openid-community approach to discovery (given how hard its proven to solve)? Id guess that the answer is
yes, there is, and it would be well received. But, its not a basic-science grant! Its what can discovery a la
openid do for it (not it for openid)!

IF I was the program manager, I want to know whats hard, and what folks think the road map should be. I want some
metrics to guess the future, and test whether my criteria are good policy guidelines for a national
infrastrcuture. How does openid help me (not is openid, openid connect, or this or that discovery
solution the single, right religion for the world).

Now, let's not forget. Most of the (pretty minimal) funds are simply for running a steering committee, not
grants for technology plays. This is akind to getting the same kind of steering committe backroom vendor
as runs the day to day management of IETF. I'm sure ITU and ESTI have the same kind of thing! In someways, its
what the Foundation itself does for openid community, but now for a wider group of partcipants who are not
tied only to web technologies, browser, or the interests (mostly) of IDPs managing user profiles.
Permalink | Reply |
headers
Francisco Corella | 16 Feb 2012 20:33
Favicon
Gravatar

Re: [OpenID] One-Click OpenID: A Solution to the NASCAR Problem

Peter,

> In terms of the orginal question concerning NSTIC opportunities
> specific to a mix of https + openid + discovery : is there a discovery
> problem? And, is the NSTIC opportunity amenable to a pitch on the need
> for a openid-community approach to discovery (given how hard its
> proven to solve)? Id guess that the answer is yes, there is, and it
> would be well received. But, its not a basic-science grant! Its what
> can discovery a la openid do for it (not it for openid)!
>
> IF I was the program manager, I want to know whats hard, and what
> folks think the road map should be. I want some metrics to guess the
> future, and test whether my criteria are good policy guidelines for a
> national infrastrcuture. How does openid help me (not is openid,
> openid connect, or this or that discovery solution the single, right
> religion for the world).
>
> Now, let's not forget. Most of the (pretty minimal) funds are simply
> for running a steering committee, not grants for technology
> plays. This is akind to getting the same kind of steering committe
> backroom vendor as runs the day to day management of IETF. I'm sure
> ITU and ESTI have the same kind of thing! In someways, its what the
> Foundation itself does for openid community, but now for a wider group
> of partcipants who are not tied only to web technologies, browser, or
> the interests (mostly) of IDPs managing user profiles.                       

NSTIC got $16.5 million for this year, of which it is spending $10
million for pilots.

Francisco

_______________________________________________
general mailing list
general <at> lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-general
Permalink | Reply |
headers
Axel.Nennker | 15 Feb 2012 09:35
Picon

Re: [OpenID] One-Click OpenID: A Solution to the NASCAR Problem

I propose to add some id-related functionality to the window object and have blogged about it here:

http://ignisvulpis.blogspot.com/2011/03/all-those-nascars.html and some other posts around that time.

 

The basic idea is to add some code like this  to the RP’s pages:

 

function onLoad() {

  if (window.openid) {

    window.openid.getPreferredOpenidProvider(callback);

  } else {

    // show the NASCAR or whatever

  }

}

 

The acceptable Idp could be a parameter to the getPreferredOpenidProvider method but most OC accept any OpenID anyway…

 

The addon that implements this is here: https://addons.mozilla.org/en-US/firefox/addon/openid-for-firefox/

It learns your openid too by looking for id_res in a server response.

 

Axel

 

 

 

From: openid-general-bounces <at> lists.openid.net [mailto:openid-general-bounces <at> lists.openid.net] On Behalf Of Francisco Corella
Sent: Wednesday, February 15, 2012 7:02 AM
To: Markus Sabadello; Chris Messina
Cc: OpenID General; Karen Lewison
Subject: Re: [OpenID] One-Click OpenID: A Solution to the NASCAR Problem

 

Markus:

OpenID Selector is not a solution to the NASCAR problem, it is the
NASCAR problem itself.  It's a good example of what I'm trying to
avoid.

Everybody:

Before telling me that what I'm proposing has been done before, please
read what I'm proposing.  Or if that takes too much effort, please
consider this: in my solution, the relying party displays a single
button "Login with OpenID".  The user clicks on the button and is
automagically redirected to her preferred OpenID provider, even if the
relying party has never heard of it.

Hint: if you want to criticize this, you could criticize the fact
that it requires an ad-hoc HTTP header, and ad-hoc HTML tag, and new
browser functionality.  Messieurs les Anglais, tirez les premiers.

Francisco

 

From: Markus Sabadello <markus.sabadello <at> gmail.com>
To: Chris Messina <chris.messina <at> gmail.com>
Cc: Francisco Corella <fcorella <at> pomcor.com>; OpenID General <openid-general <at> lists.openid.net>; Karen Lewison <kplewison <at> pomcor.com>
Sent: Tuesday, February 14, 2012 2:41 PM
Subject: Re: [OpenID] One-Click OpenID: A Solution to the NASCAR Problem

 

Yes this has existed before.

At the OpenID Summit in Nov 2009, this was called "OpenID Selector", and then later "Active Client".

Mike Jones did a demo of an OpenID-enabled version of CardSpace that could remember your OpenIDs and allowed one-click login.

And myself, I did a demo of the Higgins equivalent.

Here are some old slides and info:

http://wiki.openid.net/w/page/12995207/2009%20OpenID%20Summit 

 

Markus
-- 

Project Danube: http://projectdanube.org/

PDEC: http://personaldataecosystem.org/

 

On Tue, Feb 14, 2012 at 7:18 AM, Chris Messina <chris.messina <at> gmail.com> wrote:



On Monday, February 13, 2012, Francisco Corella <fcorella <at> pomcor.com> wrote:
> Chris,
>
>> You may also be interested in some of the Social Agent work I did with
>> Mozilla around baking identity into the browser:
>>
>> http://factoryjoe.com/social-agent/
>> http://factoryjoe.com/blog/2010/03/12/the-social-agent-part-2-connect/
>
> Thanks for link.  Interesting.  I agree that there are similarities.
> In particular, your Activate step is similar to setting an identity
> provider as the default in my scheme.
>
>> So long as choice of IDP is something that you want to provide the
>> user, something like the NASCAR, a search box, or an email field will
>> still be necessary to help them get started.
>
> No.  A solution based on a cookie set by relying party to remember
> what identity provider has been used on a previous visit would need
> something to "get started". 

Right, I'm asking about the first time visit. Not about a re-visit.


> But in my solution the <idp> element
> tells the relying party what identity provider the user wants to use
> even if the user has never visited the relying party before.

I believe this was a feature of CardSpace/Infocard.



>
> Francisco
>
> ________________________________
> From: Chris Messina <chris.messina <at> gmail.com>
> To: Francisco Corella <fcorella <at> pomcor.com>; Dick Hardt <dick.hardt <at> gmail.com>
> Cc: OpenID General <openid-general <at> lists.openid.net>; Karen Lewison <kplewison <at> pomcor.com>
> Sent: Monday, February 13, 2012 6:52 PM
> Subject: Re: [OpenID] One-Click OpenID: A Solution to the NASCAR Problem
>
> You may also be interested in some of the Social Agent work I did with Mozilla around baking identity into the browser:
> http://factoryjoe.com/social-agent/
> http://factoryjoe.com/blog/2010/03/12/the-social-agent-part-2-connect/
> So long as choice of IDP is something that you want to provide the user, something like the NASCAR, a search box, or an email field will still be necessary to help them get started.
>
> On Mon, Feb 13, 2012 at 5:12 PM, Dick Hardt <dick.hardt <at> gmail.com> wrote:
>
> Not really a new idea -- but nice to see people are still thinking about things.
> Challenges:
> How do you deal with the user getting a new machine? Is there a way to sync IDPs or does the user need to log into all the IDPs on a new machine before they can log into sites?
> How does this degrade for browsers that do not support storing the IDP (i.e., all the existing browsers out there)?
> -- Dick
> On Feb 13, 2012, at 6:00 PM, Francisco Corella wrote:
>
> FYI:
> One-Click OpenID: A Solution to the NASCAR Problem, blog post at
> http://pomcor.com/2012/02/13/one-click-openid-a-solution-to-the-nascar-problem/
> Comments welcome.
>
> Francisco
>
> Francisco Corella, PhD
> Founder & CTO, Pomcor
> Twitter: <at> fcorella
> Blog: http://pomcor.com/blog/
> Web site: http://pomcor.com
> _______________________________________________
> general mailing list
> general <at> lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-general
>
>
> _______________________________________________
> general mailing list
> general <at> lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-general
>
>
>
>
> --
> Chris Messina
> User Experience Designer, Google
>
> //chrismessina.me | + | <at> chrismessina
> This email is:   [ ] shareable    [✔] ask first   [ ] private
>
>
>

--
Chris Messina
User Experience Designer, Google

 

This email is:   [ ] shareable    [✔] ask first   [ ] private


_______________________________________________
general mailing list
general <at> lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-general



 

 

 

openid

_______________________________________________
general mailing list
general <at> lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-general
Permalink | Reply |
headers
Francisco Corella | 16 Feb 2012 01:39
Favicon
Gravatar

Re: [OpenID] One-Click OpenID: A Solution to the NASCAR Problem

Axel,

I looked at your add-on.  I actually installed it and tried it out,
but somehow I didn't recognize my identity providers.

The idea of supplying the openid to an input field of the RP by
dragging the OpenID icon is nice.  My approach, which depends on RP,
IdP and browser enhancements, is a little simpler: there is no input
field.

Francisco

From: "Axel.Nennker <at> telekom.de" <Axel.Nennker <at> telekom.de>
To: fcorella <at> pomcor.com; markus.sabadello <at> gmail.com; chris.messina <at> gmail.com
Cc: openid-general <at> lists.openid.net; kplewison <at> pomcor.com
Sent: Wednesday, February 15, 2012 12:35 AM
Subject: RE: [OpenID] One-Click OpenID: A Solution to the NASCAR Problem

I propose to add some id-related functionality to the window object and have blogged about it here:
http://ignisvulpis.blogspot.com/2011/03/all-those-nascars.html and some other posts around that time.
 
The basic idea is to add some code like this  to the RP’s pages:
 
function onLoad() {
  if (window.openid) {
    window.openid.getPreferredOpenidProvider(callback);
  } else {
    // show the NASCAR or whatever
  }
}
 
The acceptable Idp could be a parameter to the getPreferredOpenidProvider method but most OC accept any OpenID anyway…
 
The addon that implements this is here: https://addons.mozilla.org/en-US/firefox/addon/openid-for-firefox/
It learns your openid too by looking for id_res in a server response.
 
Axel
 
 
 
From: openid-general-bounces <at> lists.openid.net [mailto:openid-general-bounces <at> lists.openid.net] On Behalf Of Francisco Corella
Sent: Wednesday, February 15, 2012 7:02 AM
To: Markus Sabadello; Chris Messina
Cc: OpenID General; Karen Lewison
Subject: Re: [OpenID] One-Click OpenID: A Solution to the NASCAR Problem
 
Markus:

OpenID Selector is not a solution to the NASCAR problem, it is the
NASCAR problem itself.  It's a good example of what I'm trying to
avoid.

Everybody:

Before telling me that what I'm proposing has been done before, please
read what I'm proposing.  Or if that takes too much effort, please
consider this: in my solution, the relying party displays a single
button "Login with OpenID".  The user clicks on the button and is
automagically redirected to her preferred OpenID provider, even if the
relying party has never heard of it.

Hint: if you want to criticize this, you could criticize the fact
that it requires an ad-hoc HTTP header, and ad-hoc HTML tag, and new
browser functionality.  Messieurs les Anglais, tirez les premiers.

Francisco
 
From: Markus Sabadello <markus.sabadello <at> gmail.com>
To: Chris Messina <chris.messina <at> gmail.com>
Cc: Francisco Corella <fcorella <at> pomcor.com>; OpenID General <openid-general <at> lists.openid.net>; Karen Lewison <kplewison <at> pomcor.com>
Sent: Tuesday, February 14, 2012 2:41 PM
Subject: Re: [OpenID] One-Click OpenID: A Solution to the NASCAR Problem
 
Yes this has existed before.
At the OpenID Summit in Nov 2009, this was called "OpenID Selector", and then later "Active Client".
Mike Jones did a demo of an OpenID-enabled version of CardSpace that could remember your OpenIDs and allowed one-click login.
And myself, I did a demo of the Higgins equivalent.
Here are some old slides and info:
http://wiki.openid.net/w/page/12995207/2009%20OpenID%20Summit 
 
Markus
-- 
Project Danube: http://projectdanube.org/
PDEC: http://personaldataecosystem.org/
 
On Tue, Feb 14, 2012 at 7:18 AM, Chris Messina <chris.messina <at> gmail.com> wrote:


On Monday, February 13, 2012, Francisco Corella <fcorella <at> pomcor.com> wrote:
> Chris,
>
>> You may also be interested in some of the Social Agent work I did with
>> Mozilla around baking identity into the browser:
>>
>> http://factoryjoe.com/social-agent/
>> http://factoryjoe.com/blog/2010/03/12/the-social-agent-part-2-connect/
>
> Thanks for link.  Interesting.  I agree that there are similarities.
> In particular, your Activate step is similar to setting an identity
> provider as the default in my scheme.
>
>> So long as choice of IDP is something that you want to provide the
>> user, something like the NASCAR, a search box, or an email field will
>> still be necessary to help them get started.
>
> No.  A solution based on a cookie set by relying party to remember
> what identity provider has been used on a previous visit would need
> something to "get started". 
Right, I'm asking about the first time visit. Not about a re-visit.

> But in my solution the <idp> element
> tells the relying party what identity provider the user wants to use
> even if the user has never visited the relying party before.
I believe this was a feature of CardSpace/Infocard.


>
> Francisco
>
> ________________________________
> From: Chris Messina <chris.messina <at> gmail.com>
> To: Francisco Corella <fcorella <at> pomcor.com>; Dick Hardt <dick.hardt <at> gmail.com>
> Cc: OpenID General <openid-general <at> lists.openid.net>; Karen Lewison <kplewison <at> pomcor.com>
> Sent: Monday, February 13, 2012 6:52 PM
> Subject: Re: [OpenID] One-Click OpenID: A Solution to the NASCAR Problem
>
> You may also be interested in some of the Social Agent work I did with Mozilla around baking identity into the browser:
> http://factoryjoe.com/social-agent/
> http://factoryjoe.com/blog/2010/03/12/the-social-agent-part-2-connect/
> So long as choice of IDP is something that you want to provide the user, something like the NASCAR, a search box, or an email field will still be necessary to help them get started.
>
> On Mon, Feb 13, 2012 at 5:12 PM, Dick Hardt <dick.hardt <at> gmail.com> wrote:
>
> Not really a new idea -- but nice to see people are still thinking about things.
> Challenges:
> How do you deal with the user getting a new machine? Is there a way to sync IDPs or does the user need to log into all the IDPs on a new machine before they can log into sites?
> How does this degrade for browsers that do not support storing the IDP (i.e., all the existing browsers out there)?
> -- Dick
> On Feb 13, 2012, at 6:00 PM, Francisco Corella wrote:
>
> FYI:
> One-Click OpenID: A Solution to the NASCAR Problem, blog post at
> http://pomcor.com/2012/02/13/one-click-openid-a-solution-to-the-nascar-problem/
> Comments welcome.
>
> Francisco
>
> Francisco Corella, PhD
> Founder & CTO, Pomcor
> Twitter: <at> fcorella
> Blog: http://pomcor.com/blog/
> Web site: http://pomcor.com
> _______________________________________________
> general mailing list
> general <at> lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-general
>
>
> _______________________________________________
> general mailing list
> general <at> lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-general
>
>
>
>
> --
> Chris Messina
> User Experience Designer, Google
>
> //chrismessina.me | + | <at> chrismessina
> This email is:   [ ] shareable    [✔] ask first   [ ] private
>
>
>

--
Chris Messina
User Experience Designer, Google
 
This email is:   [ ] shareable    [✔] ask first   [ ] private

_______________________________________________
general mailing list
general <at> lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-general


 
 
 


_______________________________________________
general mailing list
general <at> lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-general
Permalink | Reply |
headers
John Bradley | 16 Feb 2012 02:02

Re: [OpenID] One-Click OpenID: A Solution to the NASCAR Problem

Francisco,

I think what people are raising is that there is significant execution risk in your good idea.

In the past browser venders were uncooperative,  currently Mozilla is developing their own mega IDP based on their idea of browser extensions.
If you can get them and the other vendors to cooperate you will have earned all our respect.

Many of us have gone down the browser extension path.  From Sxipper, Seatbelt, Microsofts prototype, Axels several Firefox add ons.

One thing that slowed people down was the rise of Mobile browsers, and the new security models.  Even someone the size of MS could not address all the platforms with extensions.

Having something that only works on a single platform is a drawback when working with consumers,  I know you fall back to regular openID.

The other approach is providing account chooser services in the cloud, so that you are not dependent on anything other than html 5 to start and then work into browser support.

Look at https://sites.google.com/site/oidfacwg/cdsdemo for one current project.

I wish you luck,  however i think you have chosen a difficult path for yourself.  

Regards
John B.

On 2012-02-15, at 9:39 PM, Francisco Corella wrote:

Axel,

I looked at your add-on.  I actually installed it and tried it out,
but somehow I didn't recognize my identity providers.

The idea of supplying the openid to an input field of the RP by
dragging the OpenID icon is nice.  My approach, which depends on RP,
IdP and browser enhancements, is a little simpler: there is no input
field.

Francisco

From: "Axel.Nennker <at> telekom.de" <Axel.Nennker <at> telekom.de>
To: fcorella <at> pomcor.com; markus.sabadello <at> gmail.com; chris.messina <at> gmail.com
Cc: openid-general <at> lists.openid.net; kplewison <at> pomcor.com
Sent: Wednesday, February 15, 2012 12:35 AM
Subject: RE: [OpenID] One-Click OpenID: A Solution to the NASCAR Problem

I propose to add some id-related functionality to the window object and have blogged about it here:
http://ignisvulpis.blogspot.com/2011/03/all-those-nascars.html and some other posts around that time.
 
The basic idea is to add some code like this  to the RP’s pages:
 
function onLoad() {
  if (window.openid) {
    window.openid.getPreferredOpenidProvider(callback);
  } else {
    // show the NASCAR or whatever
  }
}
 
The acceptable Idp could be a parameter to the getPreferredOpenidProvider method but most OC accept any OpenID anyway…
 
The addon that implements this is here: https://addons.mozilla.org/en-US/firefox/addon/openid-for-firefox/
It learns your openid too by looking for id_res in a server response.
 
Axel
 
 
 
From: openid-general-bounces <at> lists.openid.net [mailto:openid-general-bounces <at> lists.openid.net] On Behalf Of Francisco Corella
Sent: Wednesday, February 15, 2012 7:02 AM
To: Markus Sabadello; Chris Messina
Cc: OpenID General; Karen Lewison
Subject: Re: [OpenID] One-Click OpenID: A Solution to the NASCAR Problem
 
Markus:

OpenID Selector is not a solution to the NASCAR problem, it is the
NASCAR problem itself.  It's a good example of what I'm trying to
avoid.

Everybody:

Before telling me that what I'm proposing has been done before, please
read what I'm proposing.  Or if that takes too much effort, please
consider this: in my solution, the relying party displays a single
button "Login with OpenID".  The user clicks on the button and is
automagically redirected to her preferred OpenID provider, even if the
relying party has never heard of it.

Hint: if you want to criticize this, you could criticize the fact
that it requires an ad-hoc HTTP header, and ad-hoc HTML tag, and new
browser functionality.  Messieurs les Anglais, tirez les premiers.

Francisco
 
From: Markus Sabadello <markus.sabadello <at> gmail.com>
To: Chris Messina <chris.messina <at> gmail.com>
Cc: Francisco Corella <fcorella <at> pomcor.com>; OpenID General <openid-general <at> lists.openid.net>; Karen Lewison <kplewison <at> pomcor.com>
Sent: Tuesday, February 14, 2012 2:41 PM
Subject: Re: [OpenID] One-Click OpenID: A Solution to the NASCAR Problem
 
Yes this has existed before.
At the OpenID Summit in Nov 2009, this was called "OpenID Selector", and then later "Active Client".
Mike Jones did a demo of an OpenID-enabled version of CardSpace that could remember your OpenIDs and allowed one-click login.
And myself, I did a demo of the Higgins equivalent.
Here are some old slides and info:
 
 
On Tue, Feb 14, 2012 at 7:18 AM, Chris Messina <chris.messina <at> gmail.com> wrote:


On Monday, February 13, 2012, Francisco Corella <fcorella <at> pomcor.com> wrote:
> Chris,
>
>> You may also be interested in some of the Social Agent work I did with
>> Mozilla around baking identity into the browser:
>>
>> http://factoryjoe.com/social-agent/
>> http://factoryjoe.com/blog/2010/03/12/the-social-agent-part-2-connect/
>
> Thanks for link.  Interesting.  I agree that there are similarities.
> In particular, your Activate step is similar to setting an identity
> provider as the default in my scheme.
>
>> So long as choice of IDP is something that you want to provide the
>> user, something like the NASCAR, a search box, or an email field will
>> still be necessary to help them get started.
>
> No.  A solution based on a cookie set by relying party to remember
> what identity provider has been used on a previous visit would need
> something to "get started". 
Right, I'm asking about the first time visit. Not about a re-visit.

> But in my solution the <idp> element
> tells the relying party what identity provider the user wants to use
> even if the user has never visited the relying party before.
I believe this was a feature of CardSpace/Infocard.


>
> Francisco
>
> ________________________________
> From: Chris Messina <chris.messina <at> gmail.com>
> To: Francisco Corella <fcorella <at> pomcor.com>; Dick Hardt <dick.hardt <at> gmail.com>
> Cc: OpenID General <openid-general <at> lists.openid.net>; Karen Lewison <kplewison <at> pomcor.com>
> Sent: Monday, February 13, 2012 6:52 PM
> Subject: Re: [OpenID] One-Click OpenID: A Solution to the NASCAR Problem
>
> You may also be interested in some of the Social Agent work I did with Mozilla around baking identity into the browser:
> http://factoryjoe.com/social-agent/
> http://factoryjoe.com/blog/2010/03/12/the-social-agent-part-2-connect/
> So long as choice of IDP is something that you want to provide the user, something like the NASCAR, a search box, or an email field will still be necessary to help them get started.
>
> On Mon, Feb 13, 2012 at 5:12 PM, Dick Hardt <dick.hardt <at> gmail.com> wrote:
>
> Not really a new idea -- but nice to see people are still thinking about things.
> Challenges:
> How do you deal with the user getting a new machine? Is there a way to sync IDPs or does the user need to log into all the IDPs on a new machine before they can log into sites?
> How does this degrade for browsers that do not support storing the IDP (i.e., all the existing browsers out there)?
> -- Dick
> On Feb 13, 2012, at 6:00 PM, Francisco Corella wrote:
>
> FYI:
> One-Click OpenID: A Solution to the NASCAR Problem, blog post at
> http://pomcor.com/2012/02/13/one-click-openid-a-solution-to-the-nascar-problem/
> Comments welcome.
>
> Francisco
>
> Francisco Corella, PhD
> Founder & CTO, Pomcor
> Twitter: <at> fcorella
> Blog: http://pomcor.com/blog/
> Web site: http://pomcor.com
> _______________________________________________
> general mailing list
> general <at> lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-general
>
>
> _______________________________________________
> general mailing list
> general <at> lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-general
>
>
>
>
> --
> Chris Messina
> User Experience Designer, Google
>
> //chrismessina.me | + | <at> chrismessina
> This email is:   [ ] shareable    [✔] ask first   [ ] private
>
>
>

--
Chris Messina
User Experience Designer, Google
 
This email is:   [ ] shareable    [✔] ask first   [ ] private

_______________________________________________
general mailing list
general <at> lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-general


 
 
 


_______________________________________________
general mailing list
general <at> lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-general

Attachment (smime.p7s): application/pkcs7-signature, 4767 bytes
_______________________________________________
general mailing list
general <at> lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-general
Permalink | Reply |
headers
Francisco Corella | 16 Feb 2012 20:30
Favicon
Gravatar

Re: [OpenID] One-Click OpenID: A Solution to the NASCAR Problem

 John,

> I think what people are raising is that there is significant execution
> risk in your good idea.
>
> In the past browser venders were uncooperative, currently Mozilla is
> developing their own mega IDP based on their idea of browser
> extensions.  If you can get them and the other vendors to cooperate
> you will have earned all our respect.
>
> Many of us have gone down the browser extension path.  From Sxipper,
> Seatbelt, Microsofts prototype, Axels several Firefox add ons.
>
> One thing that slowed people down was the rise of Mobile browsers, and
> the new security models.  Even someone the size of MS could not
> address all the platforms with extensions.
>
> Having something that only works on a single platform is a drawback
> when working with consumers, I know you fall back to regular openID.
>
> The other approach is providing account chooser services in the cloud,
> so that you are not dependent on anything other than html 5 to start
> and then work into browser support.
>
> Look at https://sites.google.com/site/oidfacwg/cdsdemo for one current
> project.
>
> I wish you luck, however i think you have chosen a difficult path for
> yourself.

Thank you.  I agree that the main problem is not technical, it's
getting 5+ browser vendors to go along.  But that's easier now than it
used to be.  Harry Halpin of W3C proved that he can get all browser
vendors in the same room, at the Identity in the Browser workshop.  I
was impressed by that.  And there is NSTIC itself.  If an idea
demonstrated by a successful pilot is endorsed by the future NSTIC
Steering Group browser vendors will hopefully pay attention.  I know,
it's still a long shot.

The problem with a cloud solution like the GIT is that it's a massive
privacy invasion.  I like to complain about Facebook finding out what
relying parties its users log in to, but if the GIT became a universal
login method, Google would be informed of all logins of all Web users.
I wonder how the new Google privacy policy applies to the GIT.  And I
wonder how relying parties that use the GIT disclose the implications
in their privacy policies.

Google's account chooser (without the cloud-based GIT) has two
problems: (i) it only works well for email address identities, and
many OpenID providers are not webmail providers; and (ii) users will
never understand why the experience is different for some email
addresses (those hosted by OpenID providers) than others (those hosted
by webmail providers that are not OpenID providers).  Regarding (ii),
I followed the link that your provided and tried out the demo.  I
tried it in with my gmail address; that worked.  I tried it with my
Yahoo address; that produced an error message, presumably due to some
bug that can be fixed.  I tried it with my Pomcor address; that hung.
There was no warning in the demo that it would only work for some
email addresses.  You can't expect all webmail service providers to be
OpenID providers.

Francisco

_______________________________________________
general mailing list
general <at> lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-general
Permalink | Reply |
headers
John Bradley | 16 Feb 2012 21:00

Re: [OpenID] One-Click OpenID: A Solution to the NASCAR Problem

For a central GIT to be successful it would need to be run by an audited independent third party.

That is what Mozilla is doing with browserID (not independent or audited) though they have the ability to impersonate users where GIT would not.

It would be a temporary solution until browser support was available.

I am glad you have confidence in Harry's abilities.  Perhaps more than he has given some of my recent conversations with him.

You will be one of many strings pulling on those venders.

Unless you have a way to prove out your idea before they come on board, you are in for a hard time.

Those of us who have been down this road before feel for you.

John B.

On 2012-02-16, at 4:30 PM, Francisco Corella wrote:

 John,

> I think what people are raising is that there is significant execution
> risk in your good idea.
>
> In the past browser venders were uncooperative, currently Mozilla is
> developing their own mega IDP based on their idea of browser
> extensions.  If you can get them and the other vendors to cooperate
> you will have earned all our respect.
>
> Many of us have gone down the browser extension path.  From Sxipper,
> Seatbelt, Microsofts prototype, Axels several Firefox add ons.
>
> One thing that slowed people down was the rise of Mobile browsers, and
> the new security models.  Even someone the size of MS could not
> address all the platforms with extensions.
>
> Having something that only works on a single platform is a drawback
> when working with consumers, I know you fall back to regular openID.
>
> The other approach is providing account chooser services in the cloud,
> so that you are not dependent on anything other than html 5 to start
> and then work into browser support.
>
> Look at https://sites.google.com/site/oidfacwg/cdsdemo for one current
> project.
>
> I wish you luck, however i think you have chosen a difficult path for
> yourself.

Thank you.  I agree that the main problem is not technical, it's
getting 5+ browser vendors to go along.  But that's easier now than it
used to be.  Harry Halpin of W3C proved that he can get all browser
vendors in the same room, at the Identity in the Browser workshop.  I
was impressed by that.  And there is NSTIC itself.  If an idea
demonstrated by a successful pilot is endorsed by the future NSTIC
Steering Group browser vendors will hopefully pay attention.  I know,
it's still a long shot.

The problem with a cloud solution like the GIT is that it's a massive
privacy invasion.  I like to complain about Facebook finding out what
relying parties its users log in to, but if the GIT became a universal
login method, Google would be informed of all logins of all Web users.
I wonder how the new Google privacy policy applies to the GIT.  And I
wonder how relying parties that use the GIT disclose the implications
in their privacy policies.

Google's account chooser (without the cloud-based GIT) has two
problems: (i) it only works well for email address identities, and
many OpenID providers are not webmail providers; and (ii) users will
never understand why the experience is different for some email
addresses (those hosted by OpenID providers) than others (those hosted
by webmail providers that are not OpenID providers).  Regarding (ii),
I followed the link that your provided and tried out the demo.  I
tried it in with my gmail address; that worked.  I tried it with my
Yahoo address; that produced an error message, presumably due to some
bug that can be fixed.  I tried it with my Pomcor address; that hung.
There was no warning in the demo that it would only work for some
email addresses.  You can't expect all webmail service providers to be
OpenID providers.

Francisco


Attachment (smime.p7s): application/pkcs7-signature, 4767 bytes
_______________________________________________
general mailing list
general <at> lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-general
Permalink | Reply |
headers
Francisco Corella | 14 Feb 2012 04:49
Favicon
Gravatar

Re: [OpenID] One-Click OpenID: A Solution to the NASCAR Problem

Dick,

> Not really a new idea -- but nice to see people are still thinking
> about things.

Any links to prior work?

> Challenges:
>
> How do you deal with the user getting a new machine? Is there a way to
> sync IDPs or does the user need to log into all the IDPs on a new
> machine before they can log into sites?

IdPs will be synced along with all other browser settings.  It's very
possible to this securely, and I believe browser manufacturers are
working on this.  Eventually I hope it will be possible to sync across
different browsers, not just across instances of the same browser on
different machines.

> How does this degrade for browsers that do not support storing the IDP
> (i.e., all the existing browsers out there)?

The relying party can check what browser it is interacting with, and
use an ordinary OpenID input box if the browser does not support the
new one-click method.

Francisco

From: Dick Hardt <dick.hardt <at> gmail.com>
To: Francisco Corella <fcorella <at> pomcor.com>
Cc: OpenID General <openid-general <at> lists.openid.net>; Karen Lewison <kplewison <at> pomcor.com>
Sent: Monday, February 13, 2012 5:12 PM
Subject: Re: [OpenID] One-Click OpenID: A Solution to the NASCAR Problem

Not really a new idea -- but nice to see people are still thinking about things.

Challenges:

How do you deal with the user getting a new machine? Is there a way to sync IDPs or does the user need to log into all the IDPs on a new machine before they can log into sites?

How does this degrade for browsers that do not support storing the IDP (i.e., all the existing browsers out there)?

-- Dick

On Feb 13, 2012, at 6:00 PM, Francisco Corella wrote:

FYI:

One-Click OpenID: A Solution to the NASCAR Problem, blog post at
http://pomcor.com/2012/02/13/one-click-openid-a-solution-to-the-nascar-problem/

Comments welcome.

Francisco

Francisco Corella, PhD
Founder & CTO, Pomcor
Twitter: <at> fcorella
Blog: http://pomcor.com/blog/
Web site: http://pomcor.com
_______________________________________________
general mailing list
general <at> lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-general



_______________________________________________
general mailing list
general <at> lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-general
Permalink | Reply |
headers
Melvin Carvalho | 16 Feb 2012 07:38
Picon
Gravatar

Re: [OpenID] One-Click OpenID: A Solution to the NASCAR Problem

On 14 February 2012 02:00, Francisco Corella <fcorella <at> pomcor.com> wrote:
> FYI:
>
> One-Click OpenID: A Solution to the NASCAR Problem, blog post at
> http://pomcor.com/2012/02/13/one-click-openid-a-solution-to-the-nascar-problem/

myopenid.com (Janrain)  has been doing this since 2008 I believe

Add an SSL Client Certificate

Click the button below to install a secure client certificate into
your Web browser. Your browser will use your certificate to prove your
identity to myOpenID using Transport Layer Security, or TLS. Using
this certificate avoids the necessity to enter any sensitive
information, such as your password.

I just checked I still have mine:

You have the following certificates:
Label 	Serial Number 	Created 	Revoked
home 	F05F 	2009-01-13 10:53:04.808190 	Revoke this Certificate

WebID also has done some work with X.509.

Francisco, have you had a look at BrowserID?  That is also a single
button login.

>
> Comments welcome.
>
> Francisco
>
> Francisco Corella, PhD
> Founder & CTO, Pomcor
> Twitter:  <at> fcorella
> Blog: http://pomcor.com/blog/
> Web site: http://pomcor.com
>
> _______________________________________________
> general mailing list
> general <at> lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-general
>
Permalink | Reply |
headers
Peter Williams | 16 Feb 2012 08:51
Picon
Favicon
Gravatar

Re: [OpenID] One-Click OpenID: A Solution to the NASCAR Problem


I read the post.

If the metric or program acceptance were: how are several latent technologies linked together to solve a
problem that is "just holding back" the floodwall of adoption, (vs., can I have some cash for my idea, like
one might make an investor in your startup), one might well tie a couple of projects together.

Since you are having the IDP issue a client cert to the SSL module of a browser, let's remark that said cert is
essentially a cookie (in function). Its not an ID cert, issued by a CA, and its not tied to any type of
smartcard. Lets call it a IDP's session-cert. As the webid project has shown, in can contain in the URI name
field a pointer to HTML5-marked up file, listing the users XYZ service access points. Of course, this
should sound like openid1 (where the metadata tags in the users own XRD on his/her blogsite played the
role, formally). These days, it can be a blog post body itself, rather than meta links in a hard-to-edit
HTML header or XRD (XML) file. The links simply point to the OP endpoint.

Nothing "new" in that idea, except that a couple of more relevant technologies were hooked up, with a custom
SSL cert used as some glueware. Nothing stops a CA's cert also being used directly wit hthe IDP or the RP, in
multiple browsers (tied one day to a national-id smartcard, or mobile phone SIM card, or NF device... ).

3 things are different - and not just the same old war horse arguments, repeated over and over and over again.
There are different types of certs, and IDPs can issue them too (for "management/discovery purposes").
Said certs have an nice auto presentation, due to SSL sessionid mechanisms, being optionally consumed by
requesting sites. They also have nice consent mechanisms (on first time release). They can have URIs in
them, that solve the type-here problem. The URI can these days be pointing to the bodies of files/posts,
that even I can edit. Various technologies are available for markup, in the era of HTML5 semantic markup
going "consumer".

this is what Id expect to hear in the rationale for why I want funding. I would not expect to here about how to
solve the nascar problem (thats not the reason I fund stuff, though other agencies might on such
criteria). I want to hear how rich is the US national infrastructure, so lots gets solved. Id perhaps want
to here that the SSL proxy mode of the corporate firewall might be handling this class of client certs and
the https client authn, too (rather than the browser itself).

This is just my guess of what they want to hear (not that I know...). The art of winning funds to know the
mindset of the program manager. Not to do so is the commonest cause of grant application failures.
Permalink | Reply |
headers
SitG Admin | 16 Feb 2012 18:31

Re: [OpenID] One-Click OpenID: A Solution to the NASCAR Problem

>3 things are different - and not just the same old war horse 
>arguments, repeated over and over and over again. There are 
>different types of certs, and IDPs can issue them too (for 
>"management/discovery purposes").

Modern browsers have solved the "common CA pool" problem? IDPs can 
sign these different cert types (below them in that special type's 
own hierarchy) without necessarily being granted the authority to 
sign ANY cert, say of the common SSL type?

-Shade
Permalink | Reply |
headers
Francisco Corella | 16 Feb 2012 21:33
Favicon
Gravatar

Re: [OpenID] One-Click OpenID: A Solution to the NASCAR Problem

Shade,

> > 3 things are different - and not just the same old war horse
>   arguments, repeated over and over and over again. There are
>   different types of certs, and IDPs can issue them too (for
>   "management/discovery purposes").
>
> Modern browsers have solved the "common CA pool" problem? IDPs can
> sign these different cert types (below them in that special type's own
> hierarchy) without necessarily being granted the authority to sign ANY
> cert, say of the common SSL type?

Any site can issue a self-signed certificate (or a certificate that's
not signed at all), if the certificate is intended to only be
presented to the very same site that issued it.

Btw the relying party could issue a self-signed certificate that it
would verify itself.  That's a good alternative to what I'm proposing.
But what I'm proposing is simpler for the relying party, which doesn't
have to deal with certificates at all.

Francisco

_______________________________________________
general mailing list
general <at> lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-general
Permalink | Reply |
headers
Peter Williams | 16 Feb 2012 21:44
Picon
Favicon
Gravatar

Re: [OpenID] One-Click OpenID: A Solution to the NASCAR Problem


If you look at the mozilla work on browerid, its really a short-life cert scheme (in push mode).

Yo ucan do quite a bit of their architecture just using what already exists, in pull mode. If you want an RP to
mint a cert, all it has to do is resign the one thats inbound from a dis-interested third party (e.g. the govt
of the day), and register the (locally resigned) replacement as the mapping onto the local account.
Furthermore, several RP can agree to share the re-minted one issued by a particular "primary-RP" who
speaks for the "affiliation" of RPs. The extensions in the re-minted cert can have control objectives and
value add specific to that industry (that noone else cares about). For example, the reminted cert might
NOT have a chaining length control set (allowing the webid folks to build user centric chains of certs
spanning linked data graphs.)

This is an old model, from the SAML days, when IDPs had less power than they do now to structure the world
according to the IDP-centric view. In realty, im insisting on power-sharing, by excluding IDPs that
refuse to work with SP affiliations (of user organizations). Im perfectly willing to accomodate IDP
fears about cost recovery or their liability, but not their paranoias about what value they bring.
Permalink | Reply |
headers
Francisco Corella | 16 Feb 2012 21:21
Favicon
Gravatar

Re: [OpenID] One-Click OpenID: A Solution to the NASCAR Problem

Peter,

> I read the post.
>
> If the metric or program acceptance were: how are several latent
> technologies linked together to solve a problem that is "just holding
> back" the floodwall of adoption, (vs., can I have some cash for my
> idea, like one might make an investor in your startup), one might well
> tie a couple of projects together.

The focus of the pilot program is to address barriers that have held
back adoption: "Pilot Program Focus Area: Building Identity Ecosystem
Foundations and Frameworks to Address Barriers".

> Since you are having the IDP issue a client cert to the SSL module of
> a browser, let's remark that said cert is essentially a cookie (in
> function). Its not an ID cert, issued by a CA, and its not tied to any
> type of smartcard. Lets call it a IDP's session-cert.

I wouldn't call it a session-cert because it is long-lived.

> As the webid
> project has shown, in can contain in the URI name field a pointer to
> HTML5-marked up file, listing the users XYZ service access points. Of
> course, this should sound like openid1 (where the metadata tags in the
> users own XRD on his/her blogsite played the role, formally). These
> days, it can be a blog post body itself, rather than meta links in a
> hard-to-edit HTML header or XRD (XML) file. The links simply point to
> the OP endpoint.

> Nothing "new" in that idea, except that a couple of more relevant
> technologies were hooked up, with a custom SSL cert used as some
> glueware. Nothing stops a CA's cert also being used directly wit hthe
> IDP or the RP, in multiple browsers (tied one day to a national-id
> smartcard, or mobile phone SIM card, or NF device... ).
>
> 3 things are different - and not just the same old war horse
> arguments, repeated over and over and over again. There are different
> types of certs, and IDPs can issue them too (for "management/discovery
> purposes"). Said certs have an nice auto presentation, due to SSL
> sessionid mechanisms, being optionally consumed by requesting
> sites. They also have nice consent mechanisms (on first time
> release). They can have URIs in them, that solve the type-here
> problem.

I suppose you are referring here to the URI of the OpendID provider
endpoint.  Yes, my first idea was to include the URI in the
certificate.  But now I prefer to download it to the browser together
with, but outside of, the certificate.  That way the
one-click/one-button login-with-openid solution also works when the
user authenticates to the OpenID provider with the traditional
username and password.

> The URI can these days be pointing to the bodies of
> files/posts, that even I can edit. Various technologies are available
> for markup, in the era of HTML5 semantic markup going "consumer".
>
> this is what Id expect to hear in the rationale for why I want
> funding. I would not expect to here about how to solve the nascar
> problem (thats not the reason I fund stuff, though other agencies
> might on such criteria).

Sure, I won't talk about NASCAR in the proposal.

I want to hear how rich is the US national
> infrastructure, so lots gets solved. Id perhaps want to here that the
> SSL proxy mode of the corporate firewall might be handling this class
> of client certs and the https client authn, too (rather than the
> browser itself).
>
> This is just my guess of what they want to hear (not that I
> know...). The art of winning funds to know the mindset of the program
> manager. Not to do so is the commonest cause of grant application
> failures.

Thanks for the advice, I'll keep it in mind.

Francisco

_______________________________________________
general mailing list
general <at> lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-general
Permalink | Reply |
headers
Allen Tom | 16 Feb 2012 22:12
Picon
Gravatar

Re: [OpenID] One-Click OpenID: A Solution to the NASCAR Problem

Hi Francisco,


Thanks for sharing! 

One of the appealing aspects of your proposal is that it enables users to login with an account from any OpenID Provider, as opposed to being limited to a small set of NASCAR buttons. However, websites generally limit the choices available to users in order to persuade the user to login using a high value account with data and services (name, verified email address, social sharing, profile, Likes, etc).

In practice, not many websites want to users to login with 3rd party accounts unless they're guaranteed to get some data/services - it seems that most sites would rather have the user register a new local account with a password if the user doesn't want to use one of the NASCAR buttons.   Account Chooser and Mozilla's BrowserID are both relatively email-address centric because verified email address seems to be the bare minimum that sites need to to get in order to justify accepting a 3rd party login relative to just registering a local account.

Does your proposal have a way for an RP to specify the requirements for accounts that are acceptable for users to login with? For instance, an RP may only accept OpenIDs from OPs that share the user's verified email address. 

Thanks
Allen

_______________________________________________
general mailing list
general <at> lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-general
Permalink | Reply |
headers
sknvn-openid | 16 Feb 2012 22:15
Picon
Favicon

Re: [OpenID] One-Click OpenID: A Solution to the NASCAR Problem


+1 to Allen's comments.

From: Allen Tom <allentomdude <at> gmail.com>
To: Francisco Corella <fcorella <at> pomcor.com>
Cc: "openid-general <at> lists.openid.net"" <openid-general <at> lists.openid.net>
Sent: Thu, February 16, 2012 1:1 2:41 PM
Subject: Re: [OpenID] One-Click OpenID: A Solution to the NASCAR Problem

Hi Francisco,

Thanks for sharing! 

One of the appealing aspects of your proposal is that it enables users to login with an account from any OpenID Provider, as opposed to being limited to a small set of NASCAR buttons. However, websites generally limit the choices available to users in order to persuade the user to login using a high value account with data and services (name, verified email address, social sharing, profile, Likes, etc).

In practice, not many websites want to users to login with 3rd party accounts unless they're guaranteed to get some data/services - it seems that most sites would rather have the user register a new local account with a password if the user doesn't want to use one of the NASCAR buttons.   Account Chooser and Mozilla's BrowserID are both relatively email-address centric because verified email address seems to be the bare minimum that sites need to to get in order to justify accepting a 3rd party login relative to just registering a local account.

Does your proposal have a way for an RP to specify the requirements for accounts that are acceptable for users to login with? For instance, an RP may only accept OpenIDs from OPs that share the user's verified email address. 

Thanks
Allen

_______________________________________________
general mailing list
general <at> lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-general
Permalink | Reply |
headers
John Bradley | 16 Feb 2012 23:02

Re: [OpenID] One-Click OpenID: A Solution to the NASCAR Problem

At some future point there may be many IdP with rich attributes and API that RP are willing to take.

Probably they need to have some sort of trust framework or central management to track that information.

I agree that RP preference needs to be fed into the mix, though doing that without leaking PII to a potential
RP is an issue.

With Account chooser while it asks for a email address the IdP doesn't need to be an email provider.   Only the
domain name is used to perform discovery at this time.

It is a mistake for the RP to treat the user input string as being validated in any way.   

The reason for asking for an email address is that people tend to understand the question, and if the domain
doesn't have a SSO service the email can be used to bootstrap the local account creation process.

If we can come up with another identifier type/decryption that is understandable to users that could be
used as well.

I think account chooser is the path most likely to succeed.  It also has the advantage of being protocol
agnostic.  
It could work with openid 2, openID Connect, SAML or other protocols if the RP supports them.

It also allows the IDP flexibility on the primary authenticator.  Custom soft certs, smart cards, phones,
or other methods can be used.

Regards
John B.

On 2012-02-16, at 6:12 PM, Allen Tom wrote:

> Hi Francisco,
> 
> Thanks for sharing! 
> 
> One of the appealing aspects of your proposal is that it enables users to login with an account from any
OpenID Provider, as opposed to being limited to a small set of NASCAR buttons. However, websites
generally limit the choices available to users in order to persuade the user to login using a high value
account with data and services (name, verified email address, social sharing, profile, Likes, etc).
> 
> In practice, not many websites want to users to login with 3rd party accounts unless they're guaranteed to
get some data/services - it seems that most sites would rather have the user register a new local account
with a password if the user doesn't want to use one of the NASCAR buttons.   Account Chooser and Mozilla's
BrowserID are both relatively email-address centric because verified email address seems to be the bare
minimum that sites need to to get in order to justify accepting a 3rd party login relative to just
registering a local account.
> 
> Does your proposal have a way for an RP to specify the requirements for accounts that are acceptable for
users to login with? For instance, an RP may only accept OpenIDs from OPs that share the user's verified
email address. 
> 
> Thanks
> Allen
> 
> _______________________________________________
> general mailing list
> general <at> lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-general
Attachment (smime.p7s): application/pkcs7-signature, 4767 bytes
_______________________________________________
general mailing list
general <at> lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-general
Permalink | Reply |
headers
Melvin Carvalho | 17 Feb 2012 14:54
Picon
Gravatar

Re: [OpenID] One-Click OpenID: A Solution to the NASCAR Problem

On 16 February 2012 23:02, John Bradley <ve7jtb <at> ve7jtb.com> wrote:
> At some future point there may be many IdP with rich attributes and API that RP are willing to take.
>
> Probably they need to have some sort of trust framework or central management to track that information.
>
> I agree that RP preference needs to be fed into the mix, though doing that without leaking PII to a potential
RP is an issue.
>
> With Account chooser while it asks for a email address the IdP doesn't need to be an email provider.   Only
the domain name is used to perform discovery at this time.
>
> It is a mistake for the RP to treat the user input string as being validated in any way.
>
> The reason for asking for an email address is that people tend to understand the question, and if the domain
doesn't have a SSO service the email can be used to bootstrap the local account creation process.
>
> If we can come up with another identifier type/decryption that is understandable to users that could be
used as well.
>
> I think account chooser is the path most likely to succeed.  It also has the advantage of being protocol agnostic.
> It could work with openid 2, openID Connect, SAML or other protocols if the RP supports them.
>
> It also allows the IDP flexibility on the primary authenticator.  Custom soft certs, smart cards,
phones, or other methods can be used.

I've been thinking about trust for many years.

We have centralized trust assertions from people like verisign and
other CAs.  Perhaps the OIDF is going to get into centralized
whitelisting too.

A more interesting approach is the decentralize architecture.  Note:
there's a difference between centralization and specialization.

The paper I like best is :

Agents, Evolutionary Games, and Social Networks"

http://www.cdm.lcs.mit.edu/ftp/lmui/computational%20models%20of%20trust%20and%20reputation.pdf

I've been thinking lately about trying to form an abstraction
framework that could include the following 4 web of trusts:

http://trustmap.org/
http://bitcoin-otc.com/trust.php
http://www.gswot.org/
http://xmlns.com/wot/0.1/

Would love to know if there are any other relatively "open" trust
systems out there.

>
> Regards
> John B.
>
>
>
>
> On 2012-02-16, at 6:12 PM, Allen Tom wrote:
>
>> Hi Francisco,
>>
>> Thanks for sharing!
>>
>> One of the appealing aspects of your proposal is that it enables users to login with an account from any
OpenID Provider, as opposed to being limited to a small set of NASCAR buttons. However, websites
generally limit the choices available to users in order to persuade the user to login using a high value
account with data and services (name, verified email address, social sharing, profile, Likes, etc).
>>
>> In practice, not many websites want to users to login with 3rd party accounts unless they're guaranteed
to get some data/services - it seems that most sites would rather have the user register a new local account
with a password if the user doesn't want to use one of the NASCAR buttons.   Account Chooser and Mozilla's
BrowserID are both relatively email-address centric because verified email address seems to be the bare
minimum that sites need to to get in order to justify accepting a 3rd party login relative to just
registering a local account.
>>
>> Does your proposal have a way for an RP to specify the requirements for accounts that are acceptable for
users to login with? For instance, an RP may only accept OpenIDs from OPs that share the user's verified
email address.
>>
>> Thanks
>> Allen
>>
>> _______________________________________________
>> general mailing list
>> general <at> lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-general
>
>
> _______________________________________________
> general mailing list
> general <at> lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-general
>
Permalink | Reply |
headers
Francisco Corella | 17 Feb 2012 22:46
Favicon
Gravatar

Re: [OpenID] One-Click OpenID: A Solution to the NASCAR Problem

Hi Allen,

> Thanks for sharing!
>
> One of the appealing aspects of your proposal is that it enables users
> to login with an account from any OpenID Provider, as opposed to being
> limited to a small set of NASCAR buttons. However, websites generally
> limit the choices available to users in order to persuade the user to
> login using a high value account with data and services (name,
> verified email address, social sharing, profile, Likes, etc).
>
> In practice, not many websites want to users to login with 3rd party
> accounts unless they're guaranteed to get some data/services - it
> seems that most sites would rather have the user register a new local
> account with a password if the user doesn't want to use one of the
> NASCAR buttons.  Account Chooser and Mozilla's BrowserID are both
> relatively email-address centric because verified email address seems
> to be the bare minimum that sites need to to get in order to justify
> accepting a 3rd party login relative to just registering a local
> account.
>
> Does your proposal have a way for an RP to specify the requirements
> for accounts that are acceptable for users to login with? For
> instance, an RP may only accept OpenIDs from OPs that share the user's
> verified email address.

Yes, the RP can use the SREG extension of OpenID, which does exactly
that.  See:
http://openid.net/specs/openid-simple-registration-extension-1_0.html

Francisco

_______________________________________________
general mailing list
general <at> lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-general
Permalink | Reply |
headers
Francisco Corella | 16 Feb 2012 21:03
Favicon
Gravatar

Re: [OpenID] One-Click OpenID: A Solution to the NASCAR Problem

Melvin,

> > FYI:
> >
> > One-Click OpenID: A Solution to the NASCAR Problem, blog post at
> > http://pomcor.com/2012/02/13/one-click-openid-a-solution-to-the-nascar-problem/
>
> myopenid.com (Janrain)  has been doing this since 2008 I believe
>
> Add an SSL Client Certificate
>
> Click the button below to install a secure client certificate into
> your Web browser. Your browser will use your certificate to prove your
> identity to myOpenID using Transport Layer Security, or TLS. Using
> this certificate avoids the necessity to enter any sensitive
> information, such as your password.
>
> I just checked I still have mine:
>
> You have the following certificates:
> Label     Serial Number     Created     Revoked
> home     F05F     2009-01-13 10:53:04.808190     Revoke this
> Certificate
>
> WebID also has done some work with X.509.
>
> Francisco, have you had a look at BrowserID?  That is also a single
> button login.

I didn't know that myopenid lets you use a certificate.  That's cool,
I'll use it myself.  And I'll mention it in the pilot proposal.
Thanks for telling me.

Yes, I've looked at BrowserID, it's interesting.  There are things
that I don't like, but the core concept is good.

I don't like the positioning as the universal ID for the Web.  You may
want to log in to sites without disclosing your email address.

I don't like the idea of creating a new kind of public key certificate
and using JavaScript to submit it to the relying party.  It's
difficult to secure the JavaScript environment (if at all possible).

I like the idea of having a webmail service provider issue a
certificate that relying parties can use to verify the user's email
address.

Btw, in the long term, I think the best solution is for the browser to
present a certificate directly to the relying party (not necessarily
an email address certificate), so that the certificate issuer is not
informed of how the certificate is used.  (The certificate should be
submitted to the relying party as a TLS client certificate, with the
certificate sent after the handshake, as recently discussed in the TLS
WG.)  What I'm proposing can be seen as a way for the relying party to
offload certificate verification to the issuer.  That's simpler for
the relying party, and it provides an immediate solution to the
certificate revocation problem, while waiting for a better solution
down the road.

Francisco

_______________________________________________
general mailing list
general <at> lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-general
Permalink | Reply |
headers
Peter Williams | 16 Feb 2012 21:30
Picon
Favicon
Gravatar

Re: [OpenID] One-Click OpenID: A Solution to the NASCAR Problem


Ive begged people to use the client cert to myopenid for several years...

It was always seen as a double edged sword though (undermining the need for the openid protocol, itself).
Thi topic is worth understanding, as its goes to the heart of governance.

Folks were/are worried about the bootstrap-problem. this is one in which an IDP with an assertion protocol
introduces subscriber X to lots of RPs, who then dump the IDP and just use the subscriber's client cert
directly (cutting out the IDP, thereafter).

This scenario terrified the old VeriSign product managers (and execs), for example, worried about being
dis-intermediated by the RP talking to a verification agent willing to speak for several certs
authorities oeprating a a fraction of the VeriSign cost basis (once VeriSign had done the HARD task of
first-introduction). VeriSign had no opportunity to recoup its cost outlay (that is), only enabling its competitors.

This comes down go governance, though. Some folks NEVER learned to sepearate cert issuing (and liability
control) from governance of the RP, thereafter, or the associating of revenues with continuing
governance (over downstream privacy policy enforcement, say).

I was VERY VERY pleased to see a mature Google (as IDP) did not have that hangup, allowing the Microsoft
bridge (between openid protocols and ws-fedp protocols used by our Windowsy realty systems) to add a bit
of value (doing some a few protocol conversion steps, for a variety of bit formats). I gave me some renewed
hope about openid quite recently (to be honest) - which Id kind of written off.
Permalink | Reply |
headers
Melvin Carvalho | 17 Feb 2012 14:46
Picon
Gravatar

Re: [OpenID] One-Click OpenID: A Solution to the NASCAR Problem

On 16 February 2012 21:30, Peter Williams <home_pw <at> msn.com> wrote:
>
> Ive begged people to use the client cert to myopenid for several years...
>
>
>
> It was always seen as a double edged sword though (undermining the need for the openid protocol, itself).
Thi topic is worth understanding, as its goes to the heart of governance.
>
>
>
> Folks were/are worried about the bootstrap-problem. this is one in which an IDP with an assertion
protocol introduces subscriber X to lots of RPs, who then dump the IDP and just use the subscriber's client
cert directly (cutting out the IDP, thereafter).
>
>
>
> This scenario terrified the old VeriSign product managers (and execs), for example, worried about being
dis-intermediated by the RP talking to a verification agent willing to speak for several certs
authorities oeprating a a fraction of the VeriSign cost basis (once VeriSign had done the HARD task of
first-introduction). VeriSign had no opportunity to recoup its cost outlay (that is), only enabling its competitors.
>
>
>
>
>
> This comes down go governance, though. Some folks NEVER learned to sepearate cert issuing (and liability
control) from governance of the RP, thereafter, or the associating of revenues with continuing
governance (over downstream privacy policy enforcement, say).
>
>
>
> I was VERY VERY pleased to see a mature Google (as IDP) did not have that hangup, allowing the Microsoft
bridge (between openid protocols and ws-fedp protocols used by our Windowsy realty systems) to add a bit
of value (doing some a few protocol conversion steps, for a variety of bit formats). I gave me some renewed
hope about openid quite recently (to be honest) - which Id kind of written off.

IMHO one of the purposes of OpenID is to persuade product managers not
to fear openness on the web.  Indeed, it can be a competitive
advantage.

I think all of the aspiring ID systems on the web can complement each
other by agreeing the Identity is represented by a URI.  Then your
sign in process is just a flavor of same concept.

Perhaps facebook connect is already there. the very first post on
OpneID / Yadis made this clear, but perhaps that element has become
slightly faded over the years.

This also leads to the next phase which is Trust.

>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
Permalink | Reply |

Gmane