On Fri, Jan 17, 2020 at 08:44:18AM -0500, Justin Richer wrote:
> I don’t agree with this stance from a security or implementation perspective.
>
> If there’s a clear order of precedence for the information, it’s not
> particularly problematic. Everything inside the request object is to be taken
Definitely; thanks for raising that explicitly.
-Ben
On Fri, Jan 17, 2020 at 04:34:10PM +, Richard Backman, Annabelle wrote:
> We should not be prescriptive about how the AS recognizes request URIs from
> itself. Trusted authority or custom URI scheme are fine as examples, but
> ultimately
In my opinion it's still problematic if an attacker can inject claims that
aren't in the request object.
A simple (albeit OIDC specific) example would injecting prompt=none or a
login_hint, where the request object doesn't have a prompt/login_hint already.
In that case if/when people design pro
I'd be in favor of it.
On Thu, Jan 16, 2020 at 9:28 AM Torsten Lodderstedt wrote:
>
>
> Am 16.01.2020 um 16:48 schrieb Justin Richer :
>
> Maybe PAR and JAR (and JARM?) end up going out as a bundle of specs.
>
>
> Since Justin brought it up, I would like to know whether the community has
> appet
I'd support this (client_id being the only additional query parameter
allowed/required) as well.
FWIW, our AS implementations looks for and requires that the response_type
and client_id parameters be present as regular request parameters. This was
done largely to maintain some semblance of compati
+1 to keeping/using “request_uri”
On Thu, Jan 16, 2020 at 10:49 AM Richard Backman, Annabelle wrote:
> We’ve already defined a request identifier parameter. We called it
> “request_uri”. That’s what the “I” in URI stands for. Let’s just fix the
> semantics on that one. It’s bad enough that we ha
But that’s also the same for parameters in a signed (non-encrypted) request
object.
— Justin
> On Jan 17, 2020, at 11:29 AM, Jim Manico wrote:
>
> It’s actually worse. Parameters in a URL leak over bookmarks, browser
> history, logs everywhere, referrer headers...
>
> One of the most prima
We should not be prescriptive about how the AS recognizes request URIs from
itself. Trusted authority or custom URI scheme are fine as examples, but
ultimately this is an internal implementation of the AS. It could just as
easily be using data URIs containing a symmetrically encrypted database r
It’s actually worse. Parameters in a URL leak over bookmarks, browser history,
logs everywhere, referrer headers...
One of the most primary rules of secure coding on the web is to never put
sensitive data in a URL for •any• verb, not just GET.
--
Jim Manico
@Manicode
Secure Coding Education
+1
I don’t agree with this stance from a security or implementation perspective.
If there’s a clear order of precedence for the information, it’s not
particularly problematic. Everything inside the request object is to be taken
over things outside the request object. We have the exact same semanti
10 matches
Mail list logo
