On 14 Oct 2015, at 4:31 AM, j stollman <stollman.j@gmail.com> wrote:Regarding Accounting for Disclosures at AS:The suggested add-on solution to accomplish this would only solve one vector of the problem which is likely to be a narrow channel. More likely scenarios would be either (1) hacking into the Resource Server to access data or (2) using social engineering to obtain the information from someone authorized to see the data (in violation of their contract not to pass the information on). There are likely other attack vectors, as well.Jeff---------------------------------Jeff Stollman
stollman.j@gmail.com
1 202.683.8699Truth never triumphs — its opponents just die out.Science advances one funeral at a time.Max PlanckOn Tue, Oct 13, 2015 at 10:34 PM, Eve Maler <eve@xmlgrrl.com> wrote:Completing an action item I took (with Adrian) on Friday’s legal subgroup call: We had done some work a few weeks back to analyze various deltas between the “UMA-that-is” and the “UMA-that-he-posited” could solve many of the concerns of potential RS’s in the healthcare space. I captured these in a GDoc table (not the friendliest format, nor perhaps even accurate). I’ll paraphrase/correct that information here and comment further…In the GDoc, We started calling these “technical UMA safe harbor propositions”, meaning that if UMA could build in some solutions at a technical layer, then it could powerfully convey to RS’s that they would be safe in outsourcing authorization to an AS chosen by Alice (our RS-AS meta-use case). Don’t take the appearance of the phrase “safe harbor” to mean that other thing. :-)Here were the propositions we looked at and the solution spaces I thought were viable. I’m sure there are other potential propositions beyond these.Accounting for Disclosures at AS(HIPAA calls these “accounting of disclosures”.) This is a regulatory requirement that apparently isn’t really honored yet. The idea is that patients have the right to know who has received their health information for reasons other than treatment, payment, or health care operations, or disclosures specifically authorized. In other words, it’s a kind of monitoring capability.Can this be done in UMA V1? Technically, only “attempts at access” can be detected at the AS at all, and this is only if the RPT was introspected by RS at the AS. Token introspection at the AS is required by the default token profile, but it needn’t be done if (e.g.) the token can be cached and is still fresh. And if the token introspection revealed that the client isn’t authorized, or if the RS maliciously took action that was contrary to what the token said, then the introspection wouldn’t be a good clue as to whether anything was disclosed.Can UMA be extended to do this? The UMA AS-RS communications channel could be extended to let the RS report actual accesses to the AS, so that A4D could be made interoperable.Can software outside of UMA add value to do this? An UMA-enabled software system could throw events about and log access.RS takes client/RqP-dependent actions on access requestsNormally the RS knows nothing at all about the client or requesting party that approaches it. But even if the AS says the client has a valid token with the right permissions in it, the RS may want to reserve the right to make up its own mind. Adrian has called this “you cut, I choose”. I don’t like this analogy because it implies 50/50; I prefer the federated identity analogy (which he hates!), which is that a relying party always has the right to refuse service.Can this be done in UMA V1? In the UMA V1.0.1 spec, we added/tweaked text to make clear the RS’s rights: “The client's presentation of a valid RPT associated with sufficient authorization data as determined through RPT status checking (see Section 3.4) indicates that the resource owner's policies have been met for access to the protected resource. The resource server MAY apply additional authorization controls when determining how to respond.”Can this be done on a business/legal level? Yes. We have woven this recommendation throughout the spec, e.g. “Parties operating and using UMA software entities have opportunities to establish agreements about the parties' rights and responsibilities on a legal or contractual level, along with common interpretations of UMA constructs for consistent and expected software behavior. These agreements can be used to improve the parties' respective security postures, and written profiles are a key mechanism for conveying and enforcing these agreements.”AS displays to RO notices that were contributed by RS that reflect RS’s statutory responsibilities to adhere to RO/RS contract, signed by RO (or AS?)
This one is a doozy. It’s an interesting idea, but I’m not sure I understand all the ramifications. This came out of Release of Information (ROI) form discussions.Can this be done in UMA V1? No. (This was causing me to freak out, as I thought I heard Adrian claiming this was just a tiny thing that would be easy to add. :-) See his issue 224 in GitHub.Can UMA be extended to do this? Perhaps an endpoint/capability for registering either only a “dead” version of the ROI, or elements of the RS/RO contract of record, could be added. Adrian has proposed that this could include a label, an endpoint for notification of changes or cancellation (in both directions), an expiration date of the contract, and an option for the RO’s unilateral cancellation since this is always their right (as it it always the right of the RS too).
_______________________________________________
WG-UMA mailing list
WG-UMA@kantarainitiative.org
http://kantarainitiative.org/mailman/listinfo/wg-uma