[Openid-specs-ab] Simplifying preferred_locales and max_age

John Bradley ve7jtb at ve7jtb.com
Sat Feb 2 00:09:58 UTC 2013

I made similar comments in the other thread.

As for moving them to query parameters, I am not keen on a endless string of query parameters, and having two ways to do the saker thing leads to interop issues.

For max_age you don't necessarily want the user to be able to modify that in the request, that might cause security issues if auth_time is not required in the response, the RP may be thinking it is getting a stronger authentication than it is in reality.

I would prefer to leave max_age in the signed request and not confuse the lower security parameter based request with it.

There is no security implication for preferred_locales so I would make that a query parameter, and allow it to be in the request object but not require it.

John B.

On 2013-02-01, at 3:15 PM, Mike Jones <Michael.Jones at microsoft.com> wrote:

> Currently “preferred_locales” and “max_age” are specified as occurring under the “userinfo” and “id_token” elements of the request object.  I would propose moving them up to being top-level elements of the request object, and possibly also allowing them to be used directly as request parameters.  My reasoning is that it makes no practical sense to use different locales for UserInfo claim values versus ID Token claim values.  Likewise, while “max_age” does apply logically to the ID Token, it would cause no confusion to have it apply to the whole request and it could be useful to allow specifying “max_age” as a query parameter.
> One consequence of allowing “preferred_locales” to also be specified as a query parameter is that its syntax would change from a JSON array to a space-separated list of strings.
> If we did this change, it would both simplify the parsing for the MTI Fallback Position described in my previous message (one would just ignore “userinfo” and “id_token” rather than ignoring the “claims” members of “userinfo” and “id_token”) and would enable more important functionality to be used without using the request object, which I think would make many developers happy.
> Thoughts?
>                                                             -- Mike
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20130201/91292e7d/attachment.html>

More information about the Openid-specs-ab mailing list