Subject: Re: proposed CU section for CAP and UPN definition

From: Frank Dawson/CAM/Lotus <[email-masked]>
Date: Thu, 10 Jun 1999 21:15:10 GMT

Paul Hill wrote, in part:

>The UPN representation is independent of the security mechanism used
during
>a particular CUA / CS interaction. A CU may use one mechanism while using
>one CUA but the same user may use a different authentication mechanism
when
>using a different CUA, or while connecting from a different location.
>
>For Calendaring and Scheduling systems that are integrated with a
directory
>system the UPN SHOULD be stored in the attribute [TBD] with OID [TBD].
This
>enables a clear mapping between a UPN and a Distinguished Name. [note:
>Microsoft's Active Directory is storing UPNs as the userPrincipalName.]
>Within a directory service a UPN is a single valued property.

In the first paragraph, you indicate that a CU may be associated with more
than one different UPNs, depending on the access conditions/locations. This
sounds reasonable. Yet, in the second paragraph, you indicate that the TBD
LDAP property is single-valued. So, how do we create a LDAP schema with
multiple TBD LDAP properties for the UPN? Doesn't this imply that we will
have to have different property names for any instance of this class of
property? For example, capUserPrincipalName1, capUserPrincipalName2, ..,
capUserPrincipalNameN? In the "locate" document that defines extended vCard
and LDAP properties for C&S, we took the approach of a primary LDAP
property for the principal URL, that was single-valued, and another LDAP
property for "secondary" URLs that was multi-valued. Hence the secondary
property was also unordered.

Wouldn't this make sense? Others?

-- Frank

---

From: "Paul B. Hill" <[email-masked]>
Date: Thu, 10 Jun 1999 17:52:45 -0400

>LDAP property is single-valued.

After seeing your comment I re-read my text. I still don't see where I said 
that CU may be associated with more than one different UPN.

A user may authenticate with different mechanisms using the same UPN.

In the case where a site wishes to have a user associated with a UPN that 
has the form [email-masked] and user/[email-masked] only one of 
these will have the attribute name and OID that we select for CAP.

If I look at my entry one vendor's directory service I have a single 
userPrincipalName: [email-masked]. But I also have a altSecurityIdentities: 
[email-masked]. The altSecurityIdentities can be multi-valued, so I 
could also have pbh/[email-masked].

For simplicity I think we want to choose one attribute, that is single 
valued. For an implementation that wants to support multiple values it can 
assume that it has specific attribute requirements and can perform a 
mapping back to the single valued attribute.

Does this seem reasonable?

Paul