UMA telecon 2014-05-01

Owned by Eve Maler
Last updated: May 01, 2014

UMA telecon 2014-05-01

Date and Time

Agenda

  • Reminder: no meeting next week due to IIW
  • Interop and event planning
  • Case study work
    • Personal Cloud App Architecture proposal from Mark D
    • Personal loan/Life Management Platform case study?
    • "Headless" enterprise-to-users detail on AM2.0 case study?
    • Others?
  • Claim profiling work
  • AOB

Minutes

IIW and EIC

No WG meeting next week. Mark is attending. He's currently working on implementing an UMA RS. He should be able to test interop with other implementations.

Interop and event planning

We do have a challenge around what API the RS exposes. Maciej's challenge is that his RS already exposes a real-world API (vs. a theoretical, for-interop API) that doesn't adhere to the "pbryan" constraints, e.g. the _id requirement. So does it make sense to simply remove the requirement we tried out last time, around pbryan? We could specify a scenario that gives very specific guidance about the scopes available etc., but that's even "worse" than pbryan in the sense that it requires RS's to expose a totally artificial API. What if we were to dictate that the RS has to expose either multiple resources (that is, in multiple sets according to what it registers with the AS) or multiple scopes, or both? That way we can test UMA-specific interop around sufficient/insufficient authz data, permission tickets that match/don't match the requested type of access, etc. We could offer a nonnormative sample scenario to illustrate, referring to specific FTs to make our point. We could also require RS's to supply enough information directly in the interop page to explain how to access these differential resource sets and scopes, e.g. the URLs, parameters, etc. This way, clients can tell whether the RS was at fault or not if something goes wrong with authorization.

Personal Cloud App Architecture proposal from Mark D

The scenario Mark has outlined is "all Alice" (Alice-to-Alice sharing). Eve has sent Mark her "all-Alice" special graphic.

Jin has a Neighborhood Watch use case, with a camera that tracks neighborhood activity. So neighbor Alice might have a camera that saves images to her PC (let's say, in Dropbox), and neighbor Bob might want to ask for permission to access those files. So this has something in common with our previous discussions about RS=C use cases, where both Alice and Bob are (say) Flickr users and Flickr could gain more/better authorization functionality – and Alice could gain more centralized management – using an outsourced UMA AS for protection than the Flickr-native authz capabilities. Here, we're applying the same logic to Dropbox, and to the PCAA scenario where the files and operations on them are separated out. Jin mentioned NextDoor.com, a "private social network for your neighborhood", which lets neighbors prove they belong to a particular neighborhood in order to participate in Neighborhood Watch. The policies it manages require on-demand approval workflows – something Maciej's sample apps demonstrate handily! The claims that would be required in the NextDoor case would be something like a trusted third-party assertion of the person's home address.

Once Mark has a chance to revise, should we publish this on the Case Studies page? Is it one or two case studies? We won't worry about it for now.

Actually, there's a challenge if you chain Alice-to-Bob file sharing where Dropbox is both the RS and the C, with Bob-to-Bob sharing, where he permissions his Fargo account to get access to the stuff in Dropbox it needs to know. Can we use this case study writeup to explore the challenges? Or does Bob actually use Fargo directly to access Dropbox, so that it's not RS=C? Is that a reasonable scenario? The RS=C scenario is more like today's Dropbox sharing capabilities, when the RqP is a Dropbox user. If they're not a Dropbox user, then they're just using a generic browser.

Does this mean that until UMA is universally supported (smile), we need to develop an UMA client plugin?? It would have to handle getting 401's and 403's back, and doing the redirect claim-gathering flow. Is that a bridge too far?

Personal loan/Life Management Platform case study

The "three circle" design used by the UMA logo is something Domenico also saw in a personal data sharing paper from the World Economic Forum, which is cool. He's used it for his LMP material that he's presenting at EIC, and also in a newly proposed case study that updates the original Personal Loan one. LMP introduces notions of "informed pull" and "controlled push". The request for data has to include a variety of parameters, such as the data sharing policy it adheres to.

There are hints in the LMP concept of capturing "purpose", "usage", "meaningful use", etc. UMA doesn't natively carry this from C to AS, but the claims-gathering flow could be profiled for this because one way to view it is as a species of promissory claim. It appears this is going to come up more often, particularly for healthcare data. We should be capturing this requirement as best we can going forward. Domenico's wireframe illustrates how to capture this on the requesting side.

If UMA is natively friendly to "informed pull", how might it do "controlled push"? The recent Twitter thread with Igor Zboran (igi64) suggests a way to push encrypted (with IBE) content and then UMA-protect the key generator functionality. Sal will look into it! Domenico comments that the LMP concept of controlled push is mostly about the user protecting their resources, so maybe Eve is taking it too literally. But there's nothing saying you can't push the content, lock the content, and UMA-protect the lock.

Domenico will likely be able to publish before EIC, or even IIW.

We observe that the LMP movement seems to have started roughly in the post-VRM, PDS/PDE era. And now there's a new Identity Relationship Management group championed by ForgeRock and Salesforce.com (and others) that is getting started at Kantara.

"Headless" enterprise-to-users detail on AM2.0 case study?

Eve introduces this terminology, which was first heard on the UMA for the Enterprise webinar. It basically means that the RO is a company, and the policy administrator is acting on behalf of the company. Alice might be the requesting party and not the RO. This use case is sort of AS=RO or something. We may want to edit the AM2.0 case study to reflect a deeper analysis of the parties in the picture, including the "agent" of the RO (some administrator-person) and the software they use to configure policy etc. (which is not exposed on the UMA wire, but is an area where we have an asymmetry in the UMA architecture because we don't reveal it). Sal points out that bearer vs. self-signed would make a difference too.

Claim profiling work

Deferred.

Attendees

  • Thomas
  • Eve
  • Mark
  • Domenico
  • Jin
  • Sal
  • Maciej

Regrets:

  • Roland

Next Meetings

  • No meeting Thu May 8 due to IIW
  • Focus meeting Thu May 15 8:30-10am PT (time chart) - Roland can possibly attend - some people missing due to EIC
  • No meeting Thu May 22 due to absences
  • All-hands meeting Thu May 29 8:30-10am PT (time chart)

Â