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

From: Brian Campbell <[email-masked]>
Date: Mon, 4 Nov 2013 11:52:13 -0800

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

The list could probably be expanded to include a mention of how
subject is to be identified (related to discussion about subject [1])
as well as requirements the AS may place on upper limits of token
expiration and/or de-duping.

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

That's one implementation approach. But not the only one. The intent
of this section is to note the information which needs to be
exchanged/agreed upon in order for the wire protocol to work. That's
all. Implementation particulars shouldn't be here.

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

No but there's been a request, which makes sense, to explicitly state
the items which need to be known, typically via service documentation,
in order to achieve interoperability. The token endpoint is one of
those items and OAuth provides no means of discovering it or
publishing it. So I feel it's very appropriate to mention it here.
And, by way of example, if you look at service documentation for
existing deployments, you'll see that it is included.

> 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).

As I said in the previous mail on audience [2] and have been
arguing/explaining for a long time now, that suggestion is not viable
or realistic. And (as I mention above) the token endpoint URL *still*
needs to be communicated somehow. Documenting the expected value for
audience is just one more piece of information in a set of info that
has to be exchanged anyway.

[1] sub http://www.ietf.org/mail-archive/web/oauth/current/msg12250.html
[2] aud http://www.ietf.org/mail-archive/web/oauth/current/msg12251.html