Re: [OAUTH-WG] signatures, v2

Nat Sakimura <sakimura@gmail.com> Wed, 21 July 2010 08:50 UTC

DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=mJNIX3GV6Ja1/RsAISs0i8FT+cxCOdLKi7lZQvhItB7KJq1cXhUH9hTB6PzOuije/z InRP6xx4UCtvPUSqB52fv1ymM19XOOTNdRKeQGxBm8OLUmK66v/lGeVqd5/h5U2FGTo3 UaHaS3yWc/RuhIOMGx903V3Bf5sfr3Orz/Quw=
MIME-Version: 1.0
In-Reply-To: <AANLkTiks+y2gUFB1L1qnDnOxmAmiAVmHukSXwXQZu3AU@mail.gmail.com>
References: <AANLkTim7pvrLnQtz4WnDvYVRv0jbWgk3j8uMJj07CsM1@mail.gmail.com> <4C431BA3.2000907@lodderstedt.net> <AANLkTilBFabSRsxshSuBbzbYqwv7MzPbMq-fUBShjX9L@mail.gmail.com> <AANLkTiks+y2gUFB1L1qnDnOxmAmiAVmHukSXwXQZu3AU@mail.gmail.com>
Date: Wed, 21 Jul 2010 17:50:25 +0900
Message-ID: <AANLkTinsk_ZTX8Ugs0SEF1Amzgc-ko+8R_T94cV+JrpE@mail.gmail.com>
From: Nat Sakimura <sakimura@gmail.com>
To: Dirk Balfanz <balfanz@google.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: OAuth WG <oauth@ietf.org>
Subject: Re: [OAUTH-WG] signatures, v2
Precedence: list

On Wed, Jul 21, 2010 at 5:26 PM, Nat Sakimura <sakimura@gmail.com> wrote:
> Hi Dirk,
>
> Inline:
>
> On Tue, Jul 20, 2010 at 9:22 AM, Dirk Balfanz <balfanz@google.com> wrote:
>>
>>
>> On Sun, Jul 18, 2010 at 8:20 AM, Torsten Lodderstedt
>> <torsten@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
>
> 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-WG] signatures, v2 Dirk Balfanz
Re: [OAUTH-WG] signatures, v2 Naitik Shah
Re: [OAUTH-WG] signatures, v2 Dick Hardt
Re: [OAUTH-WG] signatures, v2 Torsten Lodderstedt
Re: [OAUTH-WG] signatures, v2 Dirk Balfanz
Re: [OAUTH-WG] signatures, v2 Nat Sakimura
Re: [OAUTH-WG] signatures, v2 Nat Sakimura
Re: [OAUTH-WG] signatures, v2 Ben Laurie
Re: [OAUTH-WG] signatures, v2 Nat Sakimura
Re: [OAUTH-WG] signatures, v2 Greg Brail
Re: [OAUTH-WG] signatures, v2 Greg Brail
Re: [OAUTH-WG] signatures, v2 Torsten Lodderstedt
Re: [OAUTH-WG] signatures, v2 Dirk Balfanz
Re: [OAUTH-WG] signatures, v2 Dirk Balfanz