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

[Brian Campbell <[e-mail]>]

Thanks for the review and feedback Hannes.

There are a number of different items here and I think it'll be more
productive to discuss them individually, so I'll partition this into a
different threads for each general topic. I plan to do the same thing
for your review of draft-ietf-oauth-saml2-bearer-17 from
http://www.ietf.org/mail-archive/web/oauth/current/msg12230.html

On Fri, Nov 1, 2013 at 1:52 PM, Hannes Tschofenig
<[e-mail]> wrote:
> 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
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth