[OAUTH-WG] Pete Resnick's No Objection on draft-ietf-oauth-saml2-bearer-21: (with COMMENT)

["Pete Resnick" <[e-mail]>]

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.