locked
PersonIds v/s RecordIds v/s ApplicationIds RRS feed

  • Question

  • I understand that the application would only see pseudo recordids for a given record and the same record will have different recordids with respect to different applications.  I also understand that the record ids will change when a user deauthorizes and reauthroize the same record with respect to an application.  I also understand the reasons why this is key this way as explained in Eric's blog

    Here are some of my assumptions (based on limited experimentation) and I think that some of them may not be true.  Can some one shed some insight into these and let me know if any are incorrect?

    1.  If a record R is shared between 2 users X and Y, and both have authorized the record R for the given application A,  the pseudo recordid for Record R as it appears in the AuthorizedRecords collection of X and Y respectively will be SAME when they access the application A? 

    2.  If in the above context, Y deauthorizes R and reauthorizes it again, after reauthorization, Y will continue to see the same pseudo recordid that he did before deauthorization since the record R was not "totally" deauthorized from the application's context (X continued to have authorized R for A)

    3.  If in the context #1,  X deauthorizes R, Y deauthorizes R, Y reauthorizes R (all wrt application A) :  Now, Y will see a new pseudo recordid for R since the record was "totally" deauthorized from the application's context.

    4.  Reauthorization trigged due to application configuration changes trigger will NOT change pseudo recorids.

    Would really appreciate some answers...

    Raj
    Raj HealthVault Developer Tool http://xray.getrealconsulting.com
    Friday, November 13, 2009 2:56 PM

Answers

  • Hello Rajesh,

    I have tried to reproduce the scenarios you have specified. I am explaining the way I did it below. Please correct me if I have gone wrong anywhere.

    1. For this step I have chosen one record and shared it with another user (not as guardian). Both the users shared the same record with same application. But when I checked the record key in AuthorizedRecord of PersonInfo they were different for both the users. Even when it was corresponding to the same record I got two different record IDs for both the users.

    2. For this step once Y has reauthorized the record after de-authorizing it again I got a record ID for Y which is different from the one Y was already having.

    After looking at these results I felt the step 3 will also yield a different record ID for Y and didn't test it in my sample application.

    For step 4 do you mean a rule change or something like that and then the application reauthorizing the user? Here also I felt a new record ID will be yielded.

    Please correct me if I am wrong.

    Thanks and Regards,
    Aneesh D.
    Saturday, November 14, 2009 12:02 AM
  • Hi Raj,
      In the interest of privacy of the user's health information, Healthvault explicitly prevents elevation of privilege through a collusion based scenario. Consider a case where either two applications or two people within the context of a single application, have different access rights on a record. For example.
    1. Application / User A has rights to view the blood pressure and weight data.
    2. Application / User B has rights to view the condition and medication data.
    If they both share the same record id, they can out of band collude with each other and both have access to all the 4 data types together. This is essentially elevation of privilege for these operators.
    In your particular case it would be elevation of privilege of the persons who use your application and have different access rights to a record.
    You bring up correctly, that a brute force guess based system using sentinel data within the records is still possible. It is however not a first class scenario we wish to support.

    In some sense the best way to look at this is that, in HealthVault an application or a person does not get access to the record itself. It actually gets access to read or write to a view of the record defined in terms of the thing types within the authorization of the person or the application to that record. Although these two people are authorized to use the record data in the context of your app, they really have their own views of the record, each with its own view id, which happens to be the different or the pseudo record id returned to them. The view may map to the full record, it may not, the application or person is only concerned about reading or writing information within the record, that this view provides them access to. When you lose authorization, you lose your view, when you regain it, you are given a new view, that may or may not be the same as your old one.

    Could you please add some more detail about the application you are architecting? What scenarios and use cases require such record detection?
    Tuesday, November 17, 2009 8:11 PM
  • I've actually recommended effectively the same approach (using GroupMembership and/or GroupMembershipActivity) to accomplish this kind of thing.  In one case, it was to identify users of any child app that was created by a particular master app-- each child needed to auth seperately, but there was a shared ID-proofing going on across all the child apps, and data from that process could be shared amongst the children via a GM item.

    So, I belive this approach is reasonable.  If not, I'll discuss with the team here and see what approach should be used (and contact the partners I've previously suggested this to :-)  ).
    Tuesday, November 17, 2009 11:26 PM

All replies

  • Hello Rajesh,

    I have tried to reproduce the scenarios you have specified. I am explaining the way I did it below. Please correct me if I have gone wrong anywhere.

    1. For this step I have chosen one record and shared it with another user (not as guardian). Both the users shared the same record with same application. But when I checked the record key in AuthorizedRecord of PersonInfo they were different for both the users. Even when it was corresponding to the same record I got two different record IDs for both the users.

    2. For this step once Y has reauthorized the record after de-authorizing it again I got a record ID for Y which is different from the one Y was already having.

    After looking at these results I felt the step 3 will also yield a different record ID for Y and didn't test it in my sample application.

    For step 4 do you mean a rule change or something like that and then the application reauthorizing the user? Here also I felt a new record ID will be yielded.

    Please correct me if I am wrong.

    Thanks and Regards,
    Aneesh D.
    Saturday, November 14, 2009 12:02 AM
  • Thanks Aneesh...

    Your results seem right (except 4).  The assumptions I wrote in the original post were based on similiar tests I did very long back.  But when I redid the same tests recently, I got results like what you did - which is - recordids for same record R will have different pseduo recordids when different users authorize it for the same application.

    Now, I would really like to know from why it is implemented this way.  An application once it has access to a set of records might want to be able to uniquely identify a record even in the context of different users of it .   I understand the reasoning in using pseudo recordids so that different applications are not able to do this kind of mapping. 

    Obviously, there are kludgly ways if an application really wanted to match if 2 records are same (given a pair of personid/recordid) that it is authorized to - for ex, you can always check if the Basic thing type id matches b/w the records - given this, why not expose a clean interface for this?


    Another question based on the new results is the behaviour of APIs like GetUpdatedRecordsForApplication. Will it return multiple recordids of what actually represents the same record?  By definition, the above API seem to suggest that distinct recordids within an application points to distinct records. 

    I would really appreciate if I can get some more insight into this behaviour since I we are currently architecting an application which potentially requires detecting idential records in the context of different users. 



    Raj HealthVault Developer Tool http://xray.getrealconsulting.com
    Saturday, November 14, 2009 6:11 AM
  • Raj,

    I'll check on email with some folks on the team and get back to you here.  Thanks!
    Monday, November 16, 2009 7:08 PM
  • Hi Raj,
      In the interest of privacy of the user's health information, Healthvault explicitly prevents elevation of privilege through a collusion based scenario. Consider a case where either two applications or two people within the context of a single application, have different access rights on a record. For example.
    1. Application / User A has rights to view the blood pressure and weight data.
    2. Application / User B has rights to view the condition and medication data.
    If they both share the same record id, they can out of band collude with each other and both have access to all the 4 data types together. This is essentially elevation of privilege for these operators.
    In your particular case it would be elevation of privilege of the persons who use your application and have different access rights to a record.
    You bring up correctly, that a brute force guess based system using sentinel data within the records is still possible. It is however not a first class scenario we wish to support.

    In some sense the best way to look at this is that, in HealthVault an application or a person does not get access to the record itself. It actually gets access to read or write to a view of the record defined in terms of the thing types within the authorization of the person or the application to that record. Although these two people are authorized to use the record data in the context of your app, they really have their own views of the record, each with its own view id, which happens to be the different or the pseudo record id returned to them. The view may map to the full record, it may not, the application or person is only concerned about reading or writing information within the record, that this view provides them access to. When you lose authorization, you lose your view, when you regain it, you are given a new view, that may or may not be the same as your old one.

    Could you please add some more detail about the application you are architecting? What scenarios and use cases require such record detection?
    Tuesday, November 17, 2009 8:11 PM
  • Gaurav,

    Thanks for the detailed response and it does make sense.  I think one of the reasons my test results were skewed is probably because I was sharing records as "Custodian" - and hence probably views are shared (probably not).  In any event, it is pretty clear why an pseudo recordids differ when person in context changes.

    Now, think of the application that we are talking about as a paid PHR service (at the simplest level - even though it does do lot more other things) where users are charged for using the application on a per record basis.    This is a Native HealthVault app - especially so because we wanted to take advantage of the "sharing" paradigm that HV natively supports.

    Now, here is a sample scenario.  Dad and Mom are 2 persons (different live ids).  Dad signs up for this service to manage the HealthRecord of his son thru this PHR and pays for it.  But we want all others who shares the record get access to this application to manage this record.  So, if Mom should be able to access this service to manage her son's record without paying for again.   We need a way to detect that a record in context is paid for by someone or not. For this, at the minimal we need something that is unique in the record that wont change when the person in context changes. Let me know if this explains the scenario.

    Now, here is what I am *planning* to do given that there is nothing that is unique to a record that can be used directly. To each subscribed record to the application, we will store a "Group membership" thing instance and use the id of that instnace as the unique value for the record.   Again a kludgy way - but will solve the specific problem here to some extent (problems like what if the user delete this instance are something that we need to tackle).


    It appears as a reasonable requirement from the application's perspective.  Let me know if you have any better suggestions - or comments about validiity of such a use case.

    Now, one of the overheads that I can think of the behaviour of the recordids you mentioned is that fact API calls like "GetUpdatedRecordsForApplication"  does return mutilple values all pointing to the same record - probably an over head for a "syncing" application since it needs to go thru the syncing logic twice.


    Raj HealthVault Developer Tool http://xray.getrealconsulting.com
    Tuesday, November 17, 2009 8:55 PM
  • Another scenario where unique detection of records is required is for the following.

    Consider a non native application which stores record data in local db store and wishes to allow the users to sync it with HV.  It is reasonable for such an application to validatate the linking of HV records to user records for following condition : Make sure that when a db record is getting linked to HV record, no other db record is already pushing data to it.

    I do still feel that this functionality should be eventually supported as a first class feature - probably restricting applications where the need for this is information reasonable (a check box in config center?) :)




    Raj HealthVault Developer Tool http://xray.getrealconsulting.com
    Tuesday, November 17, 2009 9:22 PM
  • I've actually recommended effectively the same approach (using GroupMembership and/or GroupMembershipActivity) to accomplish this kind of thing.  In one case, it was to identify users of any child app that was created by a particular master app-- each child needed to auth seperately, but there was a shared ID-proofing going on across all the child apps, and data from that process could be shared amongst the children via a GM item.

    So, I belive this approach is reasonable.  If not, I'll discuss with the team here and see what approach should be used (and contact the partners I've previously suggested this to :-)  ).
    Tuesday, November 17, 2009 11:26 PM