RE: Comments on sstc-saml-core-2.0-draft-17.pdf (part 1, long)

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

I'm working on integrating some of these changes into core. Some specific
responses: 

> 658 - If one can only ever supply one OneTimeUse element, why is this 
> restricted in prose instead of schema? Should we not explain that 
> reasoning? BTW - line 772 duplicates the MUST
> 
> 663 - same comment as above, and MUST is also duplicated at line 803

The MUSTs are duplicated just for clarity. I didn't see it as a problem. The
reasoning of course is based on the xsi:type loophole, and it can't be
enforced in the schema (IMHO). I added a paragraph before the ConditionsType
schema is defined:

"Because the use of the xsi:type attribute would permit an assertion to
contain more than one instance of a SAML-defined subtype of ConditionsType
(such as OneTimeUseType), the schema does not explicitly limit the number of
times particular conditions may be included. A particular type of condition
MAY define limits on such use, as shown above."

> 774 and 805 - I am not sure what these sentences actually mean - "for 
> the purposes of determining the validity of the <Conditions> element, 
> the XXXX is considered to always be valid" - are you really saying that 
> the system entity evaluating the <Conditions> need not take these 
> conditions into account when determining overall validity of the 
> <Conditions> element?

Yes. The condition is "valid" in the sense that it has no impact on the
assertion's validity, it's a condition on use. Actually an Obligation, to be
honest about it. I added a short sentence to both to this effect.

> 863-870
> 
> I notice that the encrypted assertion type looks a lot like the 
> encrypted NameID type. I was wondering whether these could be derived 
> similarly - ie. define a BaseEncryptableType, and put the EncryptedData, 
> EncryptedKey into it.

As discussed in e-mail, the best we can do here is a model group, so I'm
going to incorporate one unless people don't want one.

> 898 - SubjectLocality - presumably this should refer to the subject 
> specified at the assertion-level? Should we say that?

Yeah, I actually saw some other spots where this clarification is useful.
I'll try and find others, particularly anywhere the phrase "statement's
subject" is used.

> 1318 - 1320 (also applies to 1382)  - lines are indented where they 
> probably shouldn't be. Also, this sentence makes me ask the question - 
> "What should I do if there's no signature present?" Can I also not rely 
> on the request?

I'm going to try and wordsmith this whole issue and we'll discuss it next
call.

-- Scott