Building identity on top of OAuth 2.0?

[John Kemp]

Hi Ben,

On May 20, 2010, at 5:51 AM, Ben Laurie wrote:

> 
> 
> On 19 May 2010 15:46, Chris Messina <chris.messina at gmail.com> wrote:
> Can you please expand on and be more specific about what you mean by this:
> 
> " If, OTOH, you are interested in actually protecting peoples' identities, then OAuth 2.0 doesn't seem like a great starting point."
> 
> What would be a better starting point?
> 
> Something that has appropriate security properties.
>  
> And what does it mean to "protect peoples' identities" in your thinking?
> 
> That's a big question which I will not attempt to fully address in an email, but one obvious requirement is that no-one but the owner of the identity should be able to assert it.

Who is the "owner" of my identity? What _is_ my identity?

> This is already relaxed by federation since the IdP has to assert the identity,

The IdP (in most federated systems I've ever seen) is making an assertion that:

i) It has verified, in some way, the identity of someone.
ii) That this same "someone" has an account with the IdP
and optionally, iii) That this same "someone" has recently supplied a shared secret indicating that he or she is "logged in" to his or her account at the IdP.

None of those things is an assertion about "identity", per se. 

> not the owner (unless the owner is the IdP, of course, my preferred solution if federation is insisted on),

The IdP owns the account, certainly.

> but relaxing it further by introducing protocols that do not strongly bind the assertion to the IdP is not a good idea.

I certainly agree with that.

Cheers,

- johnk

>  
> 
> Thanks,
> 
> Chris 
> 
> Sent from my iPhone 2G
> 
> On May 19, 2010, at 2:25 AM, Ben Laurie <benl at google.com> wrote:
> 
>> 
>> 
>> On 16 May 2010 00:57, David Recordon <recordond at gmail.com> wrote:
>> The past few months I've had a bunch of one on one conversations with a lot of different people – including many of folks on this list – about ways to build a future version of OpenID on top of OAuth 2.0. Back in March when I wrote a draft of OAuth 2.0 I mentioned it as one of my future goals as well (http://daveman692.livejournal.com/349384.html).
>> 
>> Basically moving us to where there's a true technology stack of TCP/IP -> HTTP -> SSL -> OAuth 2.0 -> OpenID -> (all sorts of awesome APIs). Not just modernizing the technology, but also focusing on solving a few of the key "product" issues we hear time and time again.
>> 
>> I took the past few days to write down a lot of these ideas and glue them together. Talked with Chris Messina who thought it was an interesting idea and decided to dub it "OpenID Connect" (see http://factoryjoe.com/blog/2010/01/04/openid-connect/). And thanks to Eran Hammer-Lahav and Joseph Smarr for some help writing bits of it!
>> 
>> So, a modest proposal that I hope gets the conversation going again. http://openidconnect.com/
>> 
>> If the goal is to get something as weak as possible without it instantly collapsing around your ears, then this sounds like a great plan.
>> 
>> If, OTOH, you are interested in actually protecting peoples' identities, then OAuth 2.0 doesn't seem like a great starting point.
>>  
>> 
>> --David
>> 
>> _______________________________________________
>> specs mailing list
>> specs at lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-specs
>> 
>> 
>> _______________________________________________
>> specs mailing list
>> specs at lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-specs
> 
> _______________________________________________
> specs mailing list
> specs at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs