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

On 12/21/11 2:12 PM, Peter Williams wrote:
> let me summarize the OASIS position (stripping out the technology).
>
> 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.
>
> 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".
>
> 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).
>
> 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.

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!


Kingsley
>
>
>
> ------------------------------------------------------------------------
> From: home_pw@msn.com
> To: henry.story@bblfish.net
> CC: public-xg-webid@w3.org; foaf-protocols@lists.foaf-project.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; 
> foaf-protocols@lists.foaf-project.org
> 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 measures?
>
>
> 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.
>
>
> Henry
>
>
>
>     > From:henry.story@bblfish.net <mailto:henry.story@bblfish.net>
>     > Date: Wed, 21 Dec 2011 17:19:36 +0100
>     > To:pierre-antoine.champin@liris.cnrs.fr
>     <mailto:pierre-antoine.champin@liris.cnrs.fr>
>     > CC:foaf-protocols@lists.foaf-project.org
>     <mailto:foaf-protocols@lists.foaf-project.org>;public-xg-webid@w3.org
>     <mailto:public-xg-webid@w3.org>;sebastian@trueg.de
>     <mailto: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
>     <http://foafssl.org> :-(
>     >
>     > That's because at present it does not have redirection
>     implemented and you resource redirects
>     >
>     > $ 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/
>     <http://liris.cnrs.fr/%7Epchampin/>
>     > 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
>     <http://www.w3.org/RDF/Validator/ARPServlet?URI=http://champin.net/&PARSE=Parse+URI:+&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 wrote:
>     > >>
>     > >> 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 previous
>     > >>>> 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 important
>     > >>>> 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 redirects,
>     > >>>> 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 undefined
>     > >>>> one might say. In any case they confuse Peter Williams, and
>     risk confusing
>     > >>>> military grade security people a lot more. So if you want to
>     log in to higher
>     > >>>> security sites you may find redirects create confusion with
>     those people
>     > >>>> 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 Vocabularies"
>     > >> covers two cases one of which uses a redirect. The redirect is
>     as we mentioned
>     > >> may require us to think things through in a bit more detail,
>     though I don't think
>     > >> 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]
>     <http://www.trueg.de/sebastian/foaf%5b#me%5d>.
>     > >>
>     > >>> 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 the
>     > >> 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 #urls.
>     > >>>>
>     > >>>> 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
>     <mailto:foaf-protocols@lists.foaf-project.org>
>     >http://lists.foaf-project.org/mailman/listinfo/foaf-protocols
>     _______________________________________________
>     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	
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