On 20 May 2010 14:32, John Kemp <[email protected]> wrote: > Hi Ben, > > On May 20, 2010, at 5:51 AM, Ben Laurie wrote: > > > > > > > On 19 May 2010 15:46, Chris Messina <[email protected]> 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 <[email protected]> wrote: > > > >> > >> > >> On 16 May 2010 00:57, David Recordon <[email protected]> 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 > >> [email protected] > >> http://lists.openid.net/mailman/listinfo/openid-specs > >> > >> > >> _______________________________________________ > >> specs mailing list > >> [email protected] > >> http://lists.openid.net/mailman/listinfo/openid-specs > > > > _______________________________________________ > > specs mailing list > > [email protected] > > http://lists.openid.net/mailman/listinfo/openid-specs > >
_______________________________________________ specs mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-specs
