[Openid-specs-heart] Persistence of Credentials

Adrian Gropper agropper at healthurl.com
Tue Jun 30 01:43:52 UTC 2015


I really don't understand what this is about. Can someone present a very
simple example?

It seems to me that whatever this persistence issue is, it might be cleared
in the Vectors of Trust thread from this weekend.

Confused Adrian

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

> Either they are going to trust the guy who provides the antecedent claim
> or they are going to revalidate the credentials he\she happened to capture
> at the start of each transaction.
>
>
>
> If the relying party is going to revalidate the credential there isn’t
> much point in using the antecedent concept.  We are just trusting the
> provider to store the credentials he collected and present them for us to
> validate again.
>
>
>
> I would argue that historically providers have trusted other providers to
> sufficiently ID Proof patients that they have a common care delivery
> relationship with and it is up to the doc to decide if he trust the other
> doc to do it electronically or not.
>
>
>
> That way you only do additional credentialing for the transactions that
> require it (but not when the purpose is for Treatment between two docs or
> to communicate with the consumer) hence keeping the overall cost down using
> the ability to remotely identity proof when the use case requires (self
> referral for telemedicine, allowing a remote proxy access to a consumer
> account, presenting medical evidence for beneficiary claims, sharing
> medical records with insures for life insurance qualification, etc.).
>
>
>
>
>
>
>
> 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:45 PM
>
> *To:* Aaron Seib
> *Cc:* Glen Marshall [SRS]; openid-specs-heart at lists.openid.net
> *Subject:* Re: [Openid-specs-heart] Persistence of Credentials
>
>
>
> 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
>
>
>
>
>
>
>
> _______________________________________________
> Openid-specs-heart mailing list
> Openid-specs-heart at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-heart
>
>


-- 
Adrian Gropper MD
Ensure Health Information Privacy. Support Patient Privacy Rights.
*http://patientprivacyrights.org/donate-2/*
<http://patientprivacyrights.org/donate-2/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20150629/a66fe04a/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/a66fe04a/attachment-0003.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 3141 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20150629/a66fe04a/attachment-0004.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/a66fe04a/attachment-0005.jpg>


More information about the Openid-specs-heart mailing list