<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="">On the call today Rolland raised a use case in Sweden where OpenID Connect is used for identity proofing, leading to a split between the access channel and the authentication channel. <div class=""><br class=""></div><div class="">This is the link to the Swedish spec <a href="https://github.com/SUNET/se-leg-docs/blob/master/proofing.md" class="">https://github.com/SUNET/se-leg-docs/blob/master/proofing.md</a></div><div class=""><br class=""></div><div class="">I pointed out that the MODRNA WG is considering a very similar issue in Backchannel Authentication <a href="https://xml2rfc.tools.ietf.org/cgi-bin/xml2rfc.cgi?Submit=Submit&format=ascii&mode=html&type=ascii&url=https://bitbucket.org/openid/mobile/raw/tip/draft-mobile-client-initiated-backchannel-authentication-01.xml?at=default" class="">https://xml2rfc.tools.ietf.org/cgi-bin/xml2rfc.cgi?Submit=Submit&format=ascii&mode=html&type=ascii&url=https://bitbucket.org/openid/mobile/raw/tip/draft-mobile-client-initiated-backchannel-authentication-01.xml?at=default</a></div><div class=""><br class=""></div><div class="">There was a fair amount of discussion on that draft at our meeting in September, and Gaonzalo should have an update shortly.</div><div class=""><br class=""></div><div class="">This is also similar to the OAuth device profile. <a href="https://tools.ietf.org/html/draft-ietf-oauth-device-flow" class="">https://tools.ietf.org/html/draft-ietf-oauth-device-flow</a></div><div class=""><br class=""></div><div class="">The device profile currently only supports polling.</div><div class=""><br class=""></div><div class="">I think that it may be time to standardize a general push method for the AS to provide the token endpoint response to the client.</div><div class=""><br class=""></div><div class="">We don’t have that in device at the moment because most devices are not directly addressable, though we did discuss it at one point.</div><div class=""><br class=""></div><div class="">My personal preference would be for the client to register a callback URI during registration, and provide the AS with a access token for that endpoint in the authorization request.</div><div class=""><br class=""></div><div class="">There are security issues that need to be considered around an attacker getting that callback AT and being able to impersonate the AS.</div><div class=""><br class=""></div><div class="">I can see the need for this and we should get on top of it before we have a large number of incompatible solutions in the wild.</div><div class=""><br class=""></div><div class="">John B.</div><div class=""><br class=""></div></body></html>