I'm having some doubts about the code_and_token response type. The reason why we have both token and code response type is that each has specific security characteristics. However, the mix raises questions about token scope and other properties.
For example, -11 states that the scope in the token request can only be equal or less than the scope requested in the authorization request. This means the token issued in the redirection (which is considered less trusted due to lack of client authentication) can have a greater scope than that issued using the code, but not the other way around which actually makes more sense. If there is no difference in the properties of the two tokens issued (one directly in the redirection and another via the code), why do we need this complexity? Why can't the client just pass along the same token to the server? If there is a difference, it can only be that the token obtained using the code is "more powerful". Adding two scope parameter to the authorization request seems complex, but so other ideas on asking for one authorization with two different tokens issued as a result. Any thoughts? It would be most useful if someone who deployed this (or is planning to) can explain how they are using it. Mostly if they are issuing tokens with the same or different security properties. In -12, I am moving back to the -05 specification structure of profiles (flows). This means this code_and_token hybrid needs to be explained beyond just the definition of the extra parameter and response format. But I don't know how to describe such a profile or what the security considerations for such a hybrid look like. If we can't nail this down quickly, I propose we move this out of the specification and let someone who has implementation experience define it as an extension. EHL
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
