[foaf-protocols] looking back to 1988 for proof that cert existance in container => valid

Peter Williams home_pw at msn.com
Mon Mar 7 05:19:09 CET 2011


have to be careful though, as soon as one adds anything beyond what there is strong prior art (lampson, and X.509 1988). Even adding https to the foaf card server has to be able to claim its an instance of Lampson's logic (and one has to do it completely, using an ephemeral ciphersuite or perhaps the proxy cert).
 
Presumably, the proxy cert people, having been through IETF, have strong IP analysis.
 
http://www.freepatentsonline.com/7434253.html
 
win2000 didnt allow client certs -> NT user account mapping to then delegate (using windows tokens means). But... then, thats a decade ago. Id be suprised if its true still (simply since delegation is now so much stronger, a decade later) given the whole token mapping world, in which presentation of a client cert via https can and doesn induce the IDP to issue a token, within limited scope and assertions. Seems to be a standard part of ADFS v2.
 
Which makes me wonder, if one might go to the scripts directory of ADFS, for certs and alter it so it pings against webid documents, rather than AD. Or, rather, pings against Kingley service - which remotely tests if a named foaf card bear a cert/pubkey.
 


Date: Sun, 6 Mar 2011 21:48:53 -0500
From: kidehen at openlinksw.com
To: foaf-protocols at lists.foaf-project.org
Subject: Re: [foaf-protocols] looking back to 1988 for proof that cert existance in container => valid


On 3/6/11 12:00 AM, peter williams wrote: 




We can also see it here (albeit for 2011):
 
http://technet.microsoft.com/en-us/library/cc755292.aspx
 
Semantically, its richer than merely testing for mere existence of cert in container. There is also a match and find rule, mapping the cert (once matched) onto an account field(s) found in the same directory entry.
Yes, and I expect WebID protocol implementers to have the freedom to expand beyond WebID basics. In short, basic WebID is the minimum interop point, other features can be used to enhance the trust semantics on a per implementation basis. 

Anyway, that's what we've also sought to do, this is why we already to the account dance via OAuth :-)




 
Folks we really understand directory 1992 might be able to explain the notion of sub-entries, which equate in some sense to #tagged graphs within a foaf card, and have some interesting inheritcance and schema control models in support.
 
Anyways , good news, since rarely does MSFT do something that is not on solid IP grounds (i.e. well supported with modern IP, or the process/system is just really ancient).
Yes. That's my experience of MSFT. Worked them in early '90s, and their tech even earlier.

Kingsley




 
_______________________________________________
foaf-protocols mailing list
foaf-protocols at lists.foaf-project.org
http://lists.foaf-project.org/mailman/listinfo/foaf-protocols

-- 

Regards,

Kingsley Idehen	      
President & CEO 
OpenLink Software     
Web: http://www.openlinksw.com
Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca: kidehen 





_______________________________________________ foaf-protocols mailing list foaf-protocols at lists.foaf-project.org http://lists.foaf-project.org/mailman/listinfo/foaf-protocols 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.foaf-project.org/pipermail/foaf-protocols/attachments/20110306/c58b0ba0/attachment-0001.htm 


More information about the foaf-protocols mailing list