UMA telecon 2012-06-07

Owned by Former user (Deleted)
Last updated: Jun 10, 2012

 

UMA telecon 2012-05-31

Date and Time

  • WG telecon on Thursday, 7 June 2012, at 9am PT (time chart)
    • Skype: +99051000000481
    • US: +1-805-309-2350 (other international dial-in lines available) | Room Code: 178-2540

Agenda

  • Roll call
  • Approve minutes of 2012-05-31 meeting
  • Spec/issues review – proposed workstream priorities
    • #20: Okay to leave this out of scope and have a third party write a profile for an UMA-protected discovery service?
    • #50: Considering modularizing the AS/RS interop portion for wider non-UMA adoption
    • #56: Standardized scope descriptions for well-known APIs?
    • Look at other current issues
  • "UMA for Enterprise" use case discussion
  • AOB

Minutes

Roll call

Quorum was not reached.

Approve minutes of 2012-05-31 meeting

Deferred due to lack of quorum.

Issue #20

Okay to leave this out of scope and have a third party write a profile for an UMA-protected discovery service?

What would we lose if UMA doesn't solve this natively? Endpoint discovery is really important for a lot of use cases we care about, like the healthcare scenario. The IETF group that's grappling now with WebFinger vs. SWD seems like it might solve part of this problem. Do we believe there is more required for solving "protected discovery" than doing OAuth-protected (or UMA-protected) web discovery calls? The goal would be to allow Alice to choose who is allowed to find out who she uses as her provider for some claim or content.

The "naive" way of solving UMA-protected endpoints would be that the requester would discover the endpoint by accessing a totally ordinary resource (whose value is the endpoint), and then get sent back to the AM if they don't qualify to get through to that endpoint without an existing permission. OpenID Connect has already added the notion of an "endpoint token" to optimize this naive flow, enabling the requester not to be bounced back to an AM. Of course, this is an OAuth token, not an UMA token (requester permission token). On the discovery side of things, OIC uses SWD (if someone gives you an identifier that has a domain embedded in it, you can bootstrap finding their OIC OP endpoint). On the claims side of things, when OIC gives you back "distributed claims", it gives you back an endpoint and an optional endpoint token. If you ask OIC for a "driver's license", an OP that doesn't have it but knows where it is hands you back the endpoint and maybe a token.

We do think that the WebFinger+SWD direction is positive for what we need, but we wouldn't necessarily be crazy about their emerging "RPC-ish" approach to API design. Hopefully we can influence that. But then, since a host presenting that interface can register resource sets with the AM through UMA however it likes, does it matter? Maybe not, though it would still be valuable to standardize the actual API.

Are there any sequence diagrams available for the Street Identity use case or any other use case that needs a solution to issue #20? Eve will ask around.

Attendees

As of 22 May 2012, quorum is 6 of 10.

  1. Maler, Eve
  2. Hardjono, Thomas
  3. Fletcher, George
  4. Catalano, Domenico

Non-voting participants:

  • Nederkoorn, Cordny
  • Cox, Kevin

Regrets:

  • Drake, Trey
  • Moren, Lukasz
  • D'Agostino, Sal
  • Machulak, Maciej

Next Meetings

 

  • WG telecon on Thursday, 14 June 2012, at 9am PT (time chart)
  • WG telecon on Thursday, 21 June 2012, at 9am PT (time chart)
  • WG telecon on Thursday, 28 June 2012, at 9am PT (time chart)

Â