Re: authorization IDs in SACRED

On Thu, 13 Dec 2001, Stephen Farrell wrote:

> > Typical scenarios for other protocols that use authorization ID are
> > administrator access and proxy/middle-tier access.
>
> Do we have such requirements? Where in 3157 is that mentioned?
> ...
> I'm in "if its not needed, leave it out" mode at the moment:-)

I do apologize for not having paid enough attention to the requirements
process to make this requirement clear.  I can only reiterate that these
use cases show up in almost all modern application protocol deployments
that I'm familiar with, and it seems to me people would want them with
SACRED deployments.

It seems unreasonable to suggest that every possible use of the protocol
that isn't defined in 3157 has to be prohibited.

I think there are these choices (assuming that we're going to continue to
use SASL in the protocol):

 (1)  Leave out any mention of authorization ID.  This would be easiest
for the document authors, but doesn't meet the requirements of RFC 2222
and leaves implementors to wonder.

 (2)  Require the authorization ID field to be empty.  This would be easy
enough, but rule out any of the uses I and others have been advocating.
It would also probably require lots of justification to non-WG folks
reading the spec, including IESG, because it's different from any previous
profile of SASL.  So in terms of getting the spec through I suggest it
would slow things down, not speed them up.

 (3)  Say that use of the field is undefined in this document.  This
wouldn't rule out future use of the field, wouldn't require any further
discussion in the document, but might be confusing to implementors.

 (4)  Text like that I proposed in my previous message, which wouldn't
require any more work from implementors that don't want to support it,
supports the scenarios I'm interested in, and is consistent with most
other SASL profiles.

 - RL "Bob"