RE: [security-services-comment] Public Comment

["Scott Cantor" <cantor.2@osu.edu>]

> I think I gave the wrong impression here. I've read section 
> 3, I just didn't do a thorough review and didn't include 
> comments in this mail. I've since gone through Section 3 more 
> closely and have some suggestions, mostly editorial, that I'm 
> happy to forward if you're interested.

Yes, please, we want to try and get a reasonably final spec ready for vote
soon.

> Then I think elementFormDefault should be changed to 
> "qualified" to reduce reader confusion. When I saw 
> elementFormDefault="unqualified", I thought, "Wow, they 
> must've done that for a reason" and had to look closely to 
> see what the effect would be. IMO, changing to "qualified" 
> would better reflect the design approach of all global 
> elements and would save the next guy a little work.

We'll discuss next call. The schema boilerplate dates back before my time.

> I'm really surprised by this response. So you understand 
> lines 423 to 424 to say the descriptive text that follows 
> applies to <NameID> and not NameIDType?

I was perhaps a bit strong, I simply meant that overriding the default for
Issuer wasn't a contradiction since the element is distinct, not that the
rest of the NameID text didn't apply.

It might make sense to factor out the type definition in this case since
it's a fairly important type.

> Right. I read section 6.3  of XMLEnc as guidance rather than 
> as a normative requirement, but if SAML is just repeating 
> something that's already required by XML Encryption then the 
> MUST is fine. If SAML is imposing a higher standard than 
> XMLEnc, I'd wonder why.

My understanding was that it's a bit stronger than guidance, but regardless,
I think SAML would impose a higher standard because of the intent behind
supporting encryption. We don't want to facilitate correlation of user
activity where none would otherwise be possible.

> Semantics aside, though, I think it's better for SAML core to 
> treat <AssertionURIRef> as an identifier and leave it to 
> bindings or profiles to describe the operations, if any, that 
> might be performed against it. This just means dropping the 
> sentence on line 504 that begins, "Resolving a URI reference...".

I made some adjustments to reference the binding specification, and the
language is a bit cleaner now, I think. I think the word resolve is
sufficiently overloaded anyway, I liked retrieve better (in terms of
referencing the binding).

> "Evaluated" is better, I think, but it's still not clear to 
> me why you use MUST here. It seems weird to say a conformant 
> implementation is absolutely required to do some internal 
> processing but that it's free to ignore the result.

Well, I think the intent was that we want relying parties to process the
assertion in terms of determing its state, but then they can make their own
decision based on that. Informed obliviousness?

I've never particular liked the approach. A SHOULD is probably just as
sufficient.

> I don't think I was clear - it's the normative "MAY" I'm 
> questioning. RFC2119 says "This word, or the adjective 
> 'OPTIONAL', mean that an item is truly optional.  One vendor 
> may choose to include the item because a particular 
> marketplace requires it or because the vendor feels that it 
> enhances the product while another vendor may omit the same 
> item." I don't think you really mean that continued 
> processing beyond signature validation is truly optional for 
> a conformant assertion processor, do you?

Right, I see your point.

The remaining issues and some of the other comments should be discussed on
the next call.

-- Scott