Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants

Note: This ballot was opened for revision 17 and is now closed.

(Kathleen Moriarty) Yes

(Jari Arkko) No Objection

(Alia Atlas) No Objection

(Richard Barnes) (was Discuss) No Objection

Comment (2014-10-15)
No email
send info
"keyed message digest" -> "Message Authentication Code"

That's the proper terminology [RFC4949], especially since there are MACs that are not based on digests.

"This mechanism provides additional security properties." -- Please delete this or elaborate on what security properties it provides.

Section 8.2 should note that "Holder-of-Key Assertions" are also a mitigation for this risk.

(Benoît Claise) No Objection

(Adrian Farrel) No Objection

(Stephen Farrell) (was Discuss) No Objection

Comment (2014-10-21)
No email
send info
Thanks for adding the MTI algorithms to the saml and jwt docs
to clear the discuss I put on this one.

I didn't check the comments below.

- general: What prevents/detects conflicts between the oauth
scope parameter and the saml or jwt equivalent?  Are there
other bits of replicated data that could be the basis for a

(The comment below applies for both saml and jwt so 
putting it here.)

- The no replay protection issue was debated in the
WG wasn't it? (I think I recall it, not sure.) Seems like a
bad plan to me to not require at least implementation of
replay protection in the AS so that it can be turned on. Can
you point me at where that was discussed on the list?

(Brian Haberman) No Objection

(Joel Jaeggli) No Objection

Barry Leiba No Objection

Comment (2014-10-14 for -17)
No email
send info
Pete did a nice job on the 2119 key words, so I have nothing to add there.

-- Section 6.1 --

   The example in Section 4.2 that shows a client authenticating using
   an assertion during an Access Token Request.

Is "that" an extra word that should be removed?  (Also in Section 6.3.)

(Ted Lemon) (was Discuss) No Objection

Comment (2014-10-16 for -17)
No email
send info
Brian Campbell has explained what's going on sufficiently that I think my DISCUSS no longer applies.   Thanks, Brian!

(Pete Resnick) No Objection

Comment (2014-10-14 for -17)
No email
send info
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 -

      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

      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.
                                                   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

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:
      Assertions that do
      not identify the Authorization Server as an intended audience MUST
      be rejected.
      The Authorization Server MUST reject any assertion that does not
      contain the its own identity as the intended audience.

(Martin Stiemerling) No Objection