UMA telecon 2013-09-19

Owned by Eve Maler
Last updated: Sep 19, 2013
4 min read

UMA telecon 2013-09-19

Date and Time

Agenda

Minutes

Action item review

Keith updated us on the GPII progress. We discussed Mark's work on profiling; right now it's more conceptual, so we won't add an AI for it right now.

#PII2013 report-out

Eve went to PII. In this era of "The Summer of Snowden", it was especially interesting and, ironically, more "realistic" about what we can vs. can't do. Eve gave an Ignite talk on UMA. Stay tuned for a video of that! See #pii2013 on Twitter for the remnants of great discussions.

The reaction to the UMA topic in general was HUGE. One thought that occurred: What about presenting UMA as defining standard privacy APIs? This seems accurate and powerful! Perhaps we should prioritize our PbD spec work and associated collateral, such as an "UMA wrt PbD" FAQ, higher. There is a Privacy by Design user group meeting in December (call for proposals sends Sep 27) discussing these matters where we could try and inject our perspective.

AI: Eve with Keith reviewing: Generate some candidate PbD correlation text suitable for the UMA core spec.

Rechartering activity update (all-hands next week, for voting on this)

We previewed the draft charter changes. Keith commented that it looks true to the spirit of what we were asked to do. We'll share a redline version at least a couple of days before next week's all-hands week.

Demo video progress and other educational outreach activities

Eve is waiting (impatiently (smile) ) for a link to the rough-cut video for everyone's review. It's going to be awesome.

Some related news: Eve is presenting with Joni to the MiHIN (Michigan health) group tomorrow, and with a company that claims to provide authorization manager-like functionality next week.

Mark reports that the outcome of his project will be a presentation for (higher and lower) educational architects in the Netherlands. This is scheduled for early October (the materials will be in Dutch). These architects are responsible for setting the identity infrastructure for education in the Netherlands. He's doing screen mockups for this purpose, and they're thinking of doing a video. Could they leverage Dazza's video? Possibly, but they also have specialized scenarios.

Interop planning

The interop at MIT for Oct 31-Nov 1 is definitely off. This had to do with insufficient preparation time, both for the MIT hosts and for the OAuth interop participants. They need to figure out how to define non-UMA, non-OIDC interop scenarios. There will be a meeting prior IETF 88 in Vancouver BC where people will discuss how to set up the OAuth interop correctly. We'll target early 2014 for a joint interop of some kind. Thomas has also reached out to Nat about maybe doing an UMA+OIDC interop separately.

The feature tests are in fairly good, if draft, form. Mark will entice Cordny to take a look! We'll put feature test improvement on the back burner for now.

SAML and AS=C use cases (see email thread)

Mark's message of Aug 28 was about AS=C. The goal is dashboard-like functions. The dashboard gives insight about what's going on with information. Instead of just being about access controls, it can be helpful to see the data being managed as part of access. So the AS needs to be a C for the purpose of representing that data. The naive answer is that the AS would have to issue a token to itself. This seems inefficient.

The AS could have a "dashboard app" that is strictly a C to itself. It would have to perform UMA flows explicitly in this case, which seems inefficient because it theoretically has optimization opportunities around self-communication without going over HTTP, getting client credentials, getting an AAT, getting an RPT, asking itself for permissions, etc. Commentary: It would be nice if the RS could treat the AS's requests for this data exactly as if it were any other C; when it gets an RPT that happens to be from the AS-as-C, it introspects it or whatever in the 100% normal UMA way. Only the AS might want to change for optimization reasons.

We had previously identified a threat around bad-actor AS's doing this silently, without user permission. But could we put this permission in the realm of normal (possibly explicit) RO policy and/or the overall binding obligations environment in which the AS is operating?

Is the dashboard functionality such central functionality for an AS that we want to privilege somehow, possibly even going to the extent of putting some actual syntactic sugar in the protocol for this use case? It's a little bit like considering an AS-as-Disco-Service. Then again, we've previously resisted literally expanding the AS's scope. Should we continue to keep the scope of what an AS does "clean"?

Because complex analytics could be done by an AS, it could do important information management jobs if it had access to RS data. So access to this data isn't necessarily just about dashboard UX functionality. So we shouldn't limited the scope of what it could do with the data – it has a right to be a client doing "whatever" with the data is possible, just as much as any client!

The solution could be in the form of spec changes, best practices, profiling, binding obligations clauses, or "other".

Issue #60 relates to this. Eve will update it with this color commentary, and we should continue to discuss in email.

Attendees

  • Andrew
  • Domenico
  • Eve
  • Mark
  • Thomas
  • Keith
  • George

Next Meetings

  • All-hands meeting on Thursday, September 26, at 9am PT (time chart) – Mark regrets
  • Focus meeting on Thursday, October 3, at 9am PT (time chart)
  • Focus meeting on Thursday, October 10, at 9am PT (time chart)
  • Focus meeting on Thursday, October 17, at 9am PT (time chart) - Eve regrets, need chair pro tem (IDESG is happening Oct 15/16)
  • Focus meeting on Thursday, October 24, at 9am PT (time chart) - note that UK goes off summer time on Oct 27
  • All-hands meeting on Thursday, October 31, at 9am PT (time chart) - note that US goes off summer time on Nov 3
  • Interop event at MIT on Oct 31-Nov 1 (date and location may change)

Â