Hello,
Thanks very much for your comment. The Security Services TC discussed
this topic at our meeting on October 26, and concluded that it is indeed
possible to extend <Attribute> to allow for multiple-language friendly
attribute names.
There are two ways that additional versions of friendly names could be
provided. The first is to use the "arbitrary XML attributes" provision
of the AttributeType datatype to which <Attribute> is bound. To quote
from Section 2.7.3.1 of the SAML V2.0 core spec:
"This complex type uses an <xs:anyAttribute> extension point to allow
arbitrary XML attributes to be added to <Attribute> constructs without
the need for an explicit schema extension. This allows additional fields
to be added as needed to supply additional parameters to be used, for
example, in an attribute query. SAML extensions MUST NOT add local
(non-namespace-qualified) XML attributes or XML attributes qualified by
a SAML-defined namespace to the AttributeType complex type or a
derivation of it; such attributes are reserved for future maintenance
and enhancement of SAML itself."
The second, of course, is to extend the AttributeType complex type
itself in the manner described in Section 7, formally adding whatever
XML attributes are deemded necessary in a way that is schema-validatable.
Because it is possible for those who desire the additional information
to add it, we have chosen not to change the SAML V2.0 specs or schemas
in this respect.
Note that <StatusMessage> and <StatusDetail> are other locations within
SAML where human-visible strings may reside; in the SAML V1.x work, we
did discuss the possibility of providing error messages in multiple
languages:
http://www.oasis-open.org/committees/download.php/3690/sstc-saml-1.1-issues-draft-02.pdf
(see issue DS-14-14)
...but were unhappy with the structural options we were considering at
the time. We more or less permanently deferred the issue at that time.
If others (such as yourself?) extend SAML to include multiple-language
support and the extension is brought to our attention, we can certainly
look at it for future versions.
Eve
wrote:
> Comment from:
>
> As a general principle, content in XML documents intended for human consumption should be i18n'izable. That is, where there is some text string that humans will read, there should be a provision for providing multiple versions of it in different languages (each version presumably tagged with a language tag).
>
> The FriendlyName attribute (line 1120 in the Core spec) breaks this rule. There should be a way to give multiple FriendlyName values in different languages. This could be done with some sort of extension to Attribute, but this is not allowed. Some sort of alternate mechanism for attaching metadata (like FriendlyName) besides attributes should be defined for Attribute elements.
--
Eve Maler +1 781 442 3190
Sun Microsystems cell +1 781 354 9441
Web Products, Technologies, and Standards eve.maler @ sun.com
