Stupid is as stupid does

Microsoft HealthVault sends me an email asking for an alternate email.

Follows up a warning of being phished with a nice phat phishy link.

If you dont want users to click on it, dont make it a link.

Posted via email from Paul's posterous

On a whim

motivated by a thread on the OpenID list, I tried to use my bonoboch.mp OpenID at Microsoft HealthVault.

 

I did not of course expect it to work, but I did expect a more illuminating error message.

I think an average user might be forgiven for thinking that this would work the next time, when 'communication problems' are cleared up.

Threads

Tieing them up.

1. TrustBearer is picked by Microsoft HealthVault as an approved OP.
2. TrustBearer is proud of the distinction (perhaps seeing Msft as a strategic partner?)
3. TrustBearer CEO vows to do whatever is necessary to keep strategic partner happy (educated guess)
   
4. Along with others, TrustBearer proposes an extension to PAPE that would allow OPs to describe specific authentication mechanisms, rather than the PAPE 'policies'

Is it reasonable to assume that a certain strategic RP wants to see information as to particular authentication methods when a User SSOs in from TrustBearer - PAPE's abstractions not sufficient?

Fence straddling

Microsoft HealthVault accepts OpenID login from two specific OPs, Verisign and TrustBearer. All good, it's the RP's prerogative.

But they seem strangely ambivalent about their choice

Important: Microsoft doesn't provide OpenIDs and doesn't endorse OpenID or any particular OpenID provider.

if Microsoft's saying 'we will work with these OPs' is not an endorsement, what is it? I have to believe that Verisign and TrustBearer think of it that way.

In which I clarify

Often times, in trying to be clever and sarcastic, I dive too deep into the 'satire pool'. The urge to be witty and contrarian surpasses the urge to be clear. Consequently, the 'point' I am trying to make can, on occasion, be buried underneath surface frivolity and snideness.

As happened with my recent post on HealthVault's chosen model for OP acceptance.

With that post, I have confused Kim, and for that I here apologize.

I was responding to a post of Simon Willison, in which he defended HealthVault's right to choose OPs selectively - and not be compelled to accept any ol' OP coming in off the street presenting an identity claim.

My post might have given some the impression that I disagreed with Simon. For instance, I wrote

I disagree

Admittedly, this set a tone.

But the rest of the post was meant to point out that, while I do think the user has the right to pressure RPs like HealthVault to accept assertions from particular OPs - the appropriate mechanism for this pressure, as for many other interactions between customers and service providers (e.g. buying an OS), is through market forces. If enough users choose an OP because it is secure and privacy-respecting, or because it offers 2-factor authentication, or because it has a snazzy flash UI, the RPs will find it (if they are interested in serving their customer base).

When the RPs do find these candidate OPs (or IDPs, the issue is of course not unique to OpenID) they will themselves do their own checking and assessment before they start accepting assertions. And of course, each RP has to ask the question 'Is this OP appropriate for the resources I protect/manage?'. If the resources are neither privacy sensitive nor valuable, the list of OPs that are appropriate will be longer than for medical or financial information.

HealthVault (actually probably some other audit & risk management group in Microsoft) performed this assessment and, at least initially, came up with 2 OPs that they felt were right for them. More power to 'em. Partner selection is tough and fraught with risk - they are right to be careful.

I smile (more a smirk really) when I hear some in the user-centric world place the sole right and responsibility of choosing an OP on the user's shoulders. User's can't even remember their passwords, and you want them to assess the security infrastructure of an OP?

Surgeon: So, are we ready for your operation tomorrow?
Patient: Hi Doc, yes. But I was just reading about this new surgical instrument for the procedure. I really want you to try it out on me.
Surgeon: Hmmm, I don't know much about it ...
Patient: Oh, you'll work it out as you go

So yes Kim, I agree. Resources, and gall bladders, do have rights.

Outsourcing Assurance

HealthVault whitelists two (and only two) OPs.

Liberty Alliance announces Identity Assurance Framework.

What's the connection?

Microsoft whitelisted the Verisign and TrustBearer OPs after (presumably) their own review of the processes and authentication mechanisms of those OPs.

Will this scale if they want to assess other OPs (who will presumably clamor for the chance to assert to a big Microsoft RP)? Not well.

Just as OpenID allows HealthVault to outsource the authentication of users to OPs, Liberty IAF allows HealthVault to outsource the assessment of those same OPs to accredited 3rd parties (or at least provide a common assessment framework should Microsoft want to continue to perform the job)

Pressure

Simon Willison defends HealthVault's choice of OPs.

I disagree. It is I, as a user, that should be able to dictate to HealthVault the OPs from which they are to accept identity assertions through OpenID.

Just as I, as a user of Vista, should be able to dictate to Microsoft which software partners they work with to bundle into the OS (I particularly like the Slow Down to Crawl install).

Just as I, as a Zune user ... oh wait, there are no Zune users....

The mechanism by which I (the user) am able to indicate to HealthVault, or Vista, my preferences for their partners is called 'the market'.

Physician, heal thyself

Microsoft's HealthVault will accept 2 factor based OpenID authentication from an outside OP, but doesn't expect the same level of assurance from its own in-house authentication system.

What are the other factors that somehow balance out the 'assurance equation'?

The SSO protocol used, i.e. OpenID vs LiveID? Identity proofing? Insurance?

HealthVault Revolutionizes Social Sharing

In order to share my health data with family members, I simply send them an email and invite them to join HealthVault. How perfectly simple & straightforward! Why has this not been done before?

I expect my friends & family would really appreciate the opportunity to join my social graph (or is it a 'chart' in the medical context) in yet another context.

Here I start the sharing process.



I choose who I want to share my health info with (in this case myself) by providing an email address.



I am given intuitive and informed control over the specific types of information to be shared. There is just the right level of detail. Why just the other day I was trying to share my 'Hb1ac' levels with my hockey team. I decided against giving myself 'custodian' permissions as I feared I'd be expected to mop the clinic floors.

HealthVault sends an invite to the email address.



I get my invite from HealtVault. I am warned about 'phishing' (I am not warned about Big Pharming).



If I accept the invitation I am encouraged to create my own account at Healthvault.



Perhaps it is appropriate for a health site to rely on viral marketing methods.

Tags: HealthVault

HealthVault (Liberty Style)

Seems appropriate to trot this out.

It's a graphical portrayal of an e-prescription scenario, as enabled by Liberty Alliance Id-WSF. Before Dr Jones can write Adam a prescription, she needs to access his records and determine if there are any contra-indicated drugs.


In this scenario, HealthVault would be merely one of many health record providers.

We could update this to reflect advanced client functionality (e.g. blood pressure data securely shared from an identity enabled cuff) and social (e.g. spouses able to renew prescriptions for each other?) aspects.

Tags: HealthVault, Liberty Alliance, e-prescription

Drummond, it's Hailstorm

Drummond recommends Joe's review of HealthVault.

Joe Andrieu, one of the leaders of the VRM (Vendor Relationship Management) community, has posted a good initial assessment of Microsoft’s first foray (post-Passport) of storing personal data for consumers via their Health Care Record initiative.

I assert/claim that Drummond has mixed-up FII (Failed Identity Initiatives).

HealthVault

HealthVault Connection Center sounds like a perfect application of Liberty Alliance Advanced Client (I believe the appropriate metaphor for the likelihood of this relevance being explored further involves aerodynamically enabled swine)

The API documentation suggests a very static trust model, i.e. application developer who wants to interact with a user's health data stored in HealthVault registers the application information and the public key associated with the private key they'll use to authenticate to HealthVault (similar to OAuth's model).

Similarly, at registration time, the appn developer is expected to supply

End-user-facing text that describes the reasons for needing access to the data types that the application is requesting access to.

and

the type of access that the application requires (read, update, create, delete).

What happens if the application's needs and/or purposes change?

It's not clear how the user's identity is expressed within the messages to and from HealthVault. Is it a WS-* mechanism?

I assume the SDK documentation would explain but I'm not willing to have my Vista certified as genuine just so as to perform the SDK download.

Unrelated, is there any company more diversified than Fabrikam? They are now making medical devices!