On Nov 9, 2007 6:09 AM, Dave Cridland <[EMAIL PROTECTED]> wrote: > 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.
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). Personally I'm too interested in doing all my jabber stuff over http (I can write a client that talks xmpp proper) but I am intersted in granting that client some kind of token that would allow it to act as my user for the duration of their web session. obviously there are still some privacy concerns here, but it's better than people using jabber to pull resources by asking for the users jabber credentials directly. ~ Andes > > 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 >
