[sasl] draft-ietf-sasl-scram-11: why don't include the authentication identity in the stored key?

[Jehan Pagès <[e-mail]>]

Hello,

I am reading the SCRAM draft for an implementation and had a remark.
The SCRAM's design motivations states this:

«
The server does not gain the ability to impersonate the client to
      other servers (with an exception for server-authorized proxies),
      unless such other servers allow SCRAM authentication and use the
      same salt and iteration count for the user.
»

But if the username was included in the StoredKey algorithm (for
instance instead of salting the password only, you could salt
[authentication identity + UTF8NUL + password]), noone having the
stored key (whether the server itself or someone having gained access
to it on the user's computer for instance) could use it to access any
service other than the one it was stored for, EVEN IF this other
service has the same salt and iteration count by some extraordinary
chance, unless the same authentication identity is also used on both
service (which might be improbable, though not impossible, as such
identity often include a service domain).

Isn't it better for security (though I agree that the chances of
having same salt and iteration count are weak, here they would be even
weaker)? Moreover in my opinion, associating the
username/authentication identity and the password seems a nicer design
(by including them both into the Stored key).
Am I missing something?
Thanks.

Jehan