David key_ids are used when you need to identify which key to use of all the keys you might have. If you are doing discovery of document that is bound to the identifier of the signer, this is useful. Since OAuth 1.0 did not have discovery and required an out of band key management process, key_ids have little value.
To answer your question, key_ids dont' make sense if the keys are being managed how you describe them. I would suggest that key_ids are not included if public keys are managed independent from how Dirk had described them be discovered. I don't think key_ids make sense for shared secrets as they inherently have an out of band process for sharing them. If you would like to learn more about cryptography, I have found Bruce Schneier's book Applied Cryptography to be pretty educational. Here is a link to the Kindle version: http://www.amazon.com/Applied-Cryptography-Protocols-Algorithms-ebook/dp/B000SEHPK6/ref=kinw_dp_ke?ie=UTF8&m=AG56TWVU5XWC2&qid=1277236054&sr=8-1 -- Dick On Tue, Jun 22, 2010 at 12:20 PM, David Recordon <[email protected]>wrote: > All of the OAuth 1.0 implementations which I'm aware of either have > the server provide a shared secret to the client or the client upload > their public key to the server. > > In the case of the server providing a shared secret to the client, > what would the value of key_id be? > > In the case of a client uploading their public key to the server, what > would the value of key_id be? > > Thanks, > --David > > > On Tue, Jun 22, 2010 at 12:14 PM, Dick Hardt <[email protected]> wrote: > > I could imagine an architecture striving to be efficient, scalable, > > distributed and secure where there are hundreds of servers each with a > > unique private key baked into each server. All the public keys would be > in > > one file. > > Having a key id would help debugging as well as the signer is clearly > > indicating which key should be used. If the signing fails, it could be > the > > key, could be signature calculation, could be ... > > > > The downside of having a key_id seems heavily outweighed by the > advantages > > to me. > > On Tue, Jun 22, 2010 at 10:30 AM, Anthony Nadalin <[email protected] > > > > wrote: > >> > >> > If a server needs to verify, it can literally iterate over all of the > >> > keys associated with the client until it finds the right one. > >> > >> Depends on how the server stored the keys, this can be a very expensive > >> operation w/o a key_id to match/index on > >> > >> -----Original Message----- > >> From: [email protected] [mailto:[email protected]] On Behalf > Of > >> Brian Eaton > >> Sent: Tuesday, June 22, 2010 9:43 AM > >> To: Dick Hardt; [email protected] > >> Cc: OAuth WG > >> Subject: Re: [OAUTH-WG] proposal for signatures > >> > >> On Tue, Jun 22, 2010 at 7:17 AM, Dick Hardt <[email protected]> > wrote: > >> >> Thanks for writing this. A few questions... > >> >> > >> >> Do we need both `issuer` and `key_id`? Shouldn't we use `client_id` > >> >> instead at least for OAuth? > >> > > >> > it is the ID of the key, not the client -- used to rollover keys > >> > >> I don't think key id is necessary, but adding Hannes since he called me > >> crazy for saying that at IIW. =) > >> > >> The average client is going to have very few keys. Probably just 1. > >> 3 at the outside. > >> > >> If a server needs to verify, it can literally iterate over all of the > keys > >> associated with the client until it finds the right one. > >> > >> There is some precedent for this approach: > >> http://support.microsoft.com/kb/906305/en-us. > >> > >> Cheers, > >> Brian > >> _______________________________________________ > >> OAuth mailing list > >> [email protected] > >> https://www.ietf.org/mailman/listinfo/oauth > >> > > > > > > _______________________________________________ > > OAuth mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/oauth > > > > >
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
