Subject: Re: Open issue: requester identifier in DPV response

From: Peter Sylvester <[email-masked]>
Date: Wed, 17 Apr 2002 13:13:45 +0200 (MET DST)

> 
> Peter,
> 
> The text proposal was as follows:
> 
>  "When the request is authenticated, the requestor MUST be able, upon
>  request, to have an identifier to be included in the response. Whether
>  and how the communicated identification(s) are validated against identities
>  derived by some authentication method depends on local configurations.
>  Depending on that, the server MAY choose to copy, ignore, or replace
>  the identities by some other in the response, or to refuse the
>  request."
> 
> You said: I did not ask for "when the request is authenticated".
> 
> In such a case it means that you wanted a field to be sent by the requestor
> and to be blindly copied and pasted by the server in the response. In that
> case the semantics of this field cannot be verified by the server and thus
> cannot bear more semantics than "this is the data that I copied and pasted
> from the request".

My request is to remove the part "when .. authenticated' 
You still have the second and thrd sentence which cover
the possibilities that may occur.
To avoid a misunderstanding, replace "local configurations" by
"the validation policy". 

In the following you are combining three actions, the 
indication of what the user specified, a potential authentication,
what the server sends. You take only one case where the policy says
no authentication necessary, and just blindly copy. 

> Capturing this requirement would lead to:
> 
> "The requestor MUST be able, upon request, to have a field to be copied in
> the response."

The proposed text allows a server to modify or reject the request
in whatever way desired. The indication of a requestor identity by
the client does not mean that the client has an absolute (MUST) right
to get this back unmodified or untreated.  

> 
> We do not have such a similar facility in an OCSP response and I wonder why
> we should support it.

If your question would be 'why do we want this' I'd answer that similar
features exist in real life, when you ask for some kind of attestation
given explicitly to you and you are more or less authenticated.

"In reply of your (id of requester) demand from
date, we certifiy today that you are still alive and can vote". 

"This is an invoice for item XXX for company mycorp". 

But, if others believe that the first half-sentence should remain
in order to achieve consensus, I can live with that, too.

---

From: Denis Pinkas <[email-masked]>
Date: Wed, 17 Apr 2002 15:09:29 +0200

Peter,

> To avoid a misunderstanding, replace "local configurations" by

This does not help. There is no relationship with the validation policy, 
but this has to do with the access conditions to the DPV server.
 
> no authentication necessary, and just blindly copy.

The problem is the following: when *another* client sees the DPV response
how can it interpret the semantics of that field ? If there is more than one
interpretation, no one will have the same understanding of the semantics of
that field.

Unless we provide an unambiguous semantics of that field, no requirement
can be added.

> to get this back unmodified or untreated.

This means multiple semantics.

> date, we certifiy today that you are still alive and can vote".

In that real life example, the id of requester is verified and is
thus copied from a dully authenticated identifier.

> "This is an invoice for item XXX for company mycorp".

In that real life example, the item XX is a field that is blindly copied by
the server.

> in order to achieve consensus, I can live with that, too.

Either a choice has to be made between the various alternatives ... or two 
requirements should be incorporated. This would lead to the following text:

1. The requestor MUST be able, upon request, to have a field to be copied 
   in the response.

2. When the request is authenticated, the requestor SHOULD be able, upon
   request, to have an identifier to be included in the response. How this 
   identifier is derived from the authenticated identity depends on local 
   server conditions. The server MAY choose to refuse to include an
   identitier in the response.

Opinions ?
   
Denis

---

From: "Housley, Russ" <[email-masked]>
Date: Wed, 17 Apr 2002 11:54:24 -0400

Hi.

My comments are at the bottom ....

>    identitier in the response.

I think that the first alternative is too vague to be useful.  I nonce 
mechanism that might be included to detect reply would fulfill the requirement.

I think that the second is acceptable.  I could live with it in order to 
reach closure, but I do not think that it is necessary.

Russ