Re: [xmpp] 3920bis: authentication identity

[Peter Saint-Andre <[e-mail]>]

On 6/7/10 2:46 AM, Kevin Smith wrote:
> Sorry about jumping back into this thread - I'm trying to do a review
> today (yes, I'm running late).
> 
> On Mon, Mar 8, 2010 at 9:37 PM, Justin Karneges <[e-mail]> wrote:
>> On Monday 08 March 2010 11:55:13 Kevin Smith wrote:
>>> On Mon, Mar 8, 2010 at 7:53 PM, Justin Karneges <[e-mail]> wrote:
>>>> On Sunday 07 March 2010 19:18:54 Kurt Zeilenga wrote:
>>>>> For instance, my PLAIN id might well be "kdz" while my bare JID is
>>>>> "[e-mail]".  My DIGEST-MD5 id might be "kdz@x" in the
>>>>> realm "y@z".
>>>>
>>>> Can you give an example of how this situation might be handled in a
>>>> client UI? If the usernames can differ between mechanisms in a server
>>>> deployment, then you'd need some sort of mechanism-specific
>>>> configuration.  Psi has a "username" field in the account settings which
>>>> can be used to specify a single SASL username to be applied to all
>>>> mechanisms.  I take it this is not good enough?
>>>
>>> It actually is, if you know which mechanism your client is going to pick.
>>
>> Do you know what mechanism the client is going to pick?  Even an "apt-get
>> upgrade" could shake things up, by bringing in SCRAM and affecting mechanism
>> priority.  I suppose mechanism selection is deterministic if you have a
>> controlled client environment.  Maybe that is enough?
>>
>> To me it feels like clients should have mechanism-specific configuration, with
>> ugly words like "DIGEST-MD5" appearing in the GUI.  Or it should be possible
>> to configure clients to always use a specific mechanism, bypassing the magic
>> selection done by SASL libraries based on security settings.
> 
> Or, and this is the solution that's working fine in the real world,
> and was a SHOULD in the original RFC3920, 

Is this the text from RFC 3920 that you're referencing?

   For client-to-server communications, the "bare JID" (<node@domain>)
   SHOULD be the authorization identity, derived from the authentication
   identity, as defined in [SASL], if no authorization identity was
   specified during SASL negotiation (Section 6); the resource
   identifier portion of the "full JID" (<node@domain/resource>) SHOULD
   be the resource identifier negotiated by the client and server during
   Resource Binding (Section 7).

> using a JID derivative and
> having simple clients and a clean experience for the users.
> 
> I accept that there may be different credentials necessary for
> different mechs in a hypothetical situation, but that's covered by the
> SHOULD in 3920 - specialised deployments can always use more
> fully-featured clients (and they do exist - in a controlled
> environment Psi will do the necessary).

Agreed.

> This way we don't have a protocol that forces complex UIs on simple Users.
> 
> For reference, I've only heard of a single deployment that's ever
> wanted to not use the JID (or node) identity for this. Can someone
> (Peter?) with more experience than me say whether they know of a
> significant number of real-world deployments where this is an issue?
> For one deployment wanting to do something different, I think a SHOULD
> here is fine. Servers SHOULD use the JID - we can even add that
> clients SHOULD allow it to be something else if we need to (although I
> don't think that's true).

On the public XMPP network, I have never encountered a server that
needed anything other than localpart or localpart@domainpart. Perhaps
that's a skewed sample (all those IM users), but realistically it's what
we find deployed now.

Perhaps it makes sense to follow RFC 3920 here, then adjust it further
based on further implemenation and deployment experience when we try to
push these specs from Proposed to Draft...

/psa