> Ando and I have been discussing off-list the need for this op's request
> and response to carry additional fields. The discussion started with a
> separate error code to distinguish errors which might be communicated back
> to authenticating entity (as opposed to the LDAP client submitting the VC
> request).
>
> My current proposal is:
>
> /*
> * LDAP Verify Credentials operation
> *
> * The request is an extended request with OID 1.3.6.1.4.1.4203.666.6.5
> with value of
> * the BER encoding of:
> *
> * VCRequest ::= SEQUENCE {
> * cookie [0] OCTET STRING OPTIONAL,
> * name LDAPDN,
> * authentication AuthenticationChoice
> * controls [3] Controls OPTIONAL
> * }
> *
> * where LDAPDN, AuthenticationChoice, and Controls are as defined in RFC
> 4511.
> *
> * The response is an extended response with no OID and a value of the BER
> encoding of
> *
> * VCResponse ::= SEQUENCE {
> * resultCode ResultCode,
> * diagnosticMessage LDAPString,
> * cookie [0] OCTET STRING OPTIONAL,
> * serverSaslCreds [1] OCTET STRING OPTIONAL
> * authzid [2] OCTET STRING OPTIONAL
> * controls [3] Controls OPTIONAL
> * }
> *
> * where ResultCode is the result code enumeration from RFC 4511, and
> LDAPString and Controls are as
> * defined in RFC 4511.
> */
>
> The use of controls here is to allow both the request/return of password
> policy information to the authenticating entity (as opposed those used on
> the extended operation itself to request/return password policy
> information about the LDAP client submitting the VC request).
>
> Comments?
The code client and server side works now according to the above specs for
simple bind with request and response controls.
I note that you moved authzid retrieval to RFC 3829 authzid control. Are
you going to implement its support server-side? Otherwise I might have
time to look at it, maybe not immediately.
p.
