[Openid-specs-heart] Persistence of Credentials

Debbie Bucci debbucci at gmail.com
Mon Jun 29 23:44:39 UTC 2015


Purely speculation

Do not think PHR would not store the information only the provider's gold
star or trustmark(?) for the source event  -if that was even possible.

On Mon, Jun 29, 2015 at 7:38 PM, Aaron Seib <aaron.seib at nate-trust.org>
wrote:

> Ah – now that is helpful.  I think of it in different terms.  It isn’t so
> much a credential per se as a claim that the antecedent process took place
> and if you trust the operator of that process you can trust the claim.
>
>
>
> Credential has baggage in my head these days.  Do you need to retain my
> Driver’s License Number to be trusted to have substantiated that I am who I
> am through a patient-provider relationship?
>
>
>
> I can trust that the guy who is getting reimbursed by the hospital that
> credentialed him to provide care in the facility isn’t going to fake a
> relationship with a patient in most cases and I am not so sure that just
> because he can produce a matching drivers license number for that person is
> that big of a evidentiary hurdle for some body intent on committing fraud
> to acquire.  Hence the excellence of Glen’s question.
>
>
>
> What would the pros of storing these be?  Or am I still grasping around in
> the dark?
>
>
>
> Aaron Seib, CEO
>
> (o) 301-540-2311
>
> (m) 301-326-6843
>
> <http://nate-trust.org>
>
>
>
> *From:* Debbie Bucci [mailto:debbucci at gmail.com]
> *Sent:* Monday, June 29, 2015 7:27 PM
> *To:* Aaron Seib
> *Cc:* Glen Marshall [SRS]; openid-specs-heart at lists.openid.net
> *Subject:* Re: [Openid-specs-heart] Persistence of Credentials
>
>
>
> Aaron,
>
>
>
> The context for you and others that follow along  ...  the PHR has a
> strong token with no identity proofing.  At the time of registration - the
> token is bound to the credential (binding ceremony) that results in a
> strong identity.   If there was some persistence in the process - that
> identity proofing could potentially be reference in the future.
>
>
>
> There is a precedence for it in the Fed PKI world  ... antecedent
> in-person event
>
> Hence, a proposed antecedent process must 1) meet the thoroughness (rigor)
> of the in-person event, 2) provide supporting ID proofing artifacts or
> substantiate the applicant through a relationship, and 3) bind the
> individual to asserted identity
>
>
>
>
>
>
>
>
>
> On Mon, Jun 29, 2015 at 7:05 PM, Aaron Seib <aaron.seib at nate-trust.org>
> wrote:
>
> Glen – can you help me understand what you are asking.
>
>
>
> Should HEART have a constraint on persistence of end-user credentials.
>
>
>
> Maybe I am being captain obvious here or I am really stupid (or I am
> procrastinating on a writing assignment I was giving that isn’t jumping out
> of my head the way I wish it would) but why on earth would we be
> considering the persistence of user attributes in this domain?
>
>
>
> Not only do many of the attributes\credentials you list change over time
> there is no reason that I can imagine why we need to store such information
> at a EMR\PHR when we have modern credential management processes.
>
>
> Again, ready for my beating as I wasn’t on the call and am procrastinating
> on a writing assignment.  J
>
>
>
> Are there proponents of this idea?  It just seems like another place for
> sensitive data to be breached from to me.  The only reason you might do it
> is that it is a convenience to the consumer and he granted you permission
> to store it, right?  I wouldn’t call that a credential anymore.  I might be
> using the language differently.
>
>
>
> Aaron
>
>
>
> Aaron Seib, CEO
>
> (o) 301-540-2311
>
> (m) 301-326-6843
>
> <http://nate-trust.org>
>
>
>
> *From:* Openid-specs-heart [mailto:
> openid-specs-heart-bounces at lists.openid.net] *On Behalf Of *Glen Marshall
> [SRS]
> *Sent:* Monday, June 29, 2015 4:43 PM
> *To:* Debbie Bucci; openid-specs-heart at lists.openid.net
> *Subject:* [Openid-specs-heart] Persistence of Credentials
>
>
>
> In today's call I asked a question regarding the persistence of end-user
> identification credentials.  Some of the ones being discussed, e.g.,
> driver's license, credit card, e-mail address, etc., have a significant
> likelihood of changing between patient visits.  End-users are also likely
> to fail to remember what credentials were used previously.
>
> Given this, should HEART have a constraint on the persistence of end-user
> credentials?
>
> There may be similar issues with client systems maintaining current
> credentials.
>
> *Glen F. Marshall*
> Consultant
> Security Risk Solutions, Inc.
> 698 Fishermans Bend
> Mount Pleasant, SC 29464
> Tel: (610) 644-2452
> Mobile: (610) 613-3084
> gfm at securityrs.com
> www.SecurityRiskSolutions.com
>
> On 6/28/15 08:42, Debbie Bucci wrote:
>
>
> *When: 1 PM PST/4 PM EST*
>
> *Where: Gotomeeting – *https://global.gotomeeting.com/join/785234357
>
> *US phone number*: +1 (619) 550-0003. Access Code 785-234-357
>
>
>
>
>
> *Agenda :*
>
> ·        Roll call
>
> ·         PHR or Patient Portal (client)  to PCP or Patient portal
> (protected resource)  Introduction
>
> ·        AOB
>
>
>
> For tomorrow's call,  I would like us to focus on the following
> assumption/fact: The PHR is already recognized by the PCP prior to the
> patient's engagement.
>
> What are the sequence flows, scopes and policy decisions that need be
> prearranged/agreed upon to support the following during the patient
> registration process:
>
>    - Update the patient portal from her PHR.
>    - Update her PHR from the patient portal
>    - Sync the patient portal with her PHR.
>
>
>
>
>
> _______________________________________________
>
> Openid-specs-heart mailing list
>
> Openid-specs-heart at lists.openid.net
>
> http://lists.openid.net/mailman/listinfo/openid-specs-heart
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20150629/7e96e6ca/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 3142 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20150629/7e96e6ca/attachment-0002.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.jpg
Type: image/jpeg
Size: 3142 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20150629/7e96e6ca/attachment-0003.jpg>


More information about the Openid-specs-heart mailing list