|The underlying problem here is to create a mechanism where Alice can tell target.com to get her authenticated and approved FOAF from source.com without giving her source.com ID+Password to target.com.|
0)User is on target.com and chooses a link to "create account using FOAFnet"
1) User chooses source.com from a drop down, or copies in a URL. The URL might be:- http://source.com/login.php
2) target.com redirects to the source.com login page with a parameter which is the URL to return to at target.com. eg http://source.com/login.php?return=http://target.com/accountcreate.php (suitably escaped)
3) source.com displays a login page. User logs in.
4) If successful, user is redirected back to target.com with a URL to collect the FOAF as a parameter. This URL stays valid for (say) 5 minutes. eg
5) target.com collects the FOAF from the URL
6) source.com verifies that the hash is valid and hasn't timed out. It might also check that the domain requesting it is the same as the redirect URL when it was created. If it all checks out it deletes the record so the hash can't be used again.
7) source.com returns the FOAF
8) target.com processes the FOAF, creates the record and thanks the user.
As far as the user is concerned all they had to do was identify source.com (via drop down choice or URL) and then sign in.
If some federation is required, then source.com can check the referer field at step 3 and 6 that target.com is known to it. There's probably some MD5 trickery and additional timestamp parameters to avoid having to store the hash. But I'd take the stupid route and just store it on the users record along with the timestamp.
So all we've used here is a http redirects and GET calls. We've got two named parameters in "return" and "foaf". And we've got a simple process. This shouldn't be hard to implement in any web aware language.
[ << Authentication, Security and FOAF ] [ FOAFnet Authentication - An Implementation >> ]
[ 31-Jul-04 8:53am ]