UMA telecon 2011-05-19

Owned by Former user (Deleted)
Last updated: May 19, 2011Version comment
3 min read

UMA telecon 2011-05-19

Date and Time

  • WG telecon on Thursday, 19 May 2011, at 9-10:30am PT (time chart)
    • Skype line "C": +9900827042954214
    • US: +1-201-793-9022 (other int'l numbers) | Room Code: 295-4214

Agenda

Attendees

As of 19 May 2011 (pre-mtg), quorum is 7 of 12.

  1. Catalano, Domenico
  2. D'Agostino, Salvatore
  3. Fletcher, George
  4. Machulak, Maciej
  5. Maler, Eve
  6. Moren, Lukasz
  7. Morrow, Susan
  8. Wolniak, Maciej
  9. Wray, Frank

Non-voting:

  • Christian Scholz
  • Cordny Nederkoorn

Regrets:

  • Thomas Hardjono

Minutes

Roll call

Quorum was reached.

Approve minutes of 2011-04-28 meeting

Minutes of 2011-04-28 meeting APPROVED.

Leadership team elections

Sal moves, and George seconds, to approve the slate of:

  • Maciej M. as vice-chair for another term
  • Domenico as graphics/UX editor for another term

APPROVED by unanimous consent. Congratulations and thanks!

  • 2011-04-07-2 Frank, Kirk Open Match constellations to scoped access diagrams to see what happens. We'll keep tabs on this weekly and keep the item open.
  • 2011-04-14-1 Maciej, Alam Open Build list of FAQs (both questions and candidate answers) on the wiki. Eve has created a FAQ shell; Maciej will try and add some answers.
  • 2011-05-12-1 Eve Open Check out the possibility of running a new UMA webinar. Pending the end of the Berlin meeting.
  • 2011-05-12-2 Domenico Open Look into how to contribute Claims 2.0 to the OpenID ABC work. Domenico took this over from Eve.

Constellation/scenario review

Frank is keeping his UMA+hData notes in a new etherpad. The discovery service component is the biggest differential from straight UMA. He's adding information from the UMA and OAuth specs as he goes. People should feel free to commment in the new 'pad.

Scoped access: core spec review

Christian points to http://www.jave.de/ as a possible ASCII art editor. We want to provide swimlane diagrams for each message flow to show a "you are here" map.

Should we have a separate section for scope-related formats, or should we embed the format definitions in the message flow sections? If someone is implementing a host application, they would need to both create requested-scope descriptions and parse granted-scoped descriptions (in different interactions with the AM).

Is the spec too host-centric in its structure? Requesters in UMA are unique; should we organize the spec to be more friendly to requesters? They could totally ignore Phase 1, and they only need to do selected pieces of the further phases. George observes that the OAuth spec is written more from the perspective of the client. Maybe Phase 1 stuff should be moved to a later section!

We notice that a number of discovery solutions are coming out. hData has a patient URL that you can do discovery on to find their health data, so maybe they could look at OpenID ABC. Google's API discovery service may be relevant to our action description stuff. The service publishes the base URI for an API, the auth schemes it supports, and this includes a list of candidate scopes (which in Google's case are URIs). It's a sort of WSDL-like or WADL-like metadata definition of the interface. Could we leverage this mechanism to allow UMA endpoints to describe the schemas going back and forth? Yes, it appears so. Should we use this formalism? Possibly; Eve will discuss with Thomas.

A separate question is: Should we try to align UMA's expression of actions and scopes with some specific part of their discovery service format? We're not sure.

Eve proposed some strawman scope formats in an email. How well do these fly? Our "actions" are close to OAuth "scopes", but they have two dimensions instead of one. Should we change our language to make it less confusing with respect to OAuth? An action is, in essence a scope for a specific resource set at that host. Does it make sense to squish a whole "UMA scope" into an OAuth scope parameter, e.g. by base64'ing it? In order to answer this question, we need to know whether we're optimizing for host implementations, or requesters, or particular UMA+OAuth scenarios in the wild, or what. So we won't try to determine this answer yet until we get further in the spec text. Indeed, the host may even want additional data coming back from the AM; we'll learn this through experience.

So let's change our resource and scope language:

  • Actions -> scopes
  • Granted scope manifests -> token status

Should we re-absorb the resource registration spec into the core spec? It seems to make sense because it's not truly a module; rather, it's a fragment. We can consider this along with considering moving "Phase 1" to the end. Frank notes that hData keeps its "protecting a resource" stuff at the end.

Next Meetings

  • WG telecon on Thursday, 26 May 2011, at 9-10:30am PT (time chart) – Eve regrets; Maciej will create agenda, chair, and do notes-wrangling