RE: [security-services] Potential errata for Core

[<robert.philpott@rsa.com>]

Never mind... brain is burned out from long hours.  It's defined in the
spec under <Attribute> and is very clear. If it has no <AttributeValue>
then the attribute exists but has no values, not a value that is null or
a value that is empty.  It has no values.  

Duh. 

We now return you to your previous programming...

Rob Philpott 
RSA, the Security Division of EMC
Senior Technologist | e-Mail: robert.philpott@rsa.com | Office: (781)
515-7115 | Mobile: (617) 510-0893


> -----Original Message-----
> From: robert.philpott@rsa.com [mailto:robert.philpott@rsa.com]
> Sent: Wednesday, December 09, 2009 2:28 PM
> To: security-services@lists.oasis-open.org
> Subject: [security-services] Potential errata for Core
> 
> I got asked today about something that appears to be ambiguous in
> Core's
> description of <AttributeValue>.
> 
> I was asked how an attribute specified with no <AttributeValue>
element
> specified in an assertion should be interpreted. For example:
> 
> <saml:AttributeStatement>
>   <saml:Attribute FriendlyName="closure" Name="closure"
> NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic"/>
> </saml:AttributeStatement>
> 
> This is, of course, schema-valid.  The question is whether the absence
> of the <AttributeValue> element means that the value of that attribute
> is empty or whether it means it is nil (since these are two different
> states), or should it be disallowed (through normative language, not a
> schema change)?
> 
> IMO, based on the current wording in Core, the assumption is that the
> <AttributeValue> element should be present in both of these cases and
> it
> has to follow the specified rules.  That is, it either has an empty
> value (e.g. <AttributeValue/>) OR it has an empty value AND the XML
> attribute xsi:nil is specified and set to "true".
> 
> In these 2 items, we don't state that an <AttributeValue> element MUST
> be present.  We state that "the corresponding <AttribtueValue> element
> MUST be empty...".   To me, that implies it has to be present, but
> doesn't say so.  It doesn't address how to interpret it if it is not
> present.
> 
> There are a couple of options:
> 1)	In both cases, we change the text to say that the
> "<AttributeValue> element MUST be specified and MUST be empty..."
> 2)	We define how to interpret the case of it not being present and
> amend the text to account for that.
> 
> In the case of 2), do folks think that the absence of the
> <AttributeValue> should mean that the attribute has a null value?  In
> this case, we have to supplement the language to not just allow using
> xsi:nil="true", but also allow no <AttributeValue> at all (as per the
> example).Or do folks interpret 2) to mean the attribute has an empty
> value.  I think the former case makes more sense to me.
> 
> Thoughts?
> 
> Rob Philpott
> RSA, the Security Division of EMC
> Senior Technologist | e-Mail: robert.philpott@rsa.com
> <rphilpott@rsa.com>  | Office: (781) 515-7115 | Mobile: (617) 510-0893
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>