The underlying problem here is to create a mechanism where Alice can tell to get her authenticated and approved FOAF from without giving her ID+Password to

0)User is on and chooses a link to "create account using FOAFnet"

1) User chooses from a drop down, or copies in a URL. The URL might be:-

2) redirects to the login page with a parameter which is the URL to return to at eg (suitably escaped)

3) displays a login page. User logs in.

4) If successful, user is redirected back to with a URL to collect the FOAF as a parameter. This URL stays valid for (say) 5 minutes. eg

5) collects the FOAF from the URL

6) 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) returns the FOAF

8) processes the FOAF, creates the record and thanks the user.

As far as the user is concerned all they had to do was identify (via drop down choice or URL) and then sign in.

If some federation is required, then can check the referer field at step 3 and 6 that 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 ]