Re: [WG-UMA] Some UMA deltas related to [legal] goals

Oh yes, absolutely agreed. I was simply trying to document what AS-based token introspection could vs. could not be used for as a reliable “signal”. And note that, if the token profile being used doesn’t leverage token introspection at the AS, then that signal isn’t even available. In case of RS malice, nothing the RS reports or signals would be trustworthy. In case of RS ineptitude, this is where our legal work may come into play, requiring the RS to live up to certain security, privacy, access control, breach notification, etc. standards through model clauses or similar. In case of vectors that the RS can’t prevent, the RO would need to be aware of the possibilities, as they would be now (e.g., if someone were to screenshot Google Docs data, or if an “RqP" were to share their Google credentials, or whatever). Eve

On 14 Oct 2015, at 4:31 AM, j stollman 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 mailto:stollman.j@gmail.com 1 202.683.8699

Truth never triumphs — its opponents just die out. Science advances one funeral at a time. Max Planck

On Tue, Oct 13, 2015 at 10:34 PM, Eve Maler mailto: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 https://docs.google.com/document/d/1N6tocmA0KaBE6v3u-cZSyw0N52lG_LdWHAaPybS_... (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 requests Normally 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 https://github.com/KantaraInitiative/wg-uma/issues/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).

Eve Maler | cell +1 425.345.6756 tel:%2B1%20425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl@gmail.com mailto:xmlgrrl@gmail.com

_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org mailto:WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma http://kantarainitiative.org/mailman/listinfo/wg-uma

Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl@gmail.com