Compare commits
10 Commits
a8d785d80f
...
048c766ac7
| Author | SHA1 | Date | |
|---|---|---|---|
| 048c766ac7 | |||
| ff86660973 | |||
| 7422fc9baf | |||
| 107ce51b48 | |||
| ee4c8d749d | |||
| 03b759eafb | |||
| b219c4bb7a | |||
| bbe91ca225 | |||
| 79df96418c | |||
| c7c7f5784a |
@ -2,5 +2,7 @@
|
||||
|
||||
| Title | Description |
|
||||
| --- | --- |
|
||||
| File Thumbnails | A specification for different types of thumbnails in the context of file transfers |
|
||||
| Extensible File Thumbnails | A specification for different types of thumbnails in the context of file transfers |
|
||||
| File Upload Notifications | A specification for telling clients that a file will be sent as soon as it is uploaded |
|
||||
| SSO Login | A specification for allowing SSO logins during XMPP authentication |
|
||||
| Communities | A specification for defining loose collections of JIDs similar to Discord servers or Matrix spaces |
|
||||
|
||||
125
xep-xxxx-communities.md
Normal file
125
xep-xxxx-communities.md
Normal file
@ -0,0 +1,125 @@
|
||||
# Communities
|
||||
|
||||
In different instant messaging services, users have the options to create collections of group chat venues that are logically linked
|
||||
together.
|
||||
|
||||
This XEP is designed in a modular way, similar to [Mediated Information Exchange]. As such, this XEP only provided the basics for such
|
||||
groupings.
|
||||
|
||||
## Design Requirements
|
||||
|
||||
To aid adoption, the following requirements are considered while creating this XEP:
|
||||
|
||||
- Basic communities, i.e. grouped links to other JIDs with additional metadata, should work without server support
|
||||
- The protocol should be extensible for future evolution
|
||||
|
||||
## Basics
|
||||
|
||||
A community in XMPP is identified by a JID that "owns" the community. This may be a bare JID or a server's JID. This JID must provide
|
||||
a [PubSub](https://xmpp.org/extensions/xep-0060.html) service on which the community's metadata is stored. This XEP proposes a couple of basic nodes, but other XEPs may extend
|
||||
this set and provide custom extensions.
|
||||
|
||||
A community may be either public, meaning that anyone who knows the JID may join and query information about, or private, meaning that users
|
||||
wishing to join MUST be added by an administrator of the community. To accomplish this, public communities SHOULD set all their [PubSub](#) nodes
|
||||
to have an access model of "open", while private communities SHOULD set all of their nodes to "whitelist". A future XEP may define a way for
|
||||
administrators to pre-authenticate users such that "invite URLs" to users.
|
||||
|
||||
### Description
|
||||
|
||||
A community's information is described by a `<information />` element containing information about the community.
|
||||
|
||||
```xml
|
||||
<information xmlns="proto:urn:xmpp:community:0">
|
||||
<title>Awesome Community</title>
|
||||
<description>...</description>
|
||||
<icon url="https://example.org" />
|
||||
</information>
|
||||
```
|
||||
|
||||
This element is stored in the `proto:urn:xmpp:community:0:info` [PubSub](https://xmpp.org/extensions/xep-0060.html) node at the bare JID of the community.
|
||||
Implementations MUST use an id of "latest" to prevent multiple revisions of existing.
|
||||
|
||||
```xml
|
||||
<iq type="result" from="community.example.org">
|
||||
<pubsub xmlns="http://jabber.org/protocol/pubsub">
|
||||
<items node="proto:urn:xmpp:community:0:info">
|
||||
<item id="latest">
|
||||
<information xmlns="proto:urn:xmpp:community:0">
|
||||
<title>Awesome Community</title>
|
||||
<description>...</description>
|
||||
<icon url="https://example.org" />
|
||||
</information>
|
||||
</item>
|
||||
</items>
|
||||
</pubsub>
|
||||
</iq>
|
||||
```
|
||||
|
||||
### Channel
|
||||
|
||||
Within this XEP, a channel refers to each item within a channel group that should be displayable by the client. This XEP provides
|
||||
the `<channel />` element which community administrators MAY use to link to items within the XMPP network by its JID.
|
||||
|
||||
The defined types are:
|
||||
|
||||
- `groupchat`: A joinable group chat (MUC, MIX, ...)
|
||||
- `user`: A JID that a one-on-one conversation can be started with
|
||||
- `community`: A link to another community as defined per this XEP.
|
||||
|
||||
```xml
|
||||
<channel id="dev" type="groupchat" jid="dev@muc.example.org" title="Development" />
|
||||
```
|
||||
|
||||
The title attribute describes the function of the channel to the user. The id is used for sorting within a
|
||||
channel group. The id MUST consist of only alpha-numeric characters.
|
||||
|
||||
### Channel Groups
|
||||
|
||||
A channel group is a list of items that should be logically grouped together. This may include group chat venues (MUC, MIX),
|
||||
user JIDs (like admins), or other channel groups.
|
||||
|
||||
```xml
|
||||
<group xmlns="proto:urn:xmpp:community:0" id="development">
|
||||
<title>Development chats</title>
|
||||
<channel id="dev" type="groupchat" jid="dev@muc.example.org" title="Development" />
|
||||
<channel id="support" type="groupchat" jid="support@muc.example.org" title="Support" />
|
||||
<channel id="user" type="user" jid="user@example.org" title="Random user" />
|
||||
<channel id="other-community" type="community" jid="some-other-community.example.org" title="Partner community" />
|
||||
</group>
|
||||
```
|
||||
|
||||
Each extension item inside the `<group />` must also carry an id. The id must be unique within its surrounding group, but not the parent or child groups.
|
||||
|
||||
A community has a single `proto:urn:xmpp:community:0:groups` [PubSub](https://xmpp.org/extensions/xep-0060.html) node that contains one top-level group called the *root group*. It MAY have a title, but it does not
|
||||
have to.
|
||||
|
||||
```xml
|
||||
<iq type="result" from="community.example.org">
|
||||
<pubsub xmlns="http://jabber.org/protocol/pubsub">
|
||||
<items node="proto:urn:xmpp:community:0:groups">
|
||||
<item id="latest">
|
||||
<group xmlns="proto:urn:xmpp:community:0" id="root">
|
||||
<channel id="0000" type="groupchat" jid="welcome@muc.example.org" title="Welcome" />
|
||||
<group xmlns="proto:urn:xmpp:community:0" id="0001">
|
||||
<title>Development</title>
|
||||
<channel id="dev-0000" type="groupchat" jid="development@muc.example.org" title="Development" />
|
||||
<channel id="dev-0001" type="groupchat" jid="debugging@muc.example.org" title="Debugging" />
|
||||
</group>
|
||||
<group xmlns="proto:urn:xmpp:community:0" id="0002">
|
||||
<title>Support</title>
|
||||
<channel id="support-0000" type="groupchat" jid="support@muc.example.org" title="General Support" />
|
||||
</group>
|
||||
</group>
|
||||
</item>
|
||||
</items>
|
||||
</pubsub>
|
||||
</iq>
|
||||
```
|
||||
|
||||
# Info
|
||||
|
||||
| Key | Value |
|
||||
| --- | --- |
|
||||
| Author | PapaTutuWawa |
|
||||
| Version | 0.1.0 |
|
||||
| Short name | cmt |
|
||||
126
xep-xxxx-extensible-file-thumbnails.md
Normal file
126
xep-xxxx-extensible-file-thumbnails.md
Normal file
@ -0,0 +1,126 @@
|
||||
# Extensible File Thumbnails
|
||||
## Introduction
|
||||
|
||||
When sending media, it is often helpful for users when a thumbnail can be shown before the
|
||||
actual file is finished downloading.
|
||||
|
||||
XMPP already has a protocol for specifying thumbails, [Jingle Content Thumbnails](https://xmpp.org/extensions/xep-0264.html).
|
||||
However, this protocol requires that the thumbnail is a base64-encoded image published using
|
||||
[Bits of Binary](https://xmpp.org/extensions/xep-0231.html). This prevents clients from implementing newer technologies, such as
|
||||
[Blurhash](https://github.com/woltapp/blurhash).
|
||||
|
||||
This document specifies are more general and extensible element for specifiying thumbnails in various formats.
|
||||
|
||||
## Usage
|
||||
|
||||
```xml
|
||||
<file-thumbnail type="proto:urn:xmpp:eft:0:blurhash" xmlns="proto:urn:xmpp:eft:0">
|
||||
<blurhash>LEHV6nWB2yk8pyoJadR*.7kCMdnj</blurhash>
|
||||
</file-thumbnail>
|
||||
```
|
||||
|
||||
This example specifies a thumbnail of type `blurhash`, meaning that the child element of the
|
||||
`<file-thumbnail/>` element must contain a `<blurhash/>` element (See "Thumbnail Types").
|
||||
|
||||
A `<file-thumbnail/>` element MUST only contain one child; that is the child that is specified
|
||||
by the `<file-thumbnail/>` type attribute.
|
||||
|
||||
### Thumbnail Types
|
||||
#### Blurhash
|
||||
|
||||
If a sender specifies the type of the `<file-thumbnail/>` element to be
|
||||
`proto:urn:xmpp:eft:0:blurhash`, then the `<blurhash/>` element's value must be interpreted
|
||||
as [Blurhash](https://github.com/woltapp/blurhash) data. As a sender, care must be taken to
|
||||
not make the Blurhash thumbnail too big as to not loose the advantages of Blurhash.
|
||||
|
||||
```xml
|
||||
<file-thumbail xmlns="proto:urn:xmpp:eft:0">
|
||||
<blurhash>LEHV6nWB2yk8pyoJadR*.7kCMdnj</blurhash>
|
||||
</file-thumbnail>
|
||||
```
|
||||
|
||||
#### Jingle Content Thumbnail Compatability
|
||||
|
||||
In order to enable a pseudo-interoperability with [Jingle Content Thumbnails](https://xmpp.org/extensions/xep-0264.html), inclusion of a
|
||||
`<thumbnail/>` element is allowed. This is to allow easy reuse of an already existent [Jingle Content Thumbnails](https://xmpp.org/extensions/xep-0264.html)
|
||||
implementation. The type of the `<file-thumbnail/>` must then be set to `proto:urn:xmpp:eft:0:base64-bob`.
|
||||
|
||||
```xml
|
||||
<file-thumbail xmlns="proto:urn:xmpp:eft:0" type="proto:urn:xmpp:eft:0:base64-bob">
|
||||
<thumbnail xmlns="urn:xmpp:thumbs:1" uri="cid:sha1+...@bob.xmpp.org" media-type="image/png" width="128" height="96" />
|
||||
</file-thumbnail>
|
||||
```
|
||||
|
||||
## Usage Example with Stateless Inline Media Sharing
|
||||
|
||||
NOTE: This example is taken from [Stateless Inline Media Sharing](https://xmpp.org/extensions/xep-0385.html) and modified for this protocol.
|
||||
|
||||
```xml
|
||||
<message to='julient@shakespeare.lit' from='romeo@montague.lit'>
|
||||
<body>Look at the nice view from the summit.</body>
|
||||
<reference xmlns='urn:xmpp:reference:0' begin='17' end='20' type='data'>
|
||||
<media-sharing xmlns='urn:xmpp:sims:1'>
|
||||
<file xmlns='urn:xmpp:jingle:apps:file-transfer:5'>
|
||||
<media-type>image/jpeg</media-type>
|
||||
<name>summit.jpg</name>
|
||||
<size>3032449</size>
|
||||
<hash xmlns='urn:xmpp:hashes:2' algo='sha3-256'>2XarmwTlNxDAMkvymloX3S5+VbylNrJt/l5QyPa+YoU=</hash>
|
||||
<hash xmlns='urn:xmpp:hashes:2' algo='id-blake2b256'>2AfMGH8O7UNPTvUVAM9aK13mpCY=</hash>
|
||||
<desc>Photo from the summit.</desc>
|
||||
<file-thumbnail type="base64-bob" xmlns='urn:xmpp:thumbnail:0'>
|
||||
<base64-bob uri="cid:sha1+ffd7c8d28e9c5e82afea41f97108c6b4@bob.xmpp.org" media-type="image/png" width="128" height="96" />
|
||||
</thumbnail>
|
||||
<file-thumbnail type="proto:urn:xmpp:eft:0:blurhash" xmlns="proto:urn:xmpp:eft:0">
|
||||
<blurhash>LEHV6nWB2yk8pyoJadR*.7kCMdnj</blurhash>
|
||||
</file-thumbnail>
|
||||
<file-thumbnail type="proto:urn:xmpp:eft:0:base64-bob" xmlns="proto:urn:xmpp:eft:0">
|
||||
<thumbnail xmlns='urn:xmpp:thumbs:1'
|
||||
uri='cid:sha1+ffd7c8d28e9c5e82afea41f97108c6b4@bob.xmpp.org'
|
||||
media-type='image/png'
|
||||
width='128'
|
||||
height='96'/>
|
||||
</file-thumbnail>
|
||||
</file>
|
||||
<sources>
|
||||
<reference xmlns='urn:xmpp:reference:0' type='data' uri='https://download.montague.lit/4a771ac1-f0b2-4a4a-9700-f2a26fa2bb67/summit.jpg' />
|
||||
<reference xmlns='urn:xmpp:reference:0' type='data' uri='xmpp:romeo@montague.lit/resource?jingle;id=9559976B-3FBF-4E7E-B457-2DAA225972BB' />
|
||||
</sources>
|
||||
</media-sharing>
|
||||
</reference>
|
||||
</message>
|
||||
```
|
||||
|
||||
## Security Considerations
|
||||
|
||||
The same considerations apply as specified by [Jingle Content Thumbnails](https://xmpp.org/extensions/xep-0264.html).
|
||||
|
||||
## Todo
|
||||
|
||||
- Change XML namespace from `proto:urn:xmpp:eft:0` to `urn:xmpp:eft:0` once we submit this as an XEP
|
||||
|
||||
## Changelog
|
||||
### 0.2.1
|
||||
|
||||
- Remove namespacing of the `<file-thumbnail/>`'s child element
|
||||
|
||||
### 0.2.0
|
||||
|
||||
- Namespace the thumbnail type
|
||||
- `<file-thumbnails/>` to `<file-thumbnail/>`
|
||||
|
||||
### 0.1.0
|
||||
|
||||
- Remove the base64 thumbnail type
|
||||
- Namespace all thumbnail types
|
||||
- Remove the type attribute of `<file-thumbnail/>`
|
||||
- Rename `<file-thumbnail/>` to `<file-thumbnails/>`
|
||||
- Rename the namespace from file-thumbnails to eft
|
||||
- Rename from File Thumbnails to Extensible File Thumbnails
|
||||
|
||||
## Info
|
||||
|
||||
| Key | Value |
|
||||
| --- | --- |
|
||||
| Author | PapaTutuWawa |
|
||||
| Version | 0.2.1 |
|
||||
| Short name | eft |
|
||||
@ -1,120 +0,0 @@
|
||||
# File Thumbnails
|
||||
## Introduction
|
||||
|
||||
When sending media, it is often helpful for users when a thumbnail can be shown before the
|
||||
actual file is finished downloading.
|
||||
|
||||
XMPP already has a protocol for specifying thumbails, [Jingle Content Thumbnails](https://xmpp.org/extensions/xep-0264.html).
|
||||
However, this protocol requires that the thumbnail is a base64-encoded image published using
|
||||
[Bits of Binary](https://xmpp.org/extensions/xep-0231.html). This prevents clients from implementing newer technologies, such as
|
||||
[Blurhash](https://github.com/woltapp/blurhash).
|
||||
|
||||
This document specifies are more general and extensible element for specifiying thumbnails.
|
||||
|
||||
## Usage
|
||||
|
||||
```xml
|
||||
<file-thumbnail type="blurhash" xmlns="proto:urn:xmpp:file-thumbnails:0">
|
||||
<blurhash>LEHV6nWB2yk8pyoJadR*.7kCMdnj</blurhash>
|
||||
</thumbnail>
|
||||
```
|
||||
|
||||
In this example, the thumbnail is specified of type `proto:urn:xmpp:file-thumbnails:0:blurhash`, which means that a supporting
|
||||
client should decode the `<blurhash/>` element using the [Blurhash](https://github.com/woltapp/blurhash) algorithm.
|
||||
|
||||
Other extensions may define similar types. Note that the content of the `<file-thumbnail />` element
|
||||
is dependent on the type specified in the `<file-thumbnail />` element.
|
||||
|
||||
### Thumbnail Types
|
||||
#### Blurhash
|
||||
|
||||
If a sender specifies the type to be of `blurhash`, then the `<file-thumbnail />` element must contain the
|
||||
image data as specified by the [Blurhash](https://github.com/woltapp/blurhash) algorithm. Care should be taken to prevent
|
||||
the blurhash data from growing to large in order to prevent hitting the stanza size limit.
|
||||
|
||||
```xml
|
||||
<file-thumbail xmlns="proto:urn:xmpp:file-thumbnails:0" type="blurhash">
|
||||
<blurhash>LEHV6nWB2yk8pyoJadR*.7kCMdnj</blurhash>
|
||||
</file-thumbnail>
|
||||
```
|
||||
|
||||
#### Jingle Content Thumbnail Compatability
|
||||
|
||||
In order to enable a pseudo-interoperability with [Jingle Content Thumbnails](https://xmpp.org/extensions/xep-0264.html), a type
|
||||
`base64-bob` is defined.
|
||||
|
||||
If a sender specified the type to be of `base64-bob`, then the `<file-thumbnail />`
|
||||
element must contain exactly one `<base64-bob />` element. The attributes of the element are the same
|
||||
as the `<thumbnail />` element specified in [Jingle Content Thumbnails](https://xmpp.org/extensions/xep-0264.html).
|
||||
|
||||
```xml
|
||||
<file-thumbail xmlns="proto:urn:xmpp:file-thumbnails:0" type="base64-bob">
|
||||
<base64-bob uri="cid:sha1+...@bob.xmpp.org" media-type="image/png" width="128" height="96" />
|
||||
</file-thumbnail>
|
||||
```
|
||||
|
||||
This allows clients that already support [Jingle Content Thumbnails](https://xmpp.org/extensions/xep-0264.html) to reuse
|
||||
the same logic they use for retrieving thumbnail data.
|
||||
|
||||
#### Base64 Data
|
||||
|
||||
If a sender specified the type to be of `base64`, then the `<file-thumbnail />` element must
|
||||
contain exactly one `<base64 />` element. The element must posess an `media-type` attribute, whose value
|
||||
contains the mime type of the thumbnail data, while the inner text of the element contains the base64-encoded
|
||||
binary thumbnail data.
|
||||
|
||||
```xml
|
||||
<file-thumbail xmlns="proto:urn:xmpp:file-thumbnails:0" type="base64">
|
||||
<base64 media-type="image/png" width="128" height="96">
|
||||
[base64 data]
|
||||
</base64>
|
||||
</file-thumbnail>
|
||||
```
|
||||
|
||||
Note that this thumbnail type is essentially the same as the `base64-bob` type, but allowing the thumbnail to be used even if
|
||||
the sender is not available on a server that does not cache [Bits of Binary](https://xmpp.org/extensions/xep-0231.html) data or has it otherwise not available.
|
||||
|
||||
If using this thumbnail type, care has to be taken in order to not hit any existing stanza size limits.
|
||||
|
||||
## Usage Example with Stateless Inline Media Sharing
|
||||
|
||||
NOTE: This example is taken from [Stateless Inline Media Sharing](https://xmpp.org/extensions/xep-0385.html) and modified for this protocol.
|
||||
|
||||
```xml
|
||||
<message to='julient@shakespeare.lit' from='romeo@montague.lit'>
|
||||
<body>Look at the nice view from the summit.</body>
|
||||
<reference xmlns='urn:xmpp:reference:0' begin='17' end='20' type='data'>
|
||||
<media-sharing xmlns='urn:xmpp:sims:1'>
|
||||
<file xmlns='urn:xmpp:jingle:apps:file-transfer:5'>
|
||||
<media-type>image/jpeg</media-type>
|
||||
<name>summit.jpg</name>
|
||||
<size>3032449</size>
|
||||
<hash xmlns='urn:xmpp:hashes:2' algo='sha3-256'>2XarmwTlNxDAMkvymloX3S5+VbylNrJt/l5QyPa+YoU=</hash>
|
||||
<hash xmlns='urn:xmpp:hashes:2' algo='id-blake2b256'>2AfMGH8O7UNPTvUVAM9aK13mpCY=</hash>
|
||||
<desc>Photo from the summit.</desc>
|
||||
<file-thumbnail type="base64-bob" xmlns='urn:xmpp:thumbnail:0'>
|
||||
<base64-bob uri="cid:sha1+ffd7c8d28e9c5e82afea41f97108c6b4@bob.xmpp.org" media-type="image/png" width="128" height="96" />
|
||||
</thumbnail>
|
||||
<file-thumbnail type="blurhash" xmlns="proto:urn:xmpp:file-thumbnails:0">
|
||||
<blurhash>LEHV6nWB2yk8pyoJadR*.7kCMdnj</blurhash>
|
||||
</thumbnail>
|
||||
</file>
|
||||
<sources>
|
||||
<reference xmlns='urn:xmpp:reference:0' type='data' uri='https://download.montague.lit/4a771ac1-f0b2-4a4a-9700-f2a26fa2bb67/summit.jpg' />
|
||||
<reference xmlns='urn:xmpp:reference:0' type='data' uri='xmpp:romeo@montague.lit/resource?jingle;id=9559976B-3FBF-4E7E-B457-2DAA225972BB' />
|
||||
</sources>
|
||||
</media-sharing>
|
||||
</reference>
|
||||
</message>
|
||||
```
|
||||
|
||||
## Security Considerations
|
||||
|
||||
The same considerations apply as specified by [Jingle Content Thumbnails](https://xmpp.org/extensions/xep-0264.html).
|
||||
|
||||
## Info
|
||||
|
||||
| Key | Value |
|
||||
| --- | --- |
|
||||
| Author | PapaTutuWawa |
|
||||
| Version | 0.0.3 |
|
||||
@ -13,20 +13,19 @@ that will be replaced once the file has been uploaded.
|
||||
|
||||
```xml
|
||||
<message from="some.user@some.server/abc123" to="someone.else@other.server" id="aaaaa">
|
||||
<file-upload xmlns="proto:urn:xmpp:fun:0">
|
||||
<file xmlns="urn:xmpp:file:metadata:0">
|
||||
<name>vacation.jpg</name>
|
||||
<media-type>image/jpeg</media-type>
|
||||
</file>
|
||||
<thumbnail type="blurhash" xmlns="proto:urn:xmpp:file-thumbnails:0">
|
||||
<blurhash>LEHV6nWB2yk8pyoJadR*.7kCMdnj</blurhash>
|
||||
</thumbnail>
|
||||
<thumbnail type="base64-bob" xmlns="proto:urn:xmpp:file-thumbnails:0">
|
||||
<base64-bob uri="cid:sha1+...@bob.xmpp.org" media-type="image/png" width="128" height="96" />
|
||||
</thumbnail>
|
||||
</file-upload>
|
||||
<origin-id xmlns="urn:xmpp:sid:0" id="ccccc" />
|
||||
<no-permanent-store xmlns="urn:xmpp:hints" />
|
||||
<file-upload xmlns="proto:urn:xmpp:fun:0">
|
||||
<file xmlns="urn:xmpp:file:metadata:0">
|
||||
<name>vacation.jpg</name>
|
||||
<media-type>image/jpeg</media-type>
|
||||
<thumbnail type="blurhash" xmlns="proto:urn:xmpp:eft:0">
|
||||
<blurhash>LEHV6nWB2yk8pyoJadR*.7kCMdnj</blurhash>
|
||||
</thumbnail>
|
||||
<thumbnail type="base64-bob" xmlns="proto:urn:xmpp:eft:0">
|
||||
<base64-bob uri="cid:sha1+...@bob.xmpp.org" media-type="image/png" width="128" height="96" />
|
||||
</thumbnail>
|
||||
</file>
|
||||
</file-upload>
|
||||
<no-permanent-store xmlns="urn:xmpp:hints" />
|
||||
</message>
|
||||
```
|
||||
|
||||
@ -37,9 +36,6 @@ The metadata should include only the bare minimum, i.e. the mime type and filena
|
||||
Additionally, zero or more thumbnails can be sent with the notification in order to allow clients
|
||||
to already show a preview. The `<file-thumbnail />` element is specified by [File Thumbnails](https://github.com/PapaTutuWawa/custom-xeps/blob/master/xep-xxxx-file-thumbnails.md).
|
||||
|
||||
Note that [Unique and Stable Origin IDs](https://xmpp.org/extensions/xep-0359.html) must be used when the message is sent to a
|
||||
groupchat.
|
||||
|
||||
Since this message carries no meaning to anyone retrieving it after the file upload has been
|
||||
completed, a `<no-permanent-store />` element should be added (See [Message Processing Hints](https://xmpp.org/extensions/xep-0334.html)).
|
||||
|
||||
@ -54,17 +50,14 @@ in the message to inform clients which messages should be replaced.
|
||||
<x xmlns="jabber:x:oob">
|
||||
<url>...</url>
|
||||
</x>
|
||||
<replaces xmlns="proto:urn:xmpp:fun:0" id="ccccc" />
|
||||
<origin-id xmlns="urn:xmpp:sid:0" id="ddddd" />
|
||||
<replaces xmlns="proto:urn:xmpp:fun:0" id="aaaaa" />
|
||||
</message>
|
||||
```
|
||||
|
||||
The `id` attribute of the `<replaces />` element refers to either the stanza ID or the
|
||||
origin ID of the message that contained the original `<file-upload />`.
|
||||
The `id` attribute of the `<replaces />` element refers to either the stanza ID of the
|
||||
message that contained the original `<file-upload />`.
|
||||
|
||||
If sent to a groupchat, the origin ID must be used.
|
||||
|
||||
Note the the actual method of communicating a file is of no relevance here, as long as the
|
||||
Note that the actual method of communicating a file is of no relevance here, as long as the
|
||||
method allows a client to show it inline. Examples for such methods are
|
||||
[Out of Band Data](https://xmpp.org/extensions/xep-0066.html)
|
||||
and [Stateless Inline Media Sharing](https://xmpp.org/extensions/xep-0385.html).
|
||||
@ -80,26 +73,24 @@ If the uploading entity has cancelled the upload, then it should indicate so to
|
||||
|
||||
```xml
|
||||
<message from="some.user@some.server/abc123" to="someone.else@other.server" id="bbbbb">
|
||||
<cancelled xmlns="proto:urn:xmpp:fun:0" />
|
||||
<replaces xmlns="proto:urn:xmpp:fun:0" id="ccccc" />
|
||||
<origin-id xmlns="urn:xmpp:sid:0" id="ddddd" />
|
||||
<cancelled xmlns="proto:urn:xmpp:fun:0" id="aaaaa" />
|
||||
</message>
|
||||
```
|
||||
|
||||
In this example, the uploading entity just sends a message containing a `<cancelled />` tag to indicate the
|
||||
cancellation, allowing receiving clients to perhaps stop showing loading spinners and the like. The
|
||||
`<replaces />` is used to indicate what original message this cancellation applies to.
|
||||
cancellation, allowing receiving clients to perhaps stop showing loading spinners and the
|
||||
like. Its `id` attribute refers to the message containing the original `<file-upload />`
|
||||
element.
|
||||
|
||||
## Security Considerations
|
||||
|
||||
A client receiveing a message with an `<replaces />` element must verify if the message it
|
||||
is supposed to replace was actually sent by the sender of the `<replaces />` element to
|
||||
prevent arbitrary messages to be replaced.
|
||||
- A client receiving a File Upload Notification must ensure that only messages containing a `<file-upload />` are replaced. This is to ensure arbitrary messages being replaced by file uploads.
|
||||
- A client receiving a File Upload Notification MUST ensure that replacements and cancellations are only accepted from the JID that sent the original message containing the `<file-upload />` element. This means that as long as the two JIDs are equal when bare, then the replacement or cancellation is valid.
|
||||
|
||||
## Info
|
||||
|
||||
| Key | Value |
|
||||
| --- | --- |
|
||||
| Author | PapaTutuWawa |
|
||||
| Version | 0.0.4 |
|
||||
| Version | 0.0.5 |
|
||||
| Short name | fun |
|
||||
|
||||
135
xep-xxxx-sso-login.md
Normal file
135
xep-xxxx-sso-login.md
Normal file
@ -0,0 +1,135 @@
|
||||
# Single Sign-On (SSO) Login
|
||||
## Introduction
|
||||
|
||||
XMPP implementations can authenticate against a server with various different
|
||||
methods. There exist password-based mechanisms, like *SCRAM* or *PLAIN*, and token-based
|
||||
approaches like [FAST](https://xmpp.org/extensions/inbox/xep-fast.html). However, for certain deployments, where authentications is delagated
|
||||
to a third-party, *SCRAM* and *PLAIN* cannot be used as they require some access to the user's
|
||||
raw password (in the case of *SCRAM* the hashed password). [FAST](https://xmpp.org/extensions/inbox/xep-fast.html) can only be used for
|
||||
reauthentication without access to the user's password.
|
||||
|
||||
This specification provides a way for XMPP clients to authenticate with a server using
|
||||
server-provided single sign-on (SSO) solutions.
|
||||
|
||||
## Authentication
|
||||
|
||||
When a client connects to the server and the server deems the connection ready for authentication, a
|
||||
server providing login using SSO provides it as a [SASL2](https://xmpp.org/extensions/xep-0388.html) feature:
|
||||
|
||||
```xml
|
||||
<?xml version='1.0'?>
|
||||
<stream:stream
|
||||
from='example.org'
|
||||
id='++TR84Sm6A3hnt3Q065SnAbbk3Y='
|
||||
to='user@example.org'
|
||||
version='1.0'
|
||||
xml:lang='en'
|
||||
xmlns='jabber:client'
|
||||
xmlns:stream='http://etherx.jabber.org/streams'>
|
||||
<stream:features>
|
||||
<authentication xmlns='urn:xmpp:sasl:2'>
|
||||
<mechanism>SCRAM-SHA-1</mechanism>
|
||||
<mechanism>SCRAM-SHA-1-PLUS</mechanism>
|
||||
<sso xmlns='proto:urn:xmpp:sso:0'>
|
||||
<service id='sso-service-1' icon='https://...'>Login with Service 1</service>
|
||||
<service id='sso-service-2' icon='https://...'>Login with Service 2</service>
|
||||
<service id='sso-service-3' icon='https://...'>Login with Service 3</service>
|
||||
</sso>
|
||||
</authentication>
|
||||
</stream:features>
|
||||
```
|
||||
|
||||
Each `<service />` element identifies a SSO service that a client can authenticate against. Each `<service />` element's id attribute
|
||||
MUST be unique in its listing as it identifies what service the client wants to authenticate against in the next step. It MUST NOT contain
|
||||
the `,` and `=` characters, An optional icon attribute points to a URL where an icon for the service can be found. Clients MUST ignore non-HTTP URLs. The text of the element
|
||||
MUST provide a human-readable string identifying the service. It SHOULD idealy be short to pose minimal UI constraints.
|
||||
|
||||
While the server in this example also provides authentication using *SCRAM*, a server does not have to. In a business deployment, the only authentication
|
||||
mechanism MAY be just the company's SSO mechanism.
|
||||
|
||||
In the next step, the client specifies that it wants to authenticate using (in this example) `sso-service-1`.
|
||||
|
||||
```xml
|
||||
<authenticate xmlns='urn:xmpp:sasl:2' mechanism='SCRAM-SHA-1-PLUS'>
|
||||
<!-- Base64 of: ',,id=sso-service-1' -->
|
||||
<initial-response>LCxuPXVzZXIsaWQ9c3NvLXNlcnZpY2UtMQo=</initial-response>
|
||||
<user-agent id='d4565fa7-4d72-4749-b3d3-740edbf87770'>
|
||||
<software>AwesomeXMPP</software>
|
||||
<device>Kiva's Phone</device>
|
||||
</user-agent>
|
||||
</authenticate>
|
||||
```
|
||||
|
||||
In case the client sent an unknown SSO service identifier, it SHOULD respond with an error:
|
||||
|
||||
```xml
|
||||
<failure xmlns='urn:xmpp:sasl:2'>
|
||||
<aborted xmlns='urn:ietf:params:xml:ns:xmpp-sasl'/>
|
||||
<unknown-service xmlns='proto:urn:xmpp:sso:0'/>
|
||||
</failure>
|
||||
```
|
||||
|
||||
If the chosen service identifier is known, the server MUST send an HTTPS URL at which the client can authenticate. In case of protocols like OpenID Connect, the sent URL MUST point
|
||||
to a server-controlled callback URL, so that the server knows when the authentication succeeded. That callback URL SHOULD display a hint to the user that they may return to their
|
||||
XMPP client.
|
||||
|
||||
```xml
|
||||
<challenge xmlns='urn:xmpp:sasl:2'>
|
||||
<!-- Base64 of: 'https://auth.example.org/login?secure-parameter=abc&sid=123' -->
|
||||
aHR0cHM6Ly9hdXRoLmV4YW1wbGUub3JnL2xvZ2luP3NlY3VyZS1wYXJhbWV0ZXI9YWJjJnNpZD0xMjMK
|
||||
</challenge>
|
||||
```
|
||||
|
||||
Next, the client responds with an empty [SASL2](https://xmpp.org/extensions/xep-0388.html) response:
|
||||
|
||||
```xml
|
||||
<response xmlns='urn:xmpp:sasl:2'></response>
|
||||
```
|
||||
|
||||
The user is should then be redirected to the server-provided authorization URL.
|
||||
|
||||
## Success Case
|
||||
|
||||
If the user's authentication succeeded and the server's callback URL has been called, the server MUST retrieve user information from the authentication server and use it for
|
||||
the following session. In this example, the returned user information contained the username `user`. As such, the resulting authentication success may look like this (assuming
|
||||
the server is responsible for the `example.org` domain):
|
||||
|
||||
```xml
|
||||
<success xmlns='urn:xmpp:sasl:2'>
|
||||
<authorization-identifier>user@example.org</authorization-identifier>
|
||||
</success>
|
||||
```
|
||||
|
||||
## Failure Case
|
||||
|
||||
If the authentication somehow fails, the server MUST return a [SASL2](https://xmpp.org/extensions/xep-0388.html) authentication failure. One possible failure may be a timeout:
|
||||
|
||||
```xml
|
||||
<failure xmlns='urn:xmpp:sasl:2'>
|
||||
<aborted xmlns='urn:ietf:params:xml:ns:xmpp-sasl'/>
|
||||
<auth-timeout xmlns='proto:urn:xmpp:sso:0' />
|
||||
</failure>
|
||||
```
|
||||
|
||||
## Business Rules
|
||||
|
||||
This authentication mechanism SHOULD only be used on interactive authentication, i.e. when the user is physically able to perform actions, and not on
|
||||
non-interactive logins, for example when reconnecting after losing the connection to the server.
|
||||
|
||||
When authenticating, it is recommended to also request a token for a token-based authentication mechanism, like [FAST](https://xmpp.org/extensions/inbox/xep-fast.html), so that the user does not have
|
||||
to reauthenticate to the third-party on every new connection.
|
||||
|
||||
## Security Considerations
|
||||
|
||||
This specification allows offloading the actual credential handling from the XMPP server to another third-party. Thus, security considerations of that chosen
|
||||
third-party authentication solution apply.
|
||||
|
||||
The server-provided authentication URLs MUST be using a secure protocol, like HTTPS. Clients MUST ignore insecure URLs.
|
||||
|
||||
## Info
|
||||
|
||||
| Key | Value |
|
||||
| --- | --- |
|
||||
| Author | PapaTutuWawa |
|
||||
| Version | 0.0.1 |
|
||||
| Short name | sso |
|
||||
Loading…
Reference in New Issue
Block a user