Comments for robubu http://robubu.com the weblog of Rob Yates Sat, 14 Aug 2010 17:34:10 +0000 http://wordpress.org/?v=2.9.2 hourly 1 Comment on Abdera – Turbo by business credit loan http://robubu.com/?p=11&cpage=1#comment-91224 business credit loan Sat, 14 Aug 2010 17:34:10 +0000 http://robubu.com/?p=11#comment-91224 helpful post. helpful post.

]]> Comment on Atom Publishing Protocol – not enough for blogs? by Досуг в москве шлюхи http://robubu.com/?p=26&cpage=1#comment-90884 Досуг в москве шлюхи Tue, 03 Aug 2010 20:37:22 +0000 http://robubu.com/?p=26#comment-90884 Здравствуйте, клевый блог. а как ва идея на счет его монетизации через сапу? Здравствуйте, клевый блог. а как ва идея на счет его монетизации через сапу?

]]> Comment on Safe JSON by JavaScript Vulnerabilities – From GWT(Google web toolkit) | Little knowledge is dangerous http://robubu.com/?p=24&cpage=1#comment-90641 JavaScript Vulnerabilities – From GWT(Google web toolkit) | Little knowledge is dangerous Thu, 29 Jul 2010 01:05:39 +0000 http://robubu.com/?p=24#comment-90641 [...] Safe JSON [...] [...] Safe JSON [...]

]]> Comment on Facebook – an Openid challenge by Dafte http://robubu.com/?p=30&cpage=1#comment-88770 Dafte Fri, 11 Jun 2010 12:12:44 +0000 http://robubu.com/?p=30#comment-88770 Дозирование и системы дозирования. Разбавление растворов. Дозирование и системы дозирования. Разбавление растворов.

]]> Comment on Hardware assisted virtualization – aka xen, kvm and ec2 by Exectweets » CloudComputing3 at 01/07/10 12:19:49 http://robubu.com/?p=58&cpage=1#comment-86723 Exectweets » CloudComputing3 at 01/07/10 12:19:49 Sun, 02 May 2010 21:16:34 +0000 http://robubu.com/?p=58#comment-86723 [...] virtualization – aka xen, kvm and ec2: Hardware-assisted virtualization: Hardware-as… http://robubu.com/?p=58 CloudComputing3 - Thu 07 Jan 12:19 All Things [...] [...] virtualization – aka xen, kvm and ec2: Hardware-assisted virtualization: Hardware-as… http://robubu.com/?p=58 CloudComputing3 – Thu 07 Jan 12:19 All Things [...]

]]> Comment on WebFinger, OAuth and Freebusy lookups by Arnaud Quillaud http://robubu.com/?p=59&cpage=1#comment-84414 Arnaud Quillaud Wed, 17 Mar 2010 14:46:02 +0000 http://robubu.com/?p=59#comment-84414 While it serves a slightly different purpose, you should have a look at http://tools.ietf.org/html/draft-desruisseaux-ischedule As far as the FB query itself, see http://www.calconnect.org/pubdocs/CD0903%20Freebusy%20Read%20URL.pdf While it serves a slightly different purpose, you should have a look at http://tools.ietf.org/html/draft-desruisseaux-ischedule

As far as the FB query itself, see http://www.calconnect.org/pubdocs/CD0903%20Freebusy%20Read%20URL.pdf

]]> Comment on WebFinger, OAuth and Freebusy lookups by Prashant K http://robubu.com/?p=59&cpage=1#comment-84388 Prashant K Tue, 16 Mar 2010 20:21:39 +0000 http://robubu.com/?p=59#comment-84388 I conceptually like the proposal here. This is fantastic approach. In fact one could use this generic API calling mechanism to do things like get updates from linked-in/facebook, get location information and so on. It does make sense to use 'OAuth-style' calling for making these one-off calls to do free busy lookups without real token management etc. I am not familiar with webfinger. At this stage, I believe it would be good if we can optimize step 5 (webfinger lookup). If the user's email is something like user@yahoo.com and the call is made by yahoo (call uses yahoo certificate), it won't be necessary. Won't it cover the most of the cases? Anyway.. I believe this is a great idea ! I conceptually like the proposal here. This is fantastic approach. In fact one could use this generic API calling mechanism to do things like get updates from linked-in/facebook, get location information and so on.

It does make sense to use ‘OAuth-style’ calling for making these one-off calls to do free busy lookups without real token management etc. I am not familiar with webfinger. At this stage, I believe it would be good if we can optimize step 5 (webfinger lookup). If the user’s email is something like user@yahoo.com and the call is made by yahoo (call uses yahoo certificate), it won’t be necessary. Won’t it cover the most of the cases?

Anyway.. I believe this is a great idea !

]]> Comment on WebFinger, OAuth and Freebusy lookups by Rob Yates http://robubu.com/?p=59&cpage=1#comment-84383 Rob Yates Tue, 16 Mar 2010 17:53:32 +0000 http://robubu.com/?p=59#comment-84383 @Nathaniel I am not sure the process by which WebFinger is becoming a standard. I can't even find a mailing list about it. I will ask Eran on his blog. Maybe it will come out of the IETF OAuth group. On the format for the data, that is all in that spec from 1998. We could maybe change it if we wanted, but what exists with VFREEBUSY probably works for most. @Mark SAML does not have a binding for arbitrary REST api calls. It has a binding to http GET redirect or POST, but those are essentially browser basesd http bindings and not for general api usage. @Nathaniel I am not sure the process by which WebFinger is becoming a standard. I can’t even find a mailing list about it. I will ask Eran on his blog. Maybe it will come out of the IETF OAuth group.

On the format for the data, that is all in that spec from 1998. We could maybe change it if we wanted, but what exists with VFREEBUSY probably works for most.

@Mark SAML does not have a binding for arbitrary REST api calls. It has a binding to http GET redirect or POST, but those are essentially browser basesd http bindings and not for general api usage.

]]> Comment on WebFinger, OAuth and Freebusy lookups by Mark McG http://robubu.com/?p=59&cpage=1#comment-84382 Mark McG Tue, 16 Mar 2010 17:37:01 +0000 http://robubu.com/?p=59#comment-84382 SAML does support HTTP binding. I think Webfinger is an excellent idea for step 2, discovering the feebusy endpoint. I am not so sure about it's use in asserting identity and perhaps that is just because I don't know the types of attacks that could be launched at steps 4/5. Wouldn't a strong identity assertion protocol at step 4 negate the need for step 5 (binding issues aside)? SAML does support HTTP binding.

I think Webfinger is an excellent idea for step 2, discovering the feebusy endpoint. I am not so sure about it’s use in asserting identity and perhaps that is just because I don’t know the types of attacks that could be launched at steps 4/5.

Wouldn’t a strong identity assertion protocol at step 4 negate the need for step 5 (binding issues aside)?

]]> Comment on WebFinger, OAuth and Freebusy lookups by Nathaniel Borenstein http://robubu.com/?p=59&cpage=1#comment-84380 Nathaniel Borenstein Tue, 16 Mar 2010 16:03:26 +0000 http://robubu.com/?p=59#comment-84380 I think this is freaking brilliant. There has been a huge hole in the calendaring protocols, and you've figured out how to fill it in, almost entirely, by putting two emerging protocols together. Seriously Brilliant. That said...... and you knew this was coming... I do have some concerns. Biggest among these is the immaturity of webfinger. You're essentially talking about standardizing on the use of something that barely exists yet. We would have to put serious weight behind the webfinger effort to help it succeed, in part by participating in its evolution, but even more importantly by bringing the calendaring community in as supporters, and by helping shepherd webfinger through the IETF. (Even though most of the work will probably be done at calconnect, the documents will have to go through the IETF wringer.) Leadership in those venues would be a good thing for IBM to contribute. There are also some missing details about the format of the data that you receive about free/busy -- are you basically thinking of this as a caldav proxy, with iCal coming back? Or something more XML-ish and probably not yet well-specified? Overall though... great idea! I think this is freaking brilliant. There has been a huge hole in the calendaring protocols, and you’ve figured out how to fill it in, almost entirely, by putting two emerging protocols together. Seriously Brilliant.

That said…… and you knew this was coming… I do have some concerns. Biggest among these is the immaturity of webfinger. You’re essentially talking about standardizing on the use of something that barely exists yet. We would have to put serious weight behind the webfinger effort to help it succeed, in part by participating in its evolution, but even more importantly by bringing the calendaring community in as supporters, and by helping shepherd webfinger through the IETF. (Even though most of the work will probably be done at calconnect, the documents will have to go through the IETF wringer.) Leadership in those venues would be a good thing for IBM to contribute.

There are also some missing details about the format of the data that you receive about free/busy — are you basically thinking of this as a caldav proxy, with iCal coming back? Or something more XML-ish and probably not yet well-specified?

Overall though… great idea!

]]>