
<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">At the F2F meetings Google stated that there is a use case to return a OAuth Code / or something like it to the client so that it could be passed to the client’s back end to later have it exchanged for a AT/RT.<div class=""><br class=""></div><div class="">The logic is that the code for the backend would be to a confidential client and may have additional scopes beyond what the native app has access to.</div><div class=""><br class=""></div><div class="">This is likely useful outside the strict scope of NAPPS so should probably start life as a separate document if we want to take this on.</div><div class=""><br class=""></div><div class="">If we are using a native TA with code then we also have to consider how we get a code based on a refresh token, or use the authorization endpoint each time.</div><div class=""><br class=""></div><div class="">In <a href="https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution" class="">https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution</a> we have added a token_type to the token_endpoint request. (that lets a client specify that it wants a Proof of possession token dynamically)</div><div class=""><br class=""></div><div class="">In the same spec we also add audience “aud” to the request.</div><div class=""><br class=""></div><div class="">We could extend that to define a code token type that returns a code for a aud, as a fairly generic method.</div><div class=""><br class=""></div><div class="">The missing part would be to add the SPOP code_challange to the token_endpoint request.</div><div class=""><br class=""></div><div class="">This also has the side benefit of letting the native app and the backend server use <a href="https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution" class="">https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution</a> when exchanging code to establish a key for POP tokens.</div><div class=""><br class=""></div><div class="">I think the same method would also work for id_tokens as well rather than trying to overload a scope value.</div><div class=""><br class=""></div><div class="">So I guess the extension to the token endpoint for returning code and/or id_tokens could be one or two specs, but there is a lot of overlap so perhaps one to start?</div><div class=""><br class=""></div><div class="">Thoughts.</div><div class=""><br class=""></div><div class="">John B.</div><div class=""><br class=""></div></body></html>