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

 


Help: OASIS Mailing Lists Help | MarkMail Help

saml-dev message

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