<br><br><div class="gmail_quote">On 20 May 2010 14:32, John Kemp <span dir="ltr"><<a href="mailto:john@jkemp.net">john@jkemp.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Hi Ben,<br>
<div class="im"><br>
On May 20, 2010, at 5:51 AM, Ben Laurie wrote:<br>
<br>
><br>
><br>
> On 19 May 2010 15:46, Chris Messina <<a href="mailto:chris.messina@gmail.com">chris.messina@gmail.com</a>> wrote:<br>
> Can you please expand on and be more specific about what you mean by this:<br>
><br>
> " If, OTOH, you are interested in actually protecting peoples' identities, then OAuth 2.0 doesn't seem like a great starting point."<br>
><br>
> What would be a better starting point?<br>
><br>
> Something that has appropriate security properties.<br>
><br>
> And what does it mean to "protect peoples' identities" in your thinking?<br>
><br>
> 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.<br>
<br>
</div>Who is the "owner" of my identity? What _is_ my identity?<br>
<div class="im"><br>
> This is already relaxed by federation since the IdP has to assert the identity,<br>
<br>
</div>The IdP (in most federated systems I've ever seen) is making an assertion that:<br>
<br>
i) It has verified, in some way, the identity of someone.<br>
ii) That this same "someone" has an account with the IdP<br>
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.<br>
<br>
None of those things is an assertion about "identity", per se.<br></blockquote><div><br></div><div>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.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br>
> not the owner (unless the owner is the IdP, of course, my preferred solution if federation is insisted on),<br>
<br>
</div>The IdP owns the account, certainly.<br>
<div class="im"><br>
> but relaxing it further by introducing protocols that do not strongly bind the assertion to the IdP is not a good idea.<br>
<br>
</div>I certainly agree with that.<br>
<br>
Cheers,<br>
<br>
- johnk<br>
<div><div></div><div class="h5"><br>
><br>
><br>
> Thanks,<br>
><br>
> Chris<br>
><br>
> Sent from my iPhone 2G<br>
><br>
> On May 19, 2010, at 2:25 AM, Ben Laurie <<a href="mailto:benl@google.com">benl@google.com</a>> wrote:<br>
><br>
>><br>
>><br>
>> On 16 May 2010 00:57, David Recordon <<a href="mailto:recordond@gmail.com">recordond@gmail.com</a>> wrote:<br>
>> 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 (<a href="http://daveman692.livejournal.com/349384.html" target="_blank">http://daveman692.livejournal.com/349384.html</a>).<br>
>><br>
>> 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.<br>
>><br>
>> 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 <a href="http://factoryjoe.com/blog/2010/01/04/openid-connect/" target="_blank">http://factoryjoe.com/blog/2010/01/04/openid-connect/</a>). And thanks to Eran Hammer-Lahav and Joseph Smarr for some help writing bits of it!<br>
>><br>
>> So, a modest proposal that I hope gets the conversation going again. <a href="http://openidconnect.com/" target="_blank">http://openidconnect.com/</a><br>
>><br>
>> 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.<br>
>><br>
>> If, OTOH, you are interested in actually protecting peoples' identities, then OAuth 2.0 doesn't seem like a great starting point.<br>
>><br>
>><br>
>> --David<br>
>><br>
>> _______________________________________________<br>
>> specs mailing list<br>
>> <a href="mailto:specs@lists.openid.net">specs@lists.openid.net</a><br>
>> <a href="http://lists.openid.net/mailman/listinfo/openid-specs" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs</a><br>
>><br>
>><br>
>> _______________________________________________<br>
>> specs mailing list<br>
>> <a href="mailto:specs@lists.openid.net">specs@lists.openid.net</a><br>
>> <a href="http://lists.openid.net/mailman/listinfo/openid-specs" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs</a><br>
><br>
> _______________________________________________<br>
> specs mailing list<br>
> <a href="mailto:specs@lists.openid.net">specs@lists.openid.net</a><br>
> <a href="http://lists.openid.net/mailman/listinfo/openid-specs" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs</a><br>
<br>
</div></div></blockquote></div><br>