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

peter williams home_pw at msn.com
Mon Mar 7 17:59:26 CET 2011


Looking at that United States Patent 7434253 patent, it would address
sending the webid in SNI or HTTP header.

 

Only when the webid claim is wholly "in the cert" are folks on safer
grounds. Only when the webid is a (self-contained" locator are folks on
safer grounds.

 

If the _resolver_ address FOR the webid URI is _deduced from_ the webid,
that deduction cannot leverage information from the client PC (e.g.
sessionIDs, or IP address, or anything else).That would a hint, too. For
example of such an indirect hint, an earlier cert in the client cert chain -
that is sent by the client PC - is such a hint.

 

It's a nasty patent for FOAF+SSL/webid world, whenever the server then maps
the URI to a user "account".

 

As always, its only nasty till it gets invalidated by prior art. This will
have to wait till money is flowing in the webid world, that pays for all
that kind of preparatory study and the litigation(s). I have the material
(being in this area for decades), but as always it needs organizing for the
kinds of arguments that lawyers make, when forcing or otherwise dealing with
infringement claims etc.

 

 

From: foaf-protocols-bounces at lists.foaf-project.org
[mailto:foaf-protocols-bounces at lists.foaf-project.org] On Behalf Of Peter
Williams
Sent: Sunday, March 06, 2011 8:19 PM
To: kidehen at openlinksw.com; foaf-protocols at lists.foaf-project.org
Subject: Re: [foaf-protocols] looking back to 1988 for proof that cert
existance in container => valid

 

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 <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/20110307/ad9f2984/attachment-0001.htm 


More information about the foaf-protocols mailing list