<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Am 20.05.2010 05:18, schrieb Allen Tom:
<blockquote cite="mid:C819F7F8.3050B%25atom@yahoo-inc.com" type="cite">
<title>Re: Building identity on top of OAuth 2.0?</title>
<font face="Calibri, Verdana, Helvetica, Arial"><span
style="font-size: 11pt;">Whoa, I think it’s premature to say that
Yahoo supports OpenID Connect, but I would imagine that only a single
Access Token would be returned to coolcalendar.com – the Access Token
would presumably be good for both “openid” and “calendar” scope. Why
would the OP want to return 2 tokens?<br>
<br>
</span></font></blockquote>
<br>
very good question! <br>
<br>
Probably because the protected resources for <font
face="Calibri, Verdana, Helvetica, Arial">user data and calendar data
access are operated independently? Let's assume the AS issues
self-contained, signed, and encrypted bearer tokens. The signature and
encryption could be based on a shared secret between AS and RP. In
such a scenario, it is required to issue different, PR specific,
tokens. Otherwise, user data and calendar data service could (1) either
not decrypt and validate the token or (2) would be forced to share the
same secret. <br>
<br>
Moreover, the RPs might need different user attributes and permissions,
so even the payload might differ.<br>
<br>
regards,<br>
Torsten.</font> <br>
P.S: I suggest to move the discussing to the OAuth mailing list.
Thoughts?<br>
<br>
<blockquote cite="mid:C819F7F8.3050B%25atom@yahoo-inc.com" type="cite"><font
face="Calibri, Verdana, Helvetica, Arial"><span
style="font-size: 11pt;">Allen<br>
<br>
<br>
On 5/19/10 5:27 PM, "Dirk Balfanz" <<a moz-do-not-send="true"
href="balfanz@google.com">balfanz@google.com</a>> wrote:<br>
<br>
</span></font>
<blockquote><font face="Calibri, Verdana, Helvetica, Arial"><span
style="font-size: 11pt;"><br>
Let's say I'm coolcalendar.com <<a moz-do-not-send="true"
href="http://coolcalendar.com">http://coolcalendar.com</a>> , and I
want to "connect" one of my user's accounts to his Yahoo! account. I
don't want to roll my own auth system, so I'm happy to see that Yahoo!
supports OpenID Connect. To connect, I'll send the user over to Yahoo!
with scope=openid%20yahoo-calendar. What I get back, in your proposal,
is two different kinds of "tokens": the access token that my servers
use to access Yahoo! and something I'll call "openid connect token"
(which in your proposal comprises a few different parameters - user id,
timestamp, signature, etc.) that browsers use (in form of a cookie) to
access my own servers at coolcalendar.com <<a moz-do-not-send="true"
href="http://coolcalendar.com">http://coolcalendar.com</a>> . <br>
<br>
Why do those two tokens look different? They serve the same purpose -
authenticating access from a client to a server, so they should look
the same. <br>
<br>
Why should Yahoo! run different code to authenticate requests coming
from my server than the code I'm running on my servers to authenticate
requests coming from browsers - we have to solve the same task, so we
should run the same code. It's simpler. <br>
<br>
</span></font></blockquote>
<pre wrap="">
<fieldset class="mimeAttachmentHeader"></fieldset>
_______________________________________________
specs mailing list
<a class="moz-txt-link-abbreviated" href="mailto:specs@lists.openid.net">specs@lists.openid.net</a>
<a class="moz-txt-link-freetext" href="http://lists.openid.net/mailman/listinfo/openid-specs">http://lists.openid.net/mailman/listinfo/openid-specs</a>
</pre>
</blockquote>
<br>
</body>
</html>