Hi Brian,
On 16 Mar 2010, at 10:51 AM, Brian Eaton wrote:
> We didn't talk about the signed identity claims use case. Some
> background on that is in this thread:
>
> http://www.ietf.org/mail-archive/web/oauth/current/msg00530.html
>
> Paul - does OpenSocial still need signed identity claims?
>
Hello..
Is there any interest in being able to respond with multiple
oauth_verification_url values? I can forsee the possibility of the
Authorization Server being able to support browser-based user verification
(http/https) or text messages (assuming we could authenticate the user on
sending
I would imagine that things like Content-Length: , Content-Encoding: and
Cache-Control: would be targets for attacks if they were not protected.
There are also a lot of custom X- headers out there with unknown semantics.
BTW, another advantage of TLS is that it handles integrity of the HTTP
respo
>Would you care if some proxy or other intermediary changed the contents of
>>the Authorization HTTP header?
In OAuth 1.0 the oauth_ parameters can be transmitted in the HTTP Authorization
header - this is one of the options (and is the preferred one). In that case
protection of the Authoriza
Here is one of the original writeups of OpenSocial + 2LO with a scanned
napkin drawing :-)
http://sites.google.com/site/oauthgoog/2leggedoauth/2opensocialrestapi
On Tue, Mar 16, 2010 at 11:12 AM, David Recordon wrote:
> Kevin Marks has been bugging me for awhile to understand how
> OpenSocial ma
On Tue, Mar 16, 2010 at 11:12 AM, David Recordon wrote:
> Kevin Marks has been bugging me for awhile to understand how
> OpenSocial makes use of two-legged OAuth. I reached out to the team
> and here's their description (via Evan Gilbert). In general it seems
> like they're more making use of OA
Kevin Marks has been bugging me for awhile to understand how
OpenSocial makes use of two-legged OAuth. I reached out to the team
and here's their description (via Evan Gilbert). In general it seems
like they're more making use of OAuth's RSA signature mechanism rather
than the user authorization
SGTM -- I think the tradeoff is interoperable and simple hop-based integrity
protection (assuming existing TLS libraries exist) vs. more complicated but
full end to end integrity protection (and libraries need to be written).
On Tue, Mar 16, 2010 at 7:11 AM, Torsten Lodderstedt <
tors...@lodderste
FYI, the room for our session on Monday has been changed from California
B to Redondo. Please make a note of this if you will be in Anaheim!
/psa
Original Message
Subject: OAUTH - Requested session has been scheduled for IETF 77
Date: Tue, 16 Mar 2010 10:57:39 -0700 (PDT)
From:
On Mon, Mar 15, 2010 at 3:50 PM, Torsten Lodderstedt
wrote:
> Hi all,
>
> I composed a detailed summary at
> http://trac.tools.ietf.org/wg/oauth/trac/wiki/SignaturesWhy. Please review
> it.
We didn't talk about the signed identity claims use case. Some
background on that is in this thread:
http
Thanks Thorsten, this is good.
The "Pro Signature" section seemed a little thin to me (pro HTTPS too,
though most security pros are included obliquely in the "Powerful"
bullet). I changed the "Pro Signature" section to:
* Low latency and computational costs (HMAC)
* Provides for authentication
Hi John,
following your arguments, I could add "integrity protection of complete
HTTP requests in an interoperable way" the the "pro HTTPS" section?
regards,
Torsten.
Am 16.03.2010 07:22, schrieb John Panzer:
I'm confused by one "pro" for signatures:
"Protect integrity of whole request - au
On Mar 16, 2010, at 8:48 AM, Igor Faynberg wrote:
> That's what I have been thinking. Why is it important to sign the headers?
> (I am not against signing them, but I cannot see the need in the specific
> cases we had discussed. In other words, if I had signed the body of the
> request, I prob
I think signing Authorization Headers would make sense.
regards,
Torsten.
Am 16.03.2010 07:48, schrieb Igor Faynberg:
That's what I have been thinking. Why is it important to sign the
headers? (I am not against signing them, but I cannot see the need in
the specific cases we had discussed. In
14 matches
Mail list logo
