[Standards] XEP-0178 1.1rc3
stpeter at stpeter.im
Thu Apr 14 20:49:22 UTC 2011
On 4/14/11 2:22 PM, Philipp Hancke wrote:
> Peter Saint-Andre wrote:
>>>> never necessary to include the authzid? I suppose the latter
>>>> approach is
>>> Sure. But that was changed in version 0.0.3 and I don't think we can
>>> "fix" that now nor is there a compelling reason.
>> No, there is no compelling need -- such flexibility might be desirable
>> someday, but we don't design for someday.
> We can still be liberal in what we accept and deal with empty
> authorization ids today.
>>> I have no objections to adding a fallback to the stream's in s2s step 11
>>> if the authorization id is empty. IIRC some servers already do that.
>> What is the nature of the fallback?
> I think it gets obvious if you add a 'from' after "stream's" :-/
> The stream's 'from' attribute is used instead of the (empty)
> authorization id. Dave?
I *think* that this discussion thread leads to the following text in
Section 3, but please double-check it.
10. Server1 considers EXTERNAL to be its preferred SASL mechanism. For
server-to-server authentication the <auth/> element MUST NOT include an
authorization identity (thus Server1 includes an empty response of "="
as shown in RFC 6120).
<auth xmlns='urn:ietf:params:xml:ns:xmpp-sasl' mechanism='EXTERNAL'>=</auth>
Interoperability Note: Previous versions of this specification relied on
the authorization identity being present on the receiving server. Even
though this is no longer required, the connecting server should include
it for backward compability.
11. Server2 determines if hostname is valid.
a. If the 'from' attribute of stream header sent by Server1 can be
matched against one of the identifiers provided in the certificate
following the matching rules from RFC 6125, Server2 returns success.
Implementation Note: If Server2 needs to assign an authorization
identity during SASL negotiation, it SHOULD use the value of the 'from'
attribute of the stream header sent by Server1.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 6105 bytes
Desc: S/MIME Cryptographic Signature
More information about the Standards