View Source

UMA telecon 2009-12-03

Date and Time

• Day: Thursday, 3 Dec 2009
• 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

Voting participants:

1. Adams, Trent
2. Bryan, Paul
3. Carroll, Tom
4. Catalano, Domenico
5. Davis, Peter
6. Fletcher, George
7. Holodnik, Tom
8. Machulak, Maciej
9. Maler, Eve
10. Stollman, Jeff

Non-voting participants:

• Wilcox, Mark
• Hogberg, Jonas
• Lizar, Mark

Guests:

• Joni Brennan (staff)

Regrets:

• Christian Scholz
• Hasan Akram

Agenda

• Administrative
  • Roll call
  • Approve minutes of UMA F2F 2009-11-02, UMA telecon 2009-11-12, and UMA telecon 2009-11-19
  • Action item review
  • Discussion of spring/summer opportunities for F2F meetings and interops
• Terms negotiation (see email proposals: Eve's, Paul's)
  • Minimum scenarios to achieve victory
  • Proposal for claims-based mechanism to handle them
• General spec wrangling
• Build scenario review calendar
• AOB

Minutes

Administrative

Roll call

Quorum reached.

New process rule: Eve will check for new attendees at agenda item boundaries, to keep interruptions to a minimum.

Approve minutes of UMA F2F 2009-11-02, UMA telecon 2009-11-12, and UMA telecon 2009-11-19

Motion to approve the minutes from all of November 2009 APPROVED.

Action item review

Discussion of spring/summer opportunities for F2F meetings and interops

Eve, Peter, and Tom H. may be at the Catalyst NA event.

Is there interest in participating in an interop demo event? It depends on the timing; several event options are listed on the wiki. We did secure a commitment of $4000 in the Kantara 2010 budget for the purpose of offering a bounty to develop a hosted validator; it seems we might be ready to work on that by March.

Peter's company is working on a mobile-based AM prototype, likely to be ready for testing by the July timeframe. Paul B. will work on Host endpoint support, with wraparound filters that can do the policy enforcement point. OpenSSO uses this "wrapping" pattern for ease of deployment, e.g., with a reverse proxy, and this seems to be a good approach.

Terms negotiation (see email proposals: Eve's, Paul's)

• Minimum scenarios to achieve victory
• Proposal for claims-based mechanism to handle them

Eve's goal is to carefully balance the added complexity with the mimimum interesting value-add of user-managed terms negotiation. Her proposal examined the brainstormed scenarios we collected in the November F2F and picked among them.

Paul's proposal grew out of his initial idea of using the information card model for expressing claims required and claims presented. Complexity is an enemy again here. He tried to solve for a fairly large set of scenarios, including a classic one about achieving minimal disclosure of people's age information: "over 18" is better than "birth date of x/y/z". Other examples revolve around asking for payments of X amount, or including a transaction ID in the challenge that must appear in the response, or specifying maximum data retention periods.

This led to a perceived need for parameterization. Using static claim types seems not to work; there would be an explosion of claim types. Eve and Paul talked to Drummond Reed (executive director of the ICF) about this, and he agreed this is a sore point in the claims-handling model of cards.

In looking around at other options, Paul analyzed SAML's attribute query syntax, and the new SWT (simple web token) format for WRAP. None of these other options met his requirements; SAML2 is great for expressing claims and it's relatively efficient format – but it has perception baggage and some processing baggage. So he has proposed "Claims 2.0", a JSON-based approach that is likely to be useful to other communities as well as our own. Dick Hardt has signaled that he is working on a "JWT" format, but that's not in public yet.

We want the UMA protocol to be agnostic as to the format for claims required and presented. So if someone wants to use something like SAML, that should be fine too. HTTP content type negotiation can manage multiple ways to express claims. However, we'll need a mandatory minimum claims protocol for interoperability. Similarly, CardSpace originally mandated SAML V1.1 while allowing other formats, and as a result that's become the strong default (with SAML2 getting more play very recently).

Peter: We could model multiple representations, not just one. Why not have a normative SAML representation with a normative XSLT transformation into forms like JSON? While his implementation work is very early-stage, it's fair to say that it's on an XML encoding basis.

Mark: Take a look at OData. If we think the processing happens in a browser, JSON is a good choice. If it's a server-side process, then libraries are available. SAML might be the right fabric.

Paul: In recent times he's been influenced strongly by projects like Apache's CouchDB. Lots of data structures are coming out of the woodwork for different applications. XML is indeed more mature, and libraries are available.

George: Are filters needed for the Requester-side? Rich desktop apps, web servers, and enterprise apps are likeliest to be in the position of functioning as Requesters. Paul: Perl and Python apps are likely to find it easier to work with JSON.

Mark: The gnarly thing about SAML isn't so much the XML part, but canonicalizing it and signing it! Paul: Agreed. The WRAP list got into this issue for JSON-based formats. George: Sounds like the solution needed is the SAML SimpleSign binding! Paul: You'd need rules for JSON canonicalization, which do exist. George: The XRD group has been circling on this too; at first they thought the XRD should be signed as a blog, but now they're back to more of an XML Signature approach. If UMA parties are having to handle XML Signature for XRD trust party handling, they'll already know how to do this.

Eve: We need to get direct feedback from some parties that would serve as requesters. Today's OAuth consumers make good proxies for this. George: Also, getting someone involved in Shindig is good.

George: So how does WRAP convey to the client that it has to interact with both the protected resource and the AS (token issuer)? It doesn't seem to be covered in the spec; maybe it's a well-known location? Paul: Or maybe it could be done through LRDD. In UMA, it's explicit by way of referral. Hadn't thought of the idea that the host would be able to dynamically discover the user's desired AM, however; we had planned for explicit user introduction.

Eve: Until we get more input from people representing requesters, should we take Paul's current proposal as a strawman? Paul: We should make it a separate modular spec. And there's an argument to be made for pushing a common signing solution across all of JSON usage, not just for UMA or WRAP purposes.

General spec wrangling

Paul analyzed WRAP a lot more closely in the last couple of weeks. An issue it doesn't address (something we were already aware of) is scoping the access token. If a WRAP client needs to ask for access to a Protected Resource at the Authorization Server, it needs to scope it in some reasonable way in order to get a token that will work. If WRAP "replaces" OAuth, this isn't as big an issue. But if you try and use WRAP to satisfy UMA use cases, it's significant. Our authorization resource on the AM is our mechanism for this, at the "cost" of not allowing the UMA AM to hand an opaque token to the UMA Requester to just convey over to the UMA Host.

Once we got completely out of the authentication business, we bought some heaviness around discovery and referral. It's tempting to get back into the business for efficiency's/optimization's sake, and in fact, that's exactly what WRAP has done.

Build scenario review calendar

Maciej has posted a couple of new scenarios!

• Delegating access to a custodian

Some of the examples provided involved an underage person delegating access to an adult guardian.

• Moving resources

This is a kind of Data Portability scenario, involving easily applying the same policies again.

Eve will put a higher priority on working through disposition of scenarios.

Themes for the next telecon

• Scenario disposition
• Fleshing out the rest of the core-protocol and claims-handling strawmen
• Input from likely requester parties

In the meantime, keep those cards and letters coming on the email list!

New AI summary

Next Meeting: UMA telecon 2009-12-10

• Day: Thursday, 10 Dec 2009
• 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)