<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
h4
{mso-style-priority:9;
mso-style-link:"Heading 4 Char";
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
mso-line-height-alt:0pt;
font-size:12.0pt;
font-family:"Courier New";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
pre
{mso-style-priority:99;
mso-style-link:"HTML Preformatted Char";
margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Courier New";}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
{mso-style-priority:99;
mso-style-link:"Balloon Text Char";
margin:0in;
margin-bottom:.0001pt;
font-size:8.0pt;
font-family:"Tahoma","sans-serif";}
span.Heading4Char
{mso-style-name:"Heading 4 Char";
mso-style-priority:9;
mso-style-link:"Heading 4";
font-family:"Courier New";
font-weight:bold;}
span.HTMLPreformattedChar
{mso-style-name:"HTML Preformatted Char";
mso-style-priority:99;
mso-style-link:"HTML Preformatted";
font-family:"Courier New";}
span.BalloonTextChar
{mso-style-name:"Balloon Text Char";
mso-style-priority:99;
mso-style-link:"Balloon Text";
font-family:"Tahoma","sans-serif";}
span.apple-style-span
{mso-style-name:apple-style-span;}
span.EmailStyle23
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.EmailStyle24
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.EmailStyle25
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#002060;}
span.grey
{mso-style-name:grey;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#002060">All four countermeasures are listed below. Comments on each follow:<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#002060"><o:p> </o:p></span></p>
<p class="MsoNormal" style="page-break-before:always"><span lang="EN" style="font-size:10.0pt;font-family:"Courier New""> o Clients SHOULD not make authenticated requests with an access<o:p></o:p></span></p>
<p class="MsoNormal" style="page-break-before:always"><span lang="EN" style="font-size:10.0pt;font-family:"Courier New""> token to unfamiliar resource servers, regardless of the presence<o:p></o:p></span></p>
<p class="MsoNormal" style="page-break-before:always"><span lang="EN" style="font-size:10.0pt;font-family:"Courier New""> of a secure channel. If the resource server address is well-known<o:p></o:p></span></p>
<p class="MsoNormal" style="page-break-before:always"><span lang="EN" style="font-size:10.0pt;font-family:"Courier New""> to the client, it may authenticate the resource servers (see<o:p></o:p></span></p>
<p class="MsoNormal" style="page-break-before:always"><span lang="EN" style="font-size:10.0pt;font-family:"Courier New""> <a href="http://tools.ietf.org/html/draft-ietf-oauth-v2-threatmodel-01#section-5.1.2">Section 5.1.2</a>).<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#002060"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#002060">This one is good practice, but would translate in the OpenID Connect case to something like “Don’t use unfamiliar OpenID Providers”. That’s somewhat opposed
to the “open” intent of OpenID Connect – hence we probably shouldn’t recommend it in the specs.<o:p></o:p></span></p>
<p class="MsoNormal" style="page-break-before:always"><span lang="EN" style="font-size:10.0pt;font-family:"Courier New""><o:p> </o:p></span></p>
<p class="MsoNormal" style="page-break-before:always"><span lang="EN" style="font-size:10.0pt;font-family:"Courier New""> o Associate the endpoint address of the resource server the client<o:p></o:p></span></p>
<p class="MsoNormal" style="page-break-before:always"><span lang="EN" style="font-size:10.0pt;font-family:"Courier New""> talked to with the access token (e.g. in an audience field) and<o:p></o:p></span></p>
<p class="MsoNormal" style="page-break-before:always"><span lang="EN" style="font-size:10.0pt;font-family:"Courier New""> validate association at legitimate resource server. The endpoint<o:p></o:p></span></p>
<p class="MsoNormal" style="page-break-before:always"><span lang="EN" style="font-size:10.0pt;font-family:"Courier New""> address validation policy may be strict (exact match) or more<o:p></o:p></span></p>
<p class="MsoNormal" style="page-break-before:always"><span lang="EN" style="font-size:10.0pt;font-family:"Courier New""> relaxed (e.g. same host). This would require to tell the<o:p></o:p></span></p>
<p class="MsoNormal" style="page-break-before:always"><span lang="EN" style="font-size:10.0pt;font-family:"Courier New""> authorization server the resource server endpoint address in the<o:p></o:p></span></p>
<p class="MsoNormal" style="page-break-before:always"><span lang="EN" style="font-size:10.0pt;font-family:"Courier New""> authorization process.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#002060"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#002060">This is the one that the working group decided to recommend following on Thursday’s call.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#002060"><o:p> </o:p></span></p>
<p class="MsoNormal" style="page-break-before:always"><span lang="EN" style="font-size:10.0pt;font-family:"Courier New""> o Associate an access token with a client and authenticate the<o:p></o:p></span></p>
<p class="MsoNormal" style="page-break-before:always"><span lang="EN" style="font-size:10.0pt;font-family:"Courier New""> client with resource server requests (typically via signature in<o:p></o:p></span></p>
<p class="MsoNormal" style="page-break-before:always"><span lang="EN" style="font-size:10.0pt;font-family:"Courier New""> order to not disclose secret to a potential attacker). This<o:p></o:p></span></p>
<p class="MsoNormal" style="page-break-before:always"><span lang="EN" style="font-size:10.0pt;font-family:"Courier New""> prevents the attack because the counterfeit server is assumed to<o:p></o:p></span></p>
<p class="MsoNormal" style="page-break-before:always"><span lang="EN" style="font-size:10.0pt;font-family:"Courier New""> miss the capabilities to correctly authenticate on behalf of the<o:p></o:p></span></p>
<p class="MsoNormal" style="page-break-before:always"><span lang="EN" style="font-size:10.0pt;font-family:"Courier New""> legitimate client to the resource server (<a href="http://tools.ietf.org/html/draft-ietf-oauth-v2-threatmodel-01#section-5.4.2">Section
5.4.2</a>).<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#002060"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#002060">The client isn’t signing the Access Token in our use cases, so I’m not sure that this one is applicable.</span><span lang="EN" style="font-size:10.0pt;font-family:"Courier New""><o:p></o:p></span></p>
<p class="MsoNormal" style="page-break-before:always"><span lang="EN" style="font-size:10.0pt;font-family:"Courier New""><o:p> </o:p></span></p>
<p class="MsoNormal" style="page-break-before:always"><span lang="EN" style="font-size:10.0pt;font-family:"Courier New""> o Restrict the token scope (see
<a href="http://tools.ietf.org/html/draft-ietf-oauth-v2-threatmodel-01#section-5.1.5.1">
Section 5.1.5.1</a>) and or limit the<o:p></o:p></span></p>
<p class="MsoNormal" style="page-break-before:always"><span lang="EN" style="font-size:10.0pt;font-family:"Courier New""> token to a certain resource server (<a href="http://tools.ietf.org/html/draft-ietf-oauth-v2-threatmodel-01#section-5.1.5.5">Section
5.1.5.5</a>).<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#002060"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#002060">This is essentially the same as the one that the working group recommended. We would restrict the scope of the Access Token by including an audience.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#002060"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#002060"> Comments?<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#002060"> -- Mike<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#002060"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> Axel.Nennker@telekom.de [mailto:Axel.Nennker@telekom.de]
<br>
<b>Sent:</b> Friday, November 11, 2011 3:07 AM<br>
<b>To:</b> Mike Jones; ve7jtb@ve7jtb.com; sakimura@gmail.com<br>
<b>Cc:</b> openid-specs-ab@lists.openid.net<br>
<b>Subject:</b> RE: [Openid-specs-ab] Audience restriction of access_token/resource ep response in OpenID Connect<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Courier New"">Why should we favour one of the four listed countermeasures?<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Courier New""><a href="http://tools.ietf.org/html/draft-ietf-oauth-v2-threatmodel-01#section-4.6.4">http://tools.ietf.org/html/draft-ietf-oauth-v2-threatmodel-01#section-4.6.4</a><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Courier New""><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Courier New"">Does the Oauth Spec favour one?<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Courier New""><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Courier New"">Shouldn’t we concentrate on Connect specific threats and let the developer handle the oauth threats as suggested by the oauth countermeasures? Or does the Connect-Binding of Oauth
lead to favouring one countermeasure?<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Courier New";color:black"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Courier New";color:black"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">
<a href="mailto:openid-specs-ab-bounces@lists.openid.net">openid-specs-ab-bounces@lists.openid.net</a>
<a href="mailto:[mailto:openid-specs-ab-bounces@lists.openid.net]">[mailto:openid-specs-ab-bounces@lists.openid.net]</a>
<b>On Behalf Of </b>Mike Jones<br>
<b>Sent:</b> Freitag, 11. November 2011 05:37<br>
<b>To:</b> John Bradley; Nat Sakimura<br>
<b>Cc:</b> <a href="mailto:openid-specs-ab@lists.openid.net">openid-specs-ab@lists.openid.net</a><br>
<b>Subject:</b> Re: [Openid-specs-ab] Audience restriction of access_token/resource ep response in OpenID Connect<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Section 4.6.4 of the
<a href="http://tools.ietf.org/html/draft-lodderstedt-oauth-security-01">OAuth Threat Model and Security Considerations</a> document contains the following. The highlighting is mine:<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal" style="page-break-before:always"><span lang="EN" style="font-size:10.0pt;font-family:"Courier New""><o:p> </o:p></span></p>
<p class="MsoNormal" style="mso-line-height-alt:0pt;page-break-before:always"><a name="section-4.6.4"><b><span lang="EN" style="font-size:10.0pt;font-family:"Courier New"">4.6.4</span></b></a><b><span lang="EN" style="font-size:10.0pt;font-family:"Courier New"">.
Threat: Access token phishing by counterfeit resource server<o:p></o:p></span></b></p>
<p class="MsoNormal" style="page-break-before:always"><span lang="EN" style="font-size:10.0pt;font-family:"Courier New""><o:p> </o:p></span></p>
<p class="MsoNormal" style="page-break-before:always"><span lang="EN" style="font-size:10.0pt;font-family:"Courier New""> An attacker may pretend to be a particular resource server and to<o:p></o:p></span></p>
<p class="MsoNormal" style="page-break-before:always"><span lang="EN" style="font-size:10.0pt;font-family:"Courier New""> accept tokens from a particular authorization server. If the client<o:p></o:p></span></p>
<p class="MsoNormal" style="page-break-before:always"><span lang="EN" style="font-size:10.0pt;font-family:"Courier New""> sends a valid access tokens to this counterfeit resource server, the<o:p></o:p></span></p>
<p class="MsoNormal" style="page-break-before:always"><span lang="EN" style="font-size:10.0pt;font-family:"Courier New""> server in turn may use that token to access other services on behalf<o:p></o:p></span></p>
<p class="MsoNormal" style="page-break-before:always"><span lang="EN" style="font-size:10.0pt;font-family:"Courier New""> of the resource owner.<o:p></o:p></span></p>
<p class="MsoNormal" style="page-break-before:always"><span lang="EN" style="font-size:10.0pt;font-family:"Courier New""><o:p> </o:p></span></p>
<p class="MsoNormal" style="page-break-before:always"><span lang="EN" style="font-size:10.0pt;font-family:"Courier New""> Countermeasures:<o:p></o:p></span></p>
<p class="MsoNormal" style="page-break-before:always"><span lang="EN" style="font-size:10.0pt;font-family:"Courier New""><o:p> </o:p></span></p>
<p class="MsoNormal" style="page-break-before:always"><span lang="EN" style="font-size:10.0pt;font-family:"Courier New""> o
<span style="background:yellow;mso-highlight:yellow">Associate the endpoint address of the resource server the client<o:p></o:p></span></span></p>
<p class="MsoNormal" style="page-break-before:always"><span lang="EN" style="font-size:10.0pt;font-family:"Courier New";background:yellow;mso-highlight:yellow"> talked to with the access token (e.g. in an audience field) and<o:p></o:p></span></p>
<p class="MsoNormal" style="page-break-before:always"><span lang="EN" style="font-size:10.0pt;font-family:"Courier New";background:yellow;mso-highlight:yellow"> validate association at legitimate resource server.</span><span lang="EN" style="font-size:10.0pt;font-family:"Courier New"">
The endpoint<o:p></o:p></span></p>
<p class="MsoNormal" style="page-break-before:always"><span lang="EN" style="font-size:10.0pt;font-family:"Courier New""> address validation policy may be strict (exact match) or more<o:p></o:p></span></p>
<p class="MsoNormal" style="page-break-before:always"><span lang="EN" style="font-size:10.0pt;font-family:"Courier New""> relaxed (e.g. same host). This would require to tell the<o:p></o:p></span></p>
<p class="MsoNormal" style="page-break-before:always"><span lang="EN" style="font-size:10.0pt;font-family:"Courier New""> authorization server the resource server endpoint address in the<o:p></o:p></span></p>
<p class="MsoNormal" style="page-break-before:always"><span lang="EN" style="font-size:10.0pt;font-family:"Courier New""> authorization process.<o:p></o:p></span></p>
<p class="MsoNormal" style="page-break-before:always"><span lang="EN" style="font-size:10.0pt;font-family:"Courier New""><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">I believe we need to follow this recommendation and require an audience in the access token on at least a SHOULD basis, per the decision on the working group
call today. If anyone disagrees on security grounds, please say why.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> -- Mike<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">P.S. Requiring encryption to restrict the audience seems like SUBSTANTIAL overkill.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">
<a href="mailto:openid-specs-ab-bounces@lists.openid.net">openid-specs-ab-bounces@lists.openid.net</a>
<a href="mailto:[mailto:openid-specs-ab-bounces@lists.openid.net]">[mailto:openid-specs-ab-bounces@lists.openid.net]</a>
<b>On Behalf Of </b>John Bradley<br>
<b>Sent:</b> Thursday, November 10, 2011 6:58 PM<br>
<b>To:</b> Nat Sakimura<br>
<b>Cc:</b> <a href="mailto:openid-specs-ab@lists.openid.net">openid-specs-ab@lists.openid.net</a><br>
<b>Subject:</b> Re: [Openid-specs-ab] Audience restriction of access_token/resource ep response in OpenID Connect<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">With asymmetric keys putting it in the access token works. This is a bit like holder of key confirmation without the TLS.<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">There are a bunch of security issues with symmetric keys. <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">The protected resource has to be closely related to the authorization server, as it can masquerade as the <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Authorization server or the client with the shared secret. <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">You may also need to encrypt the token to the protected resource, otherwise it too could leak and you pare back to square one.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">John B.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">On 2011-11-10, at 8:04 PM, Nat Sakimura wrote:<o:p></o:p></p>
</div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><o:p> </o:p></p>
<p class="MsoNormal"><span class="apple-style-span"><span style="font-size:10.0pt;font-family:"Arial","sans-serif";color:#222222;background:white">Hi. </span></span><o:p></o:p></p>
<div>
<p class="MsoNormal" style="background:white"><span style="font-size:10.0pt;font-family:"Arial","sans-serif";color:#222222"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="background:white"><span style="font-size:10.0pt;font-family:"Arial","sans-serif";color:#222222">Currently, as it turns out in OpenID Connect, the way to audience restrict <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="background:white"><span style="font-size:10.0pt;font-family:"Arial","sans-serif";color:#222222">the response of a resource endpoint is to encrypt the response <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="background:white"><span style="font-size:10.0pt;font-family:"Arial","sans-serif";color:#222222">using the key of the intended client. The server has to keep track of <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="background:white"><span style="font-size:10.0pt;font-family:"Arial","sans-serif";color:#222222">to whom the access_token was issued, i.e., client audience restriction, <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="background:white"><span style="font-size:10.0pt;font-family:"Arial","sans-serif";color:#222222">and use the registration information of that client to find out the relevant key. <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="background:white"><span style="font-size:10.0pt;font-family:"Arial","sans-serif";color:#222222"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="background:white"><span style="font-size:10.0pt;font-family:"Arial","sans-serif";color:#222222">By doing so, even if the request comes from a rogue party who phished the <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="background:white"><span style="font-size:10.0pt;font-family:"Arial","sans-serif";color:#222222">legitimate client, the rogue party cannot read the response, so it is secure. <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="background:white"><span style="font-size:10.0pt;font-family:"Arial","sans-serif";color:#222222"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="background:white"><span style="font-size:10.0pt;font-family:"Arial","sans-serif";color:#222222">As to the resource endpoint audience restriction is concerned, <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="background:white"><span style="font-size:10.0pt;font-family:"Arial","sans-serif";color:#222222">it is done implicitly in the sense that as the access_token is opaque, <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="background:white"><span style="font-size:10.0pt;font-family:"Arial","sans-serif";color:#222222">only the intended endpoint can actually interprete and validate it. <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="background:white"><span style="font-size:10.0pt;font-family:"Arial","sans-serif";color:#222222">This is how the resource endpoint audience restriction is done <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="background:white"><span style="font-size:10.0pt;font-family:"Arial","sans-serif";color:#222222">in OAuth 2.0 as I understand. <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="background:white"><span style="font-size:10.0pt;font-family:"Arial","sans-serif";color:#222222"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="background:white"><span style="font-size:10.0pt;font-family:"Arial","sans-serif";color:#222222">As it is written right now, how to record both client and resource endpoint <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="background:white"><span style="font-size:10.0pt;font-family:"Arial","sans-serif";color:#222222">audience restriction is an implementation detail. <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="background:white"><span style="font-size:10.0pt;font-family:"Arial","sans-serif";color:#222222">I think it should remain implementation detail, but <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="background:white"><span style="font-size:10.0pt;font-family:"Arial","sans-serif";color:#222222">it is worthwhile to note that somehow the audience restriction MUST be done. <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="background:white"><span style="font-size:10.0pt;font-family:"Arial","sans-serif";color:#222222">I am ok with RECOMMENDing that these audience to be encoded <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="background:white"><span style="font-size:10.0pt;font-family:"Arial","sans-serif";color:#222222">in the access_token itself, but would like to let the implementors have <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="background:white"><span style="font-size:10.0pt;font-family:"Arial","sans-serif";color:#222222">choices on it. <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<p class="MsoNormal">-- <br>
Nat Sakimura (=nat)<o:p></o:p></p>
<div>
<p class="MsoNormal">Chairman, OpenID Foundation<br>
<a href="http://nat.sakimura.org/" target="_blank">http://nat.sakimura.org/</a><br>
@_nat_en<o:p></o:p></p>
</div>
<p class="MsoNormal"><br>
_______________________________________________<br>
Openid-specs-ab mailing list<br>
<a href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><o:p></o:p></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</body>
</html>