Paul Hoffman wrote:
> At 11:02 AM -0700 6/8/06, James M Snell wrote:
>> '''Ed.Note: Should this MUST stay? go? move to another section? Is it a
>> MUST/SHOULD/MAY?''' Servers utilizing authentication MUST reject
>> unauthorized or unauthenticated requests using the HTTP 401
>> "Unauthorized" response message. Per [RFC2616], 401 Unauthorized
>> responses MUST include a WWW-Authenticate header identifying the
>> authentication scheme that is to be used.
>
> This is not a security consideration, it is a protocol specification.
> And we just agreed not to specify the auth protocol.
>
Works for me, however, from what I read in the authentication thread,
what seems to have been decided was not to specify a particular
authentication scheme. Requiring the use of the 401 response and the
WWW-Authenticate header is a separate issue.
>> Servers utilizing authentication mechanisms that involve the clear-text
>> transmission of a password (e.g. HTTP Basic Authentication) are
>> encouraged to secure the connection using, for example, a Transport
>> Layer Security (TLS) connection.
>
> s/secure/encrypt/ Authentication is a form of securing.
>
>> 14.3 Privacy Concerns
>>
>> Because collections might be editable by multiple clients, privacy
>> concerns could arise when clients are granted full read and edit access
>> to all of a collections member entries and metadata. To reduce the risk
>> of inadvertent release or modification of private information via
>> collection feeds, entry documents and linked media resources, servers
>> are encouraged to utilize access control mechanisms that limit a clients
>> ability to read and edit the metadata associated with a collection and
>> it's member resources.
>
> This is not a security consideration, it is a privacy warning. Privacy
> != security. This seems particularly silly here.
>
Hmmm.. RFC2616 and RFC2518 both discuss privacy issues in their
respective security considerations sections...
>> 14.5 Digital Signatures and Encryption
>>
>> '''Ed.Note: the text here stinks, but it gets away from the shoulds and
>> musts. better text is requested :-)'''
>
> No, it should be removed. Signed and encrypted entities are no different
> than any other entity that might be processed some way.
>
Works for me. However, this will lead to implementations handling
encrypted entries in unpredictable ways. Some may store the encrypted
entry as a media resource; some may decrypt it and publish it in the
clear; some may reject it; etc. With unencrypted entries, the behavior
is generally predictable.
- James
