First draft
The original Bookmarks specification (&xep0048;) used the widely available - Private XML Storage (&xep0049;), but stored all bookmarks in a single element. - When the specification was moved to the Standards Track and Draft, it was also - updated to use the user's Pubsub service (&xep0223;), but kept this single element - containing all bookmarks inside a single Pubsub item.
-Most implementations have kept to the original, Private XML Storage based solution, and - while some newer implementations have used Pubsub, these are limited in capability by the use of - a single item.
-This specification resolves both issues by providing a new Bookmarks specification to migrate to, - and takes the opportunity to update the XML namespace in use as well. The URL storage is dropped, - since it is rarely used. Storage of URL bookmarks is therefore out of scope.
-Clients store each bookmarked chatroom as a Pubsub item within the '&namespace;' node. Each - item SHALL have, as item id, the Room JID of the chatroom (eg, coven@chat.shakespeare.lit).
-The payload of the item SHALL be a conference element qualified by the '&namespace;' namespace, with the following syntax:
-| Element or Attribute | -Definition | -Datatype | -Inclusion | -
|---|---|---|---|
| 'autojoin' attribute | -Whether the client should automatically join the conference room on login. | -boolean defaulting to false &BOOLEANNOTE; | -OPTIONAL | -
| 'name' attribute | -A friendly name for the bookmark. | -string | -RECOMMENDED | -
| <nick/> element | -The user's preferred roomnick for the chatroom. | -string | -OPTIONAL | -
| <password/> element | -Unencrypted string for the password needed to enter a password-protected room. For security reasons, use of this element is NOT RECOMMENDED. | -string | -NOT RECOMMENDED | -
Note: The datatypes are as defined in &w3xmlschema2;.
-This bookmark would be displayed as 'Council of Oberon' and, if activated, would attempt to join the conference room 'council@conference.underhill.org' with nickname 'Puck'.
-Note that a bookmark item MUST contain only one conference room.
-Note also that a conference element has no truly mandatory attributes or child elements, though a name SHOULD be given. Thus the following is legal:
-When a client is sent an event from the Pubsub service for the '&namespace;' node, it MUST check the 'autojoin' attribute if present, and join the room immediately if the attribute is both present and true.
-A server MAY choose to unify the bookmarks from both &xep0049; based and the current &xep0048;.
-When a client publishes a new item, the server MAY collate all items, casting them into the 'storage:bookmarks' namespace and setting the jid attribute to the item id in each case. When contained within a storage element qualified by the 'storage:bookmarks' namespace, this will be the correct format for both current and previous variants of &xep0048;
-If a client publishes a replacement list of bookmarks via the older specifications, a server MAY examine the list and update the individual items as required, sending updates or retraction notifications as needed. Servers electing to perform this OPTIONAL behaviour SHOULD NOT send notifications for unchanged items.
-This specification relies fully on a number of others. Most particularly, support for this protocol is available if &xep0223; is supported.
-The authors would like to note that much of the syntax description was copied exactly from &xep0048; by Rachel Blackman, Peter Millard, and Peter Saint-Andre. Much of the remainder of this specification is based closely on their work.
-The password child element of conference is well known to provide only very weak levels of security; storing it in bookmarks lowers this security still further.
-First draft.
Colors provide a valuable visual cue to recognize text. Recognition of colors works much faster than recognition of text. Together with the length and overall shape of a piece of text (such as a nickname), a color provides a decent amount of entropy to distinguish a reasonable amount of entities.
-The color generation mechanism should provide the following features:
-To generate a color from a string of text, the follownig algorithms are applied in order:
-Implementations may colorize the participants of a conversation with an individual color to make them easier to distinguish.
-In such cases, the color SHOULD be generated as described in the Generating a color section. The input used SHOULD be, in descending order of preference, (a) the name assigned in the roster, (b) the nickname from the conversation, (c) the bare JID.
-Implementations may want to show a picture in connection with a contact even if the contact does not have an avatar defined (e.g. via &xep0084;).
-In such cases, auto-generating an avatar SHOULD happen as follows:
-Input: An identifier, encoded as octets of UTF-8 (&rfc3269;).
-Output: Angle in the CbCr plane.
-Note: The goal of this algorithm is to convert arbitrary text into a scalar value which can then be used to calculate a color. As it happens, the CbCr plane of the YCbCr space determines the color (while Y merely defines the lightness); thus, an angle in the CbCr plane serves as a good scalar value to select a color.
-Input: Angle in the CbCr plane.
-Output: Angle in the CbCr plane.
-Note: This algorithm will re-map the angle to map it away from ranges which can not be distinguished by people with the respective &cvds;.
-Divide the angle by two.
-Divide the angle by two and add π/2 (half Pi).
-Input: Angle in the CbCr plane, from the previous algorithm.
-Output: Values for Cb and Cr in the YCbCr BT.601 color space in the range from -0.5 to 0.5.
-Form a vector from the angle and project it to edges of a quad in 2D space with edge length 1 around (0, 0). The resulting coordinates are Cb and Cr:
- abs(cb)) {
- factor = 0.5 / abs(cr);
-} else {
- factor = 0.5 / abs(cb);
-}
-cb = cb * factor;
-cr = cr * factor;
-]]>
- Input: Values for Cb and Cr in the YCbCr BT.601 color space in the range from -0.5 to 0.5; Value for Y.
-Output: Values for Red (R), Green (G) and Blue (B) in the RGB color space in the range from 0 to 1.
-Note: The recommended value for Y is 0.732. See Gamma Correction for a discussion on the choice of Y.
-Input: RGB values for the color to adapt (Ri, Gi, Bi) and for the background color to adapt to (Rb, Gb, Bb), in the range from 0 to 1 each.
-Output: Values for Red (Rc), Green (Gc) and Blue (Bc) in the RGB color space in the range from 0 to 1.
-Input: Values for Red (R), Green (G) and Blue (B) in the RGB color space in the range from 0 to 1.
-Output: Values for Cb and Cr in the YCbCr BT.601 color space in the range from -0.5 to 0.5; Value for Y.
-Calculate Y, Cb and Cr according to BT.601:
-Input: A set of RGB colors (each component from 0 to 1).
-Output: A mapping from CbCr pairs (each component from -0.5 to 0.5) to RGB colors.
-Note: when the algorithm finishes, the mapping maps CbCr values (rounded to two decimal places) to the R, G, B triples which come closest to the desired color and lightness.
-Input: A set of colors (the palette) as tuples of Cbp and Crp and a color to map to the closest palette color as Cb and Cr value.
-Output: A palette color as Cbr and Crr values.
-D = sqrt((Cbp-Cb)*(Cbp-Cb) + (Crp-Cr)*(Crp-Cr)).Note: the distance metric is simply the euclidian distance in the CbCr plane.
-This section holds test vectors for the different configurations. The test vectors are provided as Comma Separated Values. Strings are enclosed by single quotes ('). The first line contains a header. Each row contains, in that order, the original text, the text encoded as UTF-8 as hexadecimal octets, and the Cb, Cr, Red, Green, and Blue values.
-The used palette can be generated by sampling the RGB cube evenly with six samples on each axis (resulting in 216 colors). The resulting palette is commonly known as the palette of so-called "Web Safe" colors.
-An implementation may choose a different value for Y depending on whether the sink for the R, G and B values expects Gamma Encoded or Gamma Decoded values. The recommended default of 0.732 is 0.5 to the power of 0.45, that is, a Gamma Encoded 0.5.
-Modifications to Y SHOULD NOT be used to correct for bright/dark backgrounds. Implementations SHOULD instead use the algorithm described in Adapting the Color for specific Background Colors for that.
-As outlined above, implementations MUST offer the &rgblind; and &bblind; corrections as defined in the Corrections for &cvds; section. Users MUST be allowed to choose between:
-The last option is important for users with monochromatic view.
-Some sources on the internet indicate that people with &cvds; may profit from having larger areas of color to be able to recognize them. This should be taken into consideration when selecting font weights and line widths for colored parts.
-This specification extracts a bit more information from an entity and shows it alongside the existing information to the user. As the algorithm is likely to produce different colors for look-alikes (see &xep0165; for examples) in JIDs, it may add additional protection against attacks based on those.
-Due to the limited set of distinguishable colors, possible &cvds; and/or use of palettes, entities MUST NOT rely on colors being unique in any context.
-This section provides an overview of design considerations made while writing this specification. It shows alternatives which have been considered, and eventually rejected.
-The other common YCbCr variants, BT.709 and BT.2020, do not achieve a brightness across the color space as uniform as BT.601 does. Adapting the Y value for uniform luminosity across the range for CbCr would have complicated the algorithm with little or no gain.
-The HSV and HSL color spaces fail to provide uniform luminosity with fixed value/lightness and saturation parameters. Adapting those parameters for uniform luminosity across the hue range would have complicated the algorithm with litte to no gain.
-Given a fixed-size and finite palette of colors, it would be possible to ensure that, until the number of entities to color exceeds the number of colors, no color collisions happen.
-There are issues with this approach when the set of entities is dynamic. In such cases, it is possible that an entity changes its associated color (for example by re-joining a colored group chat), which defeats the original purpose.
-In addition, more state needs to be taken into account, increasing the complexity of choosing a color.
-This specification needs to collapse an arbitrarily long string into just a few bits (the angle in the CbCr plane). To do so, a CRC32 sum is used.
-An alternative, which may yield better distribution of colors, would have been to use a cryptographic hash function. However, the performance and implementation cost for a cryptographic hash function is considerable compared with a simple CRC32, especially on small (less than 1 kiB) inputs.
-This document requires no interaction with &IANA;.
-This document requires no interaction with the ®ISTRAR;.
-Thanks to Daniel Gultsch, Georg Lukas, and Tobias Markmann.
-First draft
&xep0391; can be used to utilize different end-to-end encryption methods to secure Jingle Transports, eg. in the context of &xep0234;. This document aims to extend &xep0391; to allow the use of OMEMO encryption with Jingle transports. To achieve this goal, this protocol extension makes use of OMEMOs KeyTransportElements.
-Conveniently the OMEMO protocol already provides a way to transport key material to another entity. So called KeyTransportElements are basically normal OMEMO MessageElements, but without a payload, so the contained key can be used for something else (See Section 4.6 of XEP-0384). This extension uses the key encrypted in the KeyTransportMessages <key> attribute and initialization vector from the <iv> attribute to secure Jingle Transports. The key corresponds to the Transport Key of XEP-0391, while the iv corresponds to the Initialization Vector. The KeyTransportMessage is the equivalent to the Envelope Element. Note that within the Envelope Element, the Transport Key is encrypted with the OMEMO ratchet.
-Unfortunately &xep0384; determines the type of the transported key to be AES-128-GCM-NoPadding, so no other configuration can be used in the context of this extension.
-Since OMEMO deviceIds are not bound to XMPP resources, the initiator MUST encrypt the Transport Key for every device of the recipient.
-In order to transport a key to the responder, the initiator creates a fresh AES-128-GCM-NoPadding Transport Key and Initialization Vector and generates an OMEMO KeyTransportElement from it as described in XEP-0384. This is then added as a child of the JET <security> element. The 'cipher' attribute MUST be set to 'aes-128-gcm-nopadding:0' (see the ciphers section of XEP-0391). The value of the 'type' attribute must be set to the namespace of the used version of XEP-0384 &VNOTE;.
- -The recipient decrypts the OMEMO KeyTransportElement to retrieve the Transport Secret. Transport Key and Initialization Vector are later used to encrypt/decrypt data as described in &xep0391;.
-To advertise its support for JET-OMEMO, when replying to service discovery information ("disco#info") requests an entity MUST return URNs for any version of this extension, as well as of the JET extension that the entity supports -- e.g., "urn:xmpp:jingle:jet-omemo:0" for this version, or "urn:xmpp:jingle:jet:0" for &xep0391; &VNOTE;.
-In order for an application to determine whether an entity supports this protocol, where possible it SHOULD use 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.
-First draft
Jingle Encrypted Transports (JET) strives to provide a modular and easily extensible way to wrap Jingle Transports in an additional end-to-end encryption layer. The focus of this specification lays on being modular. It should be possible to extend existing Jingle use scenarios with end-to-end encryption by simply adding a JET element to the negotiation.
-JET uses multiple encryption layers, so it is necessary to declare a distinct denomination for the different keys involved.
-| Designation | -Abbrevation | -Usage | -
|---|---|---|
| Transport Key | -TK | -(Symmetric) key that is used to encrypt/decrypt the bytestreams sent/received through Jingle transports. This key encrypts the data two entities want to exchange. Examples for TK can be found under "Ciphers". | -
| Initialization Vector | -IV | -Initialization vector that is used together with TK. | -
| Transport Secret | -TS | -Serialization of TK and TI. | -
| Envelope Element | -EE | -Output element of an established end-to-end encryption method when encrypting TS. | -
Lets assume Romeo wants to initiate an encrypted Jingle session with Juliet. Prior to the Jingle session initiation, an already existing, established and (ideally) authenticated end-to-end encryption session between Romeo and Juliet MUST exist. This session is needed to transfer the Transport Secret from Romeo to Juliet.
-When this precondition is met, Romeo initially generates a transport key (TK) and associated initialization vector (IV). These will later be used by the sender to encrypt, and respectively by the recipient to decrypt data that is exchanged. This protocol defines a set of usable ciphers from which Romeo might choose. TK and IV are serialized to create the transport secret (TS).
-Next Romeo uses her established encryption session with Juliet to encrypt TS. The resulting envelope element (EE) will be part of the Jingle session initiation as child of the JET &secret; element.
-When Juliet receives Romeos session request, she decrypts EE to retrieve TS, from which she can deserialize TK and IV. Now she and Romeo can go on with the session negotiation. Once the session is established, data can be encrypted and exchanged. Both parties MUST keep a copy of TS in cache until the Jingle session is ended.
-&xep0234; has the disadvantage, that transmitted files are not encrypted (aside from regular TLS transport encryption), which means that intermediate nodes like XMPP/proxy server(s) have access to the transferred data. Considering that end-to-end encryption becomes more and more important to protect free speech and personal expression, this is a major flaw that needs to be addressed.
-In order to initiate an encrypted file transfer, the initiator includes a JET &secret; in the Jingle file transfer request.
- -In this scenario Romeo wants to send an encrypted text file over to Juliet. First, he generates a fresh AES-256 transport key and IV. TK and IV are serialized into TS which is then encrypted using Romeos end-to-end-encryption session with Juliet.
-The resulting envelope element (EE) is sent as part of the security element along with the rest of the jingle stanza over to Juliet.
-Juliet decrypts the envelope element (EE) using her session with Romeo to retrieve TS from which she deserializes TK and IV. Both Juliet and Romeo then carry on with the session negotiation as described in &xep0234;. Before Romeo starts transmitting the file, he encrypts it using TK and IV. He then transmitts the encrypted file over to Juliet.
-When Juliet received the file, she uses the TK and IV to decrypt the received file.
-Juliet might want to request a file transfer from Romeo. This can be the case, when Romeo hosts the file. In order to do so, she sends generates TK and IV, creates TS from those and encrypts TS with an encryption method of her choice to get EE. TK and IV will be used by Romeo to encrypt the requested file before sending it to Juliet.
-&xep0234; defines a way for parties to request ranged transfers. This can be used to resume interrupted transfers etc. In case of an interrupted transfer, the receiving party might be able to decrypt parts of the received file. When requesting a resumption of the transfer, the recipient therefore can use the index of the last successfully decrypted byte of the file as offset in the ranged transfer. Since a resumed transfer takes place in a new session, the old transport secret might no longer be available to either party. For that reason the receiver creates a new TS for the session-initiation. The sending party then encrypts and sends only the requested parts of the file.
-In order to encrypt the transported bytestream, the initiator must transmit a cipher key to the responder. There are multiple options available:
-| Namespace | -Type | -Length (bits) | -Parameters | -Serialization | -
|---|---|---|---|---|
| urn:xmpp:ciphers:aes-128-gcm-nopadding:0 | -AES | -128 | -GCM/NoPadding | -128BitKey::96BitIV | -
| urn:xmpp:ciphers:aes-256-gcm-nopadding:0 | -AES | -256 | -GCM/NoPadding | -256BitKey::96BitIV | -
The column 'serialization' describes, how the key and iv are serialized. "::" means plain concatenation of byte arrays.
-To advertise its support for the Jingle Encrypted Transports, when replying to service discovery information ("disco#info") requests an entity MUST return URNs for any version, or extension of this protocol that the entity supports -- e.g., "urn:xmpp:jingle:jet:0" for this version, or "urn:xmpp:jingle:jet-stub:0" for a stub encryption method &VNOTE;.
-In order for an application to determine whether an entity supports this protocol, where possible it SHOULD use 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.
-The initiator SHOULD NOT use the generated key TK as IV, but instead generate a seperate random IV.
-Instead of falling back to unencrypted transfer in case something goes wrong, implementations MUST instead abort the Jingle session, informing the user.
-IMPORTANT: This approach does not deal with metadata. In case of &xep0234;, an attacker with access to the sent stanzas can for example still see the name of the file and other information included in the <file/> element.
-The responder MUST check, whether the envelope element belongs to the initiator to prevent MitM attacks
-This is only a rough draft and there is still a ton of questions left to be answered. Here is a small non-exhaustive list of things I can think of:
-First submission.
Romeo is an active XMPP IM (Instant Messaging) user or the operator of - an XMPP server. He convinces Juliet (who may not have an XMPP account yet) - to install a client but she may still need to choose an XMPP server, - create an account, and add Romeo as a contact. - This specification defines two ways for Romeo to simplify this process for Juliet:
-If Romeo is an XMPP user, he can create an out-of-band link (URI) - which allows Juliet to:
-The process is designed to automatically skip steps that Juliet already - completed, to make the overall experience as smooth as possible.
-If Romeo is an administrator of an XMPP server, he can create an - out-of-band link (URI) which allows Juliet to:
-This specification makes use of XMPP URIs. The basic URI scheme for XMPP - is defined in &rfc5122; and extended in &xep0147; and &xep0379;. - Furthermore, this heavily builds upon the blocks provided in - XEP-0379 for landing page and roster subscription. -
-- To create out-of-band invitation links, Romeo's server needs to implement - the &xep0050; commands specified in the following section, and his client - must be able to execute them. -
-- Furthermore, Romeo's server SHOULD provide a HTTPS service hosting the - landing page. -
-Romeo can query his server for the availability of "User Invitation" and - "Account Creation" commands:
-TODO: use appropriate node namespace.
-When performing the account creation, Juliet's client needs to ensure - that the server supports the extended IBR protocol with a <preauth> - token: TODO
-OPTIONAL.
-A user can execute the 'invite' command to obtain a new invitation link - with a unique invitation token.
-The token should be unique, sufficiently - long and generated by a strong random number generator.
-A server MUST provide the uri field which contains an - XMPP URI of the following format:
-xmpp:inviter@example.com?roster;preauth=TOKEN;ibr=y
- The ibr query component in the XMPP URI indicates that - the invitee is allowed to create an account on Romeo's server, using the - 'preauth' token. - If the server does not support or allow in-band registration for invited - users, the server MUST omit the ibr query component.
-Additionally, the server SHOULD provide the landing-url - field which contains an HTTPS URL of a web-based landing page as described - in &xep0379; § 3.3. The URL format may differ from the example shown here - depending on where the landing page is hosted.
-If the server omits the landing-page field, Romeo's - client SHOULD generate an appropriate landing page URL hosted by the - client developer or a trusted third party.
-A server MAY provide a field which provides the expiration date of the - generated token. The expiration date MUST conform to the DateTime profile - specified in &xep0082;. If the field is not provided, the token does not - expire.
-Romeo's client should provide adequate means to export the - landing-page URL, possibly accompanied with a short - description and the expire information, so that Romeo can - share it with Juliet by other means than XMPP, like e-mail or a QR code.
-The landing page that the generated URL points to should correspond to - the format described in XEP-0379 §3.3, and it needs to - convey the following information:
-If the landing page is hosted by Romeo's server, the server MAY display - additional information based on the supplied TOKEN value, like the name - of the inviter or validity information.
-If Juliet does not have an XMPP client installed, she will not be able - to open the xmpp: link from the invitation page. - For this case, the landing page needs to indicate that a client must be - installed first, and that the link will not work as intended without. - The automatic installation of an appropriate IM client when a user - clicks on an xmpp: is outside of the scope of this - document.
-With an XMPP client installed, Juliet can open the - xmpp: link and have the client process it - appropriately, as follows:
-If Juliet's client is already configured with an account, the default - action for the presented - xmpp:inviter@example.com?roster;... URI is to add the - inviter to Juliet's roster. This should be performed as described in - §3.4 of XEP-0379, by sending a presence subscription - request containing the 'preauth' token.
-If Juliet already has Romeo in her roster, her client should open the - appropriate chat interface instead.
-If Juliet's client does not have an XMPP account configured, she - needs to login or register an account first. Therefore, the client - should provide an interface with the following options:
-If the xmpp: URI provided by Romeo contains the - ibr=y parameter, it indicates that the server - supports the Pre-Authenticated In-Band - Registration defined in this document. If Juliet chooses this - approach, the server will ensure that after the registration, Romeo is - added to her roster with a full presence subscription.
If - Juliet chooses to login or register with a different server, her - client must complete the respective process and issue a subscription - request as described in §3.4 of XEP-0379.
-If Romeo is the administrator of an XMPP server, he might want to - ensure that Juliet obtains an account on this server, with a username - defined either by Romeo or by Juliet, and in a way that does not require - the out-of-band communication of user passwords.
-TODO: description of overall process steps, design motivation.
-A server MAY require a username to be specified for account creation. - In this case, the server MUST add the <required/> element to the - username field. - The username MUST be a valid localpart as defined in &rfc6122; §2.3.
-The server's response for account creation is the same as for user - invitation except for the format of the uri field which - contains an XMPP URI of the following format:
-xmpp:juliet@example.com?register;preauth=TOKEN
- If no username was specified during the account creation process, the - local part of the JID in the XMPP URI is omitted by the server which - results in the following format:
-xmpp:example.com?register;preauth=TOKEN
- TODO: note about sensitivity of TOKEN
-In order to allow invited users to register on a server, the - registration processs as defined in &xep0077; needs to be extended. The - invited user's client MUST add a <preauth> element in the 'TODO' - namespace to the 'jabber:iq:register' query in order to inform the - server that it wants to perform Pre-Authenticated IBR:
-If the server supports and is ready to perform Pre-Authenticated IBR, - it MUST add a <token> element to the response (TODO: 'token' or - 'preauth'?):
-After the invitee has successfully registered on the inviter's server - and roster subscription is enabled for account creation, the server MUST - use roster pushes as defined in &rfc6121; §2.1.6 in order to inform the - inviter about the invitee's new account without the need to reconnect.
-If the inviter's server does not support user invitation, the client - application SHOULD silently fall back to &xep0379; for a good user - experience.
-If a username was specified during the account creation process, the - server SHOULD NOT create an account on the server until the invitee - actually registers it with the corresponding token. - The server MUST reserve the username at least until the corresponding - token expires.
-If the invitee opens an invitation URI with ibr=y and - chooses to create a new account, the client SHOULD pre-fill the - inviter JID's domain part as the new account's domain. The client MAY - provide a mechanism to enter or choose a different server, though.
-OPTIONAL.
-OPTIONAL.
-See security considerations in &xep0379;.
-This document requires no interaction with &IANA;.
-As authorized by &xep0147;, the XMPP Registrar maintains a registry of - queries and key-value pairs for use in XMPP URIs (see &QUERYTYPES;).
-The key-value parameter preauth is added to the - register query action as defined in &xep0077;
-
- register
- ...
-
- preauth
- the token used to allow one-time in-band registration on the inviter's server
-
-
-]]>
-
- In addition to the preauth key-value parameter define - in &xep0379;, the ibr parameter is added to the - roster query action.
-
- roster
- ...
-
- ibr
- y
- the parameter to indicate that the token allows the invitee to create an account on the inviter's server via in-band registration
-
-
-]]>
-REQUIRED for protocol specifications.
-