JWKSource when the key is already in sended with the JWS????

[manolo]

Hi there,

I can´t find a way of building a JWKSource that looks in the JWS message itself. I mean; when the public key is already sended in the JWS itself, nor in a URL, nor on disk, nor anywhere else.

FOR EXAMPLE:

{
  "alg": "RS256",
  "jwk": {
    "kty": "RSA",
    "e": "AQAB",
    "use": "sig",
    "kid": "yy_Gbyj0P92sY4rvvszT2eYr8JeAnXxgJZDA3HlLXMg",
    "n": "rxpICWrh-nx0CZj_4kn65w71ee1SHJ3HOksGjsf1veVIDpvN6m6uTzlPtWOtjIL8Yk-Q-YgMCUr_xXDiHr3D8QZ8wwER6hZnG2ZIaVfFSbCWSqufyBXneGFjo8tpXB3kHLGJTW56vFSeO8DiK8J4PrHJ20t4UKv5juYTHKK7_hE"
  }
}

So I managed to do in this way:

SignedJWT inJwt = SignedJWT.parse(s);
JWK inJwk = inJwt.getHeader().getJWK();
JWKSet jwkSet = new JWKSet(inJwk);
JWKSource<SecurityContext> jwkSource = new ImmutableJWKSet<SecurityContext>(jwkSet);
JWSKeySelector<SecurityContext> keySelector = new JWSVerificationKeySelector<SecurityContext>(JWSAlgorithm.RS256, jwkSource);
ConfigurableJWTProcessor<SecurityContext> jwtProcessor = new DefaultJWTProcessor<SecurityContext>();
jwtProcessor.setJWSKeySelector(keySelector);
SecurityContext ctx = null; // optional context parameter, not required here
JWTClaimsSet inClaim = jwtProcessor.process(s, ctx);

Am i missing something? Has sense? Any other better approach?

What I would like is something like this:

JWKSource<SecurityContext> jwkSource = new InboundJWS();

[Connect2id OSS]

You could also pass the JWK via the SecurityContext.

But why do you establish the verification key like this? Anyone could manufacture a JWT with a JWK inside, and the recipient will always deem it valid.

[manolo]

yes, but if the message is also encrypted?

[Connect2id OSS]

The encryption only ensures the message is confidential, but doesn't guarantee that its source. Esp. if you use public key encryption (RSA, EC).

[manolo]

My plan is to encrypt with symetric.

So, I sign with private putting the public in the Header itself. Then encrypt with symetric.

My final plan is not to have a server dedicated to key interchange between parties...

[Connect2id OSS]

In that case the digital signature is completely redundant.

All encryption in JWE is authenticated, which means that the message is encrypted and integrity protected.

The digital signature is meant to provide non-repudiation, but since you're delivering the signing key with the JWT, that doesn't make much sense.

http://connect2id.com/products/nimbus-jose-jwt/algorithm-selection-guide

[Connect2id OSS]

In other words, anyone who has the symmetric key can define a signing JWK.

So essentially you only control the symmetric (shared) key in your app (or protocol).

[manolo]

Ohh thanks.

The point is that there is no "no repudiation" in my scenario...

[Connect2id OSS]

Closing the ticket, use case not needed.