Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migration of unmigrated content due to installation of a new plugin

UMA telecon 2010-07-22

Table of Contents
maxLevel4
minLevel3maxLevel4

Date and Time

  • WG telecon on Thursday, 22 Jul 2010, at 9-10:30am PT (time chart)
    • Skype line "C": +9900827042954214
    • US: +1-201-793-9022 | Room Code: 295-4214

...

  • Administrative
  • Dynamic registration I-D (formatted, source)
    • Aim to make final decisions in this meeting
    • Push vs. pull vs. both vs. merged: What UMA-specific input (e.g. around trusted claims) do we need to provide to help the OAuth group decide?
    • Section on pushing metadata directly: moved?
    • New section on extensibility: written?
    • Include proposal for solution for dynamic binding of user-agent clients?
    • Any other outstanding issues?
  • Resource Registration specifics (existing proposal)
    • New SMART draft?
    • How close to I-D form?
    • Walk through major issues and list decision-points
  • AOB

...

  • Christian Scholz
  • Kevin Cox

Minutes

New AI summary

2010-07-22-1

Maciej

Open

Update RRAPI proposal and provide related info.

 

2010-07-22-2

Eve

Open

Edit dynamic registration draft.

 

2010-07-22-3

Eve

Open

Confirm with focus subgroup whether to have a meeting next Wednesday.

 

Roll call

Quorum was reached.

Approve minutes of 2010-07-15 meeting

Minutes of 2010-07-15 meeting APPROVED, with correction to Tom Holodnik's attendance status.

...

Further, Eve suggests that since we're applying our own UMA design principles in discussing this, such as simplicity and others (DP1), we should mention those in this document. Even if we explore multiple registration flows, we might want to recommend that the OAuth group pick a single one, or as few as possible.

...

If we stick to the pull model for the RRAPI, then, it sounds like it's consistent both with users' expectations and with requirements to avoid the server propagation problem. The SMART approach has been to implement "bidirectional OAuth", where the host can lodge a token with the AM that the latter can then use at a protected endpoint at the host. (Wow.) Maciej will share more info on this soon. It adds one additional simple HTTP call.

Next Meetings

  • Stay tuned on whether we'll hold a focus subgroup meeting on Wednesday, 28 Jul 2010.
  • WG telecon on Thursday, 29 Jul 2010, at 9-10:30am PT (time chart)