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

[Story Henry]

On 31 Aug 2009, at 03:30, Peter Williams wrote:

>> 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.

yes, the mime type of the document returned determines the  
interpretation of the document.
Note that the mime type for rdf/xml is

application/rdf+xml

There is no need to add ";webid=true", as rdf/xml and other rdf/ 
formats specify this process clearly. I mean the process of how one  
takes a document with relative URIs to produce a graph with absolute  
URIs.

There are rdf serialisations which don't require such a process. The  
NTriples format for example encodes everything as an absolute URL. See:
	http://www.w3.org/2001/sw/RDFCore/ntriples/

You can translate any rdf document in NTriples using the python cwm  
script.

$ cwm  http://bblfish.net/people/henry/card --ntriples

> 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)!

Currently in foaf+ssl we don't sign the foaf file. For security, to  
avoid man in the middle attacks, it should be served via https.

I am not sure what the correct procedure for signing xml files would  
be. I did not look into that yet, as it adds one more layer of  
complexity to the framework, and we are trying to drive adoption, so  
we can test the concepts in more detail.

>
> 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.

SSL as it is used for fetching the foaf file, is used here only as a  
secure transport mechanism. It is transparent to the semweb layer.

> 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".

The ssl implementation that needs to be hacked is the Relying Party's  
one. The server serving the foaf file is a bog standard one, and does  
not need to be patched.

The Relying Party's ssl server needs to be a lot more flexible than  
most ssl stacks are when it asks for the client certificate. In foaf 
+ssl we do not need to tie the client certificate to a well known  
Certificate Authority (CA). This is exactly what makes foaf+ssl so  
attractive.

  The default implementation of ssl in Java, tries to verify the CA.  
If it does not know the CA, then the connection attempt is deemed have  
failed. This is what needs to be patched. Details on how to do this in  
Java are here:

http://blogs.sun.com/bblfish/entry/how_to_setup_tomcat_as

It is quite easy to get the same done in Apache. There is a way to set  
up apache so that it can pass the client cert onto the CGI application  
to continue the verification procedure.


> 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).

I think you should find this even easier than you thought. If you just  
want to use Apache check out the documentation on http://foaf.me,  
which uses php. We have implementations in perl and python too.

	Henry