On Thu, Mar 4, 2010 at 10:18 PM, Igor Faynberg <[email protected]> wrote: > The secure channel only delivers a request (or a token). But there is no > proof of authentication (or the means for non-repudiation) in the token > itself, unless the whole session has been recorded (and the key for it has > been stored).
The non-repudiation goal is the most interesting, because it is the only one in your list that is not met by WRAP over https. Non-repudiation can, sort of, be achieved by some OAuth 1.0a deployments. But not most of them. The "token auth" drafts that Eran sent out earlier explicitly remove the client secret from being used to sign resource requests, which would even further restrict the number of OAuth deployments that could claim something resembling non-repudiation. I'd also note that non-repudiation was not a security goal of OAuth 1.0a, and as a consequence probably shouldn't be relied on for non-repudiation. For example, OAuth 1.0a doesn't use a trusted timestamping service; if a key leaks, all documents signed with that key are suspect. There are existing schemes for non-repudiation that may be better suited for your use cases. Have you looked at alternatives to OAuth signing? But I have to admit I'm still unsure of your use cases. For example, do you have three players (client, server, user), or just two (client, server)? Which players are making statements that need the non-repudiation property? Cheers, Brian _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
