mirror of
https://github.com/moparisthebest/xeps
synced 2024-12-21 23:28:51 -05:00
initial published version
This commit is contained in:
stpeter
parent
be3b82bda4
commit
35029d1c7e
388
xep-0290.xml
Normal file
388
xep-0290.xml
Normal file
@ -0,0 +1,388 @@
|
||||
<?xml version='1.0' encoding='UTF-8'?>
|
||||
<!DOCTYPE xep SYSTEM 'xep.dtd' [
|
||||
<!ENTITY % ents SYSTEM 'xep.ent'>
|
||||
%ents;
|
||||
]>
|
||||
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
|
||||
<xep>
|
||||
<header>
|
||||
<title>Encapsulated Digital Signatures in XMPP</title>
|
||||
<abstract>This document provides a technical specification for Encapsulated Digital
|
||||
Signatures in the Extensible Messaging and Presence Protocol (XMPP).</abstract>
|
||||
&LEGALNOTICE;
|
||||
<number>0290</number>
|
||||
<status>Experimental</status>
|
||||
<type>Standards Track</type>
|
||||
<sig>Standards</sig>
|
||||
<approver>Council</approver>
|
||||
<dependencies>
|
||||
<spec>XMPP Core</spec>
|
||||
<spec>XEP-0001</spec>
|
||||
</dependencies>
|
||||
<supersedes/>
|
||||
<supersededby/>
|
||||
<shortname>N/A</shortname>
|
||||
&kdz;
|
||||
<revision>
|
||||
<version>0.1</version>
|
||||
<date>2011-01-26</date>
|
||||
<initials>psa</initials>
|
||||
<remark><p>Initial published version.</p></remark>
|
||||
</revision>
|
||||
<revision>
|
||||
<version>0.0.1</version>
|
||||
<date>2010-11-29</date>
|
||||
<initials>kdz</initials>
|
||||
<remark>
|
||||
<p>Proto-XEP draft.</p>
|
||||
</remark>
|
||||
</revision>
|
||||
</header>
|
||||
|
||||
<section1 topic="Introduction" anchor="intro">
|
||||
<p>This document provides a technical specification for Encapsulated Digital Signatures in
|
||||
Extensible Messaging and Presence Protocol (&xmpp;).</p>
|
||||
<p>XMPP Digital Signatures may be used to provide signer authentication, data integrity,
|
||||
non-repudiation, and other security services.</p>
|
||||
<p>This extension is intended to be highly flexible, supporting a wide range of applications.
|
||||
The extension not only supports signing by the originator, but by other entities which
|
||||
handle XMPP stanzas. Multiple entities may independently sign a stanza.</p>
|
||||
<p>A signed manifest approach is used to allow selective signing (only select elements
|
||||
may be included in the manifest) and to allow flexibility in handling verification
|
||||
errors.</p>
|
||||
<p>This extension is intended to support <em>optimistic signing</em>.</p>
|
||||
<p>This document offers an encapsulated signature approach based upon &w3xmlsig; (XMLDSIG).
|
||||
Implementations of this extension not required to fully implement the XML DSIG
|
||||
specification, they may implement only the minimal subset necessary to support this
|
||||
extension.</p>
|
||||
<p>It is noted that a number of object-level XMPP digital signature extensions have been
|
||||
specified over the years. These include &rfc3923; (XMPP E2E), &xep0116; (XMPP PGP),
|
||||
and &xep0285;. The limited applicability of encapsulating signature approaches in XMPP
|
||||
is discussed in &xep0274;.</p>
|
||||
</section1>
|
||||
<section1 topic="Signing XMPP Stanzas" anchor="stanza">
|
||||
<p>The process that a sending agent follows for securing stanzas is very similar regardless
|
||||
of the form of stanza (i.e., <iq/>, <message/>, or <presence/>).</p>
|
||||
|
||||
<p>The signer begins with the cleartext version of the <message/> stanza "S":</p>
|
||||
<example><![CDATA[
|
||||
<message from='juliet@capulet.net/balcony'
|
||||
id='183ef129'
|
||||
to='romeo@montague.net'>
|
||||
<thread>8996aef0-061d-012d-347a-549a200771aa</thread>
|
||||
<body>Wherefore art thou, Romeo?</body>
|
||||
</message>
|
||||
]]></example>
|
||||
|
||||
<p>This is modified prior to signing as follows:</p>
|
||||
<ul>
|
||||
<li>Default attribute values are added. (Namespace declarations are not modified.)</li>
|
||||
<li>Each child element of the stanza is augmented by a <tt>id</tt> attribute
|
||||
qualified in the <tt>urn:xmpp:dsig:0</tt> namespace. As these attributes are used to
|
||||
identify the element within a manifest, they must be sufficient unique.</li>
|
||||
</ul>
|
||||
<example><![CDATA[
|
||||
<message from='juliet@capulet.net'
|
||||
id='183ef129'
|
||||
to='romeo@montague.net'
|
||||
type='chat'>
|
||||
<thread xmlns:d="urn:xmpp:dsig:0" d:id="xxxx-1">8996aef0-061d-012d-347a-549a200771aa</thread>
|
||||
<body xmlns:d="urn:xmpp:dsig:0" d:id="xxxx-2">Wherefore art thou, Romeo?</body>
|
||||
</message>
|
||||
]]></example>
|
||||
|
||||
<p>The signer builds a stanza description object containing a signer element, the stanza
|
||||
element, and a timestamp element. The signer element value is the bare JID of the
|
||||
signing entity. When the signing entity is a service entity, the JID may only contain
|
||||
service domain. The stanza element is the stanza prepared above with each of its element
|
||||
replaced by an reference element.</p>
|
||||
<example><![CDATA[
|
||||
<stanza id="stanza-desc" xmlns="urn:xmpp:dsig:0">
|
||||
<signer>juliet@capulet.net</signer>
|
||||
<message from='juliet@capulet.net'
|
||||
id='183ef129'
|
||||
to='romeo@montague.net'
|
||||
type='chat'>
|
||||
<reference>xxxx-1</reference>
|
||||
<reference>xxxx-2</reference>
|
||||
</message>
|
||||
<timestamp>2010-11-11T13:33:00.123Z</timestamp>
|
||||
</stanza>
|
||||
]]></example>
|
||||
|
||||
<p>The signer then builds an XMLDSIG Manifest object which references each element via the
|
||||
<tt>xmpp:dsig:ref:0</tt> URN and provides a digest over the element (after it has
|
||||
been modified to include a <tt>d:id</tt> attribute) as transformed by the transformation
|
||||
algorithm.</p>
|
||||
<example><![CDATA[
|
||||
<Manifest id="manifest">
|
||||
<Reference URI="urn:xmpp:dsig:ref:0#xxxx-1">
|
||||
<Transforms>
|
||||
<Transform Algorithm="urn:xmpp:dsig:transform:0"/>
|
||||
</Transform>
|
||||
<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
|
||||
<DigestValue>...</DigestValue>
|
||||
</Reference>
|
||||
<Reference URI="urn:xmpp:dsig:ref:0#xxxx-2">
|
||||
<Transforms>
|
||||
<Transform Algorithm="urn:xmpp:dsig:transform:0"/>
|
||||
</Transform>
|
||||
<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
|
||||
<DigestValue>...</DigestValue>
|
||||
</Reference>
|
||||
</Manifest>
|
||||
]]></example>
|
||||
|
||||
<p>The signer then builds a SignedInfo element.</p>
|
||||
<example><![CDATA[
|
||||
<SignedInfo>
|
||||
<CanonicalizationMethod Algorithm="urn:xmpp:dsig:transform:0"/>
|
||||
<SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#dsa-sha1"/
|
||||
<Reference URI="#stanza-desc">
|
||||
<Transforms>
|
||||
<Transform Algorithm="http://www.w3.org/2006/12/xml-c14n11"/>
|
||||
</Transform>
|
||||
<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
|
||||
<DigestValue>...</DigestValue>
|
||||
</Reference>
|
||||
<Reference URI="#manifest" Type="http://www.w3.org/2000/09/xmldsig#Manifest">
|
||||
<Transforms>
|
||||
<Transform Algorithm="http://www.w3.org/2006/12/xml-c14n11"/>
|
||||
</Transform>
|
||||
<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
|
||||
<DigestValue>...</DigestValue>
|
||||
</Reference>
|
||||
</SignedInfo>
|
||||
]]></example>
|
||||
|
||||
<p>And then produces a Signature element:</p>
|
||||
<example><![CDATA[
|
||||
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
|
||||
<SignedInfo>
|
||||
<CanonicalizationMethod Algorithm="http://www.w3.org/2006/12/xml-c14n11"/>
|
||||
<SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#dsa-sha1"/
|
||||
<Reference URI="#stanza-desc">
|
||||
<Transforms>
|
||||
<Transform Algorithm="http://www.w3.org/2006/12/xml-c14n11"/>
|
||||
</Transform>
|
||||
<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
|
||||
<DigestValue>...</DigestValue>
|
||||
</Reference>
|
||||
<Reference URI="#manifest" Type="http://www.w3.org/2000/09/xmldsig#Manifest">
|
||||
<Transforms>
|
||||
<Transform Algorithm="http://www.w3.org/2006/12/xml-c14n11"/>
|
||||
</Transforms>
|
||||
<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
|
||||
<DigestValue>...</DigestValue>
|
||||
</Reference>
|
||||
</SignedInfo>
|
||||
<SignatureValue/>
|
||||
<Object>
|
||||
<stanza id="stanza-desc" xmlns="urn:xmpp:dsig:0">
|
||||
<signer>juliet@capulet.net</signer>
|
||||
<message from='juliet@capulet.net'
|
||||
id='183ef129'
|
||||
to='romeo@montague.net'
|
||||
type='chat'>
|
||||
<reference>xxxx-1</reference>
|
||||
<reference>xxxx-2</reference>
|
||||
</message>
|
||||
<timestamp>2010-11-11T13:33:00.123Z</timestamp>
|
||||
</stanza>
|
||||
</Object>
|
||||
<Object>
|
||||
<Manifest id="manifest">
|
||||
<Reference URI="urn:xmpp:dsig:ref:0#xxxx-1">
|
||||
<Transforms>
|
||||
<Transform Algorithm="urn:xmpp:dsig:transform:0"/>
|
||||
</Transform>
|
||||
<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
|
||||
<DigestValue>...</DigestValue>
|
||||
</Reference>
|
||||
<Reference URI="urn:xmpp:dsig:ref:0#xxxx-2">
|
||||
<Transforms>
|
||||
<Transform Algorithm="urn:xmpp:dsig:transform:0"/>
|
||||
</Transform>
|
||||
<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
|
||||
<DigestValue>...</DigestValue>
|
||||
</Reference>
|
||||
</Manifest>
|
||||
</Object>
|
||||
</Signature>
|
||||
]]></example>
|
||||
|
||||
<p> The signer than computes the SignatureValue element, processing the Signature element as
|
||||
a detached signature, and replaces the empty Signature element with it. Finally, the
|
||||
signer inserts the Signature element into stanza and forwards the stanza as it normally
|
||||
would.</p>
|
||||
<example><![CDATA[
|
||||
<message from='juliet@capulet.net'
|
||||
id='183ef129'
|
||||
to='romeo@montague.net'
|
||||
type='chat'>
|
||||
<thread xmlns:d="urn:xmpp:dsig:0" d:id="xxxx-1">8996aef0-061d-012d-347a-549a200771aa</thread>
|
||||
<body xmlns:d="urn:xmpp:dsig:0" d:id="xxxx-2">Wherefore art thou, Romeo?</body>
|
||||
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
|
||||
<SignedInfo>
|
||||
<CanonicalizationMethod Algorithm="http://www.w3.org/2006/12/xml-c14n11"/>
|
||||
<SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#dsa-sha1"/
|
||||
<Reference URI="#stanza-desc">
|
||||
<Transforms>
|
||||
<Transform Algorithm="http://www.w3.org/2006/12/xml-c14n11"/>
|
||||
</Transform>
|
||||
<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
|
||||
<DigestValue>...</DigestValue>
|
||||
</Reference>
|
||||
<Reference URI="#manifest" Type="http://www.w3.org/2000/09/xmldsig#Manifest">
|
||||
<Transforms>
|
||||
<Transform Algorithm="http://www.w3.org/2006/12/xml-c14n11"/>
|
||||
</Transforms>
|
||||
<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
|
||||
<DigestValue>...</DigestValue>
|
||||
</Reference>
|
||||
</SignedInfo>
|
||||
<SignatureValue>...</SignatureValue>
|
||||
<Object>
|
||||
<stanza id="stanza-desc" xmlns="urn:xmpp:dsig:0">
|
||||
<signer>juliet@capulet.net</signer>
|
||||
<message from='juliet@capulet.net'
|
||||
id='183ef129'
|
||||
to='romeo@montague.net'
|
||||
type='chat'>
|
||||
<reference>xxxx-1</reference>
|
||||
<reference>xxxx-2</reference>
|
||||
</message>
|
||||
<timestamp>2010-11-11T13:33:00.123Z</timestamp>
|
||||
<stanza>
|
||||
</Object>
|
||||
<Object>
|
||||
<Manifest id="manifest">
|
||||
<Reference URI="urn:xmpp:dsig:ref:0#xxxx-1">
|
||||
<Transforms>
|
||||
<Transform Algorithm="urn:xmpp:dsig:transform:0"/>
|
||||
</Transform>
|
||||
<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
|
||||
<DigestValue>...</DigestValue>
|
||||
</Reference>
|
||||
<Reference URI="urn:xmpp:dsig:ref:0#xxxx-2">
|
||||
<Transforms>
|
||||
<Transform Algorithm="urn:xmpp:dsig:transform:0"/>
|
||||
</Transform>
|
||||
<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
|
||||
<DigestValue>...</DigestValue>
|
||||
</Reference>
|
||||
</Manifest>
|
||||
</Object>
|
||||
</Signature>
|
||||
</message>
|
||||
]]></example>
|
||||
</section1>
|
||||
|
||||
<section1 topic="Transformation Algorithm" anchor="transform">
|
||||
<p>For referenced elements of a stanza, the referenced element is normalized (omitting
|
||||
comments), as detailed in &w3canon;, as a document subset of a document containing a
|
||||
stream element containing the appropriate jabber:client stanza element containing the
|
||||
stanza with the referenced elements. Note that jabber:client stanzas are used when
|
||||
constructing this document even when a server is signing a stanza to be sent to another
|
||||
server.</p>
|
||||
<p>For the stanza in Example 2, the input document would be:</p>
|
||||
<example><![CDATA[
|
||||
<stream:stream xmlns='jabber:client" xmlns:stream='http://etherx.jabber.org/streams'>
|
||||
<message from='juliet@capulet.net'
|
||||
id='183ef129'
|
||||
to='romeo@montague.net'
|
||||
type='chat'>
|
||||
<thread xmlns:d="urn:xmpp:dsig:0" d:id="xxxx-1">8996aef0-061d-012d-347a-549a200771aa</thread>
|
||||
<body xmlns:d="urn:xmpp:dsig:0" d:id="xxxx-2">Wherefore art thou, Romeo?</body>
|
||||
</message>
|
||||
</stream:stream>
|
||||
]]></example>
|
||||
|
||||
<p>The canonical form of element referenced by <tt>urn:xmpp:dsig:ref:0#xxx-1</tt> would
|
||||
be:</p>
|
||||
<example><![CDATA[<thread xmlns="jabber:client" xmlns:d="urn:xmpp:dsig:0" d:id="xxxx-1">8996aef0-061d-012d-347a-549a200771aa</thread>]]></example>
|
||||
</section1>
|
||||
|
||||
<section1 topic="Stanza Element References" anchor="references">
|
||||
<p>The URI 'uri:xmpp:dsig:ref:0#xxxx" refers to the child element of the stanza which
|
||||
contains the 'uri:xmpp:dsig:0' 'id' attribute with the value "xxxx".</p>
|
||||
</section1>
|
||||
|
||||
<section1 topic="Inclusion and Checking of Timestamps" anchor="timestamps">
|
||||
<p>Timestamps are included to help prevent replay attacks. All timestamps MUST conform to
|
||||
&rfc3339; and be presented as UTC with no offset, always including the seconds and
|
||||
fractions of a second to three digits (resulting in a datetime 24 characters in length).
|
||||
Absent a local adjustment to the sending agent's perceived time or the underlying clock
|
||||
time, the sending agent MUST ensure that the timestamps it sends to the receiver
|
||||
increase monotonically (if necessary by incrementing the seconds fraction in the
|
||||
timestamp if the clock returns the same time for multiple requests). The following rules
|
||||
apply to the receiving application:</p>
|
||||
|
||||
<ul style="symbols">
|
||||
<li>It MUST verify that the timestamp received is within five minutes of the current
|
||||
time, except as described below for offline messages.</li>
|
||||
<li>If the foregoing check fails, the timestamp SHOULD be presented to the receiving
|
||||
entity (human or application) marked with descriptive text indicating "old
|
||||
timestamp" or "future timestamp" and the receiving entity MAY return a stanza error
|
||||
to the sender (except as precluded in the protocol).</li>
|
||||
</ul>
|
||||
|
||||
<p>The foregoing timestamp checks assume that the recipient is online when the message is
|
||||
received. However, if the recipient is offline then the server will probably store the
|
||||
message for delivery when the recipient is next online (offline storage does not apply
|
||||
to <iq/> or <presence/> stanzas, only <message/> stanzas). As
|
||||
described in &xep0160;, when sending an offline message to the recipient, the server
|
||||
SHOULD include delayed delivery data as specified in &xep0203; so that the recipient
|
||||
knows that this is an offline message and also knows the original time of receipt at the
|
||||
server. In this case, the recipient SHOULD verify that the timestamp received in the
|
||||
encrypted message is within five minutes of the time stamped by the recipient's server
|
||||
in the <delay/> element.</p>
|
||||
</section1>
|
||||
|
||||
<section1 topic="Mandatory-to-Implement Cryptographic Algorithms" anchor="mti">
|
||||
<p>All implementations MUST support the following algorithms. Implementations MAY support
|
||||
other algorithms as well.</p>
|
||||
<ul>
|
||||
<li>TBD</li>
|
||||
</ul>
|
||||
</section1>
|
||||
|
||||
<section1 topic="Certificates" anchor="certs">
|
||||
<p>To participate in end-to-end signing using the methods defined in this document, a client
|
||||
needs to possess an X.509 certificate. It is expected that many clients will generate
|
||||
their own (self-signed) certificates rather than obtain a certificate issued by a
|
||||
certification authority (CA). In any case the certificate MUST include an XMPP address
|
||||
that is represented using the ASN.1 Object Identifier "id-on-xmppAddr" as specified in
|
||||
Section 5.1.1 of RFC 3920bis.</p>
|
||||
</section1>
|
||||
|
||||
<section1 topic="Security Considerations" anchor="security">
|
||||
<p>TBD.</p>
|
||||
</section1>
|
||||
|
||||
<section1 topic="XMPP Registrar Considerations" anchor="reg">
|
||||
<section2 topic="XML Namespace Name for Signed Data in XMPP" anchor="ns">
|
||||
<p>A URN sub-namespace of signed content for the Extensible Messaging and Presence
|
||||
Protocol (XMPP) is defined as follows.</p>
|
||||
<dl>
|
||||
<di>
|
||||
<dt>URI:</dt>
|
||||
<dd>urn:xmpp:dsig</dd>
|
||||
</di>
|
||||
<di>
|
||||
<dt>Specification:</dt>
|
||||
<dd>ProtoXEP</dd>
|
||||
</di>
|
||||
<di>
|
||||
<dt>Description:</dt>
|
||||
<dd>This is an XML namespace name of signed content for the Extensible Messaging
|
||||
and Presence Protocol as defined by ProtoXEP.</dd>
|
||||
</di>
|
||||
<di>
|
||||
<dt>Registrant Contact:</dt>
|
||||
<dd>XSF</dd>
|
||||
</di>
|
||||
</dl>
|
||||
</section2>
|
||||
</section1>
|
||||
</xep>
|
||||
147
xep-0291.xml
Normal file
147
xep-0291.xml
Normal file
@ -0,0 +1,147 @@
|
||||
<?xml version='1.0' encoding='UTF-8'?>
|
||||
<!DOCTYPE xep SYSTEM 'xep.dtd' [
|
||||
<!ENTITY % ents SYSTEM 'xep.ent'>
|
||||
%ents;
|
||||
]>
|
||||
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
|
||||
<xep>
|
||||
<header>
|
||||
<title>Service Delegation</title>
|
||||
<abstract>This specification defines an approach for users to delegate certain services (e.g. pubsub) to alternative JIDs.</abstract>
|
||||
&LEGALNOTICE;
|
||||
<number>0291</number>
|
||||
<status>Experimental</status>
|
||||
<type>Standards Track</type>
|
||||
<sig>Standards</sig>
|
||||
<dependencies>
|
||||
<spec>XMPP Core</spec>
|
||||
</dependencies>
|
||||
<supersedes/>
|
||||
<supersededby/>
|
||||
<shortname>NOT_YET_ASSIGNED</shortname>
|
||||
&infiniti;
|
||||
<revision>
|
||||
<version>0.1</version>
|
||||
<date>2011-01-26</date>
|
||||
<initials>psa</initials>
|
||||
<remark><p>Initial published version.</p></remark>
|
||||
</revision>
|
||||
<revision>
|
||||
<version>0.0.1</version>
|
||||
<date>2010-01-05</date>
|
||||
<initials>jk</initials>
|
||||
<remark><p>First draft.</p></remark>
|
||||
</revision>
|
||||
</header>
|
||||
|
||||
<section1 topic='Introduction' anchor='intro'>
|
||||
<p>It is common to use XMPP user accounts for identity. Many features for user accounts have been proposed (for example, &xep0084;, &xep0277;, etc), and this list only grows as XMPP heads into social networking territory. However, not every XMPP server in the world supports every feature, nor can this ever be expected, and this limits the usefulness of the XMPP user account identity. Also, even when servers do support a feature it may not be clear how to bind an identity to it (see the never-solved problem of learning where a user's generic &xep0060; service is, in the absence of &xep0163;). Organizations such as Buddycloud and Livefyre have recognized the need to be able to offer features to existing standard XMPP accounts by offering proprietary service delegation mechanisms. This specification proposes a Standards Track solution for discovering external services associated with XMPP user identities.</p>
|
||||
</section1>
|
||||
|
||||
<section1 topic='How It Works' anchor='protocol'>
|
||||
<section2 topic='Discovering Delegate Services' anchor='discover'>
|
||||
<p>To learn of delegate services for a user, query the bare JID of the user:</p>
|
||||
<example caption="Query for delegate services"><![CDATA[
|
||||
<iq type="get" from="alice@example.com/home" to="bob@example.com" id="d1">
|
||||
<query xmlns="urn:xmpp:tmp:delegate"/>
|
||||
</iq>
|
||||
]]></example>
|
||||
<example caption="Success response"><![CDATA[
|
||||
<iq type="result" from="bob@example.com" to="alice@example.com/home" id="d1">
|
||||
<query xmlns="urn:xmpp:tmp:delegate">
|
||||
<service type="pubsub" jid="pubsub.example.net"/>
|
||||
<service type="chess" jid="bob@chess.example.net"/>
|
||||
</query>
|
||||
</iq>
|
||||
]]></example>
|
||||
<p>In the above example, we learn that "chess" related communication should go through the "bob@chess.example.net" JID rather than the user's own JID ("bob@example.com").</p>
|
||||
</section2>
|
||||
<section2 topic='Discovering Through a Third-Party Registry' anchor='registry-discover'>
|
||||
<p>As it is expected that most servers will not even support the ability to query user accounts for delegate services, it should be possible to contact a third-party or global registry holding the same information, to be queried in much the same way:</p>
|
||||
<example caption="Query registry for delegate services"><![CDATA[
|
||||
<iq type="get" from="alice@example.com/home" to="registry.example.com" id="r1">
|
||||
<query xmlns="urn:xmpp:tmp:delegate" jid="bob@example.com"/>
|
||||
</iq>
|
||||
]]></example>
|
||||
<example caption="Success response"><![CDATA[
|
||||
<iq type="result" from="registry.example.com" to="alice@example.com/home" id="r1">
|
||||
<query xmlns="urn:xmpp:tmp:delegate">
|
||||
<service type="pubsub" jid="pubsub.example.net"/>
|
||||
<service type="chess" jid="bob@chess.example.net"/>
|
||||
</query>
|
||||
</iq>
|
||||
]]></example>
|
||||
</section2>
|
||||
<section2 topic='Managing Third-Party Registry Information' anchor='registry-manage'>
|
||||
<p>Here's how a user adds a mapping to the registry:</p>
|
||||
<example caption="Adding an entry"><![CDATA[
|
||||
<iq type="set" from="bob@example.com/home" to="registry.example.com" id="r2">
|
||||
<query xmlns="urn:xmpp:tmp:delegate">
|
||||
<service type="chess" jid="bob@chess.example.net"/>
|
||||
</query>
|
||||
</iq>
|
||||
]]></example>
|
||||
<example caption="Success response"><![CDATA[
|
||||
<iq type="result" from="registry.example.com" to="bob@example.com/home" id="r2"/>
|
||||
]]></example>
|
||||
<p>The registry will add the new service to the list of mapped services for the sender JID.</p>
|
||||
<p>To remove a service from the list, submit without a jid attribute:</p>
|
||||
<example caption="Removing an entry"><![CDATA[
|
||||
<iq type="set" from="bob@example.com/home" to="registry.example.com" id="r3">
|
||||
<query xmlns="urn:xmpp:tmp:delegate">
|
||||
<service type="chess"/>
|
||||
</query>
|
||||
</iq>
|
||||
]]></example>
|
||||
<example caption="Success response"><![CDATA[
|
||||
<iq type="result" from="registry.example.com" to="bob@example.com/home" id="r3"/>
|
||||
]]></example>
|
||||
</section2>
|
||||
<section2 topic='Confirming With the Delegate' anchor='confirm'>
|
||||
<p>Whether a delegate JID is discovered directly or via registry, the mapping is an assertion made by the user only and not by the delegate. This may have security implications. For example, a third party should not allow the user to pose as the delegate, nor should the mapping be considered an endorsement by the delegate, since anyone can assert any delegate. However, these types of things could be allowed if third parties confirm with the delegate that the association exists.</p>
|
||||
<p>Here's how to query a delegate JID to confirm if it is indeed associated with a specific user for a specific service type:</p>
|
||||
<example caption="Confirming a delegation"><![CDATA[
|
||||
<iq type="get" from="alice@example.com/home" to="bob@chess.example.net" id="c1">
|
||||
<check xmlns="urn:xmpp:tmp:delegate" type="chess" jid="bob@example.com"/>
|
||||
</iq>
|
||||
]]></example>
|
||||
<p>Note that the user JID expected to be associated with the delegate must be provided in the request. It is not possible to query a delegate to determine the user JID, since a single delegate may act for many users.</p>
|
||||
<p>Success response means the association exists:</p>
|
||||
<example caption="Success response"><![CDATA[
|
||||
<iq type="result" from="bob@chess.example.net" to="alice@example.com/home" id="c1"/>
|
||||
]]></example>
|
||||
</section2>
|
||||
</section1>
|
||||
|
||||
<section1 topic='Implementation Notes' anchor='impl'>
|
||||
<section2 topic='Use of Both Direct and Third-Party Queries' anchor='impl-both'>
|
||||
<p>Applications that are configured to use a third-party registry SHOULD still be able to query user accounts directly. For performance reasons, it is recommended to query both the user account and the registry simultaneously, and take whichever answer arrives first. If one of the queries results in an error, then the application should wait for the other query to complete before assuming no such delegate records exists.</p>
|
||||
<p>If both queries return errors, or a success result does not contain an entry for some desired delegate service, it can be assumed that the desired service is provided by the user account itself (not delegated).</p>
|
||||
</section2>
|
||||
<section2 topic='Caching' anchor='impl-caching'>
|
||||
<p>It is RECOMMENDED that discovery or confirmation of delegate information be cached indefinitely and refreshed no more frequently than every 24 hours. Data refreshing should not block access to existing information. If over 24 hours pass since the last time delegate information was needed, the application should continue to use the old data while independently firing off a task to refresh the data. This way, latency associated with a particular user delegation only occurs the first time a user is ever seen.</p>
|
||||
</section2>
|
||||
</section1>
|
||||
|
||||
<section1 topic='Security Considerations' anchor='security'>
|
||||
<p>As discussed above, a delegate mapping is an assertion by the user only. If the user should be allowed to act for the delegate, or if the user should be considered endorsed by the delegate, then the delegation needs to be confirmed first.</p>
|
||||
</section1>
|
||||
|
||||
<section1 topic='IANA Considerations' anchor='iana'>
|
||||
<p>No interaction with &IANA; is required as a result of this document.</p>
|
||||
</section1>
|
||||
|
||||
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
|
||||
<section2 topic='Protocol Namespaces' anchor='registrar-ns'>
|
||||
<p>This specification defines the following XML namespace:</p>
|
||||
<ul>
|
||||
<li>urn:xmpp:tmp:delegate</li>
|
||||
</ul>
|
||||
<p>Upon advancement of this specification from a status of Experimental to a status of Draft, the ®ISTRAR; shall add the foregoing namespace to the registry located at &NAMESPACES;, as described in Section 4 of &xep0053;.</p>
|
||||
</section2>
|
||||
<section2 topic='Namespace Versioning' anchor='registrar-versioning'>
|
||||
&NSVER;
|
||||
</section2>
|
||||
</section1>
|
||||
|
||||
</xep>
|
||||
Loading…
Reference in New Issue
Block a user