[OpenID] Windows Live ID OpenID CTP Status Update (August 2009)

[Peter Williams]

-----Original Message-----
From: hjs at bblfish.net [mailto:hjs at bblfish.net] On Behalf Of Story Henry
Sent: Sunday, August 30, 2009 9:50 AM
To: Peter Williams
Cc: openid-general at lists.openid.net; John Bradley
Subject: Re: [OpenID] Windows Live ID OpenID CTP Status Update (August 2009)





On 30 Aug 2009, at 17:28, Peter Williams wrote:

> I took my counsel on fragments from http://java.sun.com/javase/6/docs/api/java/net/URL.html?is-external=true

>

> "This fragment is not technically part of the URL. []"



That is sleight of hand in the Java documentation. That Java

documentation is not authoritative on the meaning of URLs. That's an

implementors point of view. :-)





Not that it's too relevant since we got to the more important architectural points ore relevant to openid, but the java doc is entirely supported by the (older) RFC on URLs that it references, which says the same thing.



The ref's syntax is necessarily resource-defined, and the UA should parse it according to the dictates of the media type sent along with the retrieved file. If the foaf stream at a webid s delivered under a mime type with suitable qualifier (e.g. text/foaf+rdf;webid=true ) the UA (which of course is the OP's or RP's SSL server) can know to parse out the fragment ref of the non absolute URI part of the webid, thereby determining from the cert a hash component. From existing knowhow I have, I know its trivial to take the apache xml dsig resolver for digesting http references, subclass the resolver to de-reference the webid, and ensure its digest is equal not to the digest values in the xml dsig block now but to the hash component on the webid (after parsing the fragment, to suit the profile)!



Hardly very semweb, I agree; but then semweb reasoning doesn't address ssl. And, here we are using SSL not only as a transport but as a signaling mechanism for the public key id.



To the lexer, a fragment's tag (ref/reference) is also apparently a *uric - which charset apparently includes hash (not that this choice of separator is exactly critical!)



I believe I saw that your project allows source programmers to take an SSL server implementation, add it to tomcat listener/server, and then "extend SSL". If this is true, I'll have a go - since I have a certain familiarity with the insides of the SSL protocol. I think this is all within my prototyping capabilities. I completed adding signed XRD chains to the XRI server last month, which got me over 10 years laziness/avoidance-of anything to do with Java enterprise systems. Java on the server side is seeming all rather cute (now someone _else_ has made it mature).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20090830/e496f605/attachment.htm>