[Openid-specs-ab] UserInfo Request

Nat Sakimura sakimura at gmail.com
Thu Sep 29 18:09:38 UTC 2011


For the end to end security, possible approach is to encrypt the response
using client's key.

=nat

On Fri, Sep 30, 2011 at 1:51 AM, John Bradley <ve7jtb at ve7jtb.com> wrote:

> Hi Fulup,
>
> That is true.  However if there is a vulnerability between the IdP's SSL
> accelerators and the web server then they have real problems.
>
> 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.
>
> I also have it from a number of large providers that they will not support
> MAC tokens, due to bad interoperability experiences.
>
> If we do add MAC token support it would need to be optional.  That reduces
> the value as well.
>
> 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.
>
> 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.
>
> However I am still unconvinced MAC tokens add any real value to Connect.
>
> It isn't like I have never been wrong about this stuff so I am interested
> in counter ideas.
>
> John B.
>
>
> On 2011-09-29, at 12:56 PM, Fulup Ar Foll wrote:
>
>  John,
>
> 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.
>
> Fulup
>
>
> On 29/09/2011 17:07, John Bradley wrote:
>
> 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:
>
>
>  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:
>
>  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." <jricher at mitre.org> <jricher at mitre.org>:
>
>  Sorry if this has been covered before, but am I missing why MAC or
>
>  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?
>
>  -- Justin
> ________________________________________
> From: openid-specs-ab-bounces at lists.openid.net
>
>  [openid-specs-ab-bounces at lists.openid.net] On Behalf Of Anthony
> Nadalin [tonynad at microsoft.com]
>
>  Sent: Wednesday, September 28, 2011 10:51 PM
> To: Nat Sakimura
> Cc: openid-specs-ab at lists.openid.net
> Subject: Re: [Openid-specs-ab] UserInfo Request
>
> I think it’s confusing the way it reads as it does not give me an
>
>  option to use the OAUTH Core, so how would I know????
>
>  From: Nat Sakimura [mailto:sakimura at gmail.com <sakimura at gmail.com>]
> Sent: Wednesday, September 28, 2011 5:21 PM
> To: Anthony Nadalin
> Cc: openid-specs-ab at lists.openid.net
> Subject: Re: [Openid-specs-ab] UserInfo Request
>
> I think it does. OAuth allows access_token to be used in HTTP
>
>  header, GET param, and POST param (body), and the text goes "Access
> tokens sent in the authorization header must be Bearer
> tokens<http://openid.net/specs/openid-connect-standard-1_0.html#OAuth.2.0.Bearer> <http://openid.net/specs/openid-connect-standard-1_0.html#OAuth.2.0.Bearer>[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:
>
>  1. If the access_token is sent in the HTTP header, it has to use the
>
>  Bearer tokens scheme.
>
>  2. If the request is GET, it has to use HTTP header to send the
>
>  access_token.
>
>  (3. Implicitly, because OAuth allows - do as the OAuth says for the
>
>  POST, i.e., Body.)
>
>  Are you suggesting that we should add 3. so that people does not
>
>  have to read OAuth.2.0.Bearer?
>
>  =nat
>
>
> On Thu, Sep 29, 2011 at 7:27 AM, Anthony Nadalin
>
>  <tonynad at microsoft.com<mailto:tonynad at microsoft.com> <tonynad at microsoft.com>> wrote:
>
>  In http://openid.net/specs/openid-connect-standard-1_0.html#anchor19
>
>  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.
>
>  _______________________________________________
> Openid-specs-ab mailing list
>
>
>  Openid-specs-ab at lists.openid.net<mailto:Openid-specs-ab at lists.openid.net> <Openid-specs-ab at lists.openid.net>
>
>  http://lists.openid.net/mailman/listinfo/openid-specs-ab
>
>
>
> --
> Nat Sakimura (=nat)
> Chairman, OpenID Foundationhttp://nat.sakimura.org/
> @_nat_en
>
>
>   _______________________________________________
> Openid-specs-ab mailing listOpenid-specs-ab at lists.openid.nethttp://lists.openid.net/mailman/listinfo/openid-specs-ab
>
>
> _______________________________________________
> Openid-specs-ab mailing listOpenid-specs-ab at lists.openid.nethttp://lists.openid.net/mailman/listinfo/openid-specs-ab
>
>
>
> --
> Tel:  0950.770.585
> Mail: fulup at fridu.nethttp://www.fridu.org/fulup
>
>
>
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>
>


-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20110930/7ce481cd/attachment-0001.html>


More information about the Openid-specs-ab mailing list