Subject: [OAUTH-WG] audience (was draft-ietf-oauth-jwt-bearer-06)

From: Brian Campbell <[email-masked]>
Date: Mon, 4 Nov 2013 10:45:23 -0800

On Fri, Nov 1, 2013 at 1:52 PM, Hannes Tschofenig
<[email-masked]> wrote:
> 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....
> "
>
> 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."?

This and the other assertion documents offer the token endpoint URL as
one way to identify the AS for deployments which lack some other means
of doing so. However, these assertion profiles are little slices of
functionality that augment existing deployments of OAuth, often in
conjunction with other 'federated' technologies for which there will
be an existing and agreed upon identifier that the issuer is known by.
This is not just academic - it's how these systems and deployment
already work. It's inappropriate and unrealistic for this document (or
the other assertion docs) to preclude common and useful deployment
practices.

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

I think I'm okay with that re-phrasing. Do others (my co-authors
especially) agree? Or object?

>
> The same can actually be applied to the issuer claim as well.

As I said in the previous mail about issuer, I'd like to get rid of
the comparison text. However, if such text stays, I'll work to make it
consistent throughout.

> Given that the JWT had been updated to align it with the JOSE work I suspect
> that this document also requires an update.

You may well be correct. But despite following the JOSE and JWT work,
I'm not sure I know what update(s) would be required. Can you
elaborate?

---

From: Chuck Mortimore <[email-masked]>
Date: Tue, 5 Nov 2013 21:21:17 -0800

> the other assertion docs) to preclude common and useful deployment

Agreed.

> especially) agree? Or object?

I'm good with it.

-cmort

> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>