Hello OAuth working group, I've been reading the transaction tokens draft with great interest. I think it's solving an important problem and largely I like what I'm seeing in the draft. However, I think that the way that scope and purpose are differentiated can be improved to make the specification easier to understand, easier to implement, and improve interoperability.
The way that the purpose is described and contrasted with OAuth scopes in section 5.2.1 makes good sense to me. The purp claim captures the exact purpose of this particular transaction. > This is often much narrower than a scope value issued to an external > client. This is due to the fact that in most cases, the authorization model > within the Trust Domain is quite different than the authorization model > used with clients external to the Trust Domain. To that end, it is > intentional to separate the concept of scope (often fairly coarse-grained) > used with external clients from the purpose of the transaction used within > the Trust Domain. How a given deployment represents the authorization model > within the Trust Domain is out of scope for this specification. But in the txn-token request (Section 7.1), the purpose of the transaction token is sent as the scope parameter. I think that has the potential to be confusing, because the two concepts are meant to be distinct. In my experience, non-identity experts often struggle with the existing concepts of scopes, claims, and roles. Reusing the scope parameter with purpose semantics is likely going to be a cause for confusion. Section 9.6 muddies the distinction between scope and purpose further: The TTS MUST ensure that the requested purpose (scope) of the Txn-Token is > equal or less than the scope(s) identified in the subject_token. This is > also true of requesting a replacement Txn-Token. The TTS MUST ensure there > is no unintentional increase in authorization scope. It's not clear to me what the equal to or less than language exactly means, but it's certainly very suggestive, perhaps in a way that isn't good. To me, it makes it sound like a purpose is a part of a scope, or that there's a relationship where certain scopes authorize certain purposes. It seems to me that while the decision to issue a transaction token should take the scope of the subject token into account, it potentially would also care about other claims of the subject token, the calling client, the request context, the request details, or the txn token service's policy. My suggestions are to 1. Invent a new "purpose" parameter used to request transaction tokens so that tx-token requests do not re-use scope or set it all, 2. Clarify the intentions of the "equal or less than" language in section 9.6, and 3. Consider language explicitly stating that transaction tokens MUST NOT contain a scope claim. The token exchange spec says that scope is optional, so I would simply mandate that in a transaction token exchange, scope is not used. Thinking about how I or others would likely implement this, it seems likely that validating the purpose parameter as well as the configuration and policy related to it would be a separate system from scope processing in the AS. So, from an implementation point of view, adding the new parameter would probably simplify the implementation at the AS. The new semantics and parameters that are associated with the transaction token call would mean that the client/initiating workload would already have to write some new code. While existing libraries exist that know how to do token exchange in general, the specifics of transaction tokens are still going to require some implementation work. A new purpose parameter wouldn't add significantly to that. Language to ban scopes from transaction tokens would simply be there to re-inforce what the specification is already (not) doing. It helps with interoperability to make sure that the TTS never does include a scope, in case a tx-token was ever misused. Of course we have the typ header to differentiate the tokens, but leaving the scope out helps prevent their misuse by older JWT libraries that don't know to validate the typ. And in any case, it seems that not including the scope is the intention in this draft. Cheers, Joe DeCock
_______________________________________________ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
