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: Re: [security-services-comment] Public Comment


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 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 

(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.


comment-form@oasis-open.org wrote:

> Comment from: gwachob@visa.com
> 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

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