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

> 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

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.

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

Powered by eList eXpress LLC