Re: [OAUTH-WG] signatures, v2

[Torsten Lodderstedt <[e-mail]>]

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?

- 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?

What about installed applications (mobile, desktop, set top boxes, 
gaming devices)?
  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?

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]
> https://www.ietf.org/mailman/listinfo/oauth
>