Pete Resnick has entered the following ballot position for draft-ietf-oauth-assertions-17: 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-assertions/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- 3 - Assertions used in the protocol exchanges defined by this specification MUST always be protected against tampering using a digital signature or a keyed message digest applied by the issuer. Why is that? Aren't you using assertions over a protected channel (as required by the spec) and therefore not need to sign the assertions? Indeed, why would a self-issued Bearer Assertion need to be signed at all? Does that even make sense? 4.1 - grant_type REQUIRED. The format of the assertion as defined by the authorization server. The value MUST be an absolute URI. That MUST is unnecessary. It's just definitional from 6749, 4.5 (which, as it happens, doesn't use 2119 language for this). s/MUST/will assertion REQUIRED. The assertion being used as an authorization grant. Specific serialization of the assertion is defined by profile documents. The serialization MUST be encoded for transport within HTTP forms. It is RECOMMENDED that base64url be used. The MUST seems weird here. Are you saying that the profile could not possibly have a serialization for an assertion that did not require further encoding? But the RECOMMENDED seems downright wrong: Either an implementer *needs* to know the encoding independently of the profile, and therefore this needs to be a MUST, or the profile is going to describe the encoding, which could be base64url or could be something else, and the implementation will do whatever the profile says. If you really want to say something here, I suggest replacing the last two sentences with: If the assertion is going to be transported within HTTP forms, the profile document needs to describe what (if any) encoding will be needed to do so. The base64url encoding is widely implemented and therefore suggested. scope [...] As such, the requested scope MUST be equal or lesser than the scope originally granted to the authorized accessor. s/MUST/will (unless you explain whether it's the server or the client that's supposed to be obeying that MUST, and for what reason) If the scope parameter and/or value are omitted, the scope MUST be treated as equal to the scope originally granted to the authorized accessor. The Authorization Server MUST limit the scope of the issued access token to be equal or lesser than the scope originally granted to the authorized accessor. In the first sentence, is this MUST for the server? (That is, shouldn't it be, "If the scope parameter and/or value are omitted, the server MUST use the value of the scope originally granted to the authorized accessor."?) And anyway, don't these two sentences contradict 6749, which says: The authorization server MAY fully or partially ignore the scope requested by the client, based on the authorization server policy or the resource owner's instructions. [...] If the client omits the scope parameter when requesting authorization, the authorization server MUST either process the request using a pre-defined default value or fail the request indicating an invalid scope. Here and throughout: s/non-normative example/example (As far as I know, there are no other kinds in IETF documents.) 4.1.1 - s/MUST construct/constructs 4.2, client_assertion_type and client_assertion: See comments from 4.1 regarding grant_type and assertion. 4.2.1 - s/MUST construct/constructs 5.2 - s/MUST identify/identifies For clarification: OLD Assertions that do not identify the Authorization Server as an intended audience MUST be rejected. NEW The Authorization Server MUST reject any assertion that does not contain the its own identity as the intended audience. END _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth