Discovery - 3.2 Distinguishing between signature and integrity parameters for HMAC algorithms

Issue #614 resolved
Edmund Jay created an issue

userinfo_algs_supported, id_token_algs_supported, and request_object_algs_supported an array of JWA algorithms for signature, encryption, and integrity. The HMAC algorithms can be used for both "signature" and integrity but currently, there's no way to distinguish for which purpose these algorithms are used for. Do their presence mean that they can be used for both?

Comments (6)

  1. John Bradley

    Currently there presence means that they can be used for both. Currently JWE has alg, enc, and int parameters. They will need to be separated out in discovery for each endpoint if we don't change JWE.

  2. Michael Jones

    For Registration, this is unambiguous, with all these parameters: id_token_signed_response_alg id_token_encrypted_response_alg id_token_encrypted_response_enc id_token_encrypted_response_int userinfo_signed_response_alg userinfo_encrypted_response_alg userinfo_encrypted_response_enc userinfo_encrypted_response_int. In Discovery, this is ambiguous, with only these parameters: id_token_algs_supported userinfo_algs_supported. We will watch decisions in JOSE and then consider whether to make changes.

  3. Michael Jones

    Looking at, I agree that the treatment of advertising supported algorithms is currently inconsistent. The client has fine-grained control with the parameters {userinfo,id_token}_signed_response_alg and {userinfo,id_token}_encrypted_response_{alg,enc,int} whereas the server jumbles the types of algorithms together with the parameters {userinfo,id_token,request_object,token_endpoint}_algs_supported.

    I believe that we should give the server the same degree of control as the client. I would propose these new server parameter names: {userinfo,id_token,request_object,token_endpoint}_signing_alg_values_supported {userinfo,id_token,request_object,token_endpoint}_encryption_{alg,enc}_values_supported

  4. Log in to comment