In my write-up, I'm saying that if you provide the shared key and you don't care about rotating it, then the verifier can ignore the key_id (the issuer would presumable not include the key_id). Same for public keys - if you upload them out of band and you don't think you'll ever change them, then the key_id is not necessary. I would argue that either of those practices is not advisable (despite the fact that we've all been doing it for OAuth 1), so I think the key_id is useful.
Dirk. On Tue, Jun 22, 2010 at 1:45 PM, David Recordon <record...@gmail.com> wrote: > Hey Dick, in answering my questions you made my point. If keys are > managed out of band – as is done in OAuth 1.0 and what was done in the > OAuth 2.0 Core spec until signatures were extracted – then having a > key id is not needed. I certainly understand what they're used for, > but don't find them relevant as part of the OAuth conversation today. > > And yes, Applied Cryptography is worth reading. :) > > --David > > > On Tue, Jun 22, 2010 at 12:59 PM, Dick Hardt <dick.ha...@gmail.com> wrote: > > 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 <record...@gmail.com> > > 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 <dick.ha...@gmail.com> > 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 > >> > <tony...@microsoft.com> > >> > 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: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On > Behalf > >> >> Of > >> >> Brian Eaton > >> >> Sent: Tuesday, June 22, 2010 9:43 AM > >> >> To: Dick Hardt; hannes.tschofe...@gmx.net > >> >> Cc: OAuth WG > >> >> Subject: Re: [OAUTH-WG] proposal for signatures > >> >> > >> >> On Tue, Jun 22, 2010 at 7:17 AM, Dick Hardt <dick.ha...@gmail.com> > >> >> 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 > >> >> OAuth@ietf.org > >> >> https://www.ietf.org/mailman/listinfo/oauth > >> >> > >> > > >> > > >> > _______________________________________________ > >> > OAuth mailing list > >> > OAuth@ietf.org > >> > https://www.ietf.org/mailman/listinfo/oauth > >> > > >> > > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
