<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Hi George,<div class=""><br class=""></div><div class="">Thanks for your thoughts! I’ve made some replies inline:<br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On 8 Oct 2019, at 15:28, George Fletcher <<a href="mailto:gffletch@aol.com" class="">gffletch@aol.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" class="">
<div text="#000000" bgcolor="#FFFFFF" class="">
<font face="Helvetica, Arial, sans-serif" class="">It might be possible to
extend the Native SSO spec to work across apps from different
vendors using this method.<br class=""></font></div></div></blockquote><div><br class=""></div>I’m not sure I see the overlap that would make extension possible; device_secret would not be applicable in the cross-company case I believe? (Am I right to characterise device_secret as being the real essential addition in native SSO? And it’s rather off topic, but I’m interested to know the pro/cons of using what I believe is sort-of a shared secret vs using the Secure Enclave to create a key, and using proof of possession of that key via a signed jwt to demonstrate that you’re an app from the same device.)</div><div><br class=""></div><div>You can certainly use the two specs together so that app2app is used for the initial authentication/authorization build the initial linkage from device app group to idp, with “native app from the company providing the iDP” replacing “system browser” in <a href="https://openid.net/specs/openid-connect-native-sso-1_0.html" class="">https://openid.net/specs/openid-connect-native-sso-1_0.html</a></div><div><br class=""><blockquote type="cite" class=""><div class=""><div text="#000000" bgcolor="#FFFFFF" class=""><font face="Helvetica, Arial, sans-serif" class="">It seems to me that how the requesting app specifies it's
"client_id" and other authorization parameters is out of scope for
the flow.</font></div></div></blockquote><div><br class=""></div><div>The client id and all authorization parameters are passed from the third party app (relying party) to the first party app (associated with the iDP) in exactly the same manner as they would be passed to the AS’s authorization endpoint. This is a key part of the simplicity of app2app - the relying party app has to do almost nothing different to the standard “third party app using a browser to obtain an authorization code” pattern.</div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div text="#000000" bgcolor="#FFFFFF" class=""><font face="Helvetica, Arial, sans-serif" class=""> Also, how an AS decided to honor the authorization
request and return a code:state pair to an intermediary is also
not defined within OIDC/OAuth2. I would expect that the AS will
want "client authentication" from the bank app as well as "client
identification" of the 3rd party app.<br class=""></font></div></div></blockquote><div><br class=""></div>Yes, potentially - I suspect there’s [at least] two different models in the wild, depending on whether the bank app itself is an oauth client or is merely a frontend for a oauth client implemented on the bank’s server.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div text="#000000" bgcolor="#FFFFFF" class=""><font face="Helvetica, Arial, sans-serif" class="">
<br class="">
From a standardization perspective, it seems like specifying the
request/response between the 3rd party app and "IdP App" as well
as specifying the special call between the "IDP App" (profile of
token exchange?) would complete the picture.<br class=""></font></div></div></blockquote><div><br class=""></div>The request/response between the two apps is already standardised, it’s the normal “open the authorisation endpoint in a user agent” flow.</div><div><br class=""></div><div>I think there’s definitely mileage in trying to standardise the idp app <-> idp message. I’ve reached out to a couple of vendors to see if they can share how they currently do this.</div><div><br class=""></div><div><blockquote type="cite" class=""><div class=""><div text="#000000" bgcolor="#FFFFFF" class=""><font face="Helvetica, Arial, sans-serif" class="">
<br class="">
The Native SSO spec could provide a starting point for how the
"IdP App" identifies the user to the back-end AS in a secure way
as well as possibly the profile of the token-exchange. In the case
of Native SSO, the response of the token-exchange is the actual
tokens where in this case it would need to be the "code and state"
values going back to the 3rd party app.<br class="">
<br class="">
Are there any security issues with the on OS app2app communication
that would allow for cut-and-paste attacks?<br class=""></font></div></div></blockquote><br class=""></div><div>I don’t believe so [assuming the mobile OSes correctly secure claimed https urls, which I believe they do and would cause a lot of other security problems if they didn’t, as the native apps BCP already recommends this mechanism for redirect urls for native apps] - if anything I would say it is more secure than the approaches where the user agent for the authorization endpoint is a desktop browser.</div><div><br class=""></div><div>Joseph</div><div><br class=""></div></div></body></html>