OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: [comments on SAML X.500/LDAP attribute profile from Steven Legg]

His comments are on the text I proposed on Aug 9, not on the CD, but I
guess the CD ended up pretty close to that.  Anyway FYI.

 - RL "Bob"

---------- Forwarded message ----------
Date: Mon, 23 Aug 2004 18:03:50 +1000
From: Steven Legg <steven.legg@adacel.com.au>
To: RL 'Bob' Morgan <rlmorgan@washington.edu>
Cc: pmishra@netegrity.com, rphilpott@rsasecurity.com
Subject: Re: [proposed SAML attribute profile for X.500/LDAP]


I've CCed the chairs since the public comment mechanism isn't working.

Comments in line.

> ---------- Forwarded message ----------
> Date: Mon, 9 Aug 2004 03:17:55 -0700 (PDT)
> From: RL 'Bob' Morgan <rlmorgan@washington.edu>
> To: OASIS Security Services TC <security-services@lists.oasis-open.org>
> Subject: proposed new text for X.500/LDAP attribute profile
> Below is proposed new text for the X.500/LDAP attribute profile, based on
> discussions with some X.500/LDAP experts last week (I sent .sxw format to
> the editors).  The attribute value issue is rather complex, but I think
> the proposed text will be both more or less correct for now and somewhat
> future-enabled if more sophisticated ASN.1<->XML methods emerge.  The main
> new thing is adding an "Encoding"  XML attribute to the Attribute element,
> so that the currently-specified LDAP-specific encodings might be changed
> out later (eg for the RXER encoding included in the XED work).
> I'm headed off for some vacation, but will check mail occasionally.  I
> won't be on the Tuesday call.
>  - RL "Bob"
> ---
> 8.2 X.500/LDAP Attribute Profile
> Directories based on the ITU-T X.500 specifications [X.500] and the
> related IETF Lightweight Directory Access Protocol specifications [LDAP]
> are widely deployed.  Organizations using these directories make use of
> directory schema to model information to be stored in the directories.
> This includes common schema defined in the X.500 and LDAP specifications
> themselves, schema defined in other public documents (such as the
> Internet2/Educause EduPerson schema [eduPersonSchema], or the
> inetOrgPerson schema [RFC2798]), and schema defined for particular private
> purposes.  In any of these cases, organizations may wish to reuse these

I'm not sure "reuse" is the right word here, perhaps "invoke" ?

> schema definitions in the context of SAML attribute statements, and to do
> so in an interoperable fashion.
> The X.500/LDAP attribute profile defines a common convention for the
> naming and representation of such attributes when expressed as SAML
                                ^^^^ s/such/directory/

Since the term "attribute" is heavily overloaded I usually qualify it
on every usage.

> attributes.
> 8.2.1 Required Information
> Identification: urn:oasis:names:tc:SAML:2.0:profiles:attribute:LDAP
> Contact information: security-services-comment@lists.oasis-open.org
> Description: Given below.
> Updates: None.
> 8.2.2 SAML Attribute Naming
> The NameFormat XML attribute in <AttributeDesignator> and <Attribute>
> elements MUST be urn:oasis:names:tc:SAML:2.0:attrname-format:uri.
> To construct attribute names, the URN oid namespace described in [RFC3061]
> is used. In this approach the Name XML attribute is based on the OBJECT
> IDENTIFIER assigned to the X.500/LDAP attribute type.
> Example:
> urn:oid:
> Since X.500 procedures require that every attribute type be identified
> with a unique OBJECT IDENTIFIER, this naming scheme ensures that the
> derived SAML attribute names are unambiguous.
> For purposes of human readability, there may also be a requirement for
> some applications to carry an optional string name together with the OID
> URN. The optional XML attribute FriendlyName (defined in [SAMLCore]) MAY
> be used for this purpose.  If the definition of the X.500/LDAP attribute
> type includes one or more descriptors (short names) for the attribute
> type, the FriendlyName value, if present, SHOULD be one of the defined
> descriptors.
> 8.2.3 Profile-Specific XML Attributes
> An XML attribute is defined for the  <Attribute> element:
> 	Encoding [Optional]

If a particular directory attribute has values in more than one encoding
(and the directory server is incapable of converting to a single syntax)
then multiple SAML <Attribute> elements would be required to represent them.
It seems nicer to me if the Encoding XML attribute is attached to the
SAML <AttributeValue> elements. The encoding indication is meta-data for
each directory attribute value rather than for the directory attribute type
as a whole.

> This value of this XML attribute specifies the encoding used for the SAML
> attribute value.
                  ^ (a directory attribute value)

Or substitute "X.500" for "directory". These days I tend towards using
"directory" as the adjective for abstract aspects of the directory model
and reserve "LDAP"/"X.500"/"XLDAP" for times when I need to refer to
details of representations.

Only one value of this attribute is defined at this
                       ^ XML

> time: LDAP.  This specifies the use of the LDAP-specific encoding for this
> X.500 attribute value, as described in section 8.2.5.
   ^^^^^ directory

... if you want to follow my convention.

The "X.500/LDAP" cases above could likewise be replaced by "directory".

> 8.2.4 <AttributeDesignator> Comparison
> Two <AttributeDesignator> elements are equal if and only if their Name XML
> attribute values are equal in the sense of [RFC3061]. The FriendlyName
> attribute plays no role in the comparison.
> 8.2.5 SAML Attribute Values
> X.500 attribute definitions for use in native X.500 directories specify
> the syntax of the attribute using ASN.1 [X.680].  For transfer via the
> LDAP protocol, attribute definitions may additionally include an
                           ^ syntax                      ^^^^^^^ specify
> LDAP-specific encoding, commonly of Unicode characters in UTF-8 form.
                                    ^^ producing
> This encoding is identified by an LDAP-specific syntax.

Strike the above sentence.

 > This SAML
> attribute profile only specifies the form of SAML attribute values for
> those attributes for which an LDAP-specific syntax is provided.

"for those directory attributes whose syntaxes specify an LDAP-specific

 > Future
> extensions to this profile may define attribute value formats for other
> X.500-defined attributes.
> For the following LDAP-specific syntaxes:
> Attribute Type Description
> Bit String
> Boolean
> Country String
> DN
> Delivery Method
> Directory String
> DIT Content Rule Description
> DIT Structure Rule Description
> Enhanced Guide
> Facsimile Telephone Number
> Generalized Time
> Guide
> IA5 String
> LDAP Syntax Description
> Matching Rule Description
> Matching Rule Use Description
> Name And Optional UID
> Name Form Description
> Numeric String
> Object Class Description
> Octet String
> Other Mailbox
> Postal Address
> Protocol Information
> Presentation Address
> Printable String
> Substring Assertion
> Telephone Number
> Teletex Terminal Identifier
> Telex Number
> UTC Time

Rather than explicitly list the syntaxes whose values are encoded
as xsd:string, I suggest that you have this case apply to any
directory attribute with a syntax whose LDAP-specific encoding
exclusively produces UTF-8 character strings. This will also
capture all the new directory attribute syntaxes with UTF-8 string
LDAP-specific encodings that are currently in the works.

The above syntaxes can then be listed as examples, e.g. "The following
syntaxes from RFC 2252 have LDAP-specific encodings that always produce
UTF-8 character strings:".

> the value of an X.500 attribute of this syntax is encoded as simply the
> UTF-8 string itself, as the content of the <AttributeValue> element, with
> no additional whitespace. In such cases, the xsi:type XML attribute MUST
> be set to xsd:string.  The Encoding XML attribute is provided, with a
> value of "LDAP".

Consistency: LDAP is quoted but xsd:string is not - both are XML
attribute values!

> For all other LDAP syntaxes, the attribute value is encoded, as the
> content of the <AttributeValue> element, by base64-encoding [RFC2045] the
> encompassing ASN.1 OCTET STRING-encoded LDAP attribute value. The xsi:type
> XML attribute MUST be set to xsd:base64Binary.  The Encoding XML attribute
> is provided, with a value of "LDAP".

Ditto for xsd:base64Binary and LDAP.

> When comparing SAML attribute values for equality, the matching rules
> specified for the corresponding X.500/LDAP attribute type MUST be observed
> (case sensitivity, for example).

I suggest: "When comparing SAML attribute values for equality,
the semantics of the equality matching rule
specified for the corresponding directory attribute type MUST be observed
(case sensitivity, for example)."

> 8.2.6 Example
> The following is an example of a mapping of the "givenName" LDAP/X.500
> attribute, representing the SAML assertion subject's first name. It's OID
> is and the syntax is Directory String.
> <saml:Attribute NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
> 		Name="urn:oid:" FriendlyName="givenName" Encoding="LDAP">
> 	<saml:AttributeValue xsi:type="xsd:string">By-Tor</saml:AttributeValue>
> </saml:Attribute>

"By-Tor" isn't a given name I've heard of before.
Perhaps "Bob" :-) would be better.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]