[Ietf-not43] Suggestions of changes to the requirements document

[Vittorio Bertola]

On Tue, 21 Jan 2003 13:03:26 -0500, you wrote:

>> Ok - I got your point, you're right. I'm still wondering whether, in
>> case the decision is "hide the field behind a <<private>> indication",
>> such indication should be made standard (or at least recommended) to
>> increase interoperability (for example, the client could parse the
>> field and recognize such standard answer). But OTOH some registries
>> might want, for example, to replace it with a message in the local
>> language.
>
>That's probably not a bad thing.  What's the proposed text for this?

I have tried to rephrase 3.1.4 a little to include this.

I have included the concept of "type of authentication" to allow for
more than one level of privilege. I think that we should talk about
"types", not "levels", because it's not a hierarchical structure - you
could define a type of privilege such as "privacy-protected" and
another type such as "needs payment to be accessed", but entities who
can access privileged data of the first type should not necessarily be
able to access those of the second, and vice versa; so the
authentication should be per-type (i.e. the protocol should be able to
authenticate you, and the service should be able to determine whether
you can access one type, the other, or both types of privileged data).

I'm not sure whether we need the new paragraph #2. You possibly need
it if you talk about the service, not if you talk about the protocol.


3.1.4 Level of Access

   The service MUST allow the classification of data as being either
   privileged or non-privileged, for the purpose of restricting access
   to privileged data.  Note that this requirement makes no assumption
   or prescription as to what data (social or operational) might be
   considered privileged, but merely provides the ability to make the
   classification as necessary. <new>The system SHOULD support more
   than one type of privileges.</new>

   <new>The service MUST be capable of associating a type of privilege
   (or the lack of any privilege requirement) to each single value of
   each entry.</new>

   The service MUST be capable of serving both privileged and non-
   privileged data.

   The service MUST be capable of authenticating privileged entities
   and ensuring that only those entities have access to
   <changed>privileged data of the type(s) for which they were
   authenticated.</changed>

   The service MUST be capable of providing access to non-privileged
   data without requiring authentication of any type (i.e.  anonymous
   access).

   <new>When the answer to be returned to a user after a query
   contains values of a privilege type for which the user does not
   have authorization, the service MUST NOT return such values. In
   case the choice is made to make it explicit that those values are
   not being returned due to insufficient permissions, the service
   SHOULD return the standard string "[permission denied]" in place of
   such values. In case such values are being denied for privacy
   protection reasons and the choice is made to make it explicit that
   those values are not being returned due to privacy protection
   reasons, the service SHOULD return the standard string "[private]"
   in place of such values.</new>
--=20
vb.                  [Vittorio Bertola - vb [at] bertola.eu.org]<---
-------------------> http://bertola.eu.org/ <-----------------------