Preliminary note
This document is subject to change and will hopefully be turned into a new XEP. It is assumed that you have some knowledge of the XMPP protocol.
Conformance Terms
The following keywords as used in this document are to be interpreted as described in RFC 2119: "MUST", "SHALL", "REQUIRED"; "MUST NOT", "SHALL NOT"; "SHOULD", "RECOMMENDED"; "SHOULD NOT", "NOT RECOMMENDED"; "MAY", "OPTIONAL".
Table of contents
1. Introduction
This document describes the communication between the Client and the Server's DIAS agent.
It assumes that you know the DIAS mechanism, including the meaning and the role of a 'Server', a 'Client' and an 'Agent'.
2. Service discovery
Service discovery is an XMPP extension for discovering information about Jabber entities and the items associated with such entities. The DIAS agent SHOULD use service discovery to advertise itself as such.
To see whether an entity can behave as a DIAS agent, the Client makes an "#info" query to the entity. If supported, the entity includes a <feature/> with the "var" of "http://weeno.net/dias/agent".
Example 1. Discovery request for information
<iq from='Client@jabber.org' to='agent@stuff.net' type='get' id='disco1'> <query xmlns='http://jabber.org/protocol/disco#info'/> </iq>
Example 2. Discovery result for information
<iq from='agent@stuff.net' to='Client@jabber.org' type='get' id='disco1'>
<query xmlns='http://jabber.org/protocol/disco#info'>
...
<feature var='http://weeno.net/dias/agent'/>
...
</query>
</iq>
3. Asking and getting a ticket
To ask for a ticket, the requester sends an <iq/>, containing an empty <ticket> stanza and an OPTIONAL <referer> stanza. The agent responds with a <ticket> stanza containing the value of the ticket. It MAY include a <url> containing the direct URL to be used by the Client in order to avoid phishing attacks. It MAY also include an <info> containing a human-readable informational text and a <ttl> containing the time-to-live, in seconds, of the ticket.
Sometimes the agent refuses to deliver a ticket, e.g. because it does not accept the given referer. If this happens, it sends an <error> stanza.
Example 3. Ticket request
<iq type='get' from='Client@jabber.org' to='agent@stuff.net' id='dias1'>
<ticket xmlns='http://weeno.net/dias/'>
<referer>http://stuff.net/auth.php</referer>
</ticket>
</iq>
Example 4. Normal result
<iq type='result' from='agent@stuff.net' to='Client@jabber.org' id='dias1'>
<ticket xmlns='http://weeno.net/dias/'>
<value>70ed8cca0d2685d8d866b3f729f4220c115723b6</value>
<ttl>60</ttl>
<url>http://stuff.net/auth.php?ticket=70ed8cca0d2685d8d866b3f729f4220c115723b6</url>
<info>Welcome to the Motorbike Forum. Your access is now enabled.</info>
</ticket>
</iq>
Example 5. Error result
In this example, the referer given by the requester is not accepted.
<iq type='error' from='agent@stuff.net' to='Client@jabber.org' id='dias1'>
<error type='modify'>
<not-acceptable xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'>
<bad-referer xmlns='http://weeno.net/dias/xmpp-stanzas'>
</error>
</iq>
4. Security considerations
To avoid phishing attacks, before asking a ticket to an entity the requester SHOULD check the entity's VCard, to make sure that it matches the entity the Client aims to authenticate against. Thus, the entity SHOULD have a VCard with up-to-date, detailed information.
In addition to that, if DIAS is used for an URL-aware Chanel, the requester SHOULD include a <referer> stanza containing the URL of the Server, so that the responder has a chance to reject the ticket request if it refers to a Server that the agent does not know.
Last, the responder SHOULD include a <url> stanza in the ticket response, so that the requester can access it directly and thus bypass any phishing attempt. Here again, this only makes sense when using DIAS on communication channels that involve the use of URLs.