[Standards] LAST CALL: XEP-0388 (Extensible SASL Profile)
This message constitutes notice of a Last Call for comments on XEP-0388. Title: Extensible SASL Profile Abstract: This document describes a replacement for the SASL profile documented in RFC 6120 which allows for greater extensibility. URL: https://xmpp.org/extensions/xep-0388.html This Last Call begins today and shall end at the close of business on 2024-04-01. Please consider the following questions during this Last Call and send your feedback to the standards@xmpp.org discussion list: 1. Is this specification needed to fill gaps in the XMPP protocol stack or to clarify an existing protocol? 2. Does the specification solve the problem stated in the introduction and requirements? 3. Do you plan to implement this specification in your code? If not, why not? 4. Do you have any security concerns related to this specification? 5. Is the specification accurate and clearly written? Your feedback is appreciated! ___ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-le...@xmpp.org
[Standards] LAST CALL: XEP-0386 (Bind 2)
This message constitutes notice of a Last Call for comments on XEP-0386. Title: Bind 2 Abstract: This specification provides a single-request replacement for several activities an XMPP client needs to do at startup. URL: https://xmpp.org/extensions/xep-0386.html This Last Call begins today and shall end at the close of business on 2024-04-01. Please consider the following questions during this Last Call and send your feedback to the standards@xmpp.org discussion list: 1. Is this specification needed to fill gaps in the XMPP protocol stack or to clarify an existing protocol? 2. Does the specification solve the problem stated in the introduction and requirements? 3. Do you plan to implement this specification in your code? If not, why not? 4. Do you have any security concerns related to this specification? 5. Is the specification accurate and clearly written? Your feedback is appreciated! ___ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-le...@xmpp.org
[Standards] Re: LAST CALL: XEP-0388 (Extensible SASL Profile)
On Mon, 18 Mar 2024 at 14:19, Stephen Paul Weber wrote: > >1. Is this specification needed to fill gaps in the XMPP protocol > >stack or to clarify an existing protocol? > > Yes, we currently have no way to use multiple SASL or otherwise to acheive > a > similar result. > > >2. Does the specification solve the problem stated in the introduction > >and requirements? > > Yes. However it does lack any way to support indicating to the server > which > credential will be used, other than perhaps by implication from the SASL > mechanism. > > That's not the purview of a SASL profile. If a SASL mechanism supports multiple credentials, that's entirely encapsulated within that mechanism. > >3. Do you plan to implement this specification in your code? If not, > >why not? > > Yes, I have implemented this for xmpp.js -- except for "tasks" which I > have > not implemented and I think there are no official profiles of, making that > a > somewhat more risky area of the spec. > There's XEP-0400, actually, which defines two tasks. > > >4. Do you have any security concerns related to this specification? > > No, only usability concerns outlined above > > >5. Is the specification accurate and clearly written? > > Yes > ___ > Standards mailing list -- standards@xmpp.org > To unsubscribe send an email to standards-le...@xmpp.org > ___ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-le...@xmpp.org
[Standards] Re: LAST CALL: XEP-0388 (Extensible SASL Profile)
However it does lack any way to support indicating to the server which credential will be used, other than perhaps by implication from the SASL mechanism. That's not the purview of a SASL profile. If a SASL mechanism supports multiple credentials, that's entirely encapsulated within that mechanism. Except that it is not. For example all of the SCRAM-SASL-* profiles can easily support authentication with any of the passwords on an account, but they need to know in advance which one is being used. So SASL mechanism is insufficient for selecting credential by itself. The same goes for the HT-* token mechanisms. signature.asc Description: PGP signature ___ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-le...@xmpp.org
[Standards] XMPP Council Agenda 2024-03-19
Good morning Council Members, the next XMPP Council Meeting will take place on, Tuesday, March 19 2024 at 16:00 UTC in xmpp:coun...@muc.xmpp.org?join The Agenda is as follows: 1) Roll call 2) Agenda Bashing 3) Editors update * LAST CALL: XEP-0388 (Extensible SASL Profile) * LAST CALL: XEP-0386 (Bind 2) 4) Items for voting a) Issue Last Call on XEP-0333: Displayed Markers (was: Chat Markers) https://xmpp.org/extensions/xep-0333.html 5) Pending votes * Dan on Proposed XMPP Extension: Message Displayed Synchronization See the spreadsheet of Doom: https://docs.google.com/spreadsheets/d/1H310M8z6Kdo6XyNf2DwafzrSLuwhaLNvzfaRQb5Atdg/edit?usp=sharing 6) Date of Next 7) AOB 8) Close ___ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-le...@xmpp.org
[Standards] Re: LAST CALL: XEP-0386 (Bind 2)
On Mon, 18 Mar 2024 at 08:59, Daniel Gultsch wrote: > > This message constitutes notice of a Last Call for comments on > XEP-0386. > > Title: Bind 2 > Abstract: > This specification provides a single-request replacement for several > activities an XMPP client needs to do at startup. > > URL: https://xmpp.org/extensions/xep-0386.html > > This Last Call begins today and shall end at the close of business on > 2024-04-01. > > Please consider the following questions during this Last Call and send > your feedback to the standards@xmpp.org discussion list: > > 1. Is this specification needed to fill gaps in the XMPP protocol > stack or to clarify an existing protocol? Yes. As well as making session initialization generally easier and more performant (by reducing round-trips and the associated logic), it is a big part of closing the unfriendly race condition we have between carbons and MAM ( https://docs.modernxmpp.org/client/protocol/#race-during-login ). > 2. Does the specification solve the problem stated in the introduction > and requirements? Yes. > 3. Do you plan to implement this specification in your code? If not, > why not? Yes, I have implemented it in Prosody. > 4. Do you have any security concerns related to this specification? No. > 5. Is the specification accurate and clearly written? I hope so :) Regards, Matthew ___ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-le...@xmpp.org
[Standards] Re: LAST CALL: XEP-0386 (Bind 2)
1. Is this specification needed to fill gaps in the XMPP protocol stack or to clarify an existing protocol? "Needed" is a strong word, but it is useful to have everything enabled at once. 2. Does the specification solve the problem stated in the introduction and requirements? Yes 3. Do you plan to implement this specification in your code? If not, why not? I have imlemented this for xmpp.js already 4. Do you have any security concerns related to this specification? No 5. Is the specification accurate and clearly written? Yes signature.asc Description: PGP signature ___ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-le...@xmpp.org
[Standards] Re: LAST CALL: XEP-0388 (Extensible SASL Profile)
On Mon, 18 Mar 2024 at 09:00, Daniel Gultsch wrote: > This message constitutes notice of a Last Call for comments on > XEP-0388. > > Title: Extensible SASL Profile > Abstract: > This document describes a replacement for the SASL profile documented > in RFC 6120 which allows for greater extensibility. > > URL: https://xmpp.org/extensions/xep-0388.html > > This Last Call begins today and shall end at the close of business on > 2024-04-01. > > Please consider the following questions during this Last Call and send > your feedback to the standards@xmpp.org discussion list: > > 1. Is this specification needed to fill gaps in the XMPP protocol > stack or to clarify an existing protocol? > > Well, I think so, yes. > 2. Does the specification solve the problem stated in the introduction > and requirements? > > Again, I believe so. > 3. Do you plan to implement this specification in your code? If not, > why not? > > I implemented this some time ago in order to get TOTP working in Openfire - I never merged the code into the main branch, but it is available. > 4. Do you have any security concerns related to this specification? > > Not that aren't already specified. > 5. Is the specification accurate and clearly written? > > I can't really judge this; but after implementing it I did do a sweep over it in order to tidy it up. I have noticed that Example 8 no longer has the additional data Base64 encoded, which is wrong, so this needs fixing prior to advancing it. It also spoils the joke. > Your feedback is appreciated! > ___ > Standards mailing list -- standards@xmpp.org > To unsubscribe send an email to standards-le...@xmpp.org > ___ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-le...@xmpp.org
[Standards] Re: LAST CALL: XEP-0388 (Extensible SASL Profile)
1. Is this specification needed to fill gaps in the XMPP protocol stack or to clarify an existing protocol? Yes, we currently have no way to use multiple SASL or otherwise to acheive a similar result. 2. Does the specification solve the problem stated in the introduction and requirements? Yes. However it does lack any way to support indicating to the server which credential will be used, other than perhaps by implication from the SASL mechanism. 3. Do you plan to implement this specification in your code? If not, why not? Yes, I have implemented this for xmpp.js -- except for "tasks" which I have not implemented and I think there are no official profiles of, making that a somewhat more risky area of the spec. 4. Do you have any security concerns related to this specification? No, only usability concerns outlined above 5. Is the specification accurate and clearly written? Yes signature.asc Description: PGP signature ___ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-le...@xmpp.org
[Standards] Re: LAST CALL: XEP-0388 (Extensible SASL Profile)
On Mon, 18 Mar 2024, 17:32 Stephen Paul Weber, wrote: > >> However it does lack any way to support indicating to the server > >> which > >> credential will be used, other than perhaps by implication from the SASL > >> mechanism. > >> > >> > >That's not the purview of a SASL profile. If a SASL mechanism supports > >multiple credentials, that's entirely encapsulated within that mechanism. > > Except that it is not. For example all of the SCRAM-SASL-* profiles can > easily support authentication with any of the passwords on an account, but > they need to know in advance which one is being used. So SASL mechanism is > insufficient for selecting credential by itself. > > The same goes for the HT-* token mechanisms. > Yes, I mean, the SASL profile itself doesn't do anything there. If you want to indicate a particular credential, you could use the authentication identifier to select which, and the authorization identifier might remain the same. Or a mechanism might support multiple credentials. But the SASL profile isn't involved here. ___ > Standards mailing list -- standards@xmpp.org > To unsubscribe send an email to standards-le...@xmpp.org > ___ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-le...@xmpp.org
[Standards] Re: LAST CALL: XEP-0388 (Extensible SASL Profile)
> This message constitutes notice of a Last Call for comments on > XEP-0388. > > Title: Extensible SASL Profile > Abstract: > This document describes a replacement for the SASL profile documented > in RFC 6120 which allows for greater extensibility. > > URL: https://xmpp.org/extensions/xep-0388.html > > This Last Call begins today and shall end at the close of business on > 2024-04-01. I implemeted it in QXmpp and I think it solves important issues. The only thing I noticed when implementing it is that the XML schema misses the elements , and . That should probably be fixed. :) ___ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-le...@xmpp.org
[Standards] Re: LAST CALL: XEP-0388 (Extensible SASL Profile)
> Yes, I have implemented this for xmpp.js -- except for "tasks" which I have > not implemented and I think there are no official profiles of, making that a > somewhat more risky area of the spec. There is a task defined in XEP-0480 (for upgrading server-stored SCRAM hashes, for example from SHA-1 to SHA-256) ___ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-le...@xmpp.org
