Thank you very much for your reply! Since I am not a specialist in the Apple domain I have struggled to understand our options to be able to provide SSO between the apps. From your reply It looks Associated domains will not achieve our goal so we will look into the two options you have provided. One question though that has bothered us, and something you might be able to clarify for us: When setting up the “Associated domains capability” there is specific service called "authsrv" that can be specified which implies a pointer to an authentication service in the domain. What is the purpose then of being able to define this service as an “Associated domains capability”?

Sorry, formatting went wrong. For better readability: Thank you so much for your response! Following my reasoning is not always easy, so let me try to clarify: Our goal is to authenticate mobile app users through our company wide IdP without the end users being prompted with this consent dialogue box. Supposedly, if one can publish the relevant information in an AASA file about the domain being trusted, the consent prompt will not appear. The AASA file is to be served by a webserver according to Apple specs, corresponding to an entry in the Associated domains entitlement. Details of the contents of the AASA file / Associated domains entries we understand. Our top domain is “company.com” and it is at this level we would like to serve the AASA file from through a webserver. When I earlier mentioned a problem with using “idp.company.com”, it is not because the idp in idp.company.com is a subdomain. The idp here is the actual IdP webserver built-in the product PingFederate. It is not a solution for us to use the IdP’s webserver to serve the AASA file since it is too complicated to modify that webserver. Ideally, we would like to serve the AASA file from a generic webserver located at the top level domain with FQDN “webserver.company.com”. Our questions are really o Is it possible to use a generic webserver to serve the AASA file for the Asssociated domain service . Resulting entry in the Associated domains entitlement would then be authsrv:webserver.company.com? o OR, does the webserver serving the AASA file have to be identical to the URL location of our IdP, PingFederate?

Thank you so much for your response! Following my reasoning is not always easy, so let me try to clarify: • Our goal is to authenticate mobile app users through our company wide IdP without the end users being prompted with this consent dialogue box. • Supposedly, if one can publish the relevant information in an AASA file about the domain being trusted, the consent prompt will not appear. • The AASA file is to be served by a webserver according to Apple specs, corresponding to an entry in the Associated domains entitlement. Details of the contents of the AASA file / Associated domains entries we understand. • Our top domain is “company.com” and it is at this level we would like to serve the AASA file from through a webserver. • When I earlier mentioned a problem with using “idp.company.com”, it is not because the idp in idp.company.com is a subdomain. The idp here is the actual IdP webserver built-in the product PingFederate. It is not a solution for us to use the IdP’s webserver to serve the AASA file since it is too complicated to modify that webserver. • Ideally, we would like to serve the AASA file from a generic webserver located at the top level domain with FQDN “webserver.company.com”. Our questions are really o Is it possible to use a generic webserver to serve the AASA file for the Asssociated domain service . Resulting entry in the Associated domains entitlement would then be authsrv:webserver.company.com? o OR, does the webserver serving the AASA file have to be identical to the URL location of our IdP, PingFederate?

Please disregard my typo of mentioning "company.no". Top level domain is "company.com".