Re: [OAUTH-WG] signatures, v2

[Dirk Balfanz <[e-mail]>]

On Sun, Jul 18, 2010 at 8:20 AM, Torsten Lodderstedt <
[e-mail]> 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
> [e-mail]://www.ietf.org/mailman/listinfo/oauth
>
>