RE: slow down and organize

no I dont want to do that. The topic has nothing to do with ASN.1 notation. It has nothing to do with pointing to a "PEM" file, wrapping a DER-coded value.
 
in my mind, its a toss up which is better
 
1. a webservice over http that remotes using a sparql engine/API to test a foaf card for a pubkey
2. a sparql _protocol_ run over http... using a sparql engine/API to test a foaf card for a pubkey
 
I think I have the implementation skills to consume 1
 
I think I have the implementation skills to invoke 2 and then consume an XML resultset of a few name/value pairs.
 
Is there an issue that would best frame "remoting" FROM the TLS responder some (but not all) of the verification agents steps described in section 3.1?
 
 
 



Subject: Re: slow down and organize
From: henry.story@bblfish.net
Date: Thu, 24 Feb 2011 19:58:55 +0100
CC: reto.bachmann@trialox.org; nathan@webr3.org; public-xg-webid@w3.org
To: home_pw@msn.com





On 24 Feb 2011, at 17:48, peter williams wrote:
What linked data PROPOSES for scheme #17 is great. But, can we just do it rather than talk about it? Start with the simplest version of linked data, and don’t make me learn anything about federated social webs. Just let me read a foaf card on the web, test it for a key – just like I already do with an ldap query. Do that as simply as possible, ideally in a manner that a billion PCs can do today, with no change. Don’t make me learn turtle, don’t make me learn n3, don’t make me learn inferences due to RDFa. Just let me test a key exists in a remote file, using a trivial webservice.

what you want is to develop issue-6 "using ASN.1 formats for WebID description"


    http://www.w3.org/2005/Incubator/webid/track/issues/6


Why don't you write out a simple spec on the wiki for that, put up the pros and cons you can think of
That is the simplest I can think of: A WebID that points into to a PEM file. We can see what people think.


Shall I open an action item for you?


Henry






Social Web Architect
http://bblfish.net/
 		 	   		  

Received on Thursday, 24 February 2011 19:32:20 UTC