For the end to end security, possible approach is to encrypt the response using client's key.†<div><br></div><div>=nat<br><br><div class="gmail_quote">On Fri, Sep 30, 2011 at 1:51 AM, John Bradley <span dir="ltr"><<a href="mailto:ve7jtb@ve7jtb.com">ve7jtb@ve7jtb.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div style="word-wrap:break-word">Hi Fulup,<div><br></div><div>That is true. †However if there is a vulnerability between the IdP's SSL accelerators and the web server then they have real problems.</div>
<div><br></div><div>I am guessing at that point the attacker can just sniff the response. †It adds lots of complexity in maintaining the secrets and signing the request elements (a problem for OAuth 1.1) for a small security gain.</div>
<div><br></div><div>I also have it from a number of large providers that they will not support MAC tokens, due to bad interoperability experiences.</div><div><br></div><div>If we do add MAC token support it would need to be optional. †That reduces the value as well.</div>
<div><br></div><div>I do think there is value in knowing who is sending the request. †That however is not part of the MAC token profile, other than perhaps as theatre.†</div><div><br></div><div>I do think more work needs to go into OAuth after the current spec is finalized, †If something that openID Connect can take advantage of comes out, then we should adopt it.</div>
<div><br></div><div>However I am still unconvinced MAC tokens add any real value to Connect.</div><div><br></div><div>It isn't like I have never been wrong about this stuff so I am interested in counter ideas.</div><div>
<br></div><div>John B.</div><div><br></div><div><br><div><div>On 2011-09-29, at 12:56 PM, Fulup Ar Foll wrote:</div><br><blockquote type="cite">

  
    
  
  <div text="#000000" bgcolor="#ffffff">
    John,<br>
    <br>
    While I agree with you on the principal, we cannot ignore that many
    telco grade sites brake SSL with dedicated hardware before web
    servers, in which case both SSL+Signing can make sense. This being
    said it would be again "keep it simple" principle. <br>
    <br>
    Fulup<div><div></div><div class="h5"><br>
    <br>
    On 29/09/2011 17:07, John Bradley wrote:
    <blockquote type="cite">
      <pre>Yes but as that is a direct request that should be over SSL in Connect, signing is not adding anything other than complexity.

John
On 2011-09-29, at 11:59 AM, Justin Richer wrote:

</pre>
      <blockquote type="cite">
        <pre>Since most stuff in Connect is packed inside of the token, yes, I agree.
But MAC does allow for signing of all of the parameters of an HTTP
request with a per-token secret.

-- justin

On Thu, 2011-09-29 at 10:00 -0400, Nat Sakimura wrote:
</pre>
        <blockquote type="cite">
          <pre>As far as I understand, it was both for the simplivity and
interoperability. Besides, MAC does not add much in termd og
security. 

2011/09/29 22:40 "Richer, Justin P." <a href="mailto:jricher@mitre.org" target="_blank"><jricher@mitre.org></a>:
</pre>
          <blockquote type="cite">
            <pre>Sorry if this has been covered before, but am I missing why MAC or
</pre>
          </blockquote>
          <pre>some other OAuth2-bound token can't be used in OpenID Connect? Is it
for the sake of simplicity ("just pick one") or interoperability ("...
and stick with it"), or is something else strongly binding to the
Bearer spec?
</pre>
          <blockquote type="cite">
            <pre>-- Justin
________________________________________
From: <a href="mailto:openid-specs-ab-bounces@lists.openid.net" target="_blank">openid-specs-ab-bounces@lists.openid.net</a>
</pre>
          </blockquote>
          <pre>[<a href="mailto:openid-specs-ab-bounces@lists.openid.net" target="_blank">openid-specs-ab-bounces@lists.openid.net</a>] On Behalf Of Anthony
Nadalin [<a href="mailto:tonynad@microsoft.com" target="_blank">tonynad@microsoft.com</a>]
</pre>
          <blockquote type="cite">
            <pre>Sent: Wednesday, September 28, 2011 10:51 PM
To: Nat Sakimura
Cc: <a href="mailto:openid-specs-ab@lists.openid.net" target="_blank">openid-specs-ab@lists.openid.net</a>
Subject: Re: [Openid-specs-ab] UserInfo Request

I think itís confusing the way it reads as it does not give me an
</pre>
          </blockquote>
          <pre>option to use the OAUTH Core, so how would I know????
</pre>
          <blockquote type="cite">
            <pre>From: Nat Sakimura [<a href="mailto:sakimura@gmail.com" target="_blank">mailto:sakimura@gmail.com</a>]
Sent: Wednesday, September 28, 2011 5:21 PM
To: Anthony Nadalin
Cc: <a href="mailto:openid-specs-ab@lists.openid.net" target="_blank">openid-specs-ab@lists.openid.net</a>
Subject: Re: [Openid-specs-ab] UserInfo Request

I think it does. OAuth allows access_token to be used in HTTP
</pre>
          </blockquote>
          <pre>header, GET param, and POST param (body), and the text goes "Access
tokens sent in the authorization header must be Bearer
tokens<a href="http://openid.net/specs/openid-connect-standard-1_0.html#OAuth.2.0.Bearer" target="_blank"><http://openid.net/specs/openid-connect-standard-1_0.html#OAuth.2.0.Bearer></a>[OAuth.2.0.Bearer]. If the client is using the HTTP GET method, it SHOULD send the access token in the authorization header." so it is saying:
</pre>
          <blockquote type="cite">
            <pre>1. If the access_token is sent in the HTTP header, it has to use the
</pre>
          </blockquote>
          <pre>Bearer tokens scheme.
</pre>
          <blockquote type="cite">
            <pre>2. If the request is GET, it has to use HTTP header to send the
</pre>
          </blockquote>
          <pre>access_token.
</pre>
          <blockquote type="cite">
            <pre>(3. Implicitly, because OAuth allows - do as the OAuth says for the
</pre>
          </blockquote>
          <pre>POST, i.e., Body.)
</pre>
          <blockquote type="cite">
            <pre>Are you suggesting that we should add 3. so that people does not
</pre>
          </blockquote>
          <pre>have to read OAuth.2.0.Bearer?
</pre>
          <blockquote type="cite">
            <pre>=nat


On Thu, Sep 29, 2011 at 7:27 AM, Anthony Nadalin
</pre>
          </blockquote>
          <pre><<a href="mailto:tonynad@microsoft.com" target="_blank">tonynad@microsoft.com</a><a href="mailto:tonynad@microsoft.com" target="_blank"><mailto:tonynad@microsoft.com></a>> wrote:
</pre>
          <blockquote type="cite">
            <pre>In <a href="http://openid.net/specs/openid-connect-standard-1_0.html#anchor19" target="_blank">http://openid.net/specs/openid-connect-standard-1_0.html#anchor19</a>
</pre>
          </blockquote>
          <pre>it does not call out the use of the body as an option for the access
token, since access tokens can get large there may be issues using
only the header, the bearer token specification allows usage of the
body, so should the openid standard specification.
</pre>
          <blockquote type="cite">
            <pre>_______________________________________________
Openid-specs-ab mailing list

</pre>
          </blockquote>
          <pre><a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.net</a><a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank"><mailto:Openid-specs-ab@lists.openid.net></a>
</pre>
          <blockquote type="cite">
            <pre><a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a>



--
Nat Sakimura (=nat)
Chairman, OpenID Foundation
<a href="http://nat.sakimura.org/" target="_blank">http://nat.sakimura.org/</a>
@_nat_en

</pre>
          </blockquote>
          <pre></pre>
        </blockquote>
        <pre>_______________________________________________
Openid-specs-ab mailing list
<a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.net</a>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a>
</pre>
      </blockquote>
      <pre></pre>
      <pre><fieldset></fieldset>
_______________________________________________
Openid-specs-ab mailing list
<a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.net</a>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a>
</pre>
    </blockquote>
    <br>
    <br>
    </div></div><pre cols="72">-- 
Tel:  0950.770.585
Mail: <a href="mailto:fulup@fridu.net" target="_blank">fulup@fridu.net</a>
<a href="http://www.fridu.org/fulup" target="_blank">http://www.fridu.org/fulup</a>
</pre>
  </div>

</blockquote></div><br></div></div><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" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br>Nat Sakimura (=nat)<div>Chairman, OpenID Foundation<br><a href="http://nat.sakimura.org/" target="_blank">http://nat.sakimura.org/</a><br>@_nat_en</div><br>

</div>