Clients that share a common client_id can't pre register. You need to be doing per instance dynamic client registration for that to work.
Non confidential clients need to push a key with code, or have it provisioned by the AS with the AT. Sent from my iPhone > On Mar 5, 2015, at 2:04 PM, Hannes Tschofenig <hannes.tschofe...@gmx.net> > wrote: > > Actually, I am not sure my statement below is actually correct. > > We need to distinguish the case where the client id is unique per client > software instance and when it isn't. > > If the client id is shared by multiple client software instances then > how do we make sure that clients aren't uploading keys that either have > no kid or have an kid that is not unique (since they don't know about > the existence of other client instances or that other client instances > have already uploaded a jwk with the same kid). > > Any idea how to address that problem? > > Ciao > Hannes > >> On 03/05/2015 01:43 PM, Hannes Tschofenig wrote: >> Hi John, >> >> that's a good idea. However, the dynamic client registration should >> state that the "kid" parameter is used and must be included in the JWK >> (since the kid is an optional parameter). >> >> The key name is then the 'kid' plus the client id since the value of the >> kid is not unique by itself. >> >> Ciao >> Hannes >> >>> On 03/05/2015 12:54 PM, John Bradley wrote: >>> For signing authentication requests you include the keyid in the JWT, and >>> the AS looks in the JWKS to find the correct key if there is more than one. >>> >>> I don't think that is a problem >>> >>> What we probably need to do is pass a keyid in the request if there is more >>> than one signing key registered for the client. >>> >>> John B. > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
