On Sun, Jul 18, 2010 at 8:20 AM, Torsten Lodderstedt < tors...@lodderstedt.net> wrote:
> Hi Dirk, > > I have some questions concerning your proposal: > > - As far as I understand, the difference to "magic signatures" lays in the > usage of a JSON token carrying issuer, not_before, not_after and audience. > While such properties are important for security tokens (assertions), I > cannot see an advantage of using this format for signatures of HTTP > requests. Would you please explain? > You mean advantage over magic signatures? It's really a similar idea - it's just that magic signatures as is don't quite fit the bill. For example, they have newlines in them: http://salmon-protocol.googlecode.com/svn/trunk/draft-panzer-magicsig-00.html#anchor5 > - Key management > From my point of view, your proposal does cover key management for web > applications using RSA signatures. What about web applications intending to > sign resource server requests using HMAC (for performance reasons)? Do they > need to exchange secrets with the resource server? > Correct - I'm not saying how HMAC keys are being distributed. Presumably, you would use a similar system to what many platform providers use today - you sign up as a developer, and they give you a "developer key" (or "API key"). > What about installed applications (mobile, desktop, set top boxes, gaming > devices)? > I don't think that installed apps can ever authenticate themselves (i.e., prove the statement "I am a copy of the FooBar app"), so I'm not trying to solve that. What we _can_ do is deliver OAuth tokens to an installed app of the user's choice, but the server won't know who received the token - only the user does. > 1) RSA: Do they need to provide their public key on a web server? This > would be an additional requirement for such applications. > 2) HMAC: Same as for web apps, but even harder because either (a) the > installed app has a static secret burned > into source code or (b) it needs to use a protocol for dynamic key > management the resource server has to implement. Is this the plan? > > Remark on ( > https://docs.google.com/document/pub?id=1kv6Oz_HRnWa0DaJx_SQ5Qlk_yqs_7zNAm75-FmKwNo4 > ): > "To obtain an HMAC verification key, the client has to exchange, in an > out-of-band fashion, shared keys with the issuer." > > I assume "client" should be "verifier", shouldn't it? > Yes. Thanks - fixed! Dirk. > > regards, > Torsten. > > Am 16.07.2010 02:43, schrieb Dirk Balfanz: > > Hi guys, > > after reading through the feedback, we did a pass over the OAuth > signature proposals. > > As a reminder, there are three documents: > > - a document (called "JSON Tokens") that just explains how to sign > something and verify the signature: > > http://docs.google.com/document/pub?id=1kv6Oz_HRnWa0DaJx_SQ5Qlk_yqs_7zNAm75-FmKwNo4 > > - an extension of JSON Tokens that can be used for signed OAuth tokens: > > http://docs.google.com/document/pub?id=1JUn3Twd9nXwFDgi-fTKl-unDG_ndyowTZW8OWX9HOUU > > - a different extension of JSON Tokens that can be used whenever the spec > calls for an "assertion": > > http://docs.google.com/document/pub?id=1s4kjRS9P0frG0ulhgP3He01ONlxeTwkFQV_pCoOowzc > (When used in the assertion flow, this last token can also be used to do > "2-legged" OAuth) > > A summary of the (scant) changes: > > - we spelled out what we mean by RSA-SHA256.* Ben Laurie *- can you > double-check that that sounds good? > - we decided on unpadded websafe-base64 throughout. > - some changes to parameter names. > - some small changes I might be forgetting now... > > As explained in my message to the previous thread, there is still no > envelope in there to help with encrypted tokens (b/c we don't understand > well enough what the envelopes for encrypted tokens would look like). > > One question: What's the deal with having the signature go first? If you > can explain to me why that is a good idea, I'm happy to oblige. > > Cheers, > > Dirk & Marius. > > > _______________________________________________ > OAuth mailing list > oa...@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth > >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
