[Openid-specs-ab] UserInfo Request

Richer, Justin P. jricher at mitre.org
Mon Oct 17 02:10:25 UTC 2011

Nothing that is currently enabled by the MAC spec, and at the moment nothing within scope of Connect. Having your query/form parameters signed by a secret key as a second layer of assurance (above server-side SSL) is a very handy thing indeed, and we've been using 2-legged OAuth 1.0 to do just that for years now. But at the moment, the MAC spec only cares about headers and cookies, so we can't pass around short-lived signed URLs to untrusted clients with the new stuff. Still hoping we can work something out that it comes around, but nothing seems to be moving there yet.

In any case, I'm fine with keeping it Bearer, but I wanted to make sure that this was a conscious decision and not a matter of omission.

 -- Justin

From: John Bradley [ve7jtb at ve7jtb.com]
Sent: Saturday, October 15, 2011 10:58 AM
To: Nat Sakimura
Cc: Richer, Justin P.; openid-specs-ab at lists.openid.net
Subject: Re: [Openid-specs-ab] UserInfo Request

I agree with Nat.  So far we have not seen any use case for MAC, that are not more easily acheved with JWT based bearer tokens.

With MAC tokens the only theoretical advantage is that you can store them as a cookie over a non SSL connection.
However you still need to store the per token secret, negating most of the advantage.

If you have a specific use case, that you think is not covered, then please contribute it so we can discuss it.

At the moment for simplicity and interoperability openID Connect is bearer only.

John B.

On 2011-09-29, at 11:00 AM, 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<mailto: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<mailto:openid-specs-ab-bounces at lists.openid.net> [openid-specs-ab-bounces at lists.openid.net<mailto:openid-specs-ab-bounces at lists.openid.net>] On Behalf Of Anthony Nadalin [tonynad at microsoft.com<mailto:tonynad at microsoft.com>]
> Sent: Wednesday, September 28, 2011 10:51 PM
> To: Nat Sakimura
> Cc: openid-specs-ab at lists.openid.net<mailto: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<mailto:sakimura at gmail.com>]
> Sent: Wednesday, September 28, 2011 5:21 PM
> To: Anthony Nadalin
> Cc: openid-specs-ab at lists.openid.net<mailto: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><mailto: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><mailto: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<mailto:Openid-specs-ab at lists.openid.net>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20111017/77786254/attachment-0001.html>

More information about the Openid-specs-ab mailing list