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 <[email protected]> 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 > [email protected] > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
