Agreed - that’s why we disabled request_uri by default and added
extensibility points to implement validation.
I thought it is odd that this was not mentioned in the typical “security
considerations” in the OIDC spec..
———
Dominick Baier
On 16. January 2020 at 08:07:44, Neil Madden
Is it too late to add it to the security considerations for JAR?
— Neil
> On 16 Jan 2020, at 08:15, Dominick Baier wrote:
>
>
> Agreed - that’s why we disabled request_uri by default and added
> extensibility points to implement validation.
>
> I thought it is odd that this was not
The mitigations of 10.4.1 are related, but the section heading is about (D)DoS
attacks. I think this heading needs to be reworded to apply to SSRF attacks too
or else add another section with similar mitigations.
Mitigation (a) is a bit vague as to what an "unexpected location" is. Perhaps
I agree with the IESG reasoning that merging is problimatic. Once we
allow that given a unknown list of possible paramaters with diffrent
security properties it would be quite difficult to specify safely.
Query paramaters can still be sent outside the JAR, but if they are in
the OAuth registry
+1 to this approach, and it sounds like JAR might need to come back to go
through another round anyway thanks to the breaking changes the IESG pushed
into it after it left WGLC.
I’d rather see us get this right than publish something many of us think is
broken.
Maybe PAR and JAR (and JARM?)
I like that idea - although not the 301. But returning the full url seems
like a good idea.
Most of the time PAR will be used on the backend and the user-agent won't
be directly submitting a form - so for the most common use-case a 301 would
cause problems.
On Thu, 16 Jan 2020 at 17:37, Neil
Well that’s what I’m saying — we could have had restrictions within JWK (and
maybe even a different syntax) that would guarantee a unique key ID, as well as
ways to talk about it from the outside.
— Justin
> On Jan 15, 2020, at 3:53 PM, Vladimir Dzhuvinov
> wrote:
>
> On 14/01/2020 04:25,
Thinking of all the new edge cases we'd have to cover, i don't believe its
a good idea, as-is i see it elegant, capable of re-using existing
pipelines, the moment you change the parameter name new edge cases and
conditions start to popup. As an implementer i don't care that JAR says the
Well I don't think PAR is limited to confidential clients, but also there are
client authentication methods that would make sense in this scenario, e.g.
JWT-based client_assertion authentication with a short-lived/replay-protected
JWT.
This cuts out the need for an extra HTTP call on the
I just thought about another option. What if we change PAR to not use the
request_uri parameter but a new parameter, e.g. request_id?
That would decouple both specs. The reason why we use request_uri was to make
the life of clients easier since they can use the standard library function for
Why not have the PAR endpoint return a 30x redirect with the full URL to the
authorization endpoint in the Location header? That way the AS can decide for
itself how to communicate any id from the PAR endpoint to the authorization
endpoint.
This also has the side effect that you can kick off
Right. We could add a security consideration like that, though the
mitigation probably is pretty much the same as what is stated in 10.4.1:
the server should (a) check that
the value of "request_uri" parameter does not point to an unexpected
location, (b) check the content type of the
It is not too late to add to the security considerations.
It seems that the new application/oauth.authz.req+jwt media-type is helpful
in this regard, in that if an AS can require that content-type from
dereferencing the request_uri, then seeing anything else indicates that the
request was bogus
> 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
appetite to standardize JARM as well.
Here is the link to the spec:
I believe just client_id would be sufficient for us, so I'd support a
compromise position in which that is the only additional query parameter
allowed.
-- Neil
> On 16 Jan 2020, at 13:40, John Bradley wrote:
>
> I agree with the IESG reasoning that merging is problimatic. Once we
> allow
A 30x redirect to what is designed to be an authenticated backend client
call? Doesn't seem right to me.
S pozdravem,
*Filip Skokan*
On Thu, 16 Jan 2020 at 17:37, Neil Madden wrote:
> Why not have the PAR endpoint return a 30x redirect with the full URL to
> the authorization endpoint in the
Agree that the heading at least should be changed. I am OK with adding a
dedicated section to describe the possible attacks as well. I was merely
pointing out that the mitigation can be very similar to 10.4.1 and was
asking if there is anything else to be added.
The wording around Mitigation (a)
What you’ve described is exactly what happens in XYZ:
https://oauth.xyz/interaction/
And this is what we’re discussing as the basis in TxAuth. But in this case
since you’re stuck with OAuth 2’s authorization endpoint syntax and semantics,
you’re still limited with what’s happening there and it
On Fri, Jan 17, 2020 at 12:47:45AM +0900, Nat Sakimura wrote:
> Right. We could add a security consideration like that, though the
> mitigation probably is pretty much the same as what is stated in 10.4.1:
>
> the server should (a) check that
>the value of "request_uri" parameter does not
On Thu, Jan 16, 2020 at 04:31:30PM +, Neil Madden wrote:
> The mitigations of 10.4.1 are related, but the section heading is about
> (D)DoS attacks. I think this heading needs to be reworded to apply to SSRF
> attacks too or else add another section with similar mitigations.
>
> Mitigation
I agree with this, particularly the security concerns of merging. If we merge,
we can much guarantee there will eventually be a security issue where an
attacker is able to gain an advantage by adding a parameter to the url query
(which the server would then happily process if that parameter
Hi all,
as part of the standards work on OAuth we have created several registries, see
https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml.
Adding and modifying entries in that registry often requires expert reviewers
to verify changes.
We need volunteers to become expert
22 matches
Mail list logo
