UMA telecon 2011-05-19
Date and Time
As of 19 May 2011 (pre-mtg), quorum is 7 of 12.
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:
APPROVED by unanimous consent. Congratulations and thanks!
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:
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.
Is this site useful to you? Please share it!
| | More
Pages in this Space: