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

RE: [foaf-protocols] Redirects continued -- was: Problem with certificate on home-grown WebID

From: Peter Williams <home_pw@msn.com>
Date: Thu, 22 Dec 2011 07:39:57 -0800
Message-ID: <SNT143-W54E65EA8082C88C62949B192AA0@phx.gbl>
CC: "public-xg-webid@w3.org" <public-xg-webid@w3.org>

 I dont care about XRIs. I care about the argument being made - that URIs needed a persistent URI, since the ownser of a URI changes. The theorem of webid is that the user controls the URI, and its increasingly not true. As big as it is, the web has not actually used URIs  for personal identities. SO arguments about how bit the resource URI pool are are irrelevant. By and large, its a giant mess (that works at 80%). For personal privacy, we have to do better than 80%. (remember the University of Kent proved, in a $80k study that nobody wanted openid, becuase it was too crap, just before Google introduced it to Google Apps for academia :-) ). Now, if you look at the last  years of history on CRL DP URI used in windows, folks were concerned that they didnt want what paypal objected to about webid - having a large server farm's threads dependent on pinging an untrustworthy/untrusted server. in the CRL pulling world (given introduction of the CRLs URI by a cert, similarly to a SAN URI in a cert) windows servers doing email, web, and PPP EAP-TLS with client certs bearing URIs can be told to only ever pull the (CRL) resource from a cache (and never attempt to resolve (i.e. fully de-reference) the URI, that is). This was essentially the statement that the kernel's load balancer's cache was the persistent URI, and the value of the CRL DP URI in the cert a mere "hint". The cert checking engine doing validation had a trust point (its kernel, and its trusted computing base delivered by the CPU rings and the TPM chip for safe boot) for the cache identifiers. The local cache was the mapping from an URI onto its persistent URI. Im looking againt for Henrys server. I moved my RDFa html card to azure blog storage, on an https endpoint, and reminted the cert (with the same key). lets see how his software does with CRL DP URIs.  From: henry.story@bblfish.net
Date: Thu, 22 Dec 2011 10:37:09 +0100
CC: public-xg-webid@w3.org
To: kidehen@openlinksw.com
Subject: Re: [foaf-protocols] Redirects continued -- was: Problem with  certificate  on home-grown WebID

On 21 Dec 2011, at 20:34, Kingsley Idehen wrote:
    On 12/21/11 2:12 PM, Peter Williams wrote:
        let me summarize the OASIS position (stripping out the


        a URI depends on an authority field, in which the owner of the
        domain-name can change tomorrow (by court order, or US
        government seizure, or bankcrupcy, or ICANN wants money). Thus
        URIs are not authoritative per se. Something must be done, since
        that world on which we are relying is not stable.

This sounds like the kind of thing you would call on other occasions an "academic" problem, and in that mood you would argue that the web has been around with this type of issue and has grown very big without it. 


        Thus, have a persistent URI, that many temporary URIs using
        domain-names can refer to. Only the persistent form of URI is
        usable for security purposes. If presented with a non-persistent
        URI, a verifier must use a trusted service to determine the
        persistent "synonym".

And so have you not then just moved your trust to another system? Now you need to decide who is going to be your trusted service. It's no longer DNS or something else, it's the company you decide to trust, or what not.
Perhaps that is a viable solution. But given that people are having problems even with any kind of identifier, it seems to me that we can get some way without this issue appearing. That is at present I don't think that the issue for people is the longevity of their URIs. It is the problem of having too many, because these don't communicate. Too many URIs can be dealt with by owl:sameAs between the different Ids and redirects. That solves the problem of having to change URIs. Essentially in the semantic web we don't get tied up with the idea of needing ONE UNIQUE identifier per person.
Then all that is left for XRIs is the longevity issue. But perhaps there are simpler solutions to that. I think it's something to think about.


        Then, go on as normal.


        Now the challenge for webid:- How do we determine the persistent
        id, and how does one discover the provider of authority (for the
        claimed persistent URI).

You look at the relations towards it. It is a bit what happens if someone takes a site and changes the meaning of the URIs on it. Slowly all links to that site will disappear. You can also tell by looking when links to pages were made, when the document was originally published. 
The problem with XRIs is that they require a big infrastructure to get going. We already have HTTP so we can get going there with some limitations, but with tools everybody understands. 


        I dont know of any web architecture proposal. the web
        architecture punts, and denies there is an issue. The issue is
        not really about rediercts, its about the fidelity of the URI's
        authority field, and who speaks to it. I solved it (recall) by
        cheating. I trusted the CA as the source of authority, but this
        denied a core use case of webid - self-signed client certs. I
        thus failed the exam.

Self signed server certs will be easier to deploy with DNSsec. And DNSsec can then itself be verified by other services. And perhaps there is a role for XRIs later, or perhaps that can be simplified into something else.


    The greatest thing about this insight is the context for a little
    know reality:


    Linked Data somewhat came to the fore at the expense of OWL.
    Basically, OWL sadly became the reason why the Semantic Web didn't
    take off in the eyes of many. In reality, OWL was just another
    Semantic Web Project component that suffered from the verbosity,
    special treatment, and bottomless intransigence surrounding RDF/XML.


    For the Semantic Web to manifest, RDF/XML had to get out of the
    front door (DBpedia and the Linked Open Data project took care of
    that), Linked Data had to emerge as the Semantic Web Project's
    foundation layer, and eventually OWL as the sanitizer. After all,
    this is a story about logic, structured data, hyperlinks, relations,
    and semantic fidelity exploited at InterWeb scale. 


    There is something big here! Really big, but we cannot compromise
    the AWWW. Do that, and everything crumbles fast!







          From: home_pw@msn.com

          To: henry.story@bblfish.net

          CC: public-xg-webid@w3.org;

          Subject: RE: [foaf-protocols] Redirects continued -- was:
          Problem with certificate on home-grown WebID

          Date: Wed, 21 Dec 2011 09:52:23 -0800


            The first point to recognize is THAT FOLKS ARE GOING TO DO
            IT, regardless of what some book says. verifiers can view
            that as an attack, or just bad software. But either way, it
            has to be handled.


            The seecond point is to recall my original reasoning - that
            was by analogy. I know what openid spec says, when doing a
            similar task. I know webid says nothing. What SHOULD webid
            be saying, I asked? is its silence revealing? What did
            openid base its logic on, anyways?


            Now, openid leveraged a comprehsive security model for
            discovery (one designed by engineering folks who then wrote
            a large security section and specific threat model in the
            XRD spec).


            And, that is where you start Henry. Go read the security
            sections and threat model of XRDS (and thus understand
            "secure discovery" in openid, along with its redirects and
            cross-references). Go see how an engineered spec addresses
            the same class of underlying topics ...as you face here.  Go
            and understand WHY "pure" web architecture was insufficent,
            and they constructed an entirely new framework (that
            overlayed the web). Ths folk entirely understood RDF, in its
            full academic glory. Then, they went further (as engineers).




            Yes, its going to take a while to understand the trusted
            resolution model of XRD. I ended up having to program an XRD
            server, to get inside the head of the writer of those specs.
            but, at the end there was a comprehsnvie model of secure
            discovery, and de-referencing, that pertains both to simple
            objects (an array of service access points, say) and graphs.
            I learned (and it went beyond what I already knew from the
            secure chaining models of X.500 and H323)


            Dont listen to me; Im far to stupid to be in anything other
            thant the security space, trawling through checklists and
            tick sheets addressing simple (but effective) audit,
            control, and correctness goals.  My code is nothing other
            than a rewrite of a spec, to fit the needs of a stupid
            machine. Go and look in detail at some other web
            engineering, and the OASIS engineering outputs in
            particular. There you will enconter work from folks in the
            top rank of the class, and its WORTH comprehending, if you
            accept my recommendation. Once you dominate their model,
            then figure what webid needs.


            Here is a good start: http://middleware.internet2.edu/idtrust/2008/slides/01-reed-openid-xri-xrds.ppt


            Dont go into dismissal mode, and start politicking that its
            all hogwash (or ungodly, or some other punt). Read and
            understand what your betters have already done (and THEN do
            better than them). I have total faith in you, on this. You
            and you only can break this impasse, anbd still say
            reasonably consistent with the "web architecture". You are
            exactly the right person, to find the "right" solution to
            the redirect problem in a name resolution protocol.






































              Subject: Re: [foaf-protocols]
              Redirects continued -- was: Problem with certificate on
              home-grown WebID

              From: henry.story@bblfish.net

              Date: Wed, 21 Dec 2011 18:12:52 +0100

              CC: public-xg-webid@w3.org; sebastian@trueg.de;

              To: home_pw@msn.com



                On 21 Dec 2011, at 18:05, Peter Williams wrote:
                      Our colleague from the BBC already
                        made the case for redirects.


                        The case is just normal, in larger websites. The
                        content producer and the content manager are
                        different parties, in the publishing world.
                        Content manager get to reorganize links, as they
                        control when and if content gets un/published,
                        and where it gets re-published.


                        The question is, what does the spec say about
                        the security threats, and what are the counter


                Well since you have been in the security space for
                  so long, can you come up with some security
                threat scenarios? Start with simple ones, that we
                  can answer, and lets see if we can build
                more complex ones that are problematic.





                        > From: henry.story@bblfish.net

                          > Date: Wed, 21 Dec 2011 17:19:36 +0100

                          > To: pierre-antoine.champin@liris.cnrs.fr

                          > CC: foaf-protocols@lists.foaf-project.org; public-xg-webid@w3.org; sebastian@trueg.de

                          > Subject: Re: [foaf-protocols] Redirects
                          continued -- was: Problem with certificate on
                          home-grown WebID



                          > On 21 Dec 2011, at 16:57, Pierre-Antoine
                          Champin wrote:


                          > > Hi,

                          > > 

                          > > I had the same misunderstanding as
                          Sebastian, creating WebID

                          > > http://champin.net/pa

                          > > 

                          > > I now created

                          > > http://champin.net/#pa

                          > > (which I too prefer, btw).

                          > > 

                          > > But that one does not work with foafssl.org


                          > That's because at present it does not
                          have redirection implemented and you resource


                          > $ curl -i http://champin.net/ 

                          > HTTP/1.0 302 Found

                          > Server: BaseHTTP/0.3 Python/2.5.2

                          > Date: Wed, 21 Dec 2011 16:15:10 GMT

                          > Location: http://liris.cnrs.fr/~pchampin/

                          > Content-type: text/html

                          > Vary: Host



                          > > I attach the result page. It says

                          > > 

                          > > The WebId Profile must be parseable
                          Content and transformable to an

                          > > RDF graph


                          > yep, if I were to be serious about
                          redirects I'd have to change that to say: we
                          don't work with

                          > redirects.... 


                          > Since we are looking for use case for
                          webids that redirect, let me ask you: why did
                          you find

                          > it important to have your webid redirect?



                          > Henry


                          > > 

                          > > but RDF Validator is happy with it:

                          > > 

                          > > http://www.w3.org/RDF/Validator/ARPServlet?URI=http%3A%2F%2Fchampin.net%2F&PARSE=Parse+URI%3A+&TRIPLES_AND_GRAPH=PRINT_TRIPLES&FORMAT=PNG_EMBED

                          > > 

                          > > and it is recognized by https://auth.fcns.eu/

                          > > 

                          > > pa

                          > > 

                          > > 

                          > > On 12/21/2011 02:30 PM, Henry Story

                          > >> 

                          > >> On 21 Dec 2011, at 14:05,
                          Sebastian Trüg wrote:

                          > >> 

                          > >>> On 12/21/2011 11:19 AM,
                          Henry Story wrote:

                          > >>>> 

                          > >>>> On 21 Dec 2011, at
                          09:55, Sebastian Trüg wrote:

                          > >>>> 

                          > >>>>> Attached you find
                          the result from https://foafssl.org/test/WebId.
                          To be

                          > >>>>> honest I am not sure
                          if it succeeded or not, the output confuses
                          me. :/

                          > >>>> 

                          > >>>> yes, the output of this
                          test suite is not as well finished as the

                          > >>>> one. And there is a bug
                          there, I'll fix.

                          > >>>> 

                          > >>>> Ok, so you are using a
                          WebID that redirects. I would suggest against
                          it for

                          > >>>> two reasons:

                          > >>>> 

                          > >>>> -1. It increases the
                          verification time for the verifier: the
                          verifier has

                          > >>>> to potentially do 2 HTTP
                          connections, and in any case it has to do back

                          > >>>> and forth

                          > >>>> -2 It is possible that
                          some implementations don't support redirect,
                          as it is

                          > >>>> one of these less
                          obvious features of the web. As soon as you
                          add complexity

                          > >>>> you add ways things can
                          go wrong, and your identity is perhaps

                          > >>>> enough for you not to
                          want these things to go wrong

                          > >>>> (In this case my
                          implementation does not support it. But I can
                          add it)

                          > >>>> -3 We believe we have
                          worked out the security characteristics of

                          > >>>> but they are less
                          obvious than the simple GET and will require
                          more work,

                          > >>>> so we have no language
                          in the spec at present covering those - it's

                          > >>>> one might say. In any
                          case they confuse Peter Williams, and risk

                          > >>>> military grade security
                          people a lot more. So if you want to log in to

                          > >>>> security sites you may
                          find redirects create confusion with those

                          > >>>> implementing them. This
                          comes up in ISSUE-64

                          > >>>> http://www.w3.org/2005/Incubator/webid/track/issues/64

                          > >>>> 

                          > >>>> Does that make sense?

                          > >>> 

                          > >>> Well, yes. However, I am
                          confused. You directed me to the site which I

                          > >>> took this setup from.

                          > >> 

                          > >> http://www.w3.org/TR/2008/NOTE-swbp-vocab-pub-20080828/

                          > >> 

                          > >> Yes, it is true that the "Best
                          Practice Recipes for Publishing RDF

                          > >> covers two cases one of which
                          uses a redirect. The redirect is as we

                          > >> may require us to think things
                          through in a bit more detail, though I don't

                          > >> it is a big issue.

                          > >> 

                          > >>> Also you mentioned that it
                          would be nicer to have

                          > >>> web ids like http://www.trueg.de/sebastian
                          instead of something like

                          > >>> http://www.trueg.de/sebastian/foaf[#me].

                          > >> 

                          > >>> So which is it? :)

                          > >> 

                          > >> I think I mentioned WebIDs like 

                          > >> 

                          > >> http://www.trueg.de/sebastian#me 

                          > >> 

                          > >> rather than 

                          > >> 

                          > >> http://www.trueg.de/sebastian.rdf#me

                          > >> 

                          > >> not 

                          > >> 

                          > >> http://www.trueg.de/sebastian

                          > >> 

                          > >> with a redirect.

                          > >> 

                          > >> I think there is a pragmatic
                          consideration in favour of the # one to do
                          with reduction

                          > >> in communication costs. 

                          > >> 

                          > >> But you are right that this
                          would do well to be more clearly specified in

                          > >> spec.

                          > >> 

                          > >>> 

                          > >>>> So having said that
                          there are a number of redirect types, 

                          > >>>> http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html

                          > >>>> 

                          > >>>> 300 Multiple Choices

                          > >>>> 301 Moved Permanently

                          > >>>> 302 Found // we can
                          ignore this one

                          > >>>> 303 See Other

                          > >>>> 304 Not Modified

                          > >>>> 305 Use Proxy

                          > >>>> 307 Temporary Redirect

                          > >>>> 

                          > >>>> and one needs to
                          consider which of these have what types of
                          security implications, if any.

                          > >>>> Perhaps there is not
                          much more to do here than to just think it
                          though. But if we want to

                          > >>>> help implementors
                          implement the WebId protocol so that you get a
                          consistent experience between

                          > >>>> each verification
                          service, and so that you are not left out in
                          the cold inexplicably

                          > >>>> some places and not
                          others, then we need to work this out. As you
                          see it is easier and more

                          > >>>> efficient to stick to

                          > >>>> 

                          > >>>> The question is if there
                          are any good rason for non #urls in our
                          authentication use case.

                          > >>> 

                          > >>> Only the prettyness of the
                          URL which should be irrelevant in the end

                          > >>> since the point is to not
                          show it to the user, right.

                          > >> 

                          > >> yes, that alone would not make
                          for a very good reason. Perhaps there are
                          others. It would

                          > >> be good to collect them.

                          > >> 

                          > >>> I simply followed your
                          advise, or maybe misunderstood your advise...

                          > >> 

                          > >> No you are doing well :-) You're
                          helping us think about this issue 2^6 here.
                          It's an important

                          > >> one. 

                          > >> 

                          > >> Henry

                          > >> 

                          > >>> 

                          > >>> Cheers,

                          > >>> Sebastian

                          > >>> 

                          > >>>> Henry

                          > >>>> 

                          > >>>>> 

                          > >>>>> Cheers,

                          > >>>>> Sebastian

                          > >>>>> 

                          > >>>>> On 12/20/2011 10:44
                          PM, Henry Story wrote:

                          > >>>>>> Ok, I have
                          updated the server to the new scala version.

                          > >>>>>> 

                          > >>>>>> I hope it
                          remains up until you read this e-mail. I am
                          still working on the details

                          > >>>>>> of how to
                          release it. But if it is still up please let
                          me know if it works now

                          > >>>>>> with your key.

                          > >>>>>> 

                          > >>>>>> Henry

                          > >>>>>> [snip]

                          > >>>> 

                          > >>>> Social Web Architect

                          > >>>> http://bblfish.net/

                          > >>>> 

                          > >>>> 

                          > >> 

                          > >> Social Web Architect

                          > >> http://bblfish.net/

                          > >> 

                          > >> 

                          > > 

                          > > <WebId.html>


                          > Social Web Architect

                          > http://bblfish.net/



                          > foaf-protocols mailing list

                          > foaf-protocols@lists.foaf-project.org

                          > http://lists.foaf-project.org/mailman/listinfo/foaf-protocols


                      foaf-protocols mailing list



                                          Social Web Architect






Kingsley Idehen	      
Founder & CEO 
OpenLink Software     
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca handle: @kidehen
Google+ Profile: https://plus.google.com/112399767740508618350/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen


Social Web Architect

Received on Thursday, 22 December 2011 15:40:38 UTC

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