On Fri, Nov 1, 2013 at 1:52 PM, Hannes Tschofenig <[email protected]> wrote: > 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. > "
Agreed that reads better. > 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? The fuzziness of the text in A, I believe, comes from use cases where the principal wouldn't directly be identified in the sub claim. For example, a JWT with an anonymous subject and a claim stating they are a member of a particular group might be sufficient to grant access to some types of resources (this is discussed in http://tools.ietf.org/html/draft-ietf-oauth-assertions-12#section-6.3.1). It is also not uncommon, in this federated scenarios, for additional claims/attributes to be needed along with the subject in order to uniquely identify the principle as known to the AS. Is there a way to rephrase the text for A which would be more helpful but not preclude such use cases? _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
