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
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
