W3C home > Mailing lists > Public > public-xg-webid@w3.org > June 2011

Re: [foaf-protocols] WebID test suite

From: Kingsley Idehen <kidehen@openlinksw.com>
Date: Fri, 24 Jun 2011 21:00:36 +0100
Message-ID: <4E04ECE4.30206@openlinksw.com>
To: public-xg-webid@w3.org
On 6/24/11 7:08 PM, Peter Williams wrote:
> The defacto owl sameAs part is really interesting (and its the semweb 
> part of webid that most interests me, since its about the potential 
> logic of enforcement....)
> are we saying that should n URIs be present in a cert and one of them 
> validates to the satisfaction of the verifying party, then this 
> combination of events is the statement: verifer says owl:sameAs x, 
> where x is each member of the set of SAN URIs in the cert, whether or 
> not all x were verified .


When an IdP is presented with a Cert, it is going to have its own 
heuristic for picking one WebID. Now, when there are several to choose 
from I would expect that any choice results in a path to a Public Key -> 
WebID match. Basically, inference such as owl:sameAs would occur within 
the realm of the IdP that verifiers a WebID. Such inference cannot be 
based on the existence of multiple URIs serving as WebIDs in SAN (or 
anywhere else).
> Thats quite a claim to make. An more restrcitied claim could be that

Yes, but I don't believe the spec infers that.
> verifier says webid says owl:sameAs x, where x is each member of the 
> set of SAN URIs in the cert, whether or not all x were verified .

No, don't think that's the implication from spec or what one would 
expect to happen.

> ------------------------------------------------------------------------
> From: henry.story@bblfish.net
> Date: Fri, 24 Jun 2011 19:12:59 +0200
> CC: public-xg-webid@w3.org; foaf-protocols@lists.foaf-project.org
> To: home_pw@msn.com
> Subject: Re: [foaf-protocols] WebID test suite
> On 24 Jun 2011, at 18:45, Peter Williams wrote:
>     one thing the spec does not state is what is correct behaviour
>     when a consumer is prersented with a cert with multiple SAN URIs.
> Well it does say something, even if perhaps not in the best way. It says:
> in 3.1.4
> "The Verification Agent 
> <http://www.w3.org/2005/Incubator/webid/spec/#dfn-verification_agent>/must/ attempt 
> to verify the public key 
> <http://www.w3.org/2005/Incubator/webid/spec/#dfn-public_key> information 
> associated with at least one of the claimed WebID URI 
> <http://www.w3.org/2005/Incubator/webid/spec/#dfn-webid_uri>s. The 
> Verification Agent 
> <http://www.w3.org/2005/Incubator/webid/spec/#dfn-verification_agent>/may/ attempt 
> to verify more than one claimed WebID URI 
> <http://www.w3.org/2005/Incubator/webid/spec/#dfn-webid_uri>."
> then in 3.1.7
> If the public key 
> <http://www.w3.org/2005/Incubator/webid/spec/#dfn-public_key> in the 
> Identification Certificate 
> <http://www.w3.org/2005/Incubator/webid/spec/#dfn-identification_certificate> matches 
> one in the set given by the profile document graph given above then 
> the Verification Agent 
> <http://www.w3.org/2005/Incubator/webid/spec/#dfn-verification_agent>knows 
> that the Identification Agent 
> <http://www.w3.org/2005/Incubator/webid/spec/#dfn-identification_agent> is 
> indeed identified by the WebID URI 
> <http://www.w3.org/2005/Incubator/webid/spec/#dfn-webid_uri>.
> I think the language that was going to be used for this was the 
> language of "Claimed WebIDs" - the SANs in the certificate, which each 
> get verified. The verified WebIDs are the ones the server can use to 
> identify the user. They are de-facto owl:sameAs each other.
>     If the test suite is run at site A (that cannot connect to a
>     particular part of the interent, becuase of proxy rules)
>     presumably the test suite would provide a different result to
>     another site which can perform an act of de-referencing.
> That is ok, the server would state declaratively which WebIDs were 
> claimed and which were verified. It could state why it could not 
> verify one of the WebIDs. Network problems is a fact of life, less 
> likely than strikes in France - though those have been not been 
> happening that often recently - or congestions on the road.
>     This is a general issue. The degenrate case occurs for 1 SAN URI,
>     obviously - since siteA may not be able to connect to its agent.
>     Thus, the issue of 1 or more multiple URIs is perhaps not the
>     essential requirement at issue.
>     A variation of the topic occurs when a given site (B say) is using
>     a caching proxy, that returns a cached copy of a webid document
>     (even though that document may have been removed from the
>     web). This is the topic of trusted caches, upon which it seems
>     that webid depends.
> That is what the meta testing agent will be able to tell. He will be 
> able to put up WebID profiles log in somewhere, then login a few days 
> later after having removed the profile, or changed it and report on 
> how the servers respond.
>      We would look silly if the average site grants access to a
>     resource when the identity document has been removed from the web,
> It all depends on what the cache control statements on the WebID 
> Profile says. If they state they should last a year, then it is partly 
> the fault of the WebID profile publisher. (Could Web Servers offer 
> buttons to their users to update a cache?)
> In any case it also depends on how serious the transaction is. In a 
> serious transaction it might be worth doing a quick check right before 
> the transaction, just in case.
>     yet cache continue to make consuemr believe that the identity is
>     valid. At the same time, given the comments from the US identity
>     conference (that pinging the internet during a de-referencing act
>     is probably unsunstainable), caches seem to be required (so
>     consuming sites dont generate observable network activity).
> WebID works with caches. I don't think we could think without. Even 
> X509 works with caches as is, since really an X509 signed cert is just 
> a cache of the one offered by the CA.
>     This all seems to be pointing at the issue that we have a trusted
>     cache issue at the heart of the webid proposal, and of course we
>     all know that the general web is supposed to be a (semi-trusted at
>     best) cache.
> Caches need to be taken into account. But I don't see this as a major 
> problem.
>     > From:henry.story@bblfish.net <mailto:henry.story@bblfish.net>
>     > Date: Fri, 24 Jun 2011 13:37:26 +0200
>     > CC:foaf-protocols@lists.foaf-project.org
>     <mailto:foaf-protocols@lists.foaf-project.org>
>     > To:public-xg-webid@w3.org <mailto:public-xg-webid@w3.org>
>     > Subject: WebID test suite
>     >
>     > Hi,
>     >
>     > In the spirit of test driven development, and in order to
>     increate the rate at which we can evolve WebID, we need to develop
>     test suites and reports based on those test suites.
>     >
>     > I put up a wiki page describing where we are now, where we want
>     to go.
>     >
>     >http://www.w3.org/2005/Incubator/webid/wiki/Test_Suite#
>     >
>     > Please don't hesitate to improve it, and place your own library
>     test end points up there - even if they
>     > are only human readable.
>     >
>     > The next thing is to look at the EARL ontology I wrote and see if
>     your library can also generate a test report, that folows the lead
>     of the one I put up onbblfish.net <http://bblfish.net/>. I expect
>     a lot of detailed criticism, because I did just hack this
>     together. As others implement their test reports, and as bergi
>     builds his meta tests we will quickly notice our disagreements,
>     and so be able to discuss them, and put the results into the spec.
>     >
>     > Henry
>     >
>     > Social Web Architect
>     >http://bblfish.net/
>     >
>     >
>     _______________________________________________
>     foaf-protocols mailing list
>     foaf-protocols@lists.foaf-project.org
>     <mailto:foaf-protocols@lists.foaf-project.org>
>     http://lists.foaf-project.org/mailman/listinfo/foaf-protocols
> Social Web Architect
> http://bblfish.net/



Kingsley Idehen	
President&  CEO
OpenLink Software
Web: http://www.openlinksw.com
Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca: kidehen
Received on Friday, 24 June 2011 20:01:15 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:39:45 UTC