Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants
draft-ietf-oauth-assertions-18

I very much approve of the assertions set going ahead.  I have a number of things I'd like to DISCUSS on this first:

Point 1:
-- Section 1.1 --
   However, even when profiled for specific assertion types, additional
   profiling for specific use cases will be required to achieve full
   interoperability.

In other words, even the SAML and JWT profiles aren't sufficient?  Or do those documents do this sort of use-case profiling, resulting in something that can actually work?  Or is Section 6 sufficient?  If they do, or it is, then saying that here will help.  (As a side note, I would really have preferred seeing at least the SAML draft in for IESG Eval at the same time as this doc.) 

If they don't, then I'm dismayed.  OAuth already requires out-of-band agreement on what sort of token one is going to get.  This framework additionally requires out-of-band agreement on assertion type.  If even those assertion types that are defined *further* require o-o-b agreement on the semantics of the fields they use, it seems that we're adding to the mess and not building broad interoperability.  

Point 2:
Related to point 1, would it not be good to explicitly define an "assertion type unsupported" error response (or two: "grant type unsupported" and "client assertion type unsupported"), so a server can be explicit in saying that that is why this request can't be processed?  If not, why not?  

Point 3:
Might it be a good idea, concomitant with the suggested URNs in Sections 4.1 an 4.2, to reserve the namespaces "urn:ietf:params:oauth:grant-type:" and "urn:ietf:params:oauth:client-assertion-type:" here, so they won't be used for anything else?  If not, why not?  

Point 4:
-- Section 5.2 --
I'm looking at the "SHOULD be the client_id"s in the first two bullets, and remembering the definition of "SHOULD" in RFC 2119 -- it says that not following a SHOULD requires full understanding of the implications and careful weighing.  I see nothing here that gives me a clue how to evaluate the implications.  *Why* SHOULD these be the client_id, and what will happen if they're not?  (This also applies to some of the bullets in Sections 6.x.) 

Point 5:
-- Section 5.2 --
   o  The assertion MAY contain an Assertion ID.  An Authorization
      Server MAY dictate that Assertion ID is mandatory.

How can a client know that an Authorization Server so dictates?

Point 6:
-- Section 6.1 --
   When a client uses an assertion for authentication, it SHOULD do so
   according to Section 4.2.

I'm confused: I thought 4.2 normatively described the protocol.  What's that SHOULD here?  (Same question applies to the intros to the other Sections 6.x.)

1) RFC6749 includes an incomplete list of components that are partially or fully undefined in its "Interoperability" section.  A similar section should be added to this document and I hope it can be a bit more specific.  This section would gather all the out of scope or defined in the next specification items.  The purpose being to aid implementers in following the bread crumbs leading towards interop.

2) Another point on verification: The only way for the RP to verify the "signature" is it to have the "signers" key.  Since, this is mostly about keyed MACs you can't just send that key with the "signed" assertion.  My point is, the key distribution is one more thing that's out of scope.