OAuth Google Group

Re: [oauth] Re: xml-rpc

2008-08-07T18:27:06Z

sure, that makes our job easier on the WordPress side, but we don't
have many (any?) clients that support it. I was unable to get
MarsEdit to do AtomPub properly, and the WP iPhone app specifically
uses XML-RPC. Switching that entirely over to AtomPub would take some
time with little benefit. If the main problem with both is relating

Re: [oauth] Re: xml-rpc

2008-08-07T14:40:18Z

AtomPub mentions signing of the XML body using W3C XML Digital Signature
[1]. XML Digital Signature isn't restricted to Atom content - it should
work for all XML languages, irrespective of OAuth use. FWIW, work is
ongoing in W3C to improve XML Digital Signature [2].
Cheers,
- johnk
[1] [link]

Re: xml-rpc

2008-08-07T14:04:07Z

I don't see it as an either or, seems reasonable to have both AtomPub
and XML-RPC support OAuth. XML-RPC is probably the best one to work
on first because, since it would have a larger impact.

--
Joseph Scott
jos...@randomnetworks.com
[link]

Re: [oauth] Re: xml-rpc

2008-08-07T06:55:06Z

Ok, well, if we can hit two birds with one stone, I'm all for it! Just
wasn't sure if AtomPub or the existin Atom API changed things at all, but if
not, then let's solve the problem for both protocols...! It's clear in my
mind that it's a necessary case for using OAuth -- if anything, to have a
unified experience for authorizing blogging clients on the desktop, iPhone

Re: [oauth] Re: xml-rpc

2008-08-07T06:17:56Z

Why not support OAuth for xml-rpc? There are existing clients, and it should
be fairly simple to retrofit them to use OAuth, adding additional security
and avoiding the password antipattern without other substantial changes.
FWIW, AtomPub has the same issue as XML-RPC when used with OAuth, namely
that the AtomPub body is contained in a POST or PUT body with a Content-type

Re: [oauth] Re: xml-rpc

2008-08-07T05:51:46Z

Will, I wonder if we could bypass this issue (for WordPress at least) by
just making use of the AtomPub API instead of XML-RPC? Perhaps we could just
offer a patch to that file and point to the proper OAuth endpoints in a
XRDS-Simple document?
[link]
Chris

Re: [oauth] xml-rpc

2008-08-07T03:37:22Z

It's definitely possible to use OAuth with XML-RPC calls; the only caveat is
that the body of the call will not be signed, since the Content-type of an
XML-RPC call is text/xml, rather than x-www-url-form-encoded. The existing
blogger API doesn't sign the request, either, so overall using OAuth is a

xml-rpc

2008-08-07T02:50:05Z

All the OAuth documentation states pretty clearly that the XML-RPC use
case is out of scope for Core 1.0, but I'm wondering if anyone has
spent much time looking at it. Specifically, we're working on adding
OAuth to WordPress for use in the MovableType/Blogger xml-rpc APIs.
I've toyed with a few different approaches, such as just using the

Re: Can't verify my domain, verification system seems to be down?

2008-08-06T19:04:58Z

A more appropriate group will be
[link]

We'd need more info (i.e. your domain name) to help diagnose the
problem.

Wei

Re: [oauth] Can't verify my domain, verification system seems to be down?

2008-08-06T14:16:26Z

You'd probably get better answers from the Google support channels,
but I though I'd let you know I just tried it with my domain (html
file upload too), and it worked just fine.
Stephane

Can't verify my domain, verification system seems to be down?

2008-08-06T07:17:45Z

Hi,

I want to use OAuth in my application and wanted to register my domain
with google.

I have been trying to verify my domain for 3 days now at:

[link]

Both methods 'Upload a HTML file' or 'Add a metatag' don't seem to
work.

I keep getting the following message:

Re: Best practice for non-browser app?

2008-08-01T06:04:00Z

One idea for client login to work with OpenID:
- the client can first send the email/username to the relying party
client login endpoint
- the end point replies with the client login end point of the OpenID
OP
- the client sends the username/password to the end point of the
OpenID OP
- the OpenID OP sends back some assertion

Re: [oauth] Re: Best practice for non-browser app?

2008-08-01T01:42:46Z

Note that ClientLogin does provide for a captcha challenge[1]. I also
believe that many clients don't implement this or understand it so it
may not be as useful as one might think.
The browser-based mechanism really provides nearly ultimate
extensibility (network connection, Javascript code executing on client

Re: [oauth] Re: Best practice for non-browser app?

2008-07-31T19:36:08Z

There is also noting to stop people form using that interface for servers which is the anti-pattern we are trying to solve..

EHL

Re: [oauth] Re: Best practice for non-browser app?

2008-07-31T18:38:34Z

One issue with a ClientLogin type interface (where the consumer submits
the username/password for credentials) is that it assumes that users
have passwords, which might not be the case if passwordless systems like
OpenID or Cardspace are more widely deployed.
Another issue with the ClientLogin interface is that it's impossible to