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: comments re draft-sstc-metadata-iop-02


SAML V2.0 Metadata Interoperability Profile
Document ID draft-sstc-metadata-iop-02


General comments:

- The SAML V2.0 metadata specification [SAML2Meta] requires that
signatures be verified.  What if the consumer can not verify the
signature?

- A signature may appear on a RoleDescriptor or a
AffiliationDescriptor element within an EntitiesDescriptor (or
EntityDescriptor) element.  What if the consumer can not verify the
signature on a RoleDescriptor or a AffiliationDescriptor element?

- In section 2.5.1, are you suggesting that keys bound to certificates
be called out in metadata with the <ds:KeyValue> element?  Why not use
<ds:X509Data> exclusively in this case?

- In section 2.5.1, you don't mention <ds:X509SKI> but as you know,
this element is similar to <ds:X509Certificate> in that it
unequivocally defines a key.

- As noted in section 2.7, the validUntil and cacheDuration attributes
are particularly important.  However, [SAML2Meta] does not adequately
treat the case when they appear on a RoleDescriptor or a
AffiliationDescriptor element within an EntitiesDescriptor (or
EntityDescriptor) element


Specific comments:

- [lines 163--165] Why is this reference normative?

- [lines 189--191] I think this should reference the Second Edition of [XMLSig].

- [line 245] Is this subsection really needed?

- [lines 257--258] I don't understand the normative requirement you're
trying convey in this sentence.  Shouldn't this be a MUST?

- [lines 258--260] I don't understand this sentence.  In what sense
does this profile apply to the <md:RoleDescriptor> element?

- [lines 278--279] This normative requirement is redundant since the
previous section contains an identical requirement.

- [lines 284--285] I don't see the point of allowing both forms in a
single <ds:KeyInfo> element.  This could be a source of problems in
fact.  For instance, how does a consumer process such a construct?

- [lines 294--296] This requirement contradicts (in spirit, at least)
section 3.1.5 of [SAML2Meta].

- [line 307] The parenthetical remark on this line is unclear.  What
does the pronoun "their" refer to?


Suggested edits:

- [line 179] s/S. Cantor/J. Hughes/

- [line 195] s/S. Cantor/S. Whitehead/

- [line 224] s/a public key infrastructure/an X.509-based public key
infrastructure/

- [line 225] s/as in/as specified in/

- [line 268] s/i.e./i.e.,/

- [line 311, 332, 346] s/e.g./e.g.,/


Tom Scavo
NCSA


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