[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: authmeth: Access controls vs. confidentialityRequired



Kurt D. Zeilenga writes:
> At 11:23 AM 9/28/2004, Hallvard B Furuseth wrote:
>>Kurt D. Zeilenga writes:
>>> The choice of which code to return depends on what the
>>> server is trying to indicate.   For instance, if the
>>> server requires some form of data confidentiality to
>>> update the directory, returning confidentialityRequired
>>> is a good code to indicate that this requirement has
>>> been violated.
>> (...)
>>> However, if the server is willing to
>>> perform the operation but decides in that performance
>>> that some access control factor precludes completing
>>> that operation, insufficientAccessRights is good code
>>> to indicate this.
>>
>> I don't understand.  Sounds to me like either the first case is an
>> example of the second, unless you mean the second case is about how the
>> operation is implemented - that is, it starts performing the operation
>> and then runs into the access control factor, as opposed to discovering
>> the access control factor at once.  I don't see why that should affect
>> what the server says about why the operation was refused.
> 
> I'm trying to point out that the choice of code that
> is returned in such cases often depends on whether
> the decision to return the code was made within the
> access rights (authorization) subsystem or made within
> some other administrative control subsystem.

Well, yes, that's why I started this thread.  The natural way for the
server to do this does not seem to be the right way, unless it
explicitly provides another way than access control factors which should
be used to require a secure connection for access to an entity.

I've been waffling a bit over this, but lacking examples to the
contrary, I think the draft has it right 'in theory': The server MUST
return confidentialityRequired.  In practice, I suspect that's too hard
a requirement and only should be a SHOULD, with a warning that ignoring
the SHOULD can give severely misleading error responses.

-- 
Hallvard