[OpenID] LinkedIn Connect?

Thu Apr 8 05:25:46 UTC 2010

This is great info, Mike. Thanks.

The ideas you've presented are also interesting and compelling — and would
be great to support in the EasyHybrid work.

It does seem like making identity just another piece of data that you're
authorized to get as part of an OAuth request is a good thing.

I would like to keep the autoregistration and discovery piece of OpenID
around — if only because it allows for more marketplace choice over time —
especially if people do become more comfortable sharing their profile data
generally.

I think defining the proper /profile endpoint within an LRDD/WebFinger
record could go a long way to solving the getProfile() feature you
described.

Have you thought about the deltas between the LinkedIn profile schema and
PoCo?

Chris

On Wed, Apr 7, 2010 at 3:07 PM, Mike Repass <mike.repass at gmail.com> wrote:

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

-- 
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20100407/0e550e24/attachment-0001.htm>