mirror of
https://github.com/moparisthebest/xeps
synced 2025-02-16 07:10:15 -05:00
0.6
git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@2146 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
parent
ad58687c65
commit
574fef5757
120
xep-0235.xml
120
xep-0235.xml
@ -21,6 +21,12 @@
|
||||
<supersededby/>
|
||||
<shortname>NOT_YET_ASSIGNED</shortname>
|
||||
&stpeter;
|
||||
<revision>
|
||||
<version>0.6</version>
|
||||
<date>2008-08-07</date>
|
||||
<initials>psa</initials>
|
||||
<remark><p>Clarified error handling and service discovery.</p></remark>
|
||||
</revision>
|
||||
<revision>
|
||||
<version>0.5</version>
|
||||
<date>2008-08-07</date>
|
||||
@ -181,10 +187,91 @@ oauth_version%3D1.0
|
||||
]]></code>
|
||||
</section1>
|
||||
|
||||
<section1 topic='Determining Support' anchor='support'>
|
||||
<p>If a service provides and accepts authorization tokens, it MUST advertise support for the 'urn:xmpp:tmp:oauth' namespace in its disco#info replies (if provided) its &xep0115; notations &NSNOTE;.</p>
|
||||
<section1 topic='Error Handling' anchor='error'>
|
||||
<p>If a Service Provider rejects a Consumer's access request, the Service Provider SHOULD return either a &badrequest; or ¬authorized; stanza error, with an appropriate OAuth-specific error condition as described in the following table.</p>
|
||||
|
||||
<table caption='Application-Specific Error Conditions'>
|
||||
<tr>
|
||||
<th>OAuth-Specific Condition</th>
|
||||
<th>Generic Condition</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><duplicated-parameter/></td>
|
||||
<td>&badrequest;</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><invalid-consumer-key/></td>
|
||||
<td>¬authorized;</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><invalid-nonce/></td>
|
||||
<td>¬authorized;</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><invalid-signature/></td>
|
||||
<td>¬authorized;</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><invalid-token/></td>
|
||||
<td>¬authorized;</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><missing-parameter/></td>
|
||||
<td>&badrequest;</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><token-required/></td>
|
||||
<td>¬authorized;</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><unsupported-parameter/></td>
|
||||
<td>&badrequest;</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><unsupported-signature-method/></td>
|
||||
<td>&badrequest;</td>
|
||||
</tr>
|
||||
</table>
|
||||
<p>An example follows.</p>
|
||||
<example caption='OAuth-specific error'><![CDATA[
|
||||
<iq from='feeds.worldgps.tld'
|
||||
id='sub1'
|
||||
to='travelbot@findmenow.tld/bot'
|
||||
type='error'>
|
||||
<error type='modify'>
|
||||
<bad-request xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
|
||||
<invalid-nonce xmlns='urn:xmpp:tmp:oauth:errors'/>
|
||||
</error>
|
||||
</iq>
|
||||
]]></example>
|
||||
</section1>
|
||||
|
||||
<section1 topic='Determining Support' anchor='support'>
|
||||
<p>If an entity supports the protocol specified herein, it MUST advertise that fact by returning a feature of "urn:xmpp:tmp:oauth" in response to &xep0030; information requests &NSNOTE;.</p>
|
||||
<example caption="Service discovery information request"><![CDATA[
|
||||
<iq from='travelbot@findmenow.tld/bot'
|
||||
id='disco1'
|
||||
to='feeds.worldgps.tld'
|
||||
type='get'>
|
||||
<query xmlns='http://jabber.org/protocol/disco#info'/>
|
||||
</iq>
|
||||
]]></example>
|
||||
<example caption="Service discovery information response"><![CDATA[
|
||||
<iq from='feeds.worldgps.tld'
|
||||
id='disco1'
|
||||
to='travelbot@findmenow.tld/bot'
|
||||
type='result'>
|
||||
<query xmlns='http://jabber.org/protocol/disco#info'>
|
||||
...
|
||||
<feature var='urn:xmpp:tmp:bob'/>
|
||||
...
|
||||
</query>
|
||||
</iq>
|
||||
]]></example>
|
||||
<p>In order for an application to determine whether an entity supports this protocol, where possible it SHOULD via the dynamic, presence-based profile of service discovery defined in &xep0115;. However, if an application has not received entity capabilities information from an entity, it SHOULD use explicit service discovery instead.</p>
|
||||
</section1>
|
||||
|
||||
|
||||
<section1 topic='Security Considerations' anchor='security'>
|
||||
<section2 topic='Replay Attacks' anchor='security-replay'>
|
||||
<p>Signatures generated according to the signature generation algorithm might be subject to replay attacks. However, inclusion of the XMPP "from" and "to" addresses limits these attacks to compromised servers or client-to-server connections. In addition, inclusion of the nonce value also helps to prevent replay attacks.</p>
|
||||
@ -205,7 +292,8 @@ oauth_version%3D1.0
|
||||
</section1>
|
||||
|
||||
<section1 topic='XML Schema' anchor='schema'>
|
||||
<code><![CDATA[
|
||||
<section2 topic='Protocol Namespace' anchor='schema-proto'>
|
||||
<code><![CDATA[
|
||||
<?xml version='1.0' encoding='UTF-8'?>
|
||||
|
||||
<xs:schema
|
||||
@ -228,6 +316,29 @@ oauth_version%3D1.0
|
||||
</xs:complexType>
|
||||
</xs:element>
|
||||
|
||||
</xs:schema>
|
||||
]]></code>
|
||||
</section2>
|
||||
<section2 topic='Error Namespace' anchor='schema-error'>
|
||||
<code><![CDATA[
|
||||
<?xml version='1.0' encoding='UTF-8'?>
|
||||
|
||||
<xs:schema
|
||||
xmlns:xs='http://www.w3.org/2001/XMLSchema'
|
||||
targetNamespace='urn:xmpp:tmp:oauth:errors'
|
||||
xmlns='urn:xmpp:tmp:oauth:errors'
|
||||
elementFormDefault='qualified'>
|
||||
|
||||
<xs:element name='duplicated-parameter' type='empty'/>
|
||||
<xs:element name='invalid-consumer-key' type='empty'/>
|
||||
<xs:element name='invalid-nonce' type='empty'/>
|
||||
<xs:element name='invalid-signature' type='empty'/>
|
||||
<xs:element name='invalid-token' type='empty'/>
|
||||
<xs:element name='missing-parameter' type='empty'/>
|
||||
<xs:element name='token-required' type='empty'/>
|
||||
<xs:element name='unsupported-parameter' type='empty'/>
|
||||
<xs:element name='unsupported-signature-method' type='empty'/>
|
||||
|
||||
<xs:simpleType name='empty'>
|
||||
<xs:restriction base='xs:string'>
|
||||
<xs:enumeration value=''/>
|
||||
@ -235,7 +346,8 @@ oauth_version%3D1.0
|
||||
</xs:simpleType>
|
||||
|
||||
</xs:schema>
|
||||
]]></code>
|
||||
]]></code>
|
||||
</section2>
|
||||
</section1>
|
||||
|
||||
<section1 topic='Acknowledgements' anchor='ack'>
|
||||
|
Loading…
Reference in New Issue
Block a user