RE: SCVP 16 comments deadline

[Peter Sylvester <Peter.Sylvester@xxxxxxxxxx>]

> [TF] How the server identifies the client is a mater of local server
> policy.
See my other message and a text proposal. 

> * 
> * The 3379 text says:
> * 
> *    When the DPV request is authenticated, the client SHOULD be able to
> *    include a client identifier in the request for the DPV server to
> copy
> *    into the response.  Mechanisms for matching this identifier with
> the
> *    authenticated identity depends on local DPV server conditions
> and/or
> *    the validation policy.
> * 
> * The client has no way to declare its identity in the protocol,
> * and there no provision of what this could be from what it would
> * be derived from (IP address, DNS name of the host, ...), ...
> [TF] The client can declare its identity in the request in a number of
> ways.
>  	1. by including its signing certificate in the request
> 	2. by including its DH certificate used to compute the hmac
> 	3. By HMACing the request using a shared secret or password

None of these is a "declaration" of an identity. It is a means to authenticate
the request at least in my opinion. 

Note the remark about 'may respond with an error' in
the requirements. This is intended to mean that a server may reject
a request when the declared entity is not one that can be authenticated.
(I don't think that it was meant that an error can be 'not authorized')

> 
> What identity the server knows or uses for the client based on this data
> is a matter of local server policy
>  
> * 
> * Why is this restricted to signed requests, and not to 'authenticated'?
> [TF] Its not. Section 3 defies signed requests as being either
> signedData or authenticatedData.

Ok. 

> * 
> * As already said in another may, this text could make sense if there
> * would be a corresponding requestorName in the request.

you seem to agree?