[OpenID] LinkedIn Connect?

Mike Repass mike.repass at gmail.com
Wed Apr 7 22:07:50 UTC 2010 

[jumping in]

Hi Chris, I'm the LinkedIn guy who presented at the OpenID Summit on Monday.

Indeed, we have many partners rolling their own Login with LinkedIn using
our existing OAuth flow. coworkers.com is another good example, albeit a
registration case instead of login. And we have developers in the forum
requesting improvements for this use case - the most common request is for
an endpoint that immediately redirects if an existing grant is available
(the user never sees the Providers's page if they've already given
permission), as is the case with Sign-in-with-Twitter.

At the risk of conflating protocols, I do think there is raw potential for
an "identity and profile" extension to OAuth. IDPs which carry a lot of
sensitive profile information (like LinkedIn) can probably never hand it out
to arbitrary, unknown RPs ... but we already have an OAuth solution for
managing our relationship with third parties (registration, terms of use,
signing), so why not leverage that?

Basic pieces would include:

   - An endpoint which will redirect immediately if the user is (a) signed
   in and (b) has an existing access grant for the requesting party.
      - optionally, there could be an 'immediate report' option to this
      endpoint which will return immediately even in the negative case (i.e.
      signaling that the user would be prompted). Useful for
background calls to
      detect a user's state and then adapt UX.
      - It's important to keep the "always prompt" endpoint so that
      concerned developers can make sure users understand what's happening.
   - A standard field for returning a stable user_id. And probably some
   additional metadata: in the LinkedIn case, our member_ids are actually
   per-developer-key, so it might be useful to signal that in a standard way.
   - A mechanism for third parties to invalidate a token ("Logout
   Completely"). If the third party detects that the wrong LinkedIn-user is
   connected to an account on their side (UX confusion, etc), they can be good
   citizens and invalidate the underlying token, then send the current user
   back through the full flow to get it fixed.
   - A standard field for identifying a profile endpoint which (if called
   with the access token) will return the user's profile in an extensible way.
   I'm sure there's an Open solution for the basic data (ax, poco, etc) but
   it's likely that we (LI) will always have *some* unique info so would
   love to just pass the extra stuff back in a json blob somewhere.

My idea here is not to push the wrong things into OAuth, but rather help out
the extremely common use case of a developer saying "I just want to import
that user's profile after getting their permission". Would be great if the
various OAuth libraries had a getProfile() method that worked consistently.
Even though results would be heterogenous and provider-specific - that's
alright for many (most?) developers.

As to user experience reports on the grant duration (1-day, 1 month,
Indefinite) , we don't have good data yet. Honestly the platform hasn't been
open for long enough :-). But I do have anecdotal reports that users like
the 1-day grant - it lets them try out subscription-style / ongoing services
and not worry about dealing with the third-party's cancellation later.

I do not know if users have sufficiently grok'd the concept of an IDP's
"Application Permissions Management Page". Would love to chat on common UX
issues around that.

Of course, apologies for rambling about this on an OpenID list :-P

-- Mike

On Wed, Apr 7, 2010 at 1:19 PM, Paul Lindner <lindner at inuus.com> wrote:

> We have not done much in the way of usability studies on this page.  We do
> know that most users will grant access 'until revoked', which is not too
> surprising since that's the default choice.
>
> The partner can (and does) get a stable identifier by sending a query to a
> rest endpoint that returns the member ID for the current token (and other
> information).  It's the equivalent of a PoCo @self request.
>
>
>
> On Apr 7, 2010, at 10:43 AM, Chris Messina wrote:
>
> Have you done any usability studies on this flow/screen? Any idea whether
> people understand the "duration" dropdown? And — given that elegant.ly is
> using the OAuth token to figure out identity — if and when the token expires
> — do they still have a stable identifier for the user?
>
> Chris
>
> On Wed, Apr 7, 2010 at 10:26 AM, Paul Lindner <lindner at inuus.com> wrote:
>
>> The screen you see is LinkedIn's standard OAuth Authorization Screen.
>>  When you click on the sign-in button it hits the 3rd party backend, which
>> hits our requestToken endpoint, the resulting token is immediately used to
>> redirect to the LinkedIn Authorize page.  If you're logged out you're going
>> to see the Email/Password fields.  In all cases we prompt for the duration
>> of the access grant.  Once access is granted we redirect back to the
>> originating site.
>>
>> It appears that elegant.ly  then associates the retrieved access token
>> with a cookie/session on their domain.
>>
>> Very slick.
>>
>>
>> On Apr 7, 2010, at 9:05 AM, Chris Messina wrote:
>>
>> Interesting.
>>
>> But while the signin button doesn't come from you, the OAuth page you're
>> redirected to does.
>>
>> How else is that page intended to be used?
>>
>> Chris
>>
>> Sent from my iPhone 2G
>>
>> On Apr 7, 2010, at 6:09 AM, Paul Lindner <lindner at inuus.com> wrote:
>>
>> Hi all,
>>
>> This SignIn button is not something we've designed.  However it shows that
>> people will apply existing technology to solve their problems.  In fact it's
>> not that much different than 'Sign-in With Twitter' if you think about it...
>>
>>
>> On Wed, Apr 7, 2010 at 5:00 AM, <<openid-general-request at lists.openid.net>
>> openid-general-request at lists.openid.net> wrote:
>>
>>> Nice interface, thanks for sharing.
>>>
>>> A bit of Bo-Hoo at LinkedIn for using "Sign In" which seems to
>>> indicate log in when it's not really.
>>> But perhaps no one cares. Is authn and authz just an academic
>>> difference in the wild?
>>>
>>> The world will keep turning...
>>>
>>>
>>> On Fri, Apr 2, 2010 at 7:06 PM, Chris Messina <<chris.messina at gmail.com>
>>> chris.messina at gmail.com> wrote:
>>> > Take a look at this:
>>> > visit <http://elegant.ly/>http://elegant.ly and click the "Sign In"
>>> button...
>>> > You end up at LinkedIn where you're essentially doing an OAuth dance
>>> for
>>> > sign in.
>>> > Interesting, eh?
>>> > Chris
>>> >
>>> > --
>>> > Chris Messina
>>> > Open Web Advocate, Google
>>> >
>>> > Personal: <http://factoryjoe.com/>http://factoryjoe.com
>>> > Follow me on Buzz: <http://buzz.google.com/chrismessina>
>>> http://buzz.google.com/chrismessina
>>> > ...or Twitter: <http://twitter.com/chrismessina>
>>> http://twitter.com/chrismessina
>>> >
>>> > This email is: ? [X] shareable ? ?[ ] ask first ? [ ] private
>>> >
>>> > _______________________________________________
>>> > general mailing list
>>> > <general at lists.openid.net>general at lists.openid.net
>>> > <http://lists.openid.net/mailman/listinfo/openid-general>
>>> 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
> Open Web Advocate, Google
>
> Personal: http://factoryjoe.com
> Follow me on Buzz: http://buzz.google.com/chrismessina
> ...or Twitter: http://twitter.com/chrismessina
>
> This email is:   [ ] shareable    [X] ask first   [ ] private
>
>
>
> _______________________________________________
> general mailing list
> general at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-general
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20100407/a295be51/attachment.htm>

More information about the general mailing list