[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: comments re draft-sstc-metadata-iop-02
I'd like to make one additional comment: On lines 286--288, it states that a <ds:X509SubjectName> element "MAY appear, but MUST NOT be required in order to identify the key." Yet in the TeraGrid, an X.509-based grid that uses SAML to carry authn context and attributes for the purposes of access control, the <ds:X509SubjectName> element is used to map a SAML issuer to an X.509 issuer: http://docs.google.com/Doc?id=ddj3qnj2_228hdzcdmhb This is a legitimate use of the <ds:X509SubjectName> element, I think, which seems to indicate that different deployments will tend to use SAML metadata differently (no surprise, really). In fact, this alternate use of SAML metadata is the reason I referred to the Metadata Interoperability Profile as a "deployment profile" as opposed to some universally applicable profile. Tom On Mon, Oct 6, 2008 at 9:38 PM, Tom Scavo <trscavo@gmail.com> wrote: > 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]