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. > On Mar 5, 2015, at 12:34 PM, Hannes Tschofenig <hannes.tschofe...@gmx.net> > wrote: > > Hi John, > > > On 03/05/2015 10:27 AM, John Bradley wrote: >> inline >>> On Mar 5, 2015, at 9:59 AM, Hannes Tschofenig <hannes.tschofe...@gmx.net> >>> wrote: >>> >>> Hi all, >>> >>> I refreshed the PoP key distribution document. No changes to the >>> content of the document. >>> >>> The document contains two questions, namely >>> >>> QUESTION: A benefit of asymmetric cryptography is to allow clients to >>> request a PoP token for use with multiple resource servers. The >>> downside of that approach is linkability since different resource >>> servers will be able to link individual requests to the same client. >>> (The same is true if the a single public key is linked with PoP >>> tokens used with different resource servers.) Nevertheless, to >>> support the functionality the audience parameter could carry an array >>> of values. Is this desirable? >>> >>> >>> Hannes: My view is that we do not want to introduce likability into >>> OAuth via the use of these keys. As such, different keys for different >>> origins. >>> >>> >> John: Having an array increases complexity and decreases privacy by >> allowing RS to link. >> >> Audiance should be a single value. That requires separate keys for >> symmetric, or asymmetric keys provisioned by the AS. >> >> For asymmetric keys provisioned by the client it would be up to the client >> to decide if using the same key for multiple RS makes sense. >> >> It might be that there is a single key provisioned by a MSM in the tpm that >> they want to use for all the connections as that is the most secure, and are >> not concerned with correlation as all the RS are internal to a single >> enterprise. >> > > OK. > >> >> >>> QUESTION: Should we register the token_type and alg parameters for use >>> with the dynamic client registration protocol? >>> >>> Hannes: I believe we should register these two parameters into the >>> dynamic client registration protocol since that allows us to configure >>> the values for the client rather than exchanging them with every message. >>> >> John: Yes I had assumed that that was a no brainer. >> The other question on registering is if we should allow the client to >> preregister a public key as well. >> In some situations the client may want to always use the same key and making >> them push it each time is a waste of bandwidth. > The dynamic client registration already supports the feature of > uploading a public key to the authorization server and hence the missing > feature to support that case is to allow the client to refer to that key > somehow. I assume that the public key uploaded by the dynamic client > registration protocol is referenced using a URI. The question is just > what that URI would be. > > Unfortunately, the Dynamic Client Registration spec is silent about how > to reference the public key uploaded via the jwks parameter. Did we just > found a bug in the spec? > > Ciao > Hannes > > >> >> John B. >>> Feedback appreciated before the submission deadline. >>> >>> Ciao >>> Hannes >>> >>> _______________________________________________ >>> 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
