On Sun, Jul 18, 2010 at 8:20 AM, Torsten Lodderstedt
<tors...@lodderstedt.net <mailto: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
I mean, what is the reason for including issuer, not_before, not_after
and audience into a signature?
- 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").
Such a system will work for a relatively static relation between client
and server only. Do you suggest a client should register with every
resource server in advance?
What about dynamic clients? Suppose a client is just configured with a
URL pointing to a PortableContacts resource. The client discovers the
respective authz server and obtains a token. What if the client wants to
sign the messages to the resource server?
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.
I think we can do more. Even installed applications can use signatures
to protect messages on transport. What about that use case? Clearly they
need appropriate key material. The token secret issued by the
authorization server could server that purpose.
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?
regards,
Torsten.
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
