Skip to main content

Lightweight Directory Access Protocol (LDAP) Proxied Authorization Control
draft-weltman-ldapv3-proxy-13

Approval announcement
Draft of message to be sent after approval:

Announcement

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: Internet Architecture Board <iab@iab.org>,
    RFC Editor <rfc-editor@rfc-editor.org>
Subject: Protocol Action: 'LDAP Proxied Authorization Control' 
         to Proposed Standard 

The IESG has approved the following document:

- 'LDAP Proxied Authorization Control '
   <draft-weltman-ldapv3-proxy-14.txt> as a Proposed Standard

This document has been reviewed in the IETF but is not the product of an
IETF Working Group. 

The IESG contact person is Ted Hardie.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-weltman-ldapv3-proxy-14.txt

Ballot Text

Technical Summary

This document defines the Lightweight Directory Access Protocol 
(LDAP) Proxy Authorization Control. The Proxy Authorization Control 
allows a client to request that an operation be processed under a 
provided authorization identity instead of as the current 
 authorization identity associated with the connection. 
    

Working Group Summary
 
This document was originally considered by the LDAPEXT working
group and it documents deployed mechanisms which are fairly
widely used.  The LDAPEXT working group decided to progress
a different mechanism documented in a document called the
"LDAP "Who am I?" Operation".  That group has disbanded,
but the work on that operation continues and is intended for
Standards Track.  The existance of two Standards Track mechanisms
is normally to be avoided, but in this case it was felt that this
status reflected the existing deployment and reality
  
Protocol Quality

This document was reviewed by Ted Hardie for the IESG.


Note to RFC Editor:

OLD:

The criticality MUST be present and MUST be TRUE. This requirement 
protects clients from submitting a request that is executed with an 
unintended authorization identity. 
 
Clients MUST include the criticality flag and MUST set it to TRUE. 
Servers MUST reject any request containing a Proxy Authorization 
Control without a criticality flag or with the flag set to FALSE with 
a protocolError error.  These requirements protect clients from 
submitting a request that is executed with an unintended 
authorization identity. 

New

Clients MUST include the criticality flag and MUST set it to TRUE. 
Servers MUST reject any request containing a Proxy Authorization 
Control without a criticality flag or with the flag set to FALSE with 
a protocolError error.  These requirements protect clients from 
submitting a request that is executed with an unintended 
authorization identity.

RFC Editor Note