RE: AuthzIDs or DNs, but not both

["Curtin, William" <curtinw@ftm.disa.mil>]

So then should the draft contain an additional paragraph to assure this
mapping?

For example change section 11 to:

<snip>

   The uAuthzId choice allows for compatibility with client applications 
   which wish to authenticate to a local directory but do not know their
   own Distinguished Name or have a directory entry.  The format of the 
   string is defined as only a sequence of UTF-8 encoded ISO 10646 
   characters, and further interpretation is subject to prior agreement 
   between the client and server.
  
   For example, the userid could identify a user of a specific directory 
   service, or be a login name or the local-part of an RFC 822 email 
   address. In general a uAuthzId MUST NOT be assumed to be globally unique.

<new>
   All servers which support the uAuthzId choice MUST be capable of mapping
the uAuthzId
   to an associated distinguished name for internal use.
<end new>

   Additional authorization identity schemes MAY be defined in future
   versions of this document.



							bill

> -----Original Message-----
> From: Harald Tveit Alvestrand [mailto:Harald@Alvestrand.no]
> Sent: Monday, November 15, 1999 4:47 PM
> To: Kurt D. Zeilenga; JHodges@oblix.com
> Cc: IETF LDAP Extensions WG; RL Bob Morgan
> Subject: Re: AuthzIDs or DNs, but not both
> 
> 
> At 11:30 14.11.99 -0800, Kurt D. Zeilenga wrote:
> >It appears to me that the authzIds-are-not-necessarily-DNs
> >notion will cause a ripple of change through the protocol and
> >information model.  The introduction of authzid
> >representation [AuthMeth] will lead to creatorsAuthzid,
> >modifiersAuthzid, memberAuthzid, and many other use of DNs
> >to be replaced with something that can contain both an
> >authzId.  I believe the addition of authzIds will
> >unnecessarily complicate the protocol and information model.
> 
> When we discussed this in Washington 2 years ago, I think we had an 
> implicit assumption that the authzId in the SASL exchange, 
> which may, but 
> need not, be a DN, would be *mapped to* a DN if required for 
> internal purposes.
> The purpose would be that the DN need not be maintained 
> anywhere seen by 
> the user.
> 
> I don't remember an argument that the idea "an identity is a 
> DN" should be 
> abandoned.
> In other words, I agree with Kurt.
> 
>                      Harald
> 
> --
> Harald Tveit Alvestrand, Maxware, Norway
> Harald.Alvestrand@maxware.no
>