/
UMA telecon 2010-01-21

UMA telecon 2010-01-21

Owned by Former user (Deleted)
Last updated: Jan 22, 2010Version comment

UMA telecon 2010-01-14

Date and Time

  • Day: Thursday, 21 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)

Attendees

As of 12 Jan 2010, quorum is 9 of 17.

  1. Adams, Trent
  2. Akram, Hasan
  3. Bryan, Paul
  4. Catalano, Domenico
  5. Fletcher, George
  6. Holodnik, Tom
  7. Lizar, Mark
  8. Machulak, Maciej
  9. Maler, Eve
  10. Smith, Bill

Regrets:

  • Joe Andrieu

Agenda

Minutes

Roll call

Quorum reached.

Approve minutes of UMA telecon 2010-01-14

Motion to accept minutes APPROVED.

Action item review

2009-10-15-3 is closed.
2009-12-10-06 is OBE.
2009-12-17-2 is closed.
2010-01-14-1 is closed.
2010-01-14-4 is closed.

New AIs:

2010-01-21-1

Eve

Open

Put hData scenario in Scenario document.

 

2010-01-21-2

Webinar team

Open

Flesh out the slides and merge the PDFs and upload the resulting file.

 

2010-01-21-3

Webinar team

Open

Register for the webinar.

 

2010-01-21-4

Eve

Open

Reach out to legal contacts to research the question of requesting users vs. other requesting intermediaries when it comes to terms negotiation.

 

Webinar planning and review of presentation materials

We reviewed the draft sent this morning, slide by slide. The next draft will include many wording suggestions made on the call and edited directly into the document.

Discuss our input to the OAuth process

We need to delay our submitting of the email a bit. The first OAuth telecon will be held today.

Spec review

The spec needs a typographical fix; we have two instances of Step 1b.

We are currently relying heavily not only on OAuth (which is having V2.0 throes) but also XRD (not settled yet but getting closer) and LRDD (very much not fully baked). We should treat our draft spec as a bearer of use cases for all of these, not just OAuth all by itself; wherever we have to profile or extend one, presumably this will be good input for those working on it. If XRD, and LRDD in particular, don't get settled before we have to do strawman implementations, there will probably be some mismatches around this. E.g., common webfinger implementations use an old version of XRD.

The hData scenario, now sent to the list (but not yet incorporated into the scenario document), has a diagram that illustrates how UMA could be used to protect a metadata endpoint, both against parties that want to add their own entries and against parties that want to be given a set of metadata to find the resources of other parties. Eve and Paul have talked with John Bradley a little bit about this, and George has separately done so as well. Perhaps we'll end up having an "UMA profile of XRD" for trusted XRD discovery and population, as well as profiling XRD in UMA for UMA's own flows.

Steps 5 and 6 are the newest pieces here. Step 5 lets the requester find out the requirements for obtaining resource access authorization. The requester indicates the format of claims they're prepared to respond with; it could be IMI-style, or anything else.

George asks: Who is the "consumer" here, given that a consumer key has been supplied in the example? Paul: The consumer key was publicly supplied, so it could nominally be seen as "three-legged" but really it's a two-legged flow. The token here establishes a shared secret (durable identifier) for further negotiation. Proving anything about the "subject behind the requester endpoint" (around which we still have an ongoing conceptual discussion) is not the job of the OAuth layer, but rather the claims layer.

The parties trying to come to terms, when there's a requesting person Bob who is trying to use (say) Google to access Alice's resource hosted on (say) Yahoo, are the requesting person and the authorizing person. So Paul's position is: The only party Alice can hold accountable for Bob's access of the resource is the end of the line: the requesting person. Thus, any promises Alice wants made should be made by Bob. Bob can perhaps make claims about the infrastructure he's using, but there could be arbitrary layers of infrastructure, and he may not even be aware of some of them. Google could outsource certain jobs to other cloud providers, and so on.

Paul explains that the idea of caching authorization decisions is an optimization that hosts can use, and in similar fashion, requesters don't need to keep providing the same claims. The cycle of claims-requesting might go back and forth a bit, to allow the AM to ask for further claims based on the initial claims received. But once the requester has jumped through all these hopes, they can reuse the authorization token thus established.

Eve wonders if requesting intermediary is a good phrase for the possibly arbitrary (nested, chained) numbers of parties in between the requester endpoint and any requesting user.

Implementation news

Newcastle University will be hiring a full-time software developer for 15 months to support UMA protocol implementation! The goals will be to work on higher-education use cases, and to run an AM at Newcastle. Eve has appointed Maciej "implementation coordinator" for keeping track of all of our implementation and interop efforts.

Details on next F2F meeting

We're meeting in Portland, OR on March 9 and 10. Don't forget to register! In addition to others already identified, Tom H. believes he can attend.

Next Meeting: UMA telecon 2010-01-28

  • Day: Thursday, 28 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)