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

[Andrew Newton]

I'd like to list this as its own item, perhaps making a reference to 
3.1.4.  I think that would be clearer.

-andy

Vittorio Bertola wrote:
> 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>