Contents

[edit]

How To Request Authentication

The _request_authentication method is used to ask a UNI if a network entity with certain characteristics is actually a linked location of hers. The method can have different sorts of arguments in variables which are helpful to the UNI to take the decision.

  • When given a _location variable it needs to contain the full uniform of the client that claims to be linked to the UNI. The UNI will compare it to the main client link (maybe it should foreach through all possible services instead).
  • When given a _host_IP it will compare the IP address with the location of the user. This can either be a client UNL or - in psyced - the peer address of a telnet, IRC, Jabber, webchat etc connection.
  • When given a _nonce, it will compare it to the nonce stored in the user. The nonce was once sent to the client at linking time, so the client can pass it on to other applications. You can also create one manually using the /token command.
  • You can also provide the user's _password, or the hashed password according to _method. Known methods currently are md5, http-digest and digest-md5.

Either a _notice_authentication or _error_invalid_authentication is issued after the comparisons. Should the request turn out non-obvious to reply to, a _notice_processing_authentication will be issued. You can look at checkAuthentication() in person.c where this is implemented.

[edit]

Enhance IRC with PSYC auth

A simple IRC client could provide for basic PSYC functionality simply by publishing its user's identity uniform in its $IRCNAME field (4th argument to USER in IRC protocol).

As soon as you bump into other PSYCers on IRC, you could connect, subscribe, become friends. By means of PSYC auth you can identify your friends on any IRC network, like a NickServ spanning all IRC networks at once. This would also make the nickname a user has on a particular IRC network completely unimportant - a smart PSYC/IRC hybrid client could ignore her IRC nick and just display the PSYC nickname you chose for her.

Also, should your channel actually happen to be a PSYC place it could authenticate you with your identity and sort-of upgrade you to an identified PSYC being.

The IRC client thus provides for the most minimal of requirements for a PSYC client, delegate to the identity.

(See also the idea on Inter-Client Protocol Negotiation)
[edit]

Single sign-on over HTTP and PSYC

Here's an idea from 2003.. append ?UNI=psyc://... to web requests (a "UNI" variable containing the identity uniform) for selected websites. A PSYC-enhanced web browser like PsycZilla could make it even nicer, by providing "UNI:" headers directly in HTTP. The web server would then use PSYC auth to verify the browsing identity.

Alternatively the server could request a WWW-Authenticate from the PSYC realm which the browser could handle interactively or automatically. XEP-0070 proposes that same idea for XMPP.

[edit]

Pragmatically speaking

20after4 would like to integrate Drupal with PSYC auth. The plan is: Have a psyced running on localhost (for trivial trust), then connect psyced on port 4404 and come up with this request: 

.

<PSYCvars>
_request_authenticate_poll
.

The PSYC variables are as described at the beginning of this document for authentication. No MMP variables are necessary, as the source is the incoming connection and the target is the server being asked. We could provide for both _request_authenticate and _request_authenticate_poll methods where the first looks up the information, then asynchronously returns it whereas the second answers immediately with either a final result or an intermediate excuse. So if your web app intends to close the connection and ask again later, use the _poll variant. By the way, if you want the server to do a clean close of the socket, you can send it a _request_circuit_shutdown instead of just closing the socket (which might make you lose something as the server sends to you).

Caution, this is just a proposal - it's not implemented yet. Do you like it?

<Monkey> Sounds good. "poll" is a dirty word but sometimes unavoidable. Don't spend any energy on this it's certainly not high priority. It would be nice to get some form of psyc auth going though, even if it's not very scalable.

poll: Wanted to make it clear that it's a gateway into a world that doesn't think event-oriented. energy: This is a very feasible 30 minute type of thing, plus another 30 minutes to make sure it works. The authentication backend is already there in the library.

[edit]

Social networks based on PSYC auth

Once you have PSYC auth in place you can make your social network access data that you wouldn't let average joe users access. the most obvious uses would be: a blog or a photo website just for your friends, and it reports usage to the blog owner in realtime, if you want it to.

... the Private Web!

[edit]

Authenticated PSYC forums and blogs

By clicking on a notification in the chat you can enter private forums and blogs and leave verified comments inaccessible to the general public. But maybe it is more exciting to deliver HTML directly by PSYC anyway.

(See also Newscasting, PsycZilla).
[edit]

Pushing PSYC auth

You may prefer to have all of your websites and applications subscribe to your authentication context. Similarly to presence, when you log in, your websites will be pushed currently valid auth information so your browser can log into them directly using auth data fed from the PSYC client. No more transactions on the server side necessary.

Or you could announce your web visit on demand in advance via PSYC, so by the time you connect to them via HTTP they already know who you are and trust you to do all the important things you came to do.

This means a little behavioral change for you on the browsing side: Your PSYC client gets to manage your web bookmarks, and instructs the web browser to access certain HTTP URLs it has agreed upon in advance with that webserver via PSYC.

[edit]

Questions & Answers

<kuchn> Does this mean we are only checking IP numbers? What if an IP number is shared by multiple people? Do we need the password in that case?

<lynX> Each identity can decide for itself what its requirements are to acknowledge a _request_authenticate. In some cases an IP number may be sufficient, in other cases a password or a one-time token. Consider also more cryptographic approaches using hashes etc.

[edit]

See also

[edit]

Related Technologies