UMA telecon 2010-06-03

Owned by Former user (Deleted)
Last updated: Jun 03, 2010Version comment
6 min read

UMA telecon 2010-06-03

Date and Time

  • Thursday, 3 Jun 2010 at 9:00am-10:30am PT (time chart)
    • Skype: +9900827042954214
    • US: +1-201-793-9022 | Room Code: 295-4214

Agenda

  • Administrative
  • Step 1 review
    • User stories
    • Discovery and dynamic association mechanism
    • Prototyping
  • Claims trust model review
  • AOB

Attendees

As of 3 Jun 2010 (pre-meeting), quorum is 6 of 11.

  1. Catalano, Domenico
  2. Gamby, Randall
  3. Hardjono, Thomas
  4. Holodnik, Tom
  5. Machulak, Maciej
  6. Maler, Eve
  7. Moren, Lukasz
  8. Scholz, Christian

Thomas became a voting member on this call.

Non-voting participants:

  • Gerry Gebel
  • Joe Andrieu
  • Mark Lizar

Guests:

  • Anna Ticktin (staff)

Minutes

Roll call

Quorum was reached.

Approve minutes of 2010-05-27 meeting

Minutes of 2010-05-27 meeting APPROVED.

Review nominations for spec editor and take action as appropriate

Ideally, the spec editor would take an active role in pushing the core protocol spec forward on both a substantive and an editorial level. This would include things like:

  • Accepting some action items that involve research and recommendation (like the one Christian took on the last call)
  • Keeping the core spec up to date in matching the latest drafts of OAuth, host-meta, and any other volatile specs we reference
  • Adding HTTP request and response examples (ideally for every testable spec assertion that demands one)
  • Attending telecons on a fairly regular basis, and possibly being available for occasional "focus calls" and scheduled IRC chats

This can all be done with a maximum of 5 hours a week, but there are a lot of factors affecting the estimate.

Nominations are still open, and we'll continue having ad hoc spec editing.

Action item review

  • 2009-12-03-4 Eve Open Add terms-negotiation scenarios to Scenarios document.
  • 2010-03-10-6 Joe Open Revise the protected inbox scenario for next week's call. Joe will prioritize this higher.
  • 2010-04-08-2 TomH Open Revise the tax scenario for inclusion in the Scenarios document. Now done.
  • 2010-05-13-3 Christian Open Spec out a "requester metadata" flow. Still open.
  • 2010-05-27-2 Eve Closed Record all open issues on the wiki. Now done.
  • 2010-05-27-3 Eve Open Find and distribute info on the new proposal for OAuth signing.
  • 2010-05-27-4 Eve Pending Ask Dave Crocker for help with Step 1 user stories.
  • 2010-05-27-5 Christian Open Recommend a solution for discovery, dynamic association, and host metadata for Step 1. Now closed; we'll discuss today.

Step 1 review

We walked through the versions of the spec and commented.

Intro: We think the dynamic association substep is optional in the case where the host has preregistered with the AM. And we think the web server flow is the only option among the OAuth flows in our step 1, because the authorizing user is a human being (and because it doesn't seem to make sense to use the JavaScript flow!).

Substep 1a: The claims format and access token format stuff is used in later steps, so it's "todo" for now.

Substep 1b: The "resource registration API" is a host-specific endpoint at the AM that the host needs to use its host access token to get to. (This endpoint is meant for letting the host push a data structure representing the resources belonging to this authorizing user that the AM is supposed to be protecting.) Christian is proposing that the AM provide this endpoint information at the same time as dynamically giving the host its unique client credentials, just for protocol optimization purposes. The theory is that the AM might want to give each host its own unique endpoint for this purpose, so that it can't be provided in the hostmeta.

(We sort of had this idea in the old versions of ProtectServe and UMA, except that we were using lots and lots of XRDs and had the client side "pull" unique endpoints rather than having them "pushed".)

We believe the host would have to access the resource registration endpoint through its host access token, which is another thing that would identify the host – but in the context of the specific user, not generically with respect to that host. We think it would indeed be useful to have pairwise AM:host client credentials that are reusable across users. We should capture the question as an issue in the spec.

Tom's experience working on TaxMonkey seemed to show that substep 1d (actual registration of resources) might require the host to supply claims to the AM to substantiate its right to have this relationship with the AM. Eve wonders: Can an UMA profiling of some OAuth flow (that we haven't yet defined in Step 2 for requesters) be applied in substep 1c, to allow claims to flow? Tom observes that it gets kind of confusing to figure out who the host is representing and whether this is some kind of autonomous client flow layered on top of of user delegation flow. He agrees that it would be idea to reuse a solution we already have rather than make a special exception, but either way it's complicated.

Christian has borrowed the approximate solution that is proposed in OpenID Connect for dynamic association. Basically it's a new type of OAuth flow in which the client can be handed a new unique client_id and client_secret. We differ from that proposal in inventing a new endpoint, since what's being returned is primary credentials rather than an access token (so they're overloading the OAuth token endpoint).

Denial-of-service attacks could be a problem for the AM, in which case perhaps it could employ a "proof of work" solution to mitigate the problem.

Christian is going to continue revising this substep, including describing the possibility of the host approaching the AM outside the Step 1 UMA flow. In fact, what if dynamic association gets sufficiently defined outside of UMA so that we can point to it? We'd have to profile it to add the resource registration endpoint, though, which is unfortunate. Or we could live with non-host-specific resource registration URLs. This is an open question, but for now we'll continue to define dynamic association the way we want it.

Substep 1d: The actual resource registration API is extremely simple for now. Christian currently conceives of this as a very simple way to POST (push) resource information, but we could get much more sophisticated (meaning "complex"!) here. The OAuth 2.0 work is struggling with the question of resource access scope, which could be helped by a solution here. Could wildcards play a part here, the way we've begun to use them in our nascent scope solution in Steps 2 and 3? We need to refine this more as we push further through the spec.

TaxMonkey scenario

Tom is trying to figure out real business situations in which a user has to establish that they're disclosing their resources to the right party. The user might want to set policy around length of access (e.g., "once" or "up to a certain date" and be able to revoke access at will). In this scenario, Alice is a U.S. taxpayer, and Bob is a financial aid administrator. How can she be sure she's giving access to her TaxMonkey tax return data to "Bob" at Big State U., or alternatively to "the financial aid office" at Big State U.? IRA Rule 7216 governs opt-in processes for taxpayers to let tax preparers access their tax data. The rule requires that the duration of consent be indicated in the consent process.

In an OAuth world, the 7216 requirements are actually pretty consistent with what TaxMonkey (as both resource server and authorization server) could present to Alice regarding consent forms. In an UMA world, how does TaxMonkey delegate to CopMonkey the responsibility to manage 7216 requirements? Would 7216-specific policies be needed at CopMonkey? Would CopMonkey have to be a "whitelisted" or otherwise preapproved AM from TaxMonkey's perspective?

Perhaps the host can trust the (special, 7216-compliant) AM through a number of mechanisms related to discovery and metadata. The AM might publish in its hostmeta some signed certifications, and/or a third-party trust framework might have a list of trusted certified parties that you can consult.

Randall notes that the electronic health record scenarios he's seen need a way for a user to authorize a doctor to get data from particular hospitals (vs. others), for particular lengths of time. So there are strong parallels between tax and health scenarios.

Claims trust model review

We continue to defer this, but hopefully not for much longer, as our Step 1 work starts to encroach on Step 2. People should respond on the list with their thoughts.

Christian will try to get his prototype updated to the latest draft work.

Next Meetings

  • UMA Legal telecon led by Mark Lizar on Monday, 7 Jun 2010 at 11am-noon PT (time chart)
    • Skype: +9900827042954214
    • US: +1-201-793-9022 | Room Code: 295-4214
  • UMA WG telecon led by Maciej Machulak on Thursday, 10 Jun 2010 at 9-10:30am PT (time chart)
    • Skype: +9900827042954214
    • US: +1-201-793-9022 | Room Code: 295-4214

See the UMA calendar for details of future meetings.