[Openid-specs-heart] Health Relationship Trust Profile for Fast Healthcare Interoperability Resources (FHIR) OAuth 2.0 Scopes

[Adrian Gropper]

Glen, "Strongly prefer" is hard to reconcile with NIST privacy engineering
and privacy risk management guidance. Building HEART according to these
principles, requires us to make pairwise pseudonymity the baseline for the
API unless we can identify a specific business goal that is incompatible
with pairwise pseudonymity at the base RS-AS connection.

Adrian


On Tue, Oct 6, 2015 at 2:12 PM, Glen Marshall [SRS] <gfm at securityrs.com>
wrote:

> I would strongly prefer that the function of pseudonym-to-subject
> re-identification be distinct from the AS.  Exactly how that occurs, and
> who is responsible for what functions, is policy-driven and outside of the
> use cases but is certainly an interesting topic for implementation
> guidance.  We should not constrain policy, but should expose practical
> implementation factors to inform it.
>
> *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 10/6/15 11:18, Adrian Gropper wrote:
>
> When the resource does not contain Subject identity information, the
> Authorization Server is responsible for associating the pseudonyms with an
> identity.
>
>
>
> _______________________________________________
> Openid-specs-heart mailing list
> Openid-specs-heart at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-heart
>
>


-- 

Adrian Gropper MD

PROTECT YOUR FUTURE - RESTORE Health Privacy!
HELP us fight for the right to control personal health data.
DONATE: http://patientprivacyrights.org/donate-2/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20151006/83d75f3e/attachment.html>