Re: coments on draft-ietf-sacred-protocol-bss-00

> Explain to me why I need separate authentication and authorization
> (sasl) identities for sacred?
>
> If its not needed for sacred, IMHO, it shouldn't be in.

Typical scenarios for other protocols that use authorization ID are
administrator access and proxy/middle-tier access.  I can imagine a setup
where it's useful for a sysadmin to have the ability to do upload/download
operations "as the user" as part of problem determination.  I can also
imagine setups using proxy frontends to deal with different authentication
capabilities in clients.  Just because some folks wouldn't use them
doesn't mean these scenarios should be forbidden.

RFC 2222 says that a protocol defining its use of SASL has to provide:

   5. A specification of how the authorization identity passed from the
      client to the server is to be interpreted.

So I think the point is to permit implementations to do useful things with
this without making it a burden for those that don't want to use it.
Here's language that I think does that, replacing current language in 2.2
of draft-ietf-sacred-protocol-bss-00.txt:

  Implementations MAY support the use of the SASL authorization identity
  field.  If present, the field is interpreted in an
  implementation-specific manner to select a particular account, subject
  to authorization controls applied by the server.  An unrecognized or
  inappropriate authorization identity MUST cause the server to respond
  with a 537 error code.

I will also point out that handling this as an error is an example of the
additional things that have to be reinvented at the application level if
the unwise course of defining SASL in this protocol is pursued.  Using
BEEP gives you language about handling authorization ID and error codes
for free.

 - RL "Bob"