'NoneType' object is not subscriptable error when jwk is empty

[barbj]

I was running an OP certification test with HS256. I provided a jwk url, but shouldn't have. When you invoked the jwk url endpoint, it gave you this output: $ curl -k https://169.53.42.115/oidc/endpoint/OP/jwk {"keys":[null,null]} Because of this, when I ran most of the OP:code tests, I got the following error:

status=ERROR, message='NoneType' object is not subscriptable

OP-Response-Missing and OP-Response-code would work. The first test that would fail was OP-IDToken-C-Signature (and then a bunch more).

The tests should account for this error and provide a better message.

[zandbelt]

For the record: to pass OIDC certification you'll need to support RS256 anyway. I agree that error handling around JWKs URI processing should be improved.

[panva]

For the record: to pass OIDC certification you'll need to support RS256 anyway. I agree that error handling around JWKs URI processing should be improved.

This is only the case for the Dynamic OP profile.

But.

Signing ID Tokens with RSA SHA-256 OPs MUST support signing ID Tokens with the RSA SHA-256 algorithm (an alg value of RS256), unless the OP only supports returning ID Tokens from the Token Endpoint (as is the case for the Authorization Code Flow) and only allows Clients to register specifying none as the requested ID Token signing algorithm.

With the above from Core 1.0 and checking OP-IDToken-RS256 in the profiles it seems the Hybrid and Implicit profile should have a y too.

@selfissued thoughts?

[zandbelt]

For the record: to pass OIDC certification you'll need to support RS256 anyway. I agree that error handling around JWKs URI processing should be improved.

This is only the case for the Dynamic OP profile.

The text you pasted above about "Signing ID Tokens with RSA SHA-256" leads to the conclusion that an OP supporting anything else than the combination of "none" and Authorization Code, will have to support RS256, regardless of the Dynamic OP profile.

[panva]

An OP supporting only response types not issuing id tokens from authorization_endpoint (code, code token, none) may not in general have RS256 capability.

In terms of certification given that both response types (for implicit) and all three (for hybrid) must be supported you're right (see my previous comment last part).

So if an OP only supports code, code token, none he can only certify BASIC, but should still be able to not have RS256.

[zandbelt]

I meant to say that the text implies (with the two references of the word "only" in there) that an OP supporting HS256 must also support RS256 (since HS256 != none). We should probably discuss this on the next call.

[panva]

and only allows Clients to register specifying none as the requested ID Token signing algorithm.

you're right...

[selfissued]

The requirement to support RS256 that Hans cited comes from http://openid.net/specs/openid-connect-core-1_0.html#ServerMTI.

We agree that the error handling for empty key sets should be improved but a conformant implementation can't have an empty key set.

[barbj]

Hi Filip,

Yes, I understand that. My point is that I spent hours trying to figure out what was going wrong and could only figure it out by sending an email to get the stack from the RP.

I'm just kicking the tires right now because there are a whole slew of things that I can't do because:

I haven't been able to install the SSL certificate for my OP on your RP has had a ripple effect of not being able to use SSL for absolutely anything.

My runtime will only publish the https endpoints in the discovery. Because your RP is unable to use my https endpoints, I have to fill out that awful list of properties, and sometimes I get the values wrong. When I've set the value wrong, I need a message that I can interpret correctly, not something equivalent to an NPE. Does that make sense?

How on earth do I get my SSL certificate installed on your RP? I sent an email about this on 3/29, then had an email exchange about it with Hanz earlier this month.

I must be missing something obvious because you can't call any https token (or userinfo) endpoint without the SSL certificate for the OP on your RP. Since you have multiple OPs certified, there must be some way to get that certificate installed. Can you please share that method with me? Perhaps a link to a web page that says how to do it? An email address of someone who is responsible for doing it?

Please help me out. Am I somehow asking for something out of the ordinary?

Regards, Barbara Jensen WebSphere WS-Security and Single Sign-On

[panva]

Hello Barbara,

I believe there are now multiple questions in this thread.

the empty jwks_uri json response

See a response from @selfissued

We agree that the error handling for empty key sets should be improved but a conformant implementation can't have an empty key set.

That is unless you only certify for the Basic profile with none as the only id_token_signed_response_alg option. Since you mentioned HS256 as an option in order to certify the spec and certification profile dictates you also support RS256 signing for interoperability reasons.

How can the Test Suite connect to your OP?

For one, your instance must be reachable from the certification servers. Currently https://169.53.42.115/ closes unexpectedly.

Easiest option is to have your OP use a valid accepted certificate issued by a generally trusted RCA.

If that's not an option there's an insecure option for your OP instance configuration that you can check that will make the suite ignore TLS errors, essentially allowing you to run a self-signed certificate.

If your provider exposes the discovery endpoint then check Dynamic Provider Information Discovery in addition to the Insecure one and a big chunk of the "horrible list" will go away.

NB:

Since you have multiple OPs certified, there must be some way to get that certificate installed.

I never installed any certificates on the test servers in order to run the suite.

[barbj]

Hi Filip, thanks for your quick reply. Here are my thoughts: ==> We agree that the error handling for empty key sets should be improved but a conformant implementation can't have an empty key set.

I understand that you can't have an empty key set. It was an error when entering the parameters that I had to fix, but, like I said, I did not know what the error was in order to fix it because the message I received made no sense. When I received the response about what the error was, the guy asked me to write a github issue on the subject to fix up the error processing; this wasn't my decision.

==> For one, your instance must be reachable from the certification servers. Currently https://169.53.42.115/ closes unexpectedly.

Currently, my endpoint closes unexpectedly because the server that I was using was decommissioned because it was inactive for so long while I was waiting to get this issue resolved. Servers outside our firewall cost us $$$ to run, so I can't leave them up for long periods of time. ==> If that's not an option there's an insecure option for your OP instance configuration that you can check that will make the suite ignore TLS errors, essentially allowing you to run a self-signed certificate.

I was already running with the insure option since I had to provide http endpoints. ==> If your provider exposes the discovery endpoint then check Dynamic Provider Information Discovery in addition to the Insecure one and a big chunk of the "horrible list" will go away.

The first thing I tried was discovery, then I hit the SSL issue. I'm almost certain that the next thing I tried was to leave discovery, then just check insecure and there was something that made it not work, but I can't remember what it was. I think that the endpoints in the discovery list were still being used and my endpoints were https, which was the problem. I think if my discovery published http endpoints, that would work, but I'd have to kludge up the code just for certification and then take it out after. I don't think that's the right thing to do.

Our provider's dynamic discovery endpoint publishes only secure endpoints on purpose. We make you jump through hoops to not be secure and I'm currently having to jump through hoops to not be secure.

==> Easiest option is to have your OP use a valid accepted certificate issued by a generally trusted RCA.

If you can tell me which CAs your RP trusts, I'll see if I can do that.

Thanks!

Barbara Jensen WebSphere WS-Security and Single Sign-On

[panva]

If you can tell me which CAs your RP trusts, I'll see if I can do that.

Just assume general population needs to access your https service with no warnings from their browsers. Easiest and free would be https://letsencrypt.org/

Our provider's dynamic discovery endpoint publishes only secure endpoints on purpose.

So the discovery was returning https:// endpoints which weren't accessible. Hopefully once you align the uris with what's accessible you'll be able to check the discovery option again.

[barbj]

Awesome Filip, thanks for your help.

I'll try that when I can get back to it again when I'm out from under the GDPR extravaganza.

Thanks!

Barbara Jensen WebSphere WS-Security and Single Sign-On