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

From: Peter Sylvester <[email-masked]>
Date: Tue, 16 Apr 2002 20:36:23 +0200 (MET DST)

>       Denis, Peter:
> 
>       I have one question about this proposal.  Is the object to be placed
> into the response a transaction identifier or the RP's identifier?  If it's
> the RP's identifier, IMO it should be called something like "requestor's
> claimed identity" and it should not be permitted to be altered by the
> server, although it might be permitted to be dropped.

"claimed identity" means that you concentrate in some way to
authentication. I rarher see it: The identities which are
destined to be able to present the result. 
A relay could ask 'on behalf of another client'.

Agreed that 'climed identity' may be one of the usage cases defined
in a policy.   

I may agree with something like 
'a server SHOULD not alter arbitrarily the identities'.

> 
> [The DPV server MAY require client authentication, therefore, the DPV
> request MUST be able to be authenticated].
> 
> "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."

I did not ask for "when the request is authenticated".

> 
> My personal opinion is that since the server policy (which has nothing to do
> with a validation policy) will be unkown (i.e. not visible in the response
> and not fixed by the protocol), this field would have no value.
'server policy'? What would this be? 

The point is that the server indicates the 'intended recipient'
of the response. It determines this information using some explicit
information from the client in combination with wahtever should be 
necessary as authentication.

---

From: Denis Pinkas <[email-masked]>
Date: Wed, 17 Apr 2002 11:43:39 +0200

Peter,

The text proposal was as follows:

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".

Capturing this requirement would lead to:

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

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

Opinions ?

Denis

========================================================================