[foaf-dev] # # in urls

Peter Williams pwilliams at rapattoni.com
Mon Sep 28 17:53:33 CEST 2009


On the openid general list, Henry and I were recently discussing foaf+ssl (+openid), and ways of using urls. While Henry appears mostly focused on signaling attributes from a foaf file to an openid OP (which will then assert said values using openid assertions to its consumers), I happen to be more interested in foaf+ssl being used directly by said consumers (which may optional use the services of an openid OP, to help confirm veracity).

I finally found an example from the Microsoft world of using multiple "fragments" in an URL.

http://msdn.microsoft.com/en-us/library/ms531424(VS.85).aspx (see #default#userData).

As is typical for ignorant Peter, I misnamed the feature I half-understood - improperly calling it "multiple" fragments. From the URL syntax, there is only one fragment (whose delimiter is #). But, as used in the Microsoft example, additional (#) delimiters can be correctly and properly used within the fragment tag. Internal tag parsing (using a lexer defined by the resource authority) can signal meaning(s) of delimited sub-components. One meaning set is suggested by the Microsoft profile, of course.

What I wanted to do originally and still want to do it (particularly as openid culture gets more and more about insisting that there MUST be trusted third parties OPs between users and relying parties) is allow a webid to apply the #fragment component notion suggested by the Microsoft application.

If the typical webid is http://peter.com/foaf.rdf#me and said webid was to be placed in the self-signed cert, what Id still like to do is allow the self-signed cert to bear http://peter.com/foaf.rdf#me#<hash> instead. The idea here is that the foaf+ssl protocol engine on the consumer side would only process the SSL client cert IF it is able to resolve a foaf file matching the hash.

My understanding of theory (which may of course differ from practice) is that folks receiving  #me#<hash> tag should be able to treat it opaquely during inferencing - assuming the engine has no knowedge of the resource authority's meaning (of subcomponent). And, if the foaf file rules are appropriate designed, #me#<hash> may be specified to be equivalent to #me, of course (as may #me#<hash2>).

Comment, if any, welcome.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.foaf-project.org/pipermail/foaf-dev/attachments/20090928/b88b281d/attachment.htm 


More information about the foaf-dev mailing list