OAUTH setup for webid : getting an ODS client to "Connect" to my profilepage

I could not really fathom the IX groups message on OAUTH + webid. The spec says little, and the issues are confusing. I documented what I think its trying to do here: http://yorkporc.wordpress.com/2012/01/10/webid-for-ods-user-connections-to-profile-pages/ Since an webid-friendly manager of profiles is ODS and the certifcaites managed there by a simple CA can have the digital signature bit key usage, I applied some more Microsoft sample code to take that capability and extend webid to the OAUTH handoff between an ODS profile and my windows webapps Home page, which exposes RDF/XML using a translator service redirect. While it would nice for all crawlers (building linked data graphs) to be using OAUTH to access my profile page, I cannot see Kingsley altering his linkeddata.uriburner.com installation for this. But, his ODS installation is a different matter. And in the ODS case we have a "simpler" case of mini-crawling. We see *users* being invited to "connect" their ODS profile to other profiles (and their facebook-like data graphs/APIs). It already has means to configure old Google-class hmac passwords. Well, why cannot i now CONNECT my ods name to my windows home page graph? Ive enabled an optional OAUTH guard on my profile page, using the Windows/Google agreement on tokens (being replaced by signed json in the world of LIVE.com, as we speak). Ive showin the blog post how an ODS acting as connection-client can be leveraging my ODS_managed signing key in the profile, suitably armed with webid SAN name that tells the world about the rest of the webid story. Ive shown how the resulting token minted by ODS supproted by cert can be evaulated by a security token gateway, that remints the token for use by a webid profile page guard (controlling "connectionsTo" relation formation). The token that is reminted proejcts forward the webid SAN name (now cast in the form of a SWT field). Logically, it goes into a signed JSON token, shortly.    		 	   		  

Received on Tuesday, 10 January 2012 16:56:00 UTC