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


Subject: RE: [security-services] Comparison rules for SAML elements(ISSUE:[DS-14-11: CompareElements])


For ensuring that attribute values are compared apples-to-applies, it might 
be useful to make a reference to the XML Information Set Recommendation's 
definition of normalized attribute values:

   http://www.w3.org/TR/xml-infoset/#infoitem.attribute

Hmm, I just noticed that the Infoset spec defines "normalized value" purely 
by reference to the XML spec:

   http://www.w3.org/TR/REC-xml#AVNormalize

However, using the Infoset terminology (info items and properties) is 
becoming canonical, and that spec may help us solve other comparison issues 
too, in a more substantive way.

         Eve

At 12:02 PM 1/29/02 -0500, Irving Reid wrote:
> > From: Stephen Farrell [mailto:stephen.farrell@baltimore.ie]
> >
> > Don't you need some C14N style stuff about elements and attributes
> > too?
> >
> > Examples that might be relevant (not sure, but in acending order
> > of liklihood):
> >
> > - is absence the same as the presence of a default value?
>
>I don't think we define any default values in our schema.
>
> > - is <foo></foo> the same as <foo/>?
>
>By the definition of XML, yes.
>
> > - <Subject><fred/><bill/></Subject> =
> > <Subject><bill/><fred/></Subject>?
> > - if I have an authentication assertion about <fred> and an
> >   attribute assertion about <Subject><fred/><bill/></Subject> does
> >   that attribute apply to the subject of the authentication assertion?
> >
> > Now, maybe some of these things are well-defined in the current spec,
> > but if so, it wasn't clear to me I'm afraid.
>
>I'm still not entirely comfortable with the multiple-subject stuff either.
>The intent of the language in core-25, if I'm not mistaken, is to say that
>you can put more than one subject name in to your assertion, but it would be
>a bad idea to have those subject names refer to more than one real-world
>entity.
>
>Given that, your second example where the authn assertion names Fred and the
>attr assertion names Fred and Bill, the attribute would apply to Fred.
>
>This is more an issue of the semantics of multiple subjects, rather than a
>general rule for matching values.
>
>  - irving -
>
>
>-----------------------------------------------------------------------------------------------------------------
>The information contained in this message is confidential and is intended
>for the addressee(s) only.  If you have received this message in error or
>there are any problems please notify the originator immediately.  The
>unauthorized use, disclosure, copying or alteration of this message is
>strictly forbidden. Baltimore Technologies plc will not be liable for direct,
>special, indirect or consequential damages arising from alteration of the
>contents of this message by a third party or as a result of any virus being
>passed on.
>
>
>This footnote confirms that this email message has been swept by
>Baltimore MIMEsweeper for Content Security threats, including
>computer viruses.
>
>----------------------------------------------------------------
>To subscribe or unsubscribe from this elist use the subscription
>manager: <http://lists.oasis-open.org/ob/adm.pl>

--
Eve Maler                                    +1 781 442 3190
Sun Microsystems XML Technology Center   eve.maler @ sun.com



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


Powered by eList eXpress LLC