UMA telecon 2010-01-07
| Table of Contents | ||||||
|---|---|---|---|---|---|---|
|
Date and Time
- Day: Thursday, 7 Jan 2010
- Time: 9:00-10:30am PST | 12:00-1:30pm EST | 17:00-18:30 UTC (time chart)
- Dial-In:
- Skype: +9900827042954214
- US: +1-201-793-9022 | Room Code: 295-4214 (other local country numbers available on request)
...
- Tom Holodnik
- Iain Henderson
Agenda
- Administrative
- Roll call
- Approve minutes of UMA telecon 2009-12-17
- Action item review
- Note: OAuth V2.0 telecons beginning soon
- Webinar planning: time slot, publicity, technologies
- Review and approve/defer/reject scenarios and use cases
- E-commerce
- Terms negotiation scenario discussions
- What new scenarios are in the pipeline? How to prioritize review during this month?
- Spec review and futures
- Claims format
- Core spec
- AOB
Minutes
Roll call
Quorum not achieved. It's time for Eve to do another round of making some participants non-voting.
Approve minutes of UMA telecon 2009-12-17
Deferred due to lack of quorum.
Action item review
- 2009-10-15-3 Gerry Open Write an hData scenario for the Scenario document. Likely to be submitted soon; Eve has been working with Gerry on this.
- 2009-12-10-06 Paul B. and Mike Open Provide email comments on Domenico's graphics Please do this...
...
Webinar team/WG | Open | Publicize the webinar through blogging, tweeting, etc. |
|
Joe | Open | Submit a protected-inbox scenario. |
|
Eve | Open | Revise the e-commerce scenario based on 2010-01-07 comments. |
|
Eve | Open | Mail out scenario text for people's review before next week. |
|
Paul | Open | Revise the UMA swimlane diagrams. |
|
Webinar planning: time slot, publicity, technologies
...
We need to use a webinar system that accommodates Paul's and Eve's computer systems, which means Windows-based solutions are out. Our current plan is to use the WebEx option Kantara has made available to us, and record the presentation. Joni notes that she's had a good consistent experience with it over the last three years.
E-commerce scenario discussion
Mark and Joe commented that, if Maya has a relationship manager that can itself be a recipient of messages from vendors such as "There's a recall on the slow cooker you bought because of a manufacturing defect, and your slow cooker may blow up", then Maya doesn't have to release any other communications endpoints to them. She could then check her relationship manager (personal datastore?) for "inbox messages" such as this coming from vendors. This inbox, just like any other UMA-protected resource, could be made available on a permissioned basis to particular vendors. (This would avoid "spam".)
...