> But I am affraid that origin, referer and hosts of request can be modified by
> a third party.
>
> Am I right ?
In OAuth 1.0a, the HOST HTTP header is included in the OAuth signature (if you
are using the HMAC_SHA1 or RSA_SHA1 signature mechanisms.
Origin and Referer are NOT included by defa
Hey Eran!
On Jan 9, 2010, at 12:12 PM, Eran Hammer-Lahav wrote:
[...] (sure, agreed)
> My proposed language would be along the lines of "MUST use a secure channel
> such as TLS/SSL or another mechanism providing the same protections". This
> allows not using TLS/SSL when the environment provid
On Jan 8, 2010, at 9:15 PM, Eran Hammer-Lahav wrote:
[...]
> Is there a *good* reason why the 1.0 specification should not mandate using
> a secure channel for PLAINTEXT?
I guess the question is whether you want implementations using other methods to
ensure confidentiality and which don't ne
On Oct 3, 2009, at 5:25 PM, beckett wrote:
>
>>> My understading is that I should be able to use PLAINTEXT without
>>> compromising security as long as stick with HTTPS. Is my
>>> understanding
>>> right?
>
> Depends on what you mean by "compromising security".
>
> Say user wants to move data f
On May 6, 2009, at 5:28 PM, Allen Tom wrote:
> Brian Eaton wrote:
>> Use case is consumers and service providers trying to transition to
>> OAuth 1.0a in parallel without creating down time or needing to "all
>> hold hands and jump together".
>
> I still don't quite see the problem. If the issue
On May 6, 2009, at 11:49 AM, Brian Eaton wrote:
[...]
> However, existing clients have hardcoded callback URLs on their
> approval URLs. If the consumer code can detect that the service
> provider supports OAuth 1.0a, it can automatically correct that
> problem by stripping the callback URL off
Before we go off into another discussion of versioning, I'd just like
to reiterate what I and a couple of others mentioned yesterday: OAuth
Core 1.0 does not currently assign any semantics AT ALL to
oauth_version.
It doesn't say that it is linked either to getting an access token OR
using
On May 1, 2009, at 12:02 PM, Breno de Medeiros wrote:
>
> Version 3, where the string literal is supposed to be interpreted as
> "manual entry or out-of-band" exchange of the callback token.
+1
- johnk
>
>
> Version 1 is already supported. There is interest to support some form
> of manual ent
On May 1, 2009, at 12:36 PM, Brian Eaton wrote:
>
> On Fri, May 1, 2009 at 1:25 AM, Blaine Cook wrote:
>> 1. "1.0 Rev A" with no version string change (i.e.,
>> oauth_version=1.0)
>> 2. "1.0a" (with oauth_version=1.0a)
>> 3. "1.1"
>
> Option 1. Version string should not change unless we hate
On Apr 30, 2009, at 12:11 PM, Blaine Cook wrote:
>
> On Thu, Apr 30, 2009 at 4:50 PM, Eran Hammer-Lahav > wrote:
>>> Really, why not bump the version to 1.1? Is there real magic behind
>>> the version number? What's the point of versioning the protocol
>>> if revving
>>> it is painful?
>>
>>
On Apr 29, 2009, at 4:46 PM, Brian Eaton wrote:
>
>> ii) Is the intent of the oauth_verifier to prevent the possibility of
>> a similar redirect break between acquiring the authorized request
>> token and getting the access token?
>
> You lost me on this one, can you rephrase?
The oauth_verifier
Hi Brian,
On Apr 28, 2009, at 2:12 PM, Brian Eaton wrote:
>
> On Tue, Apr 28, 2009 at 11:00 AM, John Kemp wrote:
>> All of these protocols are for Web-browser based SSO, and establish
>> the trust between the consumer and SP (using the OAuth terminology)
>> by
&
Hi Brian,
On Apr 28, 2009, at 1:36 PM, Brian Eaton wrote:
>
> On Mon, Apr 27, 2009 at 8:25 PM, pkeane wrote:
>> I'm happy with OAuth for the typical sorts of social networking,
>> photo-sharing, etc. use cases, and I use it for that. But I'd very
>> much like to be able recommend it for more
On Apr 28, 2009, at 10:32 AM, Dossy Shiobara wrote:
>
> On 4/28/09 8:41 AM, Hubert Le Van Gong wrote:
>> I also saw 2 additional ideas that might help
>> (and are not necessarily exclusive with the 2 proposals):
>>
>> (3) Make Request tokens one-time only
>> (4) Request that the user logs in at t
On Apr 26, 2009, at 12:32 AM, Nat Sakimura wrote:
>
> I agree that "2. test(B==C) , i.e., verify that the user at B is the
> same user at C" is
> not the same as "2b. min Prob(B!=C)".
>
> The former is clearly more desirable.
+1
>
> If someone logs in to the both sites using something like Open
Hi,
On Apr 24, 2009, at 12:29 PM, Manish Pandit wrote:
>
>
> On Apr 24, 2:04 am, Raymond Cheung wrote:
>> Dear all,
>>
>> I'm the newbie on OAuth. I've a silly question. How can I specify the
>> "Authentication: OAuth" header inside FORM element? Thanks.
>>
>> Best regards,
>> Raymond
>
>
> You
Ben (and now cc'ing the main list since I hear 'extensions' is going
away),
On Apr 3, 2009, at 12:02 PM, Ben Adida wrote:
>
>
>
> On Apr 3, 5:02 am, John Kemp wrote:
>> How about Content-Encoding and Content-Length then?
>
> I can see the argument f
Hello Hubert,
On Apr 3, 2009, at 6:36 AM, Hubert Le Van Gong wrote:
>
> How many implementations out there support both 200 and 201
> as valid responses from the Service Provider (when returning the
> access token).
> From a RESTful point of view I'm tempted to use 201 but I'm unsure how
> con
On Mar 13, 2009, at 8:47 AM, Zhihong wrote:
[...]
>
> I really like the way OAuth uses Authorization header so you can hide
> OAuth clutter away from app data. However, the header is not used in
> the context of HTTP auth. In OAuth, the Authorization header is always
> unsolicited and not a resp
Hi James,
On Mar 2, 2009, at 8:55 PM, Manger, James H wrote:
> [johnk said]
>> The problem is that the term 'consumer' is quite accurate and
>> descriptive when you imagine that a software application, in the role
>> of a consumer, is consuming the output of the "service provider". An
>> 'applic
On Mar 2, 2009, at 5:37 PM, Brian Eaton wrote:
>
> Ah, I totally forgot about the whole "consumer key" nomenclature.
>
> It would make me incredibly happy if OAuth talked about "consumer
> name"
Exactly, the "consumer key" is an _identifier_ (a name) for the
consuming application.
- johnk
>
On Mar 2, 2009, at 6:32 PM, Manger, James H wrote:
> I would be incredibly happy if OAuth talked about Applications,
> instead of Consumers (a term many have found strange).
The problem is that the term 'consumer' is quite accurate and
descriptive when you imagine that a software application
On Jan 8, 2009, at 1:27 PM, Hans Granqvist wrote:
>
>> It seemed to me that the original request might be more easily (if
>> only partially?) satisfied by creating an "implementation guidelines"
>> document, to which the different library implementers might submit
>> their "gotchas" and where we
On Jan 8, 2009, at 10:04 AM, Krishna Sankar (ksankar) wrote:
> Which means, we need a conformance spec and a couple of test suits
> implementations. This is all good as it shows that the domain is
> maturing … Would be happy to help in any way …
While I think that a conformance spec. and RI
24 matches
Mail list logo
