- From: Kingsley Idehen <kidehen@openlinksw.com>
- Date: Wed, 29 Jun 2011 22:00:29 +0100
- To: Henry Story <henry.story@bblfish.net>
- CC: public-xg-webid@w3.org
- Message-ID: <4E0B926D.6020502@openlinksw.com>
On 6/28/11 11:28 AM, Henry Story wrote: > > On 28 Jun 2011, at 11:18, Kingsley Idehen wrote: > >> On 6/28/11 6:53 AM, Henry Story wrote: >>> >>> On 28 Jun 2011, at 03:10, Peter Williams wrote: >>> >>>> >>>> I think you keep ignoring the fact that from time eternal browsers >>>> have had ldap clients built in, using LDAP URLs. >>> >>> I don't ignore it. I even mentioned the ldap url as being a >>> possibility for a WebId. >> >> Not a possibility, unless you are truly ignoring the fact that we >> already support ldap: scheme URIs (as SAN placed WebIDs) in our >> implementation of WebID. > > An actuality is a possibility. A manifestation of a possibility :-) > But one implementation does not a web make, and I doubt that ldap is > the easiest or most direct way to create a web of data: you'd have to > re-invent the semantic web to get that going. So that is the point here. One implementation that works unobtrusively with a Web of WebID isA part of a Web. It isn't HTTP based, but it works flawlessly in an HTTP based Web. That's the essence of my point. > >> As I keep on saying: URIs are sacrosanct. An IdP is the one to decide >> which schemes it can handle as part of its implementation of the >> WebID protocol. > > Yes, we don't restrict URIs in the spec. > >> >>> >>>> The issue is not ldap. its the fact that directories, whether ifs >>>> foaf cards, vcards, micro-formats, or any other projection of the >>>> directory record stuggle, becuase the security model was not a good >>>> social fit. Im convinced websso has got the the heart of that fit >>>> problem. And, thus, as you assert, ldap becomes an "attribute >>>> source", no different to sql or a foaf card. >>> >>> Yes, people don't want to open their ldap directories to anyone >>> without protection. But they can only open them globally if they >>> have something like WebID, and if they have a data format that >>> allows for global linkability. >> >> Yes, and that's achievable and implemented by us already. > > Kingsley, in order for this to work at a global level, you need to > have something like a GRDDL for LDAP formats, so that distributed > databases can communicate information without ambiguity and without > knowing each other ahead of time. What is GRDDL? That's about middleware for tranformation. So if I GRDDL inside, of do what GRDDL does (and even more) without calling it GRDDL does that (via literal label) not deliver on the fundamental concept? Semantics to me is about meaning that (of course) decipherable via labels, but labels (natural language) are lossy and ambiguous. Call it whatever, we have ldap: scheme WebIDs supported in our IdP and it works with clients speak WebID protocol, that's it. > I don't know of that having been specified yet by the W3C or anybody else. > >> >>> Ldap started off in the 1980 before the web, and was extended >>> without ever fixing these problems, which of course are difficult to >>> fix. The Web was designed as a hyperdocument platform from the >>> begninning. >> >> Yes, so you can transform data to many representations once its clear >> that the base schema is really conceptual rather than syntactic. >> Basically, logic delivers the conceptual schema. > > Yes, but unless you want to go to each ldap hoster and ask them what > in his version of ldap the fields mean, then you can't really build a > linked data web on ldap endpoints (ie: directly accessible ldap > endpoints globally available). > > Here is an ldap entry taken from wikipedia > dn: cn=John Doe,dc=example,dc=com > cn: John Doe > givenName: John > sn: Doe > telephoneNumber: +1 888 555 6789 > telephoneNumber: +1 888 555 1232 > mail:john@example.com <mailto:john@example.com> > manager: cn=Barbara Doe,dc=example,dc=com > objectClass: inetOrgPerson > objectClass: organizationalPerson > objectClass: person > objectClass: top > > It is an attribute value pair system, without namespacing, and so is > designed for client server interaction, not for linked data interaction. Again, middleware techniques existed before GRDDL turning the above into a Linked Data graph with a clearly define Subject in a graph that's associated with a Public Key via a WOT relation. Basically: Subject: mailto:john@example.com associated with all the Attribute=Value pairs above, in triple form as part of a structured profile + the public key association via the WOT relation. > You need to tie those into a global namespacing. Not impossible, but > you have a lot of work on your hands to get all the others to 1. > understand why it is important (because they are living in closed > worlds, and don't see what they are missing) and 2. Get an agreement > world wide on how to do this. Instead of long arguments here, why not just test the service, its live [1]: 1. https://id.myopenlink.net/ods/webid_demo.html -- WebID verification that supports WebIDs based on multiple schemes e.g. http:, mailto:, acct:, ldap: . Kingsley > >> >>> >>>> >>>> Now, what is intresting is that we keep expecting foaf cards (which >>>> are just serialized directory records, using a non-LDIF format) to >>>> find a fit, somehow addressing what failed in the ldap world. >>> >>> Foaf is based on RDF, which is designed for Linked Data (hyperdata) >>> scenarios. >>> >>> Of course Ldap can participate too, but it would to need to give a >>> clear mapping into the semweb, ie to give semantics so that users >>> from one ldap system can communicate clearly - and without prior >>> agreement on vocabulary - with another ldap system. But as I don't >>> think this is done yet, I think we can skip ldap as a priority for >>> the moment. >> >> The spec just has to be agnostic re. URI schemes. The support of any >> scheme re. WebID is an implementation matter for an IdP that supports >> the WebID protocol. That's really it. URIs are sacrosanct. Inherently >> agnostic. > > If you find something going amiss in the spec, please tell us. > >> >>> >>> If you find some big ldap vendors who really want to join, then the >>> W3C may be happy to help them semwebise the ldap system, and perhaps >>> ldap urls will combine nicely and often with http and https urls. >>> But my guess is that you will end up with huge resistance there in >>> the ldap world: there will just be too many new things to explain to >>> people. Unless it is shown to work clearly in the most natural >>> platform - the web - they won't take it on. >> >> We'll be taking our implementation to them :-) >> >>> >>> And after all who cares whether it is ldap or http that is the >>> transport protocol? Certainly not the business people who would >>> finance this. >> >> See my earlier comment. >>> >>> >>> Anyway what has this got to do with the WebID Test suite again? >>> Please try to keep the posts on topic. >> >> Well you'll see that ldap: based WebIDs work with our implementation :-) > > As I said, one implementation is not sufficient. One needs more than > one - at least three - and they have to be interoperable. It is great > that you are trying these out ahead of time. But if we can concentrate > here on getting the test cases for http and https working - and there > was strong consensus for that - then we can grow to ldap after having > solved the widely used cases. > > What I would like is to have us focus on the details of the EARL test > cases now for http and https, to make sure the structure is right. If > you see that we are closing the door technically inadvertently to > ldap, please point that out. > > Henry > >> >> >> Kingsley >>> >>> Henry >>> >>> >>>> This worries me. >>>> >>>> >>>> ------------------------------------------------------------------------ >>>> From:henry.story@bblfish.net <mailto:henry.story@bblfish.net> >>>> Date: Sun, 26 Jun 2011 18:43:24 +0200 >>>> CC:demoss.matt@gmail.com >>>> <mailto:demoss.matt@gmail.com>;public-xg-webid@w3.org >>>> <mailto:public-xg-webid@w3.org> >>>> To:home_pw@msn.com <mailto:home_pw@msn.com> >>>> Subject: Re: [foaf-protocols] WebID test suite >>>> >>>> >>>> On 26 Jun 2011, at 17:23, Peter Williams wrote: >>>> >>>> >>>> The X.509 standard worked worldwide - albeit mostly amongst >>>> universities. It was probably bigger than is the Shib world, >>>> even today. This seems to have been before Henry's time (he >>>> likes to tell the story that ldap/dap was never web scale, not >>>> realizing perhaps that the first directories "on the web" were >>>> http -> ldap -> dap gateways...). >>>> >>>> >>>> The point is the protocol was not made available directly on the >>>> web, in such a way that it could be interoperable directly as ldap. >>>> For example TCP/IP works at web scale, so does SMTP which is >>>> broken, but ldap is used a bit like SQL databases as a back end. >>>> There are logical reasons in the case of LDAP and of SQL for this. >>>> But I think you keep ignoring them: the URL. >>>> >>>> Today, of course, there are a few 10s of million AD >>>> installations, that we can expect to start connecting up quite >>>> shortly, now SAML->AD gateways are going mainstream. What folks >>>> refused to do (federate and publish directories), folks seem >>>> more willing to do when SAML claims project said directories to >>>> a limited network of consuming sites. >>>> >>>> >>>> Perhaps SAML has more of a chance, it uses a few web technologies: >>>> XML and namespaces for one. They even started working on a RESTful >>>> variant I heard. I am not a specialist of it. >>>> >>>> >>>> X.500 also had both simple and strong authentication, and the >>>> usual user, consumer (SP) and IDP model. Both could use signed >>>> operations between the "IDP" agent (the master agent for the >>>> record, in a multi-mastering world), and the consuming agent - >>>> some service, today just like a SAML2 SP server, that wishes >>>> to obtain a signed confirmation that the user knows a password, >>>> compared remotely by the IDP in return for a signed >>>> confirmation response). The user presented the password + >>>> digested-password to the consumer (!) seeking access to some >>>> port, and duely the port guard would issue a compare operation >>>> against the IDP agent. Alternatively, the user presented a >>>> signed token to the consumer, which verified it in party by >>>> "comparing" the cert against the cert in the master record. >>>> Again, the IDP would respond to a compare request with a >>>> signed token confirming the result o comparing the values. >>>> Today, in windows its trivial to issue a signed SAML "request" >>>> to a web service on an https port, that is then compared >>>> similarly. blog formats have changed - but the model has not. >>>> >>>> >>>> >>>> yesterday, I had some fun. In a MSFT sample project, one has >>>> ones client code create a "self-signed SAML file", supported by >>>> a self-signed cert. One posts this to a azure serivce, which >>>> verifies the signature and returns a mac-signed json blob - >>>> which one then posts in the www-auth header to a rest service. >>>> The claims within have identity, authn and authz claims. Being >>>> done on the OAUTH endpoint, its a minor variant of the process >>>> to induce the service to redirect to a website, seeking user >>>> confirmation etc (in the usual OAUTH backwards-flow SSO flow), >>>> There, one can do webid...validation as a condition of release >>>> the authz confirmation. >>>> If we could get less abstract, reseachy, and less webby - and >>>> just fit in with the rest of the web - we'd have a lot more >>>> adoption. >>>> >>>> >>>> Well there are all these other communities to join where people are >>>> happy to do that. >>>> Nobody is saying we can't be interoperable, btw, I don't know why >>>> anyone whould thinks so. But the intersting thing of WebID - as >>>> the name hints in a not too shy manner - is the Webiness. Now that >>>> does not stop you from storing your data in an sql database, ldap >>>> dp, or nosql datastore. We are not concerned about those here. We >>>> abstract them so as to be compatible with anything going on behind. >>>> >>>> Henry >>>> >>>> > Date: Fri, 24 Jun 2011 16:45:46 -0400 >>>> > From:demoss.matt@gmail.com <mailto:demoss.matt@gmail.com> >>>> > To:henry.story@bblfish.net <mailto:henry.story@bblfish.net> >>>> > CC:kidehen@openlinksw.com >>>> <mailto:kidehen@openlinksw.com>;public-xg-webid@w3.org >>>> <mailto:public-xg-webid@w3.org> >>>> > Subject: Re: [foaf-protocols] WebID test suite >>>> > >>>> > >Its spec concepttually little or no different to using a >>>> directory object from ldap, looking for existance of a cert >>>> value in the directory attribute.. >>>> > >>>> > >that is why I distinguish - and we should distinguish more >>>> clearly in the spec - between a claimed WebID and a verified >>>> one. A WebID presented in the SAN fields of an X509 certificate >>>> is a claimed WebID. >>>> > The Relying Party/IDP then fetches the canonical document for >>>> each WebID >>>> > >>>> > I find the contrast with a directory object to be particularly >>>> > interesting. It's usually the case that the CA is trusted to >>>> sign a DN >>>> > that corresponds to a directory object in a directory we trust >>>> to have >>>> > the correct attributes, but I would be interested to know more >>>> about >>>> > other systems where (as with WebID) the trust relationship is >>>> a bit >>>> > different. Do any of the SAML profiles do something you would >>>> consider >>>> > comparable? >>>> > >>>> > On Fri, Jun 24, 2011 at 4:31 PM, Henry Story >>>> <henry.story@bblfish.net <mailto:henry.story@bblfish.net>> wrote: >>>> > > >>>> > > On 24 Jun 2011, at 22:00, Kingsley Idehen wrote: >>>> > > >>>> > > 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). >>>> > > >>>> > > Yes, that is why I distinguish - and we should distinguish >>>> more clearly in >>>> > > the spec - between a claimed WebID and a verified one. A >>>> WebID presented in >>>> > > the SAN fields of an X509 certificate is a claimed WebID. >>>> > > The Relying Party/IDP then fetches the canonical document >>>> for each WebID. >>>> > > These documents define the meaning of the WebID, of that >>>> URI, via a >>>> > > definitive description tying the URI to knowledge of the >>>> private key of the >>>> > > public key published in the certificate. >>>> > > If the meaning of two or more URIs is tied to knowledge of >>>> the same public >>>> > > key, then the relying agent has proven of each of these URIs >>>> that its >>>> > > referent is the agent at the end of the https connection. >>>> Since that is one >>>> > > agent, the two URIs refer to the same thing. >>>> > > >>>> > > >>>> > > >>>> > > >>>> > > 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 <mailto:henry.story@bblfish.net> >>>> > > Date: Fri, 24 Jun 2011 19:12:59 +0200 >>>> > > CC:public-xg-webid@w3.org >>>> <mailto:public-xg-webid@w3.org>;foaf-protocols@lists.foaf-project.org >>>> <mailto:foaf-protocols@lists.foaf-project.org> >>>> > > To:home_pw@msn.com <mailto: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 must attempt to verify the public >>>> key information >>>> > > associated with at least one of the claimed WebID URIs. >>>> The Verification >>>> > > Agent may attempt to verify more than one claimed WebID URI." >>>> > > then in 3.1.7 >>>> > > If the public key in the Identification Certificate matches >>>> one in the set >>>> > > given by the profile document graph given above then >>>> the Verification >>>> > > Agentknows that the Identification Agent is indeed >>>> identified by the 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 on bblfish.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 <http://www.openlinksw.com/> >>>> > > Weblog:http://www.openlinksw.com/blog/~kidehen >>>> <http://www.openlinksw.com/blog/%7Ekidehen> >>>> > > Twitter/Identi.ca: kidehen >>>> > > >>>> > > >>>> > > >>>> > > >>>> > > >>>> > > Social Web Architect >>>> > >http://bblfish.net/ >>>> > > >>>> > >>>> > >>>> >>>> >>>> Social Web Architect >>>> http://bblfish.net/ >>>> >>>> >>> >>> 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 >> >> >> >> > > 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 Wednesday, 29 June 2011 21:01:14 UTC