What class of attacks is this trying to prevent? I frankly don't see a
problem with confusing different types of JWT. But I may just be
ignorant.
On Thu, Jul 27, 2017 at 2:49 PM, Brian Campbell
wrote:
> During the first WG meeting last week I asked if use of the JOSE "crit"
> (Critical) Header Pa
The draft describes it in
https://tools.ietf.org/html/draft-sheffer-oauth-jwt-bcp-01#section-2.7
On Thu, Jul 27, 2017 at 1:30 PM, Nathaniel McCallum
wrote:
> What class of attacks is this trying to prevent? I frankly don't see a
> problem with confusing different types of JWT. But I may just be
Even after reading the whole section, I still don't understand the
problem. Yes, a class of attack could exist where an attacker
substitutes a valid JWT from one security context into another
context. But isn't this resolved by audience validation?
On Thu, Jul 27, 2017 at 3:34 PM, Brian Campbell
Only if the audience is different.
On Thu, Jul 27, 2017 at 10:00 PM, Nathaniel McCallum
wrote:
> Even after reading the whole section, I still don't understand the
> problem. Yes, a class of attack could exist where an attacker
> substitutes a valid JWT from one security context into another
> c
We have the use case in SECEVENTS where a logout event (e.g. OIDF backchannel
logout) is extremely close to an ID_TOKEN.
Older relying parties who are do not yet support logout could be tricked into
accepting a logout assertion as an ID_TOKEN since they are too similar, and
because a valid ID
Brian: I did not think that 'crit' processing is required in JWT
https://tools.ietf.org/html/rfc7519
We have two goals:
Preventing new JWT profiles from being confused with older JWTs, which
'typ' solves (as does your proposal of 'crit' and 'p', but requires more
bytes)
Preventing existing JWT i
Not that I am against the general desire for JWT not to be confused, but the
attack surface for someone to take a sec event from one context and replay it
as a id_token to login is very small and if the client is correctly configured
would not work as it is now.
The only way you could replay th
Right. And this is precisely what I find strange. We are attempting to
define the differentiation between state transitions without defining
the state transitions themselves.
I want to be clear that I think there is a real need here. But it
seems to me that this need is not well defined. So I'm no
What other JWTs are there?
All JWTs use JWS and/or JWE. So a JWT is a JOSE JWT by definition. JWT
requires 'crit' processing by virtue of using JWS and JWE for signing and
encryption. The extent to which that processing is actually implemented is
a different and fair question but it's normative re
I wouldn't disagree that the issue with Connect is overstated sometimes.
And it's a non-issue with sec event due to the "nonce" claim (as you point
out) as well as the omission of the "exp" claim. Assuming correct
validation anyway.
The BCP draft suggests explicit typing to prevent Cross-JWT Confu
My only concern with a crit header is that it is potentially another layering
violation.
It really should be the application and not JWS/JWE that determines if the
content of the JWT is correct at a application layer.
To get your idea to work the application would need to push down to the JWT
One simple way to implement it would be to have an call which says “I will deal
with the following items if they exist”. This means that all the application
needs to do is to say that it will process p and not what values are acceptable.
Jim
From: jose [mailto:jose-boun...@ietf.org] O
Yeah, I've implemented it in pretty much in the way Jim describes.
In my implementation of JWT validation the application sets things up by
pushing down all the info needed for validation (things like expected
audience & issuer, keys, allowed algorithms, etc.). So I'm probably biased
by that but a
13 matches
Mail list logo
