[Openid-specs-ab] UserInfo Request

John Bradley ve7jtb at ve7jtb.com
Thu Sep 29 20:04:11 UTC 2011

Yes I think it warrants a mention in security considerations.

We are making good progress on libraries and test deployments.   Our interop at the Summit in California was a good start.

Deploying this stuff always teaches you a lot.


On 2011-09-29, at 4:46 PM, Fulup Ar Foll wrote:

> John,
> I do not disagree with your comment, and the "keep it simple and interoperable" should remain the end goal. 
> In the case of external SSL accelerators some form of "best practice deployment guideline" is probably enough. The only important thing is to make sure that real life deployment scenario are taken in account and implementable.
> Fulup
> On 29/09/2011 18:51, John Bradley 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>:
>>>>>>> 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]
>>>>>>> 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>[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>> 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>
>>>>>>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>>>>>>> --
>>>>>>> Nat Sakimura (=nat)
>>>>>>> Chairman, OpenID Foundation
>>>>>>> http://nat.sakimura.org/
>>>>>>> @_nat_en
>>>>> _______________________________________________
>>>>> Openid-specs-ab mailing list
>>>>> Openid-specs-ab at lists.openid.net
>>>>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>>>> _______________________________________________
>>>> Openid-specs-ab mailing list
>>>> Openid-specs-ab at lists.openid.net
>>>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>>> -- 
>>> Tel:  0950.770.585
>>> Mail: fulup at fridu.net
>>> http://www.fridu.org/fulup
> -- 
> Tel:  0950.770.585
> Mail: fulup at fridu.net
> http://www.fridu.org/fulup

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20110929/e901ac92/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4767 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20110929/e901ac92/attachment-0001.p7s>

More information about the Openid-specs-ab mailing list