Building identity on top of OAuth 2.0?

[Ben Laurie]

On 20 May 2010 14:32, John Kemp <john at jkemp.net> wrote:

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

I'm not sure I'm really interested in this discussion, but I note you said
"...verified the identity... " which sounds to me like it might have
something to do with 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20100520/bc1763a2/attachment.html>