On Wed, Jul 21, 2010 at 5:26 PM, Nat Sakimura <[email protected]> wrote: > Hi Dirk, > > Inline: > > On Tue, Jul 20, 2010 at 9:22 AM, Dirk Balfanz <[email protected]> wrote: >> >> >> On Sun, Jul 18, 2010 at 8:20 AM, Torsten Lodderstedt >> <[email protected]> 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 > > Well, they MAY, but they do not have to. Would not profiling Magic > Signatures so that it does not contain newlines do? >
e.g., base64url_encode(magic_sig_envelope). Downside of course is that it is one more base64url_encode. I really do not have much preference of one over another, but I have some preference on the convergence of the two. -- Nat Sakimura (=nat) http://www.sakimura.org/en/ http://twitter.com/_nat_en _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
