UMA telecon 2013-03-14

Date and Time

Focus meeting on Thursday, Mar 14, at 9am PT (time chart)
- Skype: +99051000000481
- US: +1-805-309-2350 (other international dial-in lines available) | Room Code: 178-2540

Agenda

Action item review
Live demo from Lukasz on the Cloud Identity implementation of Alice-to-Bob sharing
- We can get a join.me from Lukasz at the time; they may be recording the screencast for later use as well
Continue analyzing Nat's Alice-to-Bob workflows
Review/discuss Keith's work on NSTIC-flavored case studies and UMA-protected OpenID Connect, as available, and comparison work
AOB

Minutes

Live demo from Lukasz on the Cloud Identity implementation of Alice-to-Bob sharing / Continue analyzing Nat's Alice-to-Bob workflows

Lukasz's company is working with early customer prospects at the moment. They're seeing a lot of interest. They support OAuth (all versions), SAML, OpenID Connect, ActivityStreams, UMA, and many more.

Lukasz demonstrated a sample Newcastle University S3P portal (RS), a sample Career Monster app (client), and a sample SMARTAM authorization server (AS). All of these happen to use federated login to get into them, using, e.g., Facebook. Resource owner "John Cloudidentity Smith" has logged in to the portal. He can click from their to go to Career Monster and log in. He can see the list of available jobs there. When he applies for the Python Architect position, he has to fill out a form. This requires his name and his grades. He can supply data live, or "import from S3P". Doing the latter takes him to SMARTAM. He can approve permissions at that time, which amounts to setting some authorization policies at run time. He showed how Career Monster as a client app has been authorized. John can visit his SMARTAM activity page, which shows that information from S3P was successfully shared with Career Monster. Once the data is all imported, John can finish his job application. Career M
onster shows this change of state.

Career Monster is listed as an "authorized application" for John's sharing with himself (the UX says "Myself" to reflect that this is person-to-self sharing). Does Career Monster have unique client app credentials per requesting party (say, John vs. Bob), or does it have a single set of client app credentials? How, using UMA, does each resource owner perceive authorizations of apps vs. authorizations of requesting parties?

John can share information with Tom Smith too, such as his date of birth. In this case, Tom is using the S3P portal as a client app. In SMARTAM, John has a list of applications that the AS is already integrated with. It has a developer console that allows devs to create and integrate new apps. They have to set app info such as name, domain, and API key; app settings such as the app icon URL and whether the app is published; their UMA configuration; etc. This is all the equivalent of preregistering the client with the AS so that the resource owner will be able to set policy for those clients a priori. Cloud Identity has accomplished this within the confines of UMA because it's already silent about how to set and evaluate policy.

This doesn't necessarily seem to be a "hole" in the UMA protocol, but rather a soft spot in the Binding Obligations, since the "Client Operator" is a role that the obligations don't fully account for. See Thomas's comments on Nat's post about Alice-to-Bob sharing.

Then again, if we can figure out how to literally gather claims from the client app rather than just going by brute-force ACLs over client credentials (which are a very coarse-grained "claim"), then the whole UMA system would be more self-consistent. If we finish the portion of the UMA spec that deals with gathering claims from autonomous clients (which presumably have to be "active" clients?), maybe that can be used in combination with the human claims-gathering flows rather than as an alternative as currently envisioned.

This brings up an old topic that's slightly different: back to George's early work that wants the client app to be able to use an identity token (or some transformation of it) for its current user in a conveniently "silent" fashion so as to satisfy requests for claims without having to redirect him for the full claims-gathering process. Of course, this would reflect Tom's claims, not the app's claims about itself. Nat's "WF1" and "WF2" seem to assume exactly this flow optimization! Can we specify this? Google has done a bit of work on "bootstrapping" claims provisioning in this fashion. Ideally we'd have a serious working call with Nat, John Bradley, George, and Keith at a minimum to sort through this opportunity. If we can profile OpenID Connect to create this optimization, we'd do a service to both UMA and OpenID Connect.

Eve surmises that if static client registration is being done, as it is in SMARTAM, enough approval workflows, ToS agreements, etc. can be done "off-stage" to allow basic OAuth client authentication to serve as the only "claim" Alice needs in terms of setting policy over approved clients. Once we really get into dynamic client registration, however, we're going to need clients themselves to provide "client identity claims" in some fashion, which we haven't covered yet.

AI: Eve: Set up an ad hoc working meeting with key participants to brainstorm an OIC-UMA profile that optimizes the claims delivery process, possibly as envisioned by Nat's Alice-to-Bob blog post.

Attendees

Lukasz
Eve
George
Keith
Thomas

Next Meetings

Focus meeting on Thursday, Mar 21, at 9am PT (time chart)
All-hands meeting on Thursday, Mar 28, at 9am PT (time chart)

Browser not supported