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] Potential errata for Core

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.  


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

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