Re: [kitten] On SASL's authzid

[Nico Williams <[e-mail]>]

On Fri, Mar 7, 2014 at 2:52 PM, Nordgren, Bryce L -FS
<[e-mail]> wrote:
>> > If this was software, you'd keep the API stable during minor revisions and
>> rearrange things for major revisions. The UI would supply whatever it had to
>> in order to use the version of SASL it wants to use.
>>
>> But SASL doesn't define an API (unlike GSS).  So we need to identify what is
>> to be kept stable, if anything, and it's not as simple as "the API".
>
> In general, I would suggest that if a proposed change inspires compatibility concerns, it would seem to belong to the set of things you'd prefer to keep stable.

I don't diagree.  However, since SASL doesn't have an "API" or
anything quite so well defined, so we don't quite know what the
intention was/is, if any, as to this sort of change.  We should state
what a mechanism can and cannot do.

I'm of the opinion that adding a required authzid-like item (like in
that the item is to be transported by the mechanism, but provided and
interpreted by the application) is a change to SASL, therefore not a
change that a mechanism may introduce.  Adding an _optional_
authzid-like item would be OK, but then we get to split hairs as to
what makes something optional or required: if not providing the
"optional" item means the mechanism won't work, then it sounds like
"required" to me, but if it's only the one mechanism that breaks, then
maybe we shouldn't care.

In any case, it does seem clear now that user= _is_ the same as
authzid.  So we don't have to spend any more effort thinking about the
above (though arguably we should).

Nico
--