Pete Resnick has entered the following ballot position for draft-ietf-oauth-saml2-bearer-21: No Objection
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-oauth-saml2-bearer/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- 2.1/2.2 - This paragraph shows why I don't like haphazard use of 2119. The first "MUST be" is obviously silly and should simply be "is". But the second one buries what *might* be a proper and important use of MUST (you MUST NOT try to stick in two SAML Assertions) with a simple definitional one. (And that assumes that it's even plausible to try to use more than one SAML Assertion. If you simply can't, it's just s/MUST contain/contains.) The base64url encoding MUST is fine, because you don't want people sticking in raw XML, but the SHOULD NOTs for line wrapping and pad I am curious about: Isn't a parser going to have to check for line wrapping and pad anyway and undo it (because it's not a MUST NOT), and therefore this SHOULD NOT really isn't about interoperability so much as neatness (in which case they SHOULD NOTs are not appropriate)? 3 - Subpoint 2: Just for clarification, I like the non-passive sentence better: "The Authorization Server MUST reject any assertion that does not contain its own identity as the intended audience." Subpoint 5: OLD The <SubjectConfirmation> element MUST contain a <SubjectConfirmationData> element, unless the Assertion has a suitable NotOnOrAfter attribute on the <Conditions> element, in which case the <SubjectConfirmationData> element MAY be omitted. That one's sure to get misquoted somewhere and confuse someone. Instead: NEW If the Assertion does not have a suitable NonOnOrAfter attribute on the <Conditions> element, the <SubjectConfirmation> element MUST contain a <SubjectConfirmationData> element. Subpoint 6: OLD The authorization server MUST verify that the NotOnOrAfter instant has not passed, subject to allowable clock skew between systems. An invalid NotOnOrAfter instant on the <Conditions> element invalidates the entire Assertion. An invalid NotOnOrAfter instant on a <SubjectConfirmationData> element only invalidates the individual <SubjectConfirmation>. NEW The authorization server MUST reject the entire Assertion if the NotOnOrAfter instant on the <Conditions> element has passed (subject to allowable clock skew between systems). The authorization server MUST reject the <SubjectConfirmation> (but MAY still use the rest of the Assertion) if the NotOnOrAfter instant on the <SubjectConfirmationData> has passed (subject to allowable clock skew). Subpoint 7: Are you sure those SHOULDs and SHOULD NOTs are not conflicting? Can you not have an authenticated subject with an autonomously acting client? Subpoint 9: As I asked in the -assertions document, is this really a requirement? Subpoint 11: Again, it would be better to put the MUST on the action (e.g., "MUST reject") to make it clear who is doing what. 3.1/3.2 - s/MUST construct/constructs 4 - s/Though non-normative// 9 - Seems like OASIS.saml-deleg-cs and OASIS.saml-sec-consider-2.0-os are Normative, not Informative. _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
