none
Private domains (http://domains.live.com) service going away RRS feed

  • Question

  • Shared Care Plan (Health Record Bank) is an application that my company developed several years back. This app uses HealthVault as the patient data repository and uses the private domain myscp.us as the "root" of all usernames (firstname.lastname@myscp.us). This private domain is registered at http://domains.live.com and account provisioning process we developed used the API services exported from http://domains.live.com in order to create the HealthVault accounts for our patients. Note that this design allows some nice branding of our application - a feature that is about to go away, since I just received the email saying "As of April 10th 2014, Outlook.com no longer supports new custom domain sign ups. We appreciate that you have used this service and we regret to inform you of this change".

    As the alternative, Outlook.com team offers the transition to Office360 - a change that is not meaningful in the context of a free service provided by Shared Care Plan application, since the cheapest Office365 mailbox costs $5 / user / month and our users would have no interest in any other benefits that Office365 brings to the game.

    To make my point very clear: we used the API from http://domains.live.com so that our own account provisioning application can generate the user credentials that are happily accepted by HealthVault. This seems to be gone and my question is whether anyone knows whether Outlook.com may still offer something similar (by gut feel is NO)


    Nik

    Tuesday, May 27, 2014 8:43 PM

Answers

  • Nik,

    There are 2 broad categories of accounts for Microsoft services.

    The first is organizational accounts which are owned and managed by the organization. (i.e. ACME your scenario above). These allow access to enterprise-focused services like O365, CRM Online, OneDrive Pro, etc. Typically, an organization buys a set of licenses and allows their constituents (i.e. employees) to use the services. The organizations administrator can create these accounts and pass them the individuals.

    The other account type is Microsoft account which is for access to Outlook.com, OneDrive, and other services focused on individual users. In other words, there isn't an organization that administers these accounts, it's the individual. For these accounts, the individual must create their account, not an organization.

    HealthVault uses Microsoft account for user authentication. There's an identity federation alternative in HealthVault (See 1311 release blog), which allows large organizations to stand up and manage user identity on their own, and federate these identities to sign-in to HealthVault.

    Friday, June 6, 2014 8:41 PM

All replies

  • Hi Nik,

    To the best of my knowledge there is no support to automate account creation for any Microsoft account. In fact the process includes a number of features intended to ensure there is a real person at the keyboard creating the account. 

    Thursday, June 5, 2014 8:08 PM
    Moderator
  • This simply cannot be correct Sean, as it completely defeats the very likely use case scenarios for HealthVault, as well as other Microsoft services. Take for example a large company ACME that decided to provide each of its employees an Office 360 account. Are you telling me that ACME will instruct each of their employees to go to Office 360 website, create for themselves an Hotmail, Google or Yahoo email account that will then be used in the process of provisioning the Office 360 account? Further, each ACME employee would then present her own credit card number and ask the employer to refund the charge each month??

    I am trying to point out in living color that each Microsoft service ought to have the means to provision the service using API - just as http://domains.live.com did until now. Clearly, such provisioning is not meant to be used by "end users", and I was not asking my question in the end user context. 

    Most likely we are discussing the case where the account provisioning is to be done for a class of customers that are not willing or needing any other Office 365 service than authentication. This used to be a free service and now charging for authentication seems wrong given the fact that the whole application service is free for the whole community.


    Nik

    Thursday, June 5, 2014 10:23 PM
  • Nik,

    There are 2 broad categories of accounts for Microsoft services.

    The first is organizational accounts which are owned and managed by the organization. (i.e. ACME your scenario above). These allow access to enterprise-focused services like O365, CRM Online, OneDrive Pro, etc. Typically, an organization buys a set of licenses and allows their constituents (i.e. employees) to use the services. The organizations administrator can create these accounts and pass them the individuals.

    The other account type is Microsoft account which is for access to Outlook.com, OneDrive, and other services focused on individual users. In other words, there isn't an organization that administers these accounts, it's the individual. For these accounts, the individual must create their account, not an organization.

    HealthVault uses Microsoft account for user authentication. There's an identity federation alternative in HealthVault (See 1311 release blog), which allows large organizations to stand up and manage user identity on their own, and federate these identities to sign-in to HealthVault.

    Friday, June 6, 2014 8:41 PM
  • Hi Ali

    Thanks for your reply as it establishes the context in which we can rapidly converge to the solution I am trying to find. The important aspect of my solution is a free authentication service, since the membership for SCP (Shared Care Plan) application is free. Note that SCP is using HealthVault as persistent data store - service that is also free. 

    The relevant section of 1311 release blog article is clearly this:

    HealthVault has added support for the WS-Federation protocols as part of a new identity federation feature. This will allow organizations that provide sign-in credentials for large consumer populations, to federate consumer identity with HealthVault when users sign-up or sign-in. If you’re interested in enabling connectivity with HealthVault using your organization’s identity provider that supports a large consumer base, contact us to find out more.

    So, I will contact Raj to find out more.

    Nik


    Nik

    Friday, June 6, 2014 9:16 PM