https://github.com/fippo/xmpp-fed

XMPP Federation specifications
https://github.com/fippo/xmpp-fed

Last synced: about 1 month ago
JSON representation

XMPP Federation specifications

• Host: GitHub
• URL: https://github.com/fippo/xmpp-fed
• Owner: fippo
• Created: 2013-02-27T18:17:11.000Z (almost 12 years ago)
• Default Branch: master
• Last Pushed: 2013-04-08T16:21:47.000Z (over 11 years ago)
• Last Synced: 2024-10-18T16:28:07.269Z (3 months ago)
• Size: 320 KB
• Stars: 0
• Watchers: 4
• Forks: 0
• Open Issues: 0
• Metadata Files:
  • Readme: README.md

Awesome Lists containing this project

README

        
XMPP Federation

===============

"How to trust a connection is authorized for traffic intended for a given domain."

The approach is two-fold:

* Determine trust (prooftype)

* Delegation

Prooftype

=========

There are multiple approaches to verifying the domain associated with a (TLS) connection:

* DANE < http://tools.ietf.org/html/draft-ietf-dane-protocol-23 >

* POSH (defined herein), using HTTPS and PKIX

* PKIX < http://tools.ietf.org/html/rfc6125 >

Delegation

==========

Delegation is where one domain (e.g. "im.example.com") is actually hosted at another domain ("hosting.example.net").  There are multiple approaches to secure delegation:

* DNSSEC < http://tools.ietf.org/html/rfc4033 >

* HTTPS redirect of POSH (defined herein)

Assertions

==========

In XMPP, every connection has an identity associated with it in at least one direction.  This is indicated in the <stream:stream> root element; the "from" attribute for the sending entity, and "to" for the receiving entity.

The actual assertion is made from the certificate offered during TLS negotation (client-to-server or server-to-server), or via dialback <db:result/> for server-to-server.