<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">
I John,
<div><br>
</div>
<div>Sorry I missed the F2F, but I also see value in the Token Endpoint returning codes for client back ends to exchange for an AT/RT.</div>
<div><br>
</div>
<div>Unfortunately I am confused by your question; are you asking if a new spec should be developed around this idea, or if it should be wrapped into an existing spec?</div>
<div><br>
</div>
<div>Sorry for the confusion.</div>
<div><br>
</div>
<div>MV</div>
<div><br>
</div>
<div><br>
<div>
<div>On Nov 26, 2014, at 5:48 PM, John Bradley <<a href="mailto:ve7jtb@ve7jtb.com">ve7jtb@ve7jtb.com</a>> wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite">
<div 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>
</div>
_______________________________________________<br>
Openid-specs-native-apps mailing list<br>
<a href="mailto:Openid-specs-native-apps@lists.openid.net">Openid-specs-native-apps@lists.openid.net</a><br>
http://lists.openid.net/mailman/listinfo/openid-specs-native-apps<br>
</blockquote>
</div>
<br>
</div>
</body>
</html>