The kid in the JWT is the most appropriate thing if the iss has reregistered a jwks_uri. If you send a jwks_uri the AS needs to have some trust model to match the "iss" to that jwks_uri that we haven't described for Connect or Oauth at this point.
Mostly we have been sticking to jwks that are pushed durring registration or a jwks_uri that is pushed in registration or discovered based on the iss in Connect discovery. Yes we need discovery for Oauth at some point. The PoP key distribution needs a parameter to pass a kid if you are not passing the key. John B. > On Mar 5, 2015, at 12:51 PM, Justin Richer <jric...@mit.edu> wrote: > > If you're using them for the token endpoint, you set your > token_endpoint_authorization_method to a method that supports it (which we > don't define in OAuth but other protocols and profiles do). Then you'll > usually reference them using the 'kid' field defined in JWK, or you might > just use the only key that's been registered (it's very common for a client > to have only one key), or you might pass the JWK URI directly (in the "jku" > header), or several other methods. If you're using them for some other piece > of interaction (of which there are several defined and in the wild already), > then the same rubric applies. This is all discussed in the JOSE documents, > such as this section in JWS: > > https://tools.ietf.org/html/draft-ietf-jose-json-web-signature-41#appendix-D > <https://tools.ietf.org/html/draft-ietf-jose-json-web-signature-41#appendix-D> > > What we're providing is a hook for higher level protocols, not a > determination of how exactly to use it. All of these uses will reference back > to the client performing the action, which can be correlated to the JWK set > referenced in the registration below. > > -- Justin > > On 3/5/2015 6:37 AM, Hannes Tschofenig wrote: >> Hi Justin, Hi all, >> >> In context of the draft-ietf-oauth-pop-key-distribution-01 update we >> just ran into a question regarding key naming. >> >> The Dynamic Client Registration Protocol defines these two parameters >> that allow a client to upload a public key to the authorization server: >> >> jwks_uri >> URL referencing the client's JSON Web Key Set [JWK] document, >> which contains the client's public keys. The value of this field >> MUST point to a valid JWK Set document. These keys can be used by >> higher level protocols that use signing or encryption. For >> instance, these keys might be used by some applications for >> validating signed requests made to the token endpoint when using >> JWTs for client authentication [OAuth.JWT]. Use of this parameter >> is preferred over the "jwks" parameter, as it allows for easier >> key rotation. The "jwks_uri" and "jwks" parameters MUST NOT both >> be present in the same request or response. >> jwks >> Client's JSON Web Key Set [JWK] document value, which contains the >> client's public keys. The value of this field MUST be a JSON >> object containing a valid JWK Set. These keys can be used by >> higher level protocols that use signing or encryption. This >> parameter is intended to be used by clients that cannot use the >> "jwks_uri" parameter, such as native clients that cannot host >> public URLs. The "jwks_uri" and "jwks" parameters MUST NOT both >> be present in the same request or response. >> >> Now, the question is how these keys are actually referenced? What do I >> need to indicate to select a specific key when I want to use these keys. >> >> Ciao >> Hannes >> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org <mailto:OAuth@ietf.org> >> https://www.ietf.org/mailman/listinfo/oauth >> <https://www.ietf.org/mailman/listinfo/oauth> > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
