UMA telecon 2013-12-19

Owned by Eve Maler
Last updated: Mar 16, 2014
4 min read

UMA telecon 2013-12-19

Date and Time

Agenda

  • Roll call
  • Action item review
  • RSR challenge for attributes and attribute bundles
  • Interop feature test work
  • Healthcare use case status
  • AOB

Minutes

Roll call

 Quorum was reached.

Action item review

Mark is still working on his AI: "Propose spec text around "option 3" for AS=C, exploring the potential for turning off some MUSTs around the requirement for AS and C to communicate through HTTP API endpoints."

RSR challenge for attributes and attribute bundles

We've already given Roland feedback that the value of the "name" property in JSON shouldn't be a person's actual identifier. For this, we recommend treating the AS as a client of the RS, so that the access to this PII can be under the RO's control, audited, etc.

Now we're thinking that we want to develop best practices around "What scopes should look like when the RS is an attribute provider (which includes an IdP that also holds attributes). We note that Roland's example does legitimately use scopes to provide different "views" over an RO's (set of) digital identity (attributes), but carries with it an implicit assumption of a GET ("claim pull") operation – or at least doesn't distinguish between getting and setting and whatever other actions could be performed. Thus, his scope design doesn't have "action" grain for permissions. We'd like to solve for best practices that enable finer "action" grain for those who want it. Eve gives examples of other non-GET things you might want to do to identity data (just sticking to RESTful verbs, it should be noted, are insufficient for protecting the real-world APIs we see around us, like Twitter and Flickr):

  • A client specializing in deidentifying data might need to get "transform" or even "delete" access.
  • A client specializing in tokenizing data might need to get "transform" access. 
  • And yes, a client specializing in being a relying party (for either the RO herself or even a third party interested in Alice) might need to get "retrieve" access.

We might just say that we "recommend" action-based scopes, but not require them – or we might not express an opinion at all! In fact, it's not crazy to imagine that a scope definition could call out to specific code that needs to be executed. This might, e.g., apply in the enterprise circumstance.

Jin's current POC work, which involves NIST 800-162, has healthcare-related rule sets over what actions on data are allowable. This is in natural language, and gets compiled into JSON. Maybe we can ask Ron to come and talk about this precise process, as he has implemented. We can see the near-natural-language "Rules Builder" they've put online. At runtime, a request would come in from Nancy the practitioner. There's a JSON response back saying that her access request is permitted.

Keith notes that the Scalable Privacy "Needs and Preferences" doc has hints of what scopes they'll need.

Should we add a section to the RSR spec to suggest how to standardize scopes? And then ultimately if we do have best-practices advice about resource sets or scopes when it comes to "claim types", we could point to things like the X.500 attribute profile of SAML (which describes how to stuff OID-based fields into SAML), the OpenID Connect reserved claims, etc. as examples.

So, looking at Roland's example one more time, other than our advice not to pass attribute values, we don't yet had any further feedback on the design (that is, it's a viable approach as far as we can tell right now). More to come, though.

Interop feature test work

Eve would like to use the UMA-dev list for interop planning and discussion. She'll remind the wg-uma list once again how to sign up for it.

Healthcare use case status

The document we've been working in is here. Jin has pointed us to a use case that is currently undergoing a funding request for a REST-flavored pilot: Privacy, Access and Security Services (PASS). Section 2.5.2 of that doc shows a "record access" use case. The VA has already implemented the "XACML way" to do this use case. They ran a pilot with UT-Austin and Jericho for a patient consent directive approach. There's a "security label" on the resource that indicates "sensitive" vs. "highly restricted", based on federal law, with break-glass exceptions.

This makes Eve think about our conversation above: An RS could mark resource sets as having types (or sensitivity levels) that can flow through to the AS, enabling policies to be created along sensitivity or type lines and enabling interesting dashboard readings for privacy levels (e.g., "You granted access to these n highly sensitive items to x jurisdictions worldwide"). Domenico did some work around privacy-primary views and capabilities – see the "access analytics UX" wireframes here. Also see his "trust model user guide" here. The Privacy Manager work that's going on concurrently with Scalable Privacy may find our UX wireframes interesting.

Ultimately, how much distinction is there, really, between scopes and resource sets? Wouldn't Roland's "scopes" (which amount to individual attributes) want to have the option of sensitivity levels too? The reason for our resource set/scope split was extreme "RESTful" thinking. But couldn't the JSON format of scope descriptions accommodate sensitivity levels and types as easily as the resource level?

We'll keep working on this.

Attendees

 As of 19 December 2013 (pre-meeting), quorum is 7 of 12. (We discovered that Mark's participation was incorrectly recorded all this time as "non-voting", so we switched him prior to the call start, but did not attempt to fix prior incorrect records.)

  1. Eve
  2. Andrew
  3. Jin
  4. Mark
  5. Sal
  6. Keith
  7. Thomas

Non-voting participants:

  • Nat
  • Mark

Regrets:

  • Maciej
  • Lukasz

 Next Meetings

  • No meeting Thu Dec 26 (holidays)
  • Focus meeting Thu Jan 2 8:30-10am PT (time chart)
  • Focus meeting Thu Jan 9 8:30-10am PT (time chart)
  • Focus meeting Thu Jan 16 8:30-10am PT (time chart)
  • Focus meeting Thu Jan 23 8:30-10am PT (time chart)
  • All-hands meeting Thu Jan 30 8:30-10am PT (time chart)