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: Attribute values or the lack therof

> You have dealt with this issue by defining the proprietary 
> URN.  The rules about defining proprietary URN's has always 
> been a bit fuzzy to me, but I'm not sure that doing what you 
> did conforms to URN registration "rules". Perhaps someone 
> better versed in URN namespace definitions can elaborate.  

Right, strictly speaking, you can't just invent URNs. This is only an issue
in practice for published documents and implementations that go beyond
internal use, but it's better form to use a URL for something like this
unless you have a real URN namespace to use.

> I think the "right" solution to this issue is to fix the SAML 
> spec by permitting an AttributeValue element to be returned 
> as an empty element - i.e. <AttributeValue/>.


> One "might" 
> say that this is already allowed by declaring that section 
> 1.2.1 does not apply to the "user" data provided in this 
> element.  Section 1.2.1 starts out with the sentence "All 
> SAML string and URI reference values have the type xsd:String 
> and xsd:anyURI, respectively...".  So one could just say that 
> the attribute value data is not a "SAML string".  Thus it can 
> be permissible to send an empty element for <AttributeValue>.

That would probably be my interpretation as well, but we should clarify it.
I rather expect the schema to change there for 2.0 anyway.
-- Scott

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