[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]
Bob,
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:2.5.4.3
>
> 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
encoding."
> 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 1.3.6.1.4.1.1466.115.121.1.3
> Bit String 1.3.6.1.4.1.1466.115.121.1.6
> Boolean 1.3.6.1.4.1.1466.115.121.1.7
> Country String 1.3.6.1.4.1.1466.115.121.1.11
> DN 1.3.6.1.4.1.1466.115.121.1.12
> Delivery Method 1.3.6.1.4.1.1466.115.121.1.14
> Directory String 1.3.6.1.4.1.1466.115.121.1.15
> DIT Content Rule Description 1.3.6.1.4.1.1466.115.121.1.16
> DIT Structure Rule Description 1.3.6.1.4.1.1466.115.121.1.17
> Enhanced Guide 1.3.6.1.4.1.1466.115.121.1.21
> Facsimile Telephone Number 1.3.6.1.4.1.1466.115.121.1.22
> Generalized Time 1.3.6.1.4.1.1466.115.121.1.24
> Guide 1.3.6.1.4.1.1466.115.121.1.25
> IA5 String 1.3.6.1.4.1.1466.115.121.1.26
> INTEGER 1.3.6.1.4.1.1466.115.121.1.27
> LDAP Syntax Description 1.3.6.1.4.1.1466.115.121.1.54
> Matching Rule Description 1.3.6.1.4.1.1466.115.121.1.30
> Matching Rule Use Description 1.3.6.1.4.1.1466.115.121.1.31
> Name And Optional UID 1.3.6.1.4.1.1466.115.121.1.34
> Name Form Description 1.3.6.1.4.1.1466.115.121.1.35
> Numeric String 1.3.6.1.4.1.1466.115.121.1.36
> Object Class Description 1.3.6.1.4.1.1466.115.121.1.37
> Octet String 1.3.6.1.4.1.1466.115.121.1.40
> OID 1.3.6.1.4.1.1466.115.121.1.38
> Other Mailbox 1.3.6.1.4.1.1466.115.121.1.39
> Postal Address 1.3.6.1.4.1.1466.115.121.1.41
> Protocol Information 1.3.6.1.4.1.1466.115.121.1.42
> Presentation Address 1.3.6.1.4.1.1466.115.121.1.43
> Printable String 1.3.6.1.4.1.1466.115.121.1.44
> Substring Assertion 1.3.6.1.4.1.1466.115.121.1.58
> Telephone Number 1.3.6.1.4.1.1466.115.121.1.50
> Teletex Terminal Identifier 1.3.6.1.4.1.1466.115.121.1.51
> Telex Number 1.3.6.1.4.1.1466.115.121.1.52
> UTC Time 1.3.6.1.4.1.1466.115.121.1.53
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 2.5.4.42 and the syntax is Directory String.
>
> <saml:Attribute NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
> Name="urn:oid:2.5.4.42" 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.
Regards,
Steven
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]