[Openid-specs-heart] Resources vs Resource sets

Mon Aug 1 14:07:59 UTC 2016

Webfinger doesn't solve the problem on its own. If you push the 
discovery problem off to webfinger, then you've got to ask yourself -- 
how do you protect the webfinger lookup? Then how do you discover how a 
webfinger endpoint is protected?

  -- Justin

On 8/1/2016 9:54 AM, Aaron Seib wrote:
>
> Justin
>
> Thank you for explaining this consideration.  I especially like the 
> statement you make toward the end that:
>
> ·“Protected service discovery is a thorny problem, and not one I've 
> seen an elegant solution for yet.”
>
> Does WebFinger have the vulnerability you describe as well?  I don’t 
> know if it is an stated precondition of HEART that it support 
> Protected Service Discovery but I suspect that the consumer has that 
> expectation and as such either we have to explicitly inform them of 
> the risk as part of our offering or look to another approach, right?
>
> Aaron Seib, CEO
>
> @CaptBlueButton
>
>  (o) 301-540-2311
>
> (m) 301-326-6843
>
> <nate-trust.org>
>
> *From:*Openid-specs-heart 
> [mailto:openid-specs-heart-bounces at lists.openid.net] *On Behalf Of 
> *Justin Richer
> *Sent:* Monday, August 01, 2016 8:30 AM
> *To:* Adrian Gropper; Debbie Bucci
> *Cc:* HEART List; Dixie Baker
> *Subject:* Re: [Openid-specs-heart] Resources vs Resource sets
>
> As far as what matters, you're missing a key point: it very much 
> matters to HEART that an RS and AS that are both *run* by the same 
> group don't have to be *built* by the same group. Runtime choice 
> matters for more than just patients.
>
> As far as the patient choice of AS at all times, there are two very 
> real consequences to discovery that we need to be aware of as a group. 
> Both of these have been discussed here in HEART before (as well as 
> elsewhere, particularly in the UMA working group) but to reiterate:
>
>  1) To have the AS selectable at runtime by a client with no token 
> (ie: a "dry start" to get to the resource, like we have in UMA), you 
> need to limit the type of API you protect. The RS needs to know 
> *which* AS to get to without a hint from the security layer. This puts 
> APIs styled like OpenID Connect's UserInfo Endpoint out of reach since 
> they use the access token to dispatch to the appropriate resource 
> owner and therefore appropriate resource. In general, FHIR records are 
> going to have a patient or record identifier in the URL, but this of 
> course has privacy implications as you're leaking identifying 
> information in an unprotected component (the URL itself).
>
> 2) The above leads us to an interesting attack. Let's say I get (or 
> guess) a patient's record URL, /PXZ-1234. I don't know who it's for 
> and I don't have access to it. But I use my generic client to call 
> said URL, and the RS dutifully goes and figures out that this is 
> Alice's record and it's protected by Alice's AS, alicehealth.org. This 
> is Alice's own personal AS and she's the only one that uses it. I can 
> go to alicehealth.org and see that stamped right on the front page. 
> What have we learned? That /PXZ-1234 belongs to Alice, a real-life 
> person that we can probably find now. And we've got her medical record 
> number, she can become a target for other attacks, online and off. 
> Remember, all of this is required by the current protocols and would 
> be universal if it were "patient always gets to choose the AS no 
> matter what" as Adrian suggests (though I'll note that this is NOT in 
> the HEART charter or mission).
>
> Protected service discovery is a thorny problem, and not one I've seen 
> an elegant solution for yet. Not to say it's intractable but rather to 
> get us to be aware of the consequences of our decisions here.
>
>  -- Justin
>
> On 7/31/2016 7:04 PM, Adrian Gropper wrote:
>
>     Debbie,
>
>     Thanks for giving me another opportunity to explain what's at
>     stake for all of us.
>
>     As far as the substantive point of this interchange, it doesn't
>     matter if only 5% or 10% of the AS are independent - it will be
>     enough to make every authorization service patient-centered and
>     make transparency and longitudinal health records the norm for all
>     of us.
>
>     I don't understand why any AS operated by an RS matters in the
>     HEART context. It's entirely captive and not an interoperability
>     issue. The only AS that matters to HEART is the one a patient has
>     a choice over.
>
>     Adrian
>
>
>     On Sunday, July 31, 2016, Debbie Bucci <debbucci at gmail.com
>     <mailto:debbucci at gmail.com>> wrote:
>
>     Adrian -
>
>     My sincere apologies if I offended you.   I just voiced a personal
>     opinion.  That was not the point of the paragraph though - I
>     failed to state the point I was trying to make - sorry to send you
>     off on a tangent.
>
>     Totally agree with the following statement.
>
>     The degree to which HEART chooses to profile particular subsets of
>     FHIR has nothing to do with whether a person chooses to outsource
>     his / her authorization server. It simply has to do with the
>     person's user experience in setting policies that
>     HIPAA-covered-entities and FTC-covered-entities and
>     42-CFR-covered-entities as resource servers will need to follow.
>     In some cases, the resource servers will voluntarily take
>     advantage of the FHIR standard while in others it will not apply
>     at all.
>
>
>     I do not see the rise of totally independent AS.   I see it more
>     as a federate authorization model (kind of what MIT is thinking
>     about with Datahub - DUMA - PDS).  All RS will have their own AS
>     processes to deal with - even if trusted, most likely the sharing
>     preference/consent/ROI would be replicated to the RA AS to manage
>     ongoing requests.
>
>
>
>
>     _______________________________________________
>
>     Openid-specs-heart mailing list
>
>     Openid-specs-heart at lists.openid.net
>     <mailto: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/20160801/1ec45965/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 3198 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20160801/1ec45965/attachment.jpe>