Jwks Keys without use parameter

[sagarshah1983]

Hello everyone,
We are using Hydra 1.9.
We have one oauth client registered as follows. Using this client, we are trying to get access token using client credentials flow with private key jwt method.

{
    "client_id": "31386382-2423-4116-a7bd-1af1c94c144b",
    "client_name": "service client app",
    "redirect_uris": [],
    "grant_types": [
        "client_credentials"
    ],
    "response_types": [
        "token"
    ],
    "scope": "openid fhirUser launch/patient offline_access system/*.read system/Provenance.read system/Procedure.read system/PractitionerRole.read system/Practitioner.read system/Patient.read system/Organization.read system/Observation.read system/MedicationStatement.read system/MedicationRequest.read system/Medication.read system/Location.read system/Immunization.read system/Group.write system/Group.read system/Goal.read system/Encounter.read system/DocumentReference.read system/DiagnosticReport.read system/Device.read system/Condition.read system/CareTeam.read system/CarePlan.read system/AllergyIntolerance.read",
    "audience": [
        "https://fhir-qa-1.test.yourcareuniverse.net/tenant/7db7dfb5-2f73-4b96-bcf1-131410518850"
    ],
    "owner": "service client app",
    "policy_uri": "",
    "allowed_cors_origins": [],
    "tos_uri": "",
    "client_uri": "",
    "logo_uri": "",
    "contacts": [],
    "client_secret_expires_at": 0,
    "subject_type": "public",
    "jwks_uri": "https://inferno.mhdidevxasayd.com/inferno/.well-known/jwks.json",
    "jwks": {},
    "token_endpoint_auth_method": "private_key_jwt",
    "token_endpoint_auth_signing_alg": "ES384",
    "userinfo_signed_response_alg": "none",
    "created_at": "2021-08-11T22:12:00Z",
    "updated_at": "2021-08-11T22:11:59.898059Z",
    "metadata": {
        "external": true
    }
}

As shown above, here's the public keys located.
https://inferno.healthit.gov/inferno/.well-known/jwks.json

When we call token endpoint using the client_assertion, we are seeing this error.
Request:

client_assertion=eyJ0eXAiOiJKV1QiLCJhbGciOiJFUzM4NCIsImtpZCI6IjRiNDlhNzM5ZDFlYjExNWIzMjI1ZjRjZjliZWI2ZDFiIn0.eyJpc3MiOiIzMTM4NjM4Mi0yNDIzLTQxMTYtYTdiZC0xYWYxYzk0YzE0NGIiLCJzdWIiOiIzMTM4NjM4Mi0yNDIzLTQxMTYtYTdiZC0xYWYxYzk0YzE0NGIiLCJhdWQiOiJodHRwczovL2lkcC1xYS0xLnRlc3QueW91cmNhcmV1bml2ZXJzZS5uZXQvb2F1dGgyL3Rva2VuIiwiZXhwIjoxNjI4ODA2MTM0LCJqdGkiOiI0OTJkZDc2NWUyMWE3MzY4NDZlZmYwYjY2YmRlYmVmMDg2MzZkMWQ1ODNjOTU5MWQ0YWFkYTE5YTQ5OWU1YzFjIn0.wn5Znd-dorfsKamhRwWaEyT-ohAIMDVTCDW-7-dytnCEoVECZBbIbwZMMvEkLZvovjFzuQ7UiPgN0qzJW85tKurGmC4QJDDOkDwQNuV9qnyzec33xExa0Rm2gzan15i6&client_assertion_type=urn%3Aietf%3Aparams%3Aoauth%3Aclient-assertion-type%3Ajwt-bearer&grant_type=client_credentials&scope=system%2FMedication.read%20system%2FAllergyIntolerance.read%20system%2FCarePlan.read%20system%2FCareTeam.read%20system%2FCondition.read%20system%2FDevice.read%20system%2FDiagnosticReport.read%20system%2FDocumentReference.read%20system%2FEncounter.read%20system%2FGoal.read%20system%2FImmunization.read%20system%2FLocation.read%20system%2FMedicationRequest.read%20system%2FObservation.read%20system%2FOrganization.read%20system%2FPractitioner.read%20system%2FProcedure.read%20system%2FProvenance.read

Response:

{
  "error": "invalid_request",
  "error_description": "The request is missing a required parameter, includes an invalid parameter value, includes a parameter more than once, or is otherwise malformed. Unable to find ECDSA public key with use='sig' for kid '4b49a739d1eb115b3225f4cf9beb6d1b' in JSON Web Key Set."
}

So question -
Is use=sig parameter mandatory in the public keys. As per specifications (https://datatracker.ietf.org/doc/html/rfc7517), I see it as an optional field.
Please clarify, how can authentication work with the public keys listed above.
Is this a bug?

Please advise.

Looking forward to hear from you.
Regards,
Sagar

[vinckr]

I can't really comment on the validity of your client_assertion request, but when I read the documentation, it seems the sig parameter is not necessarily mandatory, however, in all the subsequent examples I can see it included.
"use": "sig",
I have also created some keypairs with hydra keys create and they all feature use: sig as well. So you probably need it.

I will see to educate myself a bit more on the use of jwks and especially the part you are having trouble with, but I am fairly certain you need that part.
Did you create the keys with hydra?

[sagarshah1983]

Thank you for your response, @vinckr .
I did not create any keys with hydra as such. we are using an external tool that requires access to our API. That external tool is "inferno" registered with our Hydra instance as a service client.
Keys are provided by inferno. This tool is going to be used as a government certification tool for our solutions.

As I read from the spec, I found this para, which made me think that this field "use" is an optional one.

Other values MAY be used.  The "use" value is a case-sensitive
   string.  Use of the "use" member is OPTIONAL, unless the application
   requires its presence.

Could you please take a look at it once more and see what it may require to make this parameter optional. I also verified that if I add "use"="sig" in these keys and then try token endpoint, it works fine and issues me the access token.

Please let me know, if any further questions.
Appreciate it!

Regards,
Sagar

[sagarshah1983]

Also in my original message, I realized jwks url was incorrect. I have edited original message.
But here's the public jwks url from inferno tool - https://inferno.healthit.gov/inferno/.well-known/jwks.json

[vinckr]

Note the second part of the message:
. Use of the "use" member is OPTIONAL, unless the application requires its presence.
Since you use the public key to verify the signature you need to specify this.
In the Hydra docs it says:

// Use ("public key use") identifies the intended use of
// the public key. The "use" parameter is employed to indicate whether
// a public key is used for encrypting data or verifying the signature
// on data. Values are commonly "sig" (signature) or "enc" (encryption).
//
// required: true
// example: sig
Use string `json:"use,omitempty"`

Unfortunately, it is required. Maybe you can generate the keys with the use parameter in inferno?

[sagarshah1983]

Thanks @vinckr for your quick response. Is it possible to make this parameter as optional (with a new configuration). I am not sure of impact though.
As we don't have any control over inferno tool, which is meant for certification of health care solutions. and it does not allow generating new public keys.

[sagarshah1983]

Use of the "use" member is OPTIONAL, unless the application requires its presence.

Further, my understanding is application in above context is the client application trying to register and authenticate with Authz server

[sagarshah1983]

Thank you for your response, @vinckr .
As I understand now, hydra requires it in the jwks keys. Can we make it as optional though as part of an enhancement in hydra.
I am not certain, if we have any control over inferno keys that being used for certification purpose from the government.

[sagarshah1983]

Also I found this note from Open ID Specs.

 The "use" and "key_ops" JWK members SHOULD NOT be used together;
   however, if both are used, the information they convey MUST be
   consistent.  Applications should specify which of these members they
   use, if either is to be used by the application.

Inferno uses key_ops instead of use. Can that be allowed as an alternative when use is not passed in the input. This can block us on certification criteria.
Appreciate your suggestions on this!

Regards,
Sagar

[vinckr]

Hey @sagarshah1983,
I understand your predicament, and I think if you can somehow use key_ops instead that sounds like a good fix.
Could you open an issue based on this discussion with some info around the problem, what you propose as fix, and if you have any insight, what would need to be changed in Ory Hydra to make it work?

[sagarshah1983]

Sure thing, @vinckr
I will create this as a bug and try to put additional information around it.

[sagarshah1983]

I have created #2681 for the same.
Thank you for looking into it!