- From: Kingsley Idehen <kidehen@openlinksw.com>
- Date: Fri, 24 Jun 2011 21:00:36 +0100
- To: public-xg-webid@w3.org
- Message-ID: <4E04ECE4.30206@openlinksw.com>
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 . No. 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. Kingsley > ------------------------------------------------------------------------ > 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/ > -- Regards, 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