[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [saml-dev] Extending the AttributeStatement?
> Firstly, I want to be able to set up an AttributeStatement > that contains one or more Attributes, where *each* Attribute > may have either a value (which might be any content) OR may > have information indicating why no value is being provided > (using some sort of structure similar to that used for samlp:Status). Something to keep in mind is that in most real world situations, it turns out that people often never want to reveal that sort of information because it can be considered a security or privacy exposure to explain in detail why something failed. So spending a lot of time on status expressibility hasn't (so far) produced any spec value, IMHO. > Secondly, I'd like to be able to include a "FriendlyName" for > any Attribute in multiple languages. This issue was raised at the time the original proposal to include FriendlyName was made. The conclusion was that nobody (that I recall) in the TC supported anything that complex, but precluding the idea of FriendlyName simply because it would be "better" to fully support i18n was too harsh. In practice, since SAML assertions are not meant to be human readable, FriendlyName is really more of a debugging tool when attribute names are opaque, and it's not clear that full i18n is indeed worth the complexity there. Anyway, I'm not trying to convince you, I'm merely noting that it was discussed, and should be in the TC minutes someplace. > It does not seem that the Attribute element is extensible > except through use of foreign-namespace attributes; there's > no ability to define additional child elements (which I find > that a bit awkward). It's impossible to do this everywhere that somebody might conceivably want without making the schema incredibly complex. In fact, the real alternative is to essentially provide almost no structure at all, which some people in the TC have favored. Wildcards in XSD are very complex and they have unforeseen impacts and take a lot of work to add without breaking things. > And it's not clear to me how to define > an undefined number of FriendlyNames, each with metadata > indicating the language, using attributes. This wasn't viewed as a requirement, as I note above. It can't be done with XML attributes in any reasonable way. -- Scott
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]