Thanks!
On Wednesday, February 10, 2010, Manger, James H
wrote:
> John,
>
> I like your choice of base64url as a way to armour binary data and avoid
> escaping issues.
>
> It might be nicer to sign the bytes that get armoured, instead of the ASCII
> output of the armouring.
> I don't think this
Feedback specific to the Salmon proposal should go to the Salmon list [1].
EHL
[1] http://groups.google.com/group/salmon-protocol/subscribe
> -Original Message-
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
> Of Manger, James H
> Sent: Wednesday, February 10, 2
John,
I like your choice of base64url as a way to armour binary data and avoid
escaping issues.
It might be nicer to sign the bytes that get armoured, instead of the ASCII
output of the armouring.
I don't think this compromises the robustness aim of Magic Signatures.
It would mean you sign the
While I agree with Blain’s conclusion, I would characterize it a bit
differently: there currently is no general consensus as to what the best way to
approach this is, and whether there is value in a generic permission parameter.
My favorite example is health records API in which reading is the m
> -Original Message-
> From: Dick Hardt [mailto:dick.ha...@gmail.com]
> Sent: Wednesday, February 10, 2010 7:53 PM
> How about using draft-hardt-oauth-wrap and adding a section for how the
> Client can sign?
We might end up with something that looks just like that, but your suggestions
> -Original Message-
> From: Greg Brail [mailto:gbr...@sonoasystems.com]
> Sent: Wednesday, February 10, 2010 9:07 PM
> To: Eran Hammer-Lahav; OAuth WG (oauth@ietf.org)
> Subject: RE: [OAUTH-WG] Which draft to use as a starting point for 'using a
> token'?
>
> Like a lot of people, I thi
Like a lot of people, I think, things are moving along and we're trying to keep
up. I do have a few more basic questions.
Like it or not, the concept of a "consumer key" and "access token" is
hard-wired into many developers' perceptions of OAuth, and a major difference
between the two specs is
How about using draft-hardt-oauth-wrap and adding a section for how the Client
can sign?
-- Dick
On 2010-02-04, at 11:28 PM, Eran Hammer-Lahav wrote:
> On the call today I clarified what is going on with all the different drafts.
> In brief:
>
> draft-hammer-oauth - documentation of the OAuth
Thanks for the feedback. That’s what I presumed and I’m glad I wasn’t
missing anything.
For the record, I ended up adding two comma-separated parameters to the
request token request like so:
read_permissions=user&write_permission=accounts,accounts/transactions
[Documentation: https://ironmoney.c
