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

[Ballot comment]

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
vulnerability?

(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?

[Ballot discuss]
This has probably already been considered and addressed by the working group, but coming into this as a neophyte it seems like a glaring omission that the security considerations of bearer assertions are not discussed here.  Isn't it the case that the use of bearer assertions requires a trust relationship between the client and relying party such that the client can be assured that the relying party will not misuse the assertion to authenticate with some other entity?  I realize that this sort of assertion will likely only be used in cases where the assertion only works to authenticate to a specific relying party, but I think this bears mentioning in the security considerations.

[Ballot discuss]

Putting one discuss here rather than one on each of the other
docs. We can fix that as appropriate after we chat.  Where are
the MTI signature and mac algs for these specified? If those
can be tracked back via the SAML and jose docs that's fine,
but I'm not sure if they are.

[Ballot comment]

- 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
vulnerability?

(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?

[Ballot discuss]
"The assertion MUST contain an Audience that identifies the Authorization Server as the intended audience.  Assertions that do not identify the Authorization Server as an intended audience MUST be rejected."

Could you please identify the threat model within which this "MUST" is required?  This requirement doesn't follow from any of the threats elaborated in Section 8.

The Audience is only necessary if the Issuer wishes to constrain the set of Authorization Servers with which an assertion may be used.  So ISTM that this should be "MAY contain..."

[Ballot comment]
"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.

[Ballot comment]
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.)

[Ballot 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

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-oauth-assertions-17.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

We received the following comments/questions from the IANA's reviewer:

Upon approval of this document, IANA understands that there is a single action which must be completed.

In the OAuth Parameters subregsitry in the Oauth Parameters registry located at:

https://www.iana.org/assignments/oauth-parameters/

three new OAth parameters are to be registered as follows:

Name: assertion
Parameter Usage Location: token request
Change Controller: IETF
Reference: [ RFC-to-be ]

Name: client_assertion
Parameter Usage Location: token request
Change Controller: IETF
Reference: [ RFC-to-be ]

Name: client_assertion_type
Parameter Usage Location: token request
Change Controller: IETF
Reference: [ RFC-to-be ]

The OAuth Parameters registry is a Specification Required (see RFC 5226) registry, and we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC.

IANA understands that this is the only action required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants) to Proposed Standard


The IESG has received a request from the Web Authorization Protocol WG
(oauth) to consider the following document:
- 'Assertion Framework for OAuth 2.0 Client Authentication and
  Authorization Grants'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2014-09-29. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This specification provides a framework for the use of assertions
  with OAuth 2.0 in the form of a new client authentication mechanism
  and a new authorization grant type.  Mechanisms are specified for
  transporting assertions during interactions with a token endpoint, as
  well as general processing rules.

  The intent of this specification is to provide a common framework for
  OAuth 2.0 to interwork with other identity systems using assertions,
  and to provide alternative client authentication mechanisms.

  Note that this specification only defines abstract message flows and
  processing rules.  In order to be implementable, companion
  specifications are necessary to provide the corresponding concrete
  instantiations.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-oauth-assertions/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-oauth-assertions/ballot/


No IPR declarations have been submitted directly on this I-D.

Writeup for "Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants"

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

The RFC type is 'Standards Track' and the type is indicated in the title page. Although the document is architectural in nature it is the umbrella document for two other 'Standards Track' specifications that instantiate this document for use with SAML assertions and JSON Web Tokens.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

This specification provides a framework for the use of assertions with OAuth 2.0 in the form of a new client authentication mechanism and a new authorization grant type. Mechanisms are specified for transporting assertions during interactions with a token endpoint, as well as general processing rules.

The intent of this specification is to provide a common framework for OAuth 2.0 to interwork with other identity systems using assertions, and to provide alternative client authentication mechanisms.

Note that this specification only defines abstract message flows and processing rules. In order to be implementable, companion specifications are necessary to provide the corresponding concrete instantiations.

Working Group Summary:

Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough?

This document has been submitted to the IESG before and was returned to the working group due to interoperability concerns. The working group has discussed those concerns and has worked on several iterations of the document to reduce the amount of optional functionality.

Document Quality:

The working group decided to separate the framework for assertion handling from instance documents supporting SAML assertion and JSON-based encoded tokens. Readers who want to implement the functionality also need to consult one of the extension documents.

Personnel:

The document shepherd is Hannes Tschofenig and the responsible area director is Kathleen Moriarty.

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

The draft authors believe that this document is ready for publication. The document has received review comments from working group members, the OAuth working group chairs, and from the IESG. These review comments have been taken into account.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

This document has gotten feedback from the working group and given the focused use cases it has received adequate review.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

Since the OAuth working group develops security protocols any feedback from the security community is always appreciated.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

Although the document shepherd had concerns earlier with the document, they have been addressed in the meanwhile.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

Yes, the authors (Chuck Mortimore , Brian Campbell , Mike Jones , and Yaron Y. Goland ) have confirmed that they are not aware of any IPRs.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

No IPR disclosures have been filed.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

The working group has consensus to publish this document.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

No appeal or extreme discontent has been raised.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

The shepherd has checked the nits.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews.

There is no such review necessary.

(13) Have all references within this document been identified as either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

Yes.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No, there is no need for a downref.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

The publication of this document does not change the status of other RFCs.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226).

The document adds three values to an existing registry established with RFC 6749.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

The document only adds entries to existing registries and does not define any new registries.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc.

There are only snippets of message exchanges used in the examples; no pseudo code is contained in the document that requires validation.

Writeup for "Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants"

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

The RFC type is 'Standards Track' and the type is indicated in the title page. Although the document is architectural in nature it is the umbrella document for two other 'Standards Track' specifications that instantiate this document for use with SAML assertions and JSON Web Tokens.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

This specification provides a framework for the use of assertions with OAuth 2.0 in the form of a new client authentication mechanism and a new authorization grant type. Mechanisms are specified for transporting assertions during interactions with a token endpoint, as well as general processing rules.

The intent of this specification is to provide a common framework for OAuth 2.0 to interwork with other identity systems using assertions, and to provide alternative client authentication mechanisms.

Note that this specification only defines abstract message flows and processing rules. In order to be implementable, companion specifications are necessary to provide the corresponding concrete instantiations.

Working Group Summary:

Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough?

This document has been submitted to the IESG before and was returned to the working group due to interoperability concerns. The working group has discussed those concerns and has worked on several iterations of the document to reduce the amount of optional functionality.

Document Quality:

The working group decided to separate the framework for assertion handling from instance documents supporting SAML assertion and JSON-based encoded tokens. Readers who want to implement the functionality also need to consult one of the extension documents.

Personnel:

The document shepherd is Hannes Tschofenig and the responsible area director is Kathleen Moriarty.

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

The draft authors believe that this document is ready for publication. The document has received review comments from working group members, the OAuth working group chairs, and from the IESG. These review comments have been taken into account.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

This document has gotten feedback from the working group and given the focused use cases it has received adequate review.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

Since the OAuth working group develops security protocols any feedback from the security community is always appreciated.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

Although the document shepherd had concerns earlier with the document, they have been addressed in the meanwhile.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

Yes, the authors (Chuck Mortimore , Brian Campbell , Mike Jones , and Yaron Y. Goland ) have confirmed that they are not aware of any IPRs.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

No IPR disclosures have been filed.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

The working group has consensus to publish this document.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

No appeal or extreme discontent has been raised.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

The shepherd has checked the nits.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews.

There is no such review necessary.

(13) Have all references within this document been identified as either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

Yes.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No, there is no need for a downref.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

The publication of this document does not change the status of other RFCs.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226).

The document adds three values to an existing registry established with RFC 6749.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

The document only adds entries to existing registries and does not define any new registries.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc.

There are only snippets of message exchanges used in the examples; no pseudo code is contained in the document that requires validation.

[Ballot discuss]
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.

[Ballot comment]
1) Completely agree with Barry's point #1.

2) s1: I think it'd help to define what an assertion is or just point to definition in RFC 6819.

3) s3: (I teetered on making this a discuss) "sign" is used a couple of times in this document when you're talking about either digital signatures or keyed MACs.  Please try to scrub these out and make the distinction that you're either digitally signing or using a keyed MAC.

[Ballot comment]
4.2:

      When present, the "client_id" MUST
      identify the client to the authorization server.

I don't understand what this is saying. How is the entity that is creating the assertion able to be sure that the client_id identifies the client to the authorization server? Is there some verification that must be done? If it doesn't identify the client, isn't the server simply going to send back and invalid_client error? What does this requirement mean?

5.1: Why aren't Issued At and Expires At REQUIRED to be at UTC?

5.2:

      The Authorization
      Server MUST verify that it is an intended audience for the
      assertion.

This is written strangely. Don't you instead mean, "The Authorization Server MUST reject [with such-and-so error] an Audience value that it does not belong to" or something to that effect? Assuming that's right, is it completely out of band how the server determines that?

                                                          The
      authorization server MUST verify that the expiration time has not
      passed, subject to allowable clock skew between systems.
     
As above, don't you really mean that the the server MUST reject things that have expired?

                                                                The
      authorization server SHOULD reject assertions with an Expires At
      attribute value that is unreasonably far in the future.

Given that "unreasonably far in the future" is clearly a judgment call on the part of the server, the SHOULD requirement seems weird. Shouldn't that be: "The authorization server MAY reject assertions with an Expires At attribute value that the server considers unreasonably far in the future."?

      The Authorization Server MUST validate the assertion's signature
      to verify the Issuer of the assertion.

As above, I think you mean "Server MUST reject assertions which do not validate".

Strictly editorial: I liked the format of 4.1 and 4.2 better than 5.2. Instead of embedding "MUST contain" or  "MAY contain", I prefer the format of:

    Issuer  REQUIRED. Blah blah.
   
    Subject RECOMMENDED. Blah blah.
   
    Issued At OPTIONAL. Blah Blah.

6.1: This is not clarifying; it appears to be completely redundant. If it is *not* redundant, you need to pull those things out and highlight them. I found myself jumping back and forth between this section and 4 and 5 trying to figure out what I missed. I couldn't find any differences. Keep the first sentence and the example; ditch the rest.

6.2: Skip the bits about client_assertion, client_assertion_type, Subject, Audience, and signature verification; they're redundant. Skip the first two sentences of "Issuer"; also redundant. Move the bit about STS into earlier sections; it gets re-used. Just keep the intro, the grant_type, and the example.

6.3 and 6.4 have similar issues to 6.1 and 6.2, and similar cleanups. I can go through in detail if you need, but I think you have the idea.

[Ballot discuss]
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.)

[Ballot comment]
And here are a bunch of non-blocking comments that I think will be useful.  Feel free to chat with me about these, as well -- I'd really like you to consider them, but I won't get in the way if you disagree with these.

-- Section 1 --
  and JSON Web Token (JWT) Bearer Token Profiles for
  OAuth 2.0 [I-D.ietf-oauth-jwt-bearer] defines a concrete
  instantiation for JWT tokens.

Nit: JSON Web Token tokens?  Is that not like "Personal PIN Number", or "ATM Machine"?  Wouldn't it do to say, "concrete instantiation for JWTs."

-- Section 3 --
  1.  Bearer Assertions: Any entity in possession of a bearer assertion
      (e.g. the bearer) can use it to get access to the associated

See, this is why I don't like the use of these latin abbreviations: they're usually unnecessary, and we often get them wrong. The one you want here is "i.e.": the bearer is not an *example* of an entity in possession of the assertion; any entity in possession of one *is* the bearer of it. 

NEW1
  1.  Bearer Assertions: Any entity in possession of a bearer assertion
      (i.e., the bearer) can use it to get access to the associated

... or, more simply (and why not?) ...

NEW2
  1.  Bearer Assertions: Any entity in possession of a bearer assertion
      (the bearer) can use it to get access to the associated

I would also make the whole thing plural when you talk about secure channels later in that item, because there are multiple channels involved: "Secure communication channels are required between all entities...." (Also in Section 7.2.)

-- Section 4.2 --
  client_id  OPTIONAL.  The client identifier as described in Section
      2.2 of OAuth 2.0 [RFC6749].  When present, the "client_id" MUST
      identify the client to the authorization server.

Very small point...  this strikes me as a wrong use of 2119 MUST: you're not talking about a protocol choice (as you do in the next item, where the "MUST be an absolute URI" is quite correct), but are just saying what this parameter does.  Make it, 'When present, the "client_id" identifies the client to the authorization server.'

-- Section 6.1 --
The example here (and the paragraph introducing it) is identical to the example in Section 4.2 (except for what appears to be a copy/paste error in the snipped base64 (the final "4")).  Do we really need to have it repeated here?  At the most, a "See the example in Section 4.2," ought to be enough (or reverse it, with a forward ref from 4.2 to here). 

Similarly, the example in Section 6.3 is identical to the one in Section 4.1.

-- Section 7.3 --
      However, this does not prevent
      legitimate protocol entities from obtaining information from an
      assertion they may not have been allowed to obtain.

This reads like it's the assertion they may not have been allowed to obtain, when you mean that about the information.  I suggest this:

NEW
      However, this does not prevent
      legitimate protocol entities from obtaining from an assertion
      information they may not have been allowed to obtain.
END

      To mitigate potential
      privacy problems, prior consent from the resource owner has to be
      obtained.

Prior consent for what?  It's not clear.

IANA has reviewed draft-ietf-oauth-assertions-08 and has the following
comments:

IANA understands that, upon approval of this document, there is a single action which IANA must complete.

In the OAuth Parameters subregistry of the OAuth Parameters registry located at:

http://www.iana.org/assignments/oauth-parameters/oauth-parameters.xml

three new OAuth Parameters will be registered as follows:

Name: assertion
Parameter Usage Location: token request
Change controller: IETF
Reference: [ RFC-to-be ]

Name: client_assertion
Parameter Usage Location: token request
Change controller: IETF
Reference: [ RFC-to-be ]

Name: client_assertion_type
Parameter Usage Location: token request
Change controller: IETF
Reference: [ RFC-to-be ]

IANA understands that this is the only action required to be completed upon approval of this document.

Note: The actions requested in this document will not be completed
until the document has been approved for publication as an RFC.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (Assertion Framework for OAuth 2.0) to Proposed Standard


The IESG has received a request from the Web Authorization Protocol WG
(oauth) to consider the following document:
- 'Assertion Framework for OAuth 2.0'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2012-12-24. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This specification provides a framework for the use of assertions
  with OAuth 2.0 in the form of a new client authentication mechanism
  and a new authorization grant type.  Mechanisms are specified for
  transporting assertions during interactions with a token endpoint, as
  well as general processing rules.

  The intent of this specification is to provide a common framework for
  OAuth 2.0 to interwork with other identity systems using assertions,
  and to provide alternative client authentication mechanisms.

  Note that this specification only defines abstract message flows and
  processing rules.  In order to be implementable, companion
  specifications are necessary to provide the corresponding concrete
  instantiations.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-oauth-assertions/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-oauth-assertions/ballot/


No IPR declarations have been submitted directly on this I-D.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)? Why is
this the proper type of RFC? Is this type of RFC indicated in the title
page header?

The RFC type is 'Standards Track' and the type is indicated in the title
page. Although the document is architectural in nature it is the
umbrella document for two other 'Standards Track' specifications that
extend this document with SAML and JSON specific details.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary:

  The Assertion Framework for OAuth 2.0 allows the use of assertions
  in the form of a new client authentication mechanism
  and a new authorization grant type.  Mechanisms are specified for
  transporting assertions during interactions with a token endpoint, as
  well as general processing rules.

  The intent of this specification is to provide a common framework for
  OAuth 2.0 to interwork with other identity systems using assertions,
  and to provide alternative client authentication mechanisms.

  Note that this specification only defines abstract message flows and
  processing rules.  In order to be implementable, companion
  specifications are necessary to provide the corresponding concrete
  instantiations.

Working Group Summary:

Was there anything in WG process that is worth noting? For example, was
there controversy about particular points or were there decisions where
the consensus was particularly rough?

There was no controversy around this document.

Document Quality:

The working group decided to separate the framework for assertion
handling from instance documents supporting SAML assertion and JSON-
based encoded tokens. Readers who want to implement the functionality
also need to consult one of the extension documents, such as .

Personnel:

The document shepherd is Hannes Tschofenig and the responsible area
director is Stephen Farrell.

(3) Briefly describe the review of this document that was performed by
the Document Shepherd. If this version of the document is not ready for
publication, please explain why the document is being forwarded to the
IESG.

The draft authors believe that this document is ready for publication.
The document shepherd has reviewed the document and provided detailed
comments. Those review comments have been taken into account and have
lead to clarifications regarding the claimed security benefits. 

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

This document has gotten feedback from the working group but certainly
not to the extend other OAuth working group documents, like the OAuth
Core specification and the OAuth Bearer Token specification, had
received. This can be explained by the focused use cases. The ability to
use assertions in the way described by the document is not needed in
every deployment.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that took
place.

Additional feedback from the security community would be appreciated.
Also, it would be helpful to get additional reviews from outside the
group from people already using assertions to ensure that the use cases
and the offered security benefits are well understood.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

The shepherd still believes that the document authors could have done a
better job in explaining the use cases for which the proposed
functionality are applicable. The concerns have been raised in http://
www.ietf.org/mail-archive/web/oauth/current/msg09961.html

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why?

The shepherd has gotten a confirmation from the authors that no IPR
disclosures are needed.

(8) Has an IPR disclosure been filed that references this document? If
so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

No IPR disclosures have been filed.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others being
silent, or does the WG as a whole understand and agree with it?

Only a subset of working group participants have reviewed the document
but enough to move forward with the publication.  However, because the
SAML and JWT Assertion Profiles based on it have been implemented and
are being used by a number of parties, we have high confidence in the
sufficiency and accuracy of the document text.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

No appeal or extreme discontent has been raised.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

The document has been verified and contains no nits.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

There is no such review necessary.

(13) Have all references within this document been identified as either
normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

No.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

No, there is no need for a downref.

(16) Will publication of this document change the status of any existing
RFCs? Are those RFCs listed on the title page header, listed in the
abstract, and discussed in the introduction? If the RFCs are not listed
in the Abstract and Introduction, explain why, and point to the part of
the document where the relationship of this document to the other RFCs
is discussed. If this information is not in the document, explain why
the WG considers it unnecessary.

The publication of this document does not change the status of other
RFCs.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

The document adds three values to an existing registry established with
RFC 6749.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find useful
in selecting the IANA Experts for these new registries.

The document only adds entries to existing registries and does not
define any new registries.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

There are only snippets for examples and no pseudo code is contained
that requires validation.