Re: [Standards] Authorization over HTTP
Dnia 09-11-2007, Pt o godzinie 10:40 +0100, Michal 'vorner' Vaner pisze: Some kind of single-use password? Could be useful for other things too, like I want to log in from a internet coffee I do not trust at all. And again OpenID is a solution here. You are in an internet cafe, and type http://somesite.com/ in the IE there. SomeSite asks you for login. You enter your OpenID there. Your mobile in your pocket beeps, signalling that your XMPP IM client wants your attention. You take it out, and see a question: Hello, it's Your XMPP+OpenID Server. SomeSite http://somesite.com/ needs you to authorise. Additionally it wants to read your vCard data. What do you want to do? [Authenticate and allow access] [Only authenticate] [Cancel] -- /\_./o__ Tomasz Sterna (/^/(_^^' Xiaoka.com ._.(_.)_ XMPP: [EMAIL PROTECTED]
Re: [Standards] Authorization over HTTP
Dnia 09-11-2007, Pt o godzinie 09:15 +, Kevin Smith pisze: a way to authenticate a third party as you, without revealing your credentials to them. This is not the way to go. I would not trust a third party, for full access to all my server data. Correct way to go, is to allow a third party access to encapsulated parts of the user data. Permanent, time-framed or one-time. And this is what OpenID was designed for and is good at. One just need to allow roster read access, vcard read access right for the requesting site and it's done. This would require OpenID frontend to jabberd server data. Easy thing to implement. What we could design though, is XMPP based transport for OpenID requests between servers. But IIUC the main PITA is XMPP usage, because it's easier and more natural for web servers to talk HTTP not XMPP. -- /\_./o__ Tomasz Sterna (/^/(_^^' Xiaoka.com ._.(_.)_ XMPP: [EMAIL PROTECTED]
Re: [Standards] Authorization over HTTP
Hello On Fri, Nov 09, 2007 at 11:07:03AM +0100, Tomasz Sterna wrote: Dnia 09-11-2007, Pt o godzinie 10:40 +0100, Michal 'vorner' Vaner pisze: Some kind of single-use password? Could be useful for other things too, like I want to log in from a internet coffee I do not trust at all. And again OpenID is a solution here. You are in an internet cafe, and type http://somesite.com/ in the IE there. SomeSite asks you for login. You enter your OpenID there. Your mobile in your pocket beeps, signalling that your XMPP IM client wants your attention. You take it out, and see a question: Well, I ment something else. I want to connect to my XMPP server from the cafe. So I (at home) generate single-use password on the server and log in by that. Would be nice if there was a XEP for generate me one single-login password. But it could probably be done with AD-HOC commands. Maybe an informational XEP? -- This email was generated by a biological random generator. If you want more random text, just respond to this email. Michal 'vorner' Vaner pgp4YsLLqfRI1.pgp Description: PGP signature
Re: [Standards] Authorization over HTTP
On Thu Nov 8 17:49:28 2007, anders conbere wrote: Okay... so given that use case (and maybe this is a use case that the xmpp foundation doesn't want to get into) the best way I can see for easing the task for developers is creating an authorization scheme, that allows me to pass of the authentication request via basic http to the jabber server, and recieve from the server an authentication token that I then use to contact the jabber server. You're talking about a pawn ticket mechanism - so the user requests a magic key granting a third party access some portion of normally private data. Could you take a look at the URLAUTH mechanism for IMAP, and see if this approximates your needs? This is a pretty solid mechanism, in deployment, and has gone through security analysis, so it's a reasonable one to port to XMPP. Loosely: 1) External service provides its XMPP identity to the user, along with what access it requires to the user's data. (In this case, the roster). This would be encoded as a URL. 2) If the user agrees, the user hands this URL to their server, and the server hands back a signed version of it. 3) The service can then connect to XMPP, and use this token as authorization to obtain the user's data. In Lemonade, with URLAUTH, it works similarly, although the user has to make up the URL. (Or rather, their client does): 1) User decides to send an email, and uploads a copy to IMAP. 2) User constructs a URL to the message, attaches the relevant stuff which says the submission server can access it, and hands it to the IMAP server to sign. 3) User then sends the signed URL via SMTP in lieu of the DATA command, and the submission server then uses it to both locate, and access, the message data for sending. Dave. -- Dave Cridland - mailto:[EMAIL PROTECTED] - xmpp:[EMAIL PROTECTED] - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
Re: [Standards] Binary data over XMPP
There are already several binary-to-text encodings which perform a bit better than Base64, two of them are: 1. http://en.wikipedia.org/wiki/ASCII85 invented by Adobe 2. http://base91.sourceforge.net/ cheers Tobias Markmann On Nov 9, 2007 10:29 AM, Michal 'vorner' Vaner [EMAIL PROTECTED] wrote: Hello On Fri, Nov 09, 2007 at 10:18:51AM +0100, Matthias Wimmer wrote: Hi Thomasz! Tomasz Sterna schrieb: Simplest that comes to mind: Let's take first 256 allowable UTF-8 characters and assign them to 256 values of a single byte. It is not possible to sent the complete set of the first 256 Unicode code points within XML. E.g. U+ cannot be present in an XML document. That's why there was 'allowable' -- the ones which you are allowed to send -- put characters in line, strike out all the ones you can't send and take the first 256. -- Hallowed be the zeroes and ones Michal 'vorner' Vaner
Re: [Standards] OpenID for XMPP (Was: Authorization over HTTP)
Dnia 09-11-2007, Pt o godzinie 07:39 -0800, anders conbere pisze: This is exactly why I'm talking about, and why openID is not a good solution here. OpenID is fantastic at prooving you're the user you say you are this means that we could safely /Authenticate/ with a jabber server. but we want to do more than that, we want to grant a client continued access to those restricted api's (in this case roster add / remove / request and maybe message sending). How very untrue... http://openid.net/specs/openid-attribute-exchange-1_0-07.html This is the protocol my OpenID gives my e-mail addresses, birthdate, gender, avatar, PO address, my JIDs and other IM IDs, and many more, to the requesting parties. During first login to the site with OpenID I'm informed which pieces of information the external party requested, and I'm able to choose which I want to give, and the period that the acceptance is valid (one-time, until some date or forever). -- /\_./o__ Tomasz Sterna (/^/(_^^' Xiaoka.com ._.(_.)_ XMPP: [EMAIL PROTECTED]
Re: [Standards] OpenID for XMPP (Was: Authorization over HTTP)
On Nov 9, 2007 8:20 AM, Tomasz Sterna [EMAIL PROTECTED] wrote: Dnia 09-11-2007, Pt o godzinie 07:39 -0800, anders conbere pisze: This is exactly why I'm talking about, and why openID is not a good solution here. OpenID is fantastic at prooving you're the user you say you are this means that we could safely /Authenticate/ with a jabber server. but we want to do more than that, we want to grant a client continued access to those restricted api's (in this case roster add / remove / request and maybe message sending). How very untrue... http://openid.net/specs/openid-attribute-exchange-1_0-07.html This is the protocol my OpenID gives my e-mail addresses, birthdate, gender, avatar, PO address, my JIDs and other IM IDs, and many more, to the requesting parties. During first login to the site with OpenID I'm informed which pieces of information the external party requested, and I'm able to choose which I want to give, and the period that the acceptance is valid (one-time, until some date or forever). I'm not seeing in that spec the tools necessary for authorization, which is why I would suspect many of the same people who authored that spec went on to author the OAuth spec http://oauth.googlecode.com/svn/spec/branches/1.0/drafts/5/spec.html That is a spec specifically for /authorizing/ client applications to use restricted api's I'm not following how attribute exchange is particularly useful for granting a client access to api's (perhaps a set of attributes yes, but at least I'm not seeing it provision for resources). ~ Anders -- /\_./o__ Tomasz Sterna (/^/(_^^' Xiaoka.com ._.(_.)_ XMPP: [EMAIL PROTECTED]
Re: [Standards] Binary data over XMPP
On Fri, Nov 09, 2007 at 10:01:39AM -0700, Joe Hildebrand wrote: On Nov 9, 2007, at 8:47 AM, Tobias Markmann wrote: There are already several binary-to-text encodings which perform a bit better than Base64, two of them are: 1. http://en.wikipedia.org/wiki/ASCII85 invented by Adobe 2. http://base91.sourceforge.net/ Both of those seem to allow and , which make them less than ideal for embedding in XML. XMPP is not XML :-))) R
Re: [Standards] Binary data over XMPP
Hello On Fri, Nov 09, 2007 at 10:01:39AM -0700, Joe Hildebrand wrote: On Nov 9, 2007, at 8:47 AM, Tobias Markmann wrote: There are already several binary-to-text encodings which perform a bit better than Base64, two of them are: 1. http://en.wikipedia.org/wiki/ASCII85 invented by Adobe 2. http://base91.sourceforge.net/ Both of those seem to allow and , which make them less than ideal for embedding in XML. Why not replace these 2 with something else? -- If you are over 80 years old and accompanied by your parents, we will cash your check. Michal 'vorner' Vaner pgpTvutzcdXDn.pgp Description: PGP signature
Re: [Standards] Binary data over XMPP
Exactly, it doesn't matter what character the already available methods/implementation output as long as they don't output more than 101 different characters. If they output one we can't use we just replace it with one we can use. cheers Tobias On Nov 9, 2007 7:45 PM, Michal 'vorner' Vaner [EMAIL PROTECTED] wrote: Hello On Fri, Nov 09, 2007 at 10:01:39AM -0700, Joe Hildebrand wrote: On Nov 9, 2007, at 8:47 AM, Tobias Markmann wrote: There are already several binary-to-text encodings which perform a bit better than Base64, two of them are: 1. http://en.wikipedia.org/wiki/ASCII85 invented by Adobe 2. http://base91.sourceforge.net/ Both of those seem to allow and , which make them less than ideal for embedding in XML. Why not replace these 2 with something else? -- If you are over 80 years old and accompanied by your parents, we will cash your check. Michal 'vorner' Vaner
Re: [Standards] s2s blocking of abusive users
Tomasz Sterna wrote: Dnia 08-11-2007, Cz o godzinie 13:15 -0700, Peter Saint-Andre pisze: [..] Unfortunately we did not have a way to ask the sending domain to shut off traffic for just those accounts, so we were forced to temporarily shut down all s2s traffic between jabber.org and the sending domain. This is how things always worked well. If one sends too much, you just stop reading and let the lower layers take care of throttling. It seems to me that it would be good to have an XMPP extension that enables a receiving domain to request that the sending domain shut down s2s traffic on a per-account basis. Isn't that throwing responsibility on the victim? It should be the aggressor, that takes consequences of the action (finding out the abuser). Right. I agree that the sending domain is a victim. But it may not even know that the receiving domain is a victim (because the sending domain admins are not paying close attention or whatever). So at least the receiving domain should have a way to inform the sending domain that there is a problem. That raises the more general issue of better real-time reporting on the operation of your IM service, but that's not a protocol issue so it's off-topic here. What I'm afraid of, is if we encourage taking care of abuse at the passive (receiving) side, that cannot take real action on the abuse, the active (sending) side won't ever implement efficient way of preventing abuses, relying on the reports from victims. (Similar to what is happening in the SMTP realm with SPAM) - Oh, this user is abusing you? I'll disable his account. And this one now? I'm disabling it now. instead of proactive: - My users are abusing you and you throttled me? Oh! I will find out the responsible ones. And will take actions to not let it happen again, cause this is hitting all my innocent users. Hmm. By throttled me do you mean shut down s2s entirely or rate limited s2s? I agree that proactive is better. So are you suggesting that how the jabber.org admins handled this last time was OK and that we don't need better mechanisms for reporting abuse? One thing that would help is better communication among the admins who run XMPP IM services. Like a real community of admins who have to deal with the day-to-day issues of running the code you write based on the specs I define. :) And the funny thing is, I'm one of those admins, so I do feel the pain at the end of the chain even though I don't write any code. But again that's off-topic here -- I'll pursue that somewhere else... Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] Binary data over XMPP
Rachel Blackman wrote: I think we've lost sight of whatever the original problem we were trying to solve was (inline images? Size of binary blobs to mobiles?) and have become caught up in hypothetical solutions which may no longer be directly connected to the issue. :) Right! So let's bite the bullet and say that In-Band Bytestreams is perfectly fine for small bits of data (and maybe even larger blobs of data). If we need something that's good for including really tiny bits of data in a stanza (e.g., via data: URL) then let's define that too so that we can do small incline icons or rasterized images for whiteboards or whatever all else people want to build. All this hypothetical stuff is well and good but it's a tangent. Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] Proposed XMPP Extension: Data Element
XMPP Extensions Editor wrote: The XMPP Extensions Editor has received a proposal for a new XEP. Title: Data Element Abstract: This document specifies a method for including small bits of binary data in an XMPP stanza via the data: URL scheme. URL: http://www.xmpp.org/extensions/inbox/data-element.html See, that was easy, wasn't it? ;-) /psa smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] Proposed XMPP Extension: Data Element
On Fri Nov 9 23:29:05 2007, XMPP Extensions Editor wrote: The XMPP Extensions Editor has received a proposal for a new XEP. And the spot's even red. Although the wrong shade. :-) Dave. -- Dave Cridland - mailto:[EMAIL PROTECTED] - xmpp:[EMAIL PROTECTED] - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
Re: [Standards] Proposed XMPP Extension: Data Element
Peter Saint-Andre wrote: XMPP Extensions Editor wrote: The XMPP Extensions Editor has received a proposal for a new XEP. Title: Data Element Abstract: This document specifies a method for including small bits of binary data in an XMPP stanza via the data: URL scheme. URL: http://www.xmpp.org/extensions/inbox/data-element.html See, that was easy, wasn't it? ;-) And there's always http://wiki.jabber.org/index.php/XHTML_Inband_Images too (I haven't looked at that in a while, but we might want a way to refer to the data/ element from within the same stanza via a sid of some kind). Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] Proposed XMPP Extension: Data Element
On Nov 9, 2007, at 3:55 PM, Peter Saint-Andre wrote: Peter Saint-Andre wrote: XMPP Extensions Editor wrote: The XMPP Extensions Editor has received a proposal for a new XEP. Title: Data Element Abstract: This document specifies a method for including small bits of binary data in an XMPP stanza via the data: URL scheme. URL: http://www.xmpp.org/extensions/inbox/data-element.html See, that was easy, wasn't it? ;-) And there's always http://wiki.jabber.org/index.php/ XHTML_Inband_Images too (I haven't looked at that in a while, but we might want a way to refer to the data/ element from within the same stanza via a sid of some kind). In the XHTML-IM body: img cid='1'/ ...and then within the same message stanza... data cid='1' src='data:image/png;base64,LOTSOFBASE64STUFFHERE'/ La. :) -- Rachel Blackman [EMAIL PROTECTED] Trillian Messenger - http://www.trillianastra.com/
Re: [Standards] [Fwd: I-D Action:draft-cridland-sasl-tls-sessions-00.txt]
Dnia 09-11-2007, Pt o godzinie 23:34 +, Dave Cridland pisze: In particular, think of it in terms of a (mythical?) server that supports XEP-0198 as well. commercial jabberd 2.1 supports XEP-0198 /commercial although only on the very basic level. -- /\_./o__ Tomasz Sterna (/^/(_^^' Xiaoka.com ._.(_.)_ XMPP: [EMAIL PROTECTED]
Re: [Standards] Question About XEP-0060 Authorization
Thanks Peter. Please do keep me updated. If I can be of any assistance, please let me know. I will continue to investigate possible alternatives as well. On Nov 9, 2007 1:01 PM, Peter Saint-Andre [EMAIL PROTECTED] wrote: Lindsay Oproman wrote: Hello, I have a question about subscription authorization that I was hoping someone on this list might be able to help me with. I didn't see anything in the documentation that answers my question. This may be because I am new to XMPP and do not fully understand how resources are treated by the server. Essentially, what I'm trying to do is have notifications sent to *all* FULL JIDs of a subscriber upon publication. For example, [EMAIL PROTECTED] subscribes to a topic. Something is then published to that topic. I want a notification to go to both [EMAIL PROTECTED]/resourceA and [EMAIL PROTECTED]/resourceB... not just the primary entity (whatever that may be). Hmm. I'll have to check the spec, but I think we may need a new subscription configuration option for this. Forcing each full jid to subscribe separately shouldn't be necessary. Peter -- Peter Saint-Andre https://stpeter.im/
Re: [Standards] Binary data over XMPP
On Friday 09 November 2007 3:35 pm, Dave Cridland wrote: ubiquitous encryption Best laugh of the day! Other protocols have been fighting this battle for years. Is XMPP so much different? I can see the headlines: XMPP finally gets everyone in the world to use encryption. Email working group wasted their lives. -Justin
