2010/1/14 Blaine Cook <[email protected]>:
> 2010/1/14 Eran Hammer-Lahav <[email protected]>:
>> QUESTION: Do you prefer:
>>
>> A. Directly processing the HTTP request into a base string for signing
>> (draft-hammer-oauth style).
>> B. Treating the request as an API call with form-encoded parameters (OAuth
>> 1.0 style).
>> C. Converting the request into a normalized message and signing that (Eaton
>> style).
>
> For protocol independence of presenting a token + signed message, (C).
> I wonder if John Panzer's recent proposal for Salmon [1] could be
> adapted to use (C) elegantly? I think Salmon/PSHB is an interesting
> use-case for delegated authorization and subsequent authentication,
> and as such might be a good place to think about approaches like
> Brian's.
On second thought (and after reading Eran's Question #2) I'd like to
clarify this a bit; I like that Brian's proposal makes it flexible to
determine what is to be signed. Including the data twice in the
request is silly; perhaps an approach like Brian's, but with the
"message" part replaced with pointers-to-the-message-parts.
e.g.,
instead of envelope:
{ "name": "source.example.com",
"algorithm": "RSA-SHA256",
"timestamp": 1260253850,
"nonce": "0437f743b5809" }
and message:
{ "url": "http://source.example.com/x/y/z"; }
just include the message-parts in the envelope:
{ "name": "source.example.com",
"algorithm": "RSA-SHA256",
"timestamp": 1260253850,
"nonce": "0437f743b5809",
"message": [ "url" ] }
See my reply to Eran's Question #2 for reasoning.
b.
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
