UMA telecon 2012-06-21

Owned by Former user (Deleted)
Last updated: Jun 27, 2012
3 min read

Date and Time

  • WG telecon on Thursday, 21 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-06-14 meeting
  • Meeting wrangling
    • Thomas running call; need note-taker?
    • No meeting next week due to US holiday
  • Feature test-fest progress and other AI review
  • Review and discuss Kevin's enterprise-related FAQs
  • Spec/issues review
    • #20: Only discuss if we have new input related to OIC/Street Identity/etc.
    • #56: Standardized scope descriptions for well-known APIs?
    • #58: Specify how to write UMA profiles?
  • AOB

Minutes

Roll call

Quorum was reached.

Approve minutes of 2012-06-14 meeting

Minutes of 2012-06-14 meeting APPROVED.

Feature test-fest progress and other AI review

  • Trey already completed a feature test strawman for Section 3 of the spec. He'll continue working on it.
    Participant and solution entries for SMART have been completed on the OSIS wiki.
  • Contact with Tom Brown has been made. Will be discussing discovery work with him.
  • Thomas hasn't yet updated Section 3.1.1 of the spec.
  • Thomas has posted the use case from MIT Media Lab to the list.
  • Kevin has already sent his input for the FAQ to Eve.

Issue #20 discussion

Maciej: In SMART-AM the resources are known already. Current version of SMART-AM has no Discovery feature. Host refers/redirects Requestor to the AM.

Trey: Carriers and Providers scenario: In this space the resources are already known by AM. In fact the AM and Host are operated by the same entity, so they are aware of the resources already.

Thomas: In the Enterprise scenario, the resources are typically controlled by the same entity operating AM (both internal). Asks if there are any consumer-oriented scenarios where the resources are known in advance.

Issue #56 discussion: standardized scope descriptions for well-known APIs?

Trey: Yes it would be good to have profiles (for standardized scopes). Mentions efforts in SCIM, where entitlements are expressed in the XACML syntax. Resources access via URI. Example is Google gcal which uses URIs to pass on scopes: get URI (not token). Provides a path to a "thing" (URN) plus "action" (eg. view, delete, etc). Trey likes XACML for its good syntax but it's heavy processing on  the back end. Choice seems to be opaque-tokens vs. point-to-something. Wish there was a middle way. Thomas mentions policy-identification used in PKIX via policy-oids, but same degree of processing needed in the back end (server-side). Trey suggests that it would be good to have one or two profiles for scopes: URIs and schema for XACML statements.

Lukasz: Only has an example for collaborative hosts. Want to propose a simple namespace. Thomas says OAUTH WG did not want to address/use name-spaces (ala SAML), but that any solution using scopes will end up using namespaces. Trey agrees.

Issue #58 discussion: specify how to write UMA profiles?

- Trey: Yes profiles make sense. Profiles can incorporate operational experience of specific businesses (eg. carrier industry). Makes the case real. For carries business, UMA is one part of the service. May donate back profile to the UMA WG.

Kevin: Thomas asks of Kevin has a Australian Federal Government scenario. Kevin says the Australian Federal Government has no interest in UMA per se, but in the larger issues like privacy and consent. They would like to be able to make money out of it: to provide paid access to users, where users pay on a per-access basis. Thomas asks about banks like CBA and Westpac in Australia. Kevin mentions that banks want to share data but do not want to show origin of the data: They want to share customer data with each other. But they don't want to show which bank has which customer. Kevin says this is a 2-way thing: data should be shared-ownership between customer and bank.

Trey: Carriers are interested in UMA more for capturing consent of the user (not so much sharing of data). Customers can still withdraw consent. Carriers possess data already. They run both RS/OAuth and AM/UMA. Over time data in RA (RS?) has grown. They want to make $$ or share data about customer. Therefore want to use UMA to build "perimeter" around  this data and the distribution of data. Hard problem is policy scheme for such a scenario.

Sal: Sees the need for UMA profiles. Need a mechanism for authorization to allow the sharing/exchange of data. Sal asks if anyone is seeing IdP use-case? Trey mentions he is working on RP side, so not needing verification of identity. From UMA side, there is little difference if you are an IdP or RP. The only difference could be whether or not you have "assured identity". Example:  AT&T acts as an IdP and RP: It already knows who you are (has assured identity). But it wants explicit user-consent via UMA.

Attendees

As of 15 June 2012, quorum is 5 of 9.

Voting participants:

  1. Catalano, Domenico
  2. D'Agostino, Salvatore
  3. Drake, Trey
  4. Hardjono, Thomas
  5. Machulak, Maciej
  6. Moren, Lukasz

Non-voting participants:

  • Cox, Kevin

Next Meetings

  • WG telecon on Thursday, 28 June 2012, at 9am PT (time chart)
  • NO TELECON on Thursday, 5 July 2012