[foaf-protocols] Fw: CPAN Upload: T/TO/TOBYINK/CGI-Auth-FOAF_SSL-1.001_02.tar.gz

Peter Williams home_pw at msn.com
Tue Jan 18 18:49:52 CET 2011


what is interesting about that explanation is
 
it assumes the foaf model of "agents" (which was reasonable in the FOAF+SSL era, but perhaps not today since the incubator charter specifically unlinks webid protocol from FOAF)
 
it assumes the cert is not a signed blob, but a signed claim (from an agent). Typically, that agent would be known in claims-land as an authority, or issuer. Moreover, in claims-land, there MUST exist an a priori "trust" relationship between verifiers of claims and issuers of claims. Now, I'm not sure this is appropriate, if this is the only trust model being contemplated by the designers of the webid protocol; since it's a minor variant of the self-asserted infocard capability built into windows https flows for years now (around which there are patents and lots of initiative work in the openid+infocard groups).
 
One might start with the semantics of X.509, which imposes semantics on multiple subj alt names (of any name type). If one starts by denying that the ISO/ITU-T semantics apply, then the object is not a cert - being merely a value blob of some concrete but anonymous type that derives from the Cert abstract type. Obviously, this group can then define what that anontype is when the SSL client auth procedure is used in an https context for the semweb agents (foaf or otherwise), and define a custom meaning of multiple alt names.
 
Question is: should the notion be generalized, so there can be lots of different anontypes for different nyms?
 
I could be  pursuaded to say there is but one (for the first 4 yeares); IF there is some very coherent semweb-related rationale - some dominant model of syno-nyms that we want adopted. For example, the "structured-names" theory of semweb might be so important to pursue that the goup encourages a 2 webid world: the URI, and the structured name that ties the URI to the world of name resolvers working in the manner that is most consistent with the semweb in general.
 
 
> Date: Tue, 18 Jan 2011 17:16:59 +0000
> From: tai at g5n.co.uk
> To: home_pw at msn.com
> CC: foaf-protocols at lists.foaf-project.org
> Subject: Re: [foaf-protocols] Fw: CPAN Upload: T/TO/TOBYINK/CGI-Auth-FOAF_SSL-1.001_02.tar.gz
> 
> On Tue, 18 Jan 2011 09:06:35 -0800
> Peter Williams <home_pw at msn.com> wrote:
> 
> > so what does it mean to put multiple refs in the cert's subj alt name?
> 
> I think most implementations do support this now - it's a feature
> that's been much discussed on this list in the past. CGI::Auth::FOAF_SSL
> was one of the first to do support it.
> 
> Essentially if you've got a subjectAltName of:
> 
> URI:http://alice.example/foaf#me URI:http://example.com/alice.rdf#me
> 
> Then the certificate is claiming that both URIs are identifiers for the
> agent (i.e. person, usually) making the HTTPS request.
> 
> In terms of server implementation, you'd check the first URI, and then
> fall back to subsequent URIs in the case where the first did not result
> in a positive authentication.
> 
> -- 
> Toby A Inkster
> <mailto:mail at tobyinkster.co.uk>
> <http://tobyinkster.co.uk>
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.foaf-project.org/pipermail/foaf-protocols/attachments/20110118/48964a6d/attachment.htm 


More information about the foaf-protocols mailing list