Comments on: Atompub & OpenID http://blog.ianbicking.org/2007/08/06/atompub-openid/ Mon, 01 Dec 2008 20:18:57 +0000 http://wordpress.org/?v=2.2.3 By: John Panzer http://blog.ianbicking.org/2007/08/06/atompub-openid/#comment-94 John Panzer Wed, 08 Aug 2007 17:42:42 +0000 http://blog.ianbicking.org/2007/08/06/atompub-openid/#comment-94 "Update: Another question/thought: is it okay to send multiple WWW-Authenticate headers, to give the client options for how it wants to do authentication? It seems vaguely okay, according to RFC 2616 14.47." It's allowed, and Google's GData does it to offer two options for authentication (ClientLogin and AuthSub): WWW-Authenticate: GoogleLogin realm="https://www.google.com/accounts/ClientLogin", service="blogger" WWW-Authenticate: AuthSub realm="https://www.google.com/accounts/AuthSubRequest", service="blogger" “Update: Another question/thought: is it okay to send multiple WWW-Authenticate headers, to give the client options for how it wants to do authentication? It seems vaguely okay, according to RFC 2616 14.47.”

It’s allowed, and Google’s GData does it to offer two options for authentication (ClientLogin and AuthSub):

WWW-Authenticate: GoogleLogin realm=”https://www.google.com/accounts/ClientLogin”, service=”blogger” WWW-Authenticate: AuthSub realm=”https://www.google.com/accounts/AuthSubRequest”, service=”blogger”

]]> By: Sylvain Hellegouarch http://blog.ianbicking.org/2007/08/06/atompub-openid/#comment-86 Sylvain Hellegouarch Tue, 07 Aug 2007 14:46:16 +0000 http://blog.ianbicking.org/2007/08/06/atompub-openid/#comment-86 Most AtomPub clients out there are not automated and require human feedback, they aren't different from a browser therefore. For automated authentication not requiring human intervention, you need authentication services like those offering OpenID to come up with such solution. I feel like you put the burden on clients which is not where it should be, the problem comes from auth scheme which have never been really thought out of the browser context. Most AtomPub clients out there are not automated and require human feedback, they aren’t different from a browser therefore. For automated authentication not requiring human intervention, you need authentication services like those offering OpenID to come up with such solution. I feel like you put the burden on clients which is not where it should be, the problem comes from auth scheme which have never been really thought out of the browser context.

]]> By: John Panzer http://blog.ianbicking.org/2007/08/06/atompub-openid/#comment-81 John Panzer Tue, 07 Aug 2007 06:47:22 +0000 http://blog.ianbicking.org/2007/08/06/atompub-openid/#comment-81 See http://journals.aol.com/panzerjohn/abstractioneer/entries/2007/05/04/aol-openauth-and-atom-publishing-protocol/1440 and, possibly more relevantly, the ongoing OAuth effort: http://groups.google.com/group/oauth See http://journals.aol.com/panzerjohn/abstractioneer/entries/2007/05/04/aol-openauth-and-atom-publishing-protocol/1440 and, possibly more relevantly, the ongoing OAuth effort: http://groups.google.com/group/oauth

]]> By: Ian Bicking http://blog.ianbicking.org/2007/08/06/atompub-openid/#comment-79 Ian Bicking Mon, 06 Aug 2007 22:59:51 +0000 http://blog.ianbicking.org/2007/08/06/atompub-openid/#comment-79 Atompub has all the same problems any web service has when it's being used by a browser. It's nothing that special about Atompub, except that it could be a service that browsers actually use directly. Notably few people use HTTP authentication with websites and normal browsers. OpenID doesn't use HTTP authentication either. If I redirect an Atompub client to a login page, the client won't know what to do with that. A human would, because humans can read instructions and understand the login pattern. We need a way for Atompub clients to understand that same pattern. Atompub has all the same problems any web service has when it’s being used by a browser. It’s nothing that special about Atompub, except that it could be a service that browsers actually use directly. Notably few people use HTTP authentication with websites and normal browsers. OpenID doesn’t use HTTP authentication either.

If I redirect an Atompub client to a login page, the client won’t know what to do with that. A human would, because humans can read instructions and understand the login pattern. We need a way for Atompub clients to understand that same pattern.

]]> By: Sylvain Hellegouarch http://blog.ianbicking.org/2007/08/06/atompub-openid/#comment-78 Sylvain Hellegouarch Mon, 06 Aug 2007 22:52:54 +0000 http://blog.ianbicking.org/2007/08/06/atompub-openid/#comment-78 For large dataset it's quite likely that the server would use the collection listing as per the AtomPub spec. That could help the parsing. Mind you if only all the browsers were supporting E4X the parsing would look much nicer to everyone. > But services like Atompub don’t work nicely with the kinds of authentication methods that normal websites use. I don't quite understand that statement. AtomPub abides to the HTTP rules and I don't understand why an AtomPub service would therefore be any different from any other websites out there. For large dataset it’s quite likely that the server would use the collection listing as per the AtomPub spec. That could help the parsing. Mind you if only all the browsers were supporting E4X the parsing would look much nicer to everyone.

> But services like Atompub don’t work nicely with the kinds of authentication methods that normal websites use.

I don’t quite understand that statement. AtomPub abides to the HTTP rules and I don’t understand why an AtomPub service would therefore be any different from any other websites out there.

]]> By: Ian Bicking http://blog.ianbicking.org/2007/08/06/atompub-openid/#comment-77 Ian Bicking Mon, 06 Aug 2007 21:15:40 +0000 http://blog.ianbicking.org/2007/08/06/atompub-openid/#comment-77 Right now I'm looking at smallish data sets, where the server does most of the filtering. That might be a problem later, I'm not sure. I could imagine just using <code>"{ns}tag"</code> for namespaces, but I suppose that would bulk up the file some. Still, yes, it means that you have to in effect parse the document to resolve the namespaces. Or use conventions, and then translate if their conventions for prefixes aren't the same as your own. Still, their simpler translation would make it easier to create a DOM-like facade on top. In fact, it seems quite easy to create something DOM-like in that case. That would be appealing. I think eventually I'll find [JSONP](http://bob.pythonmac.org/archives/2005/12/05/remote-json-jsonp/) will be necessary, at which point a JSON format would be nicer (though packing an XML response in a string would also be possible). Anyway, maybe it'll come up then. Either way, the issue I'm struggling with isn't an issue XML or JSON, but authentication. Right now I’m looking at smallish data sets, where the server does most of the filtering. That might be a problem later, I’m not sure. I could imagine just using "{ns}tag" for namespaces, but I suppose that would bulk up the file some. Still, yes, it means that you have to in effect parse the document to resolve the namespaces. Or use conventions, and then translate if their conventions for prefixes aren’t the same as your own.

Still, their simpler translation would make it easier to create a DOM-like facade on top. In fact, it seems quite easy to create something DOM-like in that case. That would be appealing.

I think eventually I’ll find JSONP will be necessary, at which point a JSON format would be nicer (though packing an XML response in a string would also be possible). Anyway, maybe it’ll come up then.

Either way, the issue I’m struggling with isn’t an issue XML or JSON, but authentication.

]]> By: mikeal http://blog.ianbicking.org/2007/08/06/atompub-openid/#comment-76 mikeal Mon, 06 Aug 2007 20:41:48 +0000 http://blog.ianbicking.org/2007/08/06/atompub-openid/#comment-76 The issue with using vanilla atom and javascript is that javascript is terrible at parsing large xml datasets. For this reason gdata has implemented a json datatype for use in atom, http://code.google.com/apis/gdata/json.html I have to say I'm not a fan of their formatting. The way they hack in namespaces on javascript still requires some annoying parsing. At OSAF we went a different route, our's is specific to representing EIM in JSON but you'll see the difference. http://chandlerproject.org/Projects/EimJsonSpec -Mikeal The issue with using vanilla atom and javascript is that javascript is terrible at parsing large xml datasets.

For this reason gdata has implemented a json datatype for use in atom, http://code.google.com/apis/gdata/json.html

I have to say I’m not a fan of their formatting. The way they hack in namespaces on javascript still requires some annoying parsing.

At OSAF we went a different route, our’s is specific to representing EIM in JSON but you’ll see the difference.

http://chandlerproject.org/Projects/EimJsonSpec

-Mikeal

]]>