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
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
