[OAUTH-WG] draft-ietf-oauth-jwt-bearer-06

[Hannes Tschofenig <[e-mail]>]

Hi Mike, Hi all,

I read through draft-ietf-oauth-jwt-bearer-06 in an attempt to find out 
whether I would be able to produce an interoperable implementation from 
this document.

A few minor things came to my mind:

Section 3:

You write:
"
    1.   The JWT MUST contain an "iss" (issuer) claim that contains a
         unique identifier for the entity that issued the JWT.  Issuer
         values SHOULD be compared using the Simple String Comparison
         method defined in Section 6.2.1 of RFC 3986 [RFC3986], unless
         otherwise specified by the application.
"

What is not stated here is what are the two values that are compared 
against each other. One value is the issuer claim from the JWT and the 
other value is the, I guess, an entry from a whitelist of trusted issuers.



You write:
"
    2.   The JWT MUST contain a "sub" (subject) claim identifying the
         subject of the transaction.  The subject MAY identify the
         resource owner for whom the access token is being requested.

         A.  When using a JWT as an authorization grant, the subject
             SHOULD identify an authorized accessor for whom the access
             token is being requested (typically the resource owner, or
             an authorized delegate).

         B.  For client authentication, the subject MUST be the
             "client_id" of the OAuth client.
"

Should this rather read:

"
    2.   The JWT MUST contain a "sub" (subject) claim identifing the
         principal that is the subject of the JWT. Two cases need to
         be differentiated:

         A.  For the authorization grant, the subject
             SHOULD identify an authorized accessor for whom the access
             token is being requested (typically the resource owner, or
             an authorized delegate).

         B.  For client authentication, the subject MUST be the
             "client_id" of the OAuth client.
"

Why isn't the SHOULD under (A) actually a MUST? Then, the current text 
in A is so fuzzy that it actually doesn't allow someone to create a test 
case to test whether an implementation is interoperable or not. With B 
the situation is different. Is there something else we can say for A?

You write:

"
  3.   The JWT MUST contain an "aud" (audience) claim containing a
         value that identifies the authorization server as an intended
         audience.  The token endpoint URL of the authorization server
         MAY be used as a value for an "aud" element to identify the
         authorization server as an intended audience of the JWT.  JWTs
         that do not identify the authorization server as an intended
         audience MUST be rejected.  Audience values SHOULD be compared
         using the Simple String Comparison method defined in Section
         6.2.1 of RFC 3986 [RFC3986], unless otherwise specified by the
         application.
"

If the endpoint URL of the AS is not used then what else? Wouldn't it be 
useful to say "The token endpoint URL of the authorization server
         MUST be used as a value for an "aud" element to identify the
         authorization server as an intended audience of the JWT."?

Then, I have a suggestion for re-phrasing this sentence from :
"
         Audience values SHOULD be compared
         using the Simple String Comparison method defined in Section
         6.2.1 of RFC 3986 [RFC3986], unless otherwise specified by the
         application.
"
to:

"
In the absence of an application profile standard specifying
otherwise, a compliant JWT Bearer application MUST compare the audience 
values using the Simple String Comparison method defined in Section
         6.2.1 of RFC 3986 [RFC3986].
"

The same can actually be applied to the issuer claim as well.
Given that the JWT had been updated to align it with the JOSE work I 
suspect that this document also requires an update.


Section 5 about "Interoperability Considerations" says:

"
Specific items that require agreement are as
    follows: values for the issuer and audience identifiers, the location
    of the token endpoint, and the key used to apply and verify the
    digital signature or keyed message digest over the JWT.
"

I believe that this list is not correct.

What is needed is:

  * At the authorization server there needs to be a whitelist of trusted 
issuers. For a succesful protocol run the JWT needs to be created by an 
issuer who is in the whitelist.

  * Along with the entry in the whitelist of trusted issuers needs to be 
a key.

There is no new endpoint URL defined by this document. As such, I 
wouldn't mention those.

I also do not think that the audience identifier needs to be agreed if 
you define it as the token endpoint URL of the authorization server (as 
I suggested above).

Ciao
Hannes