I think that a basic answer is that this would be either an extension
(as done with OpenSocial for the same reasons) or a separate service
(give the token, get the stable identifier for the user, if they want to
share it with you). However, you may also want to look at the hybrid
OpenID-OAuth
I thought this worked well in the Pownce demo last year. There does
seem to be controversy about its usability; if someone wants to try this
out and provide data on any issues they find with real users that would
be worth a dozen extension specs.
Seth Fitzsimmons wrote:
> Fire Eagle has some d
kellan wrote:
> On Thu, Feb 19, 2009 at 2:23 PM, Eran Hammer-Lahav
> wrote:
>
>> Are there any providers our there without support for the Authorization
>> header (as a way to send OAuth parameters)?
>>
>>
>
> I could launch one if that would help.
>
>
>> Any reason why Service Provide
On Fri, Mar 13, 2009 at 6:10 AM, John Kemp wrote:
>
> 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,
On Mon, Mar 16, 2009 at 9:34 AM, Zhihong wrote:
>
> ...
>
> 2. OAuth is a 3-party dance. When a failure is returned from service
> provider (like invalid sig or rejected token), consumer can't simply
> respond to the 401 and continue the exchange. It needs to switch
> context to send an error to
I'd suggest also implementing processChallenge() to deal with
WWW-Authenticate: challenges from a server and making it available to
clients in a reasonable way.
I don't understand the use of UsernamePasswordCredentials in
setCredentials example though :).
Paul Austin wrote:
> The current OAut
A temporary email address is probably more immediately deployable. However,
if there's interest, providing a POST endpoint to send something like an
Atom Entry to, guarded by OAuth via the Authorization: header, is pretty
well understood standards-based technology with libraries already written.
I
IIRC, I believe the signing is a workaround for environments that can't or
don't want to support SSL. And SSL is problematic primarily for small SPs
that can't justify purchase of their own certs. Unfortunately, this puts a
burden on clients.
Also, most of these come down to encoding issues, whi
These are really on different levels of the stack, so it's very hard to
give advice without knowing your specific needs. But GFC also implements
the OpenSocial APIs, which rely on OAuth for authentication. So it's
not necessarily either/or. GFC adds drop-in JS-based modules that make
it easy
Wow, this is great. Would be good to have some of this info linked to
from oauth.net too :). Thanks Eve!
Eve Maler wrote:
> (Sorry, been traveling...) There's a physical statuette thingie and a
> paper certificate that come with the virtual honor :-), and I'll bring
> those to IIW to transfe
Sure, this makes sense to me. It's kind of analogous to the other two
legged case where you have just a Consumer with a secret (provided through
some out of band mechanism) that makes requests with empty strings for the
user's secret.
On Fri, May 15, 2009 at 3:59 AM, Toby wrote:
>
> Sure, I cou
On Tue, May 19, 2009 at 6:01 PM, Evert Pot wrote:
>
> Dear list,
>
> I'm tasked with designing a new developer api for our application.
> Part of this is coming up with an authentication scheme. I've looked
> into OAuth, and I would like to know if OAuth is right for me, because
> it doesn't exac
Seth Fitzsimmons wrote:
>>> I've got an app here that we'd like to have authenticated RSS feeds on
>>> it-- non-public data that nonetheless can stream pretty nicely in an RSS
>>> format. It seems that OAuth-for-desktop-apps is a great fit for this,
>>> with the only problem being that the RSS read
On Thu, Jun 4, 2009 at 10:31 PM, Chris Messina wrote:
>
>
> On Thu, Jun 4, 2009 at 9:14 PM, John Panzer wrote:
>>
>> Yes, Blogger feeds support Google AuthSub, Google Client Auth, and
>> OAuth. Clients are most welcomed.
>>
>> I highly encourage the use o
Yes. (It could also help you get rid of passwords entirely too.)
On Friday, July 24, 2009, Ethan Jewett wrote:
> In my relatively uneducated opinion, one major security benefit of using
> OAuth for client apps is that the client is only provided with an access
> token for the service and not
A feature I'd also like to have as a consumer is the reverse operation
- starting with a broad scope for initial setup, then narrowing scope
before storing my secret anywhere other than local memory.
On Friday, October 16, 2009, Allen Tom wrote:
>
> Hi Robert,
>
> The text in the Yahoo documenta
I think this means that you login (once) to authorize the application to use
your account, then it stores the token it receives and uses it for
subsequent requests on behalf of other users.
At least, that's what the Salmon proxy service I threw together does.
On Thu, Nov 12, 2009 at 7:58 PM, bob_
This is a great summary from Chris, Eran, Dick, and David. Thanks guys!
David Recordon wrote:
Sorry for emailing across a few lists, but this morning Chris Messina,
Dick Hardt, and I wrote a post on O'Reilly Radar talking about the
successes of OAuth 1.0a, the introduction of WRAP, and where w
nd delete and destroy all copies.
>> --
>> You received this message because you are subscribed to the Google Groups
>> "OAuth" group.
>> To post to this group, send email to oa...@googlegroups.com.
>> To unsubscribe from this group, send email to
>>
ser data, etc).
>
> An obvious question is, how do we push browsers in this direction? What can
> be done to encourage browsers to treat previously unseen OAuth SPs in a
> similar way that invalid SSL certs are treated... or as you mention, bad-site
> iframes.
>
> Cheers,
> P
ceived this message because you are subscribed to the Google Groups
> "OAuth" group.
> To post to this group, send email to oa...@googlegroups.com.
> To unsubscribe from this group, send email to
> oauth+unsubscr...@googlegroups.com.
> For more options, visit this group at
>
21 matches
Mail list logo
