UMA telecon 2010-04-08

Owned by Former user (Deleted)
Last updated: Apr 14, 2010Version comment

UMA telecon 2010-04-08

Date and Time

  • Day: Thursday, 8 Apr 2010
  • Time: 9:00am-10:30am PST | 12:00-1:30pm EST | 16:00-17:30 UTC (time chart)
  • Dial-In:
    • Skype: +9900827042954214
    • US: +1-201-793-9022 | Room Code: 295-4214 (other local country numbers available on request)

Agenda

  • Roll call
  • Approve minutes of 2010-03-25 and 2010-04-01 meetings
  • Action item review
  • Protocol issues review
    • Compliance with OAuth 2.0: UMA spec revision plans
    • Token validation: input to OAuth group? any firm decisions?
    • Scope: input to OAuth group?
    • Signing: new thoughts?
    • Refresh tokens: close out this issue?
    • Any others we have time for
  • AOB

Attendees

As of 7 Apr 2010, quorum is 6 of 11.

  1. Adams, Trent
  2. Armstrong, Brian
  3. Bryan, Paul
  4. Catalano, Domenico
  5. Fletcher, George
  6. Holodnik, Tom
  7. Machulak, Maciej
  8. Maler, Eve
  9. Moren, Lukasz

Non-voting participants:

  • Mark Lizar

Minutes

New AI summary

  • Eve to turn Paul's "claims 2.0" proposal into a draft spec.
  • TomH to revise the tax scenario for inclusion in the Scenarios document.

Roll call

Quorum was reached.

Lukasz is a software developer working on UMA at Newcastle University. During the last Google Summer of Code he worked on JBoss.

Approve minutes of 2010-03-25 and 2010-04-01 meetings

Minutes of 2010-03-25 and 2010-04-01 meetings APPROVED.

Action item review

  • 2009-12-03-04 Eve Open Add terms-negotiation scenarios to Scenarios document.
  • 2010-03-10-2 Maciej Open Do next round of spec editing. See below.
  • 2010-03-10-6 Joe Open Revise the protected inbox scenario for next week's call.
  • 2010-03-18-3 TomH Open Flesh out the small-business scenarios, including any distinctive aspects around claims etc. Now closed, and he has a new follow-on AI.
  • 2010-03-25-1 Paul/TomH Open Send email giving examples of how a resource-oriented scope approach is necessary.
  • 2010-04-01-2 Eve Open Consult with Domenico about lexicon diagram changes.
  • 2010-04-01-3 Eve Open Create a new technical report draft on legal considerations in UMA authorization scenarios.

Compliance with OAuth 2.0 issue

Eve is advocating that we immediately move onto an OAuth 2.0 draft basis, and try to keep up with any changes weekly if possible. Maciej will prepare some initial thoughts, and Eve will meet with him next Monday at 8am PT to discuss them.

Identity token issue

George notes that his notion of an identity token could take the form of a third-party claim about a user's identifier. It currently plays into the UMA flow where some requesting user Bob needs to prove to the authorizing user Alice's AM who he is. Can this be a bearer token, or does it need to be a holder-of-key token, or what? If Alice has set up an access control list at the AM that has an entry on it for Bob, someone getting hold of a bearer token of Bob's could impersonate him.

Eve would like to see us work on our "claims 2.0" stuff in modular spec form. George, Paul, and Tom express interest. We may be able to leverage John Panzer's "magic signature" work as part of this.

George reports that Joseph Smarr from Google is going to be chairing a WG at the OpenID Foundation around attribute schemas (that is, the semantics of claims), which could be relevant to the general proposition of solving "claims 2.0", under which the identity token issue falls. Joseph is likely to lean on the Portable Contacts API for the attribute schema work. But our biggest concern is how to protect an attribute in its encoded form as it flows through all these protocols, rather than getting specific about all of the kinds of attribute information that could be passed around. Maybe our two efforts can complement each other.

Can we partner with the OpenID folks on claims 2.0? Let's approach the wider community once we have a strawman spec we can point them to.

Discovery issue

Tom observes that in OAuth, there's a callback URL that a host (in our terminology) would send back to the requester. Our AM has to know the collection of policies and claims associated with that resource. Either the authorizing user has configured these directly into the AM, or perhaps the host may natively have some of that knowledge itself. He sent out thoughts on this, including a scenario related to tax data where we might need some discovery of that data at the host.

Paul describes some of the thoughts we had in the early ProtectServe days, which touch on usability issues because ordinary people are going to want to manage resource protection in a user-friendly way, not by dealing with URLs. He asks for more concrete requirements around tax liability and regulations that can help focus us. Tom's sample "TaxMonkey.com" would have to adhere to IRS rules, and conduct an opt-in process in a manner described by the IRS. Could the opt-in happen indirectly, at the CopMonkey AM instead? The IRS probably doesn't have an opinion on this yet! Since we have a design principle to move complexity to the AM, it sounds like we should prefer it in this case if we can.

Tom had originally wanted to work on a payroll scenario, "which is like tax, but much worse." (smile) So for now he'll just work further on the tax scenario. He's willing to accept some pushback on the more enterprise-y aspects of his use cases. Eve supports the notion of figuring out where our 1.0 boundaries are, and learning what may be in our "backlog" for future versions.

Modularity issue

Eve had wondered whether some of the profiles of, and extensions to, WRAP (soon to be extensions to OAuth 2.0) that we are defining should be in separate specs, vs. all being in a single UMA core protocol spec. This may hinge on wider (non-UMAnitarian) community interest. For example, the host-AM introduction flow, and any attendant implications for our step 3, may want to be packaged separately. And the claims-required flow may be good as a separate piece.

Paul notes that we're already going to have a claim format spec, so there are at least two specs we'll be working on. "We don't need to rearrange furniture when the house isn't finished yet." So he advises to keep our core protocol spec in one piece for now, and if strong interest is expressed in just one separable piece of it, we can consider breaking it out at any time. This seems reasonable.

Tom expresses an interest in the claims-required piece apart from the dynamic-introduction piece. It's a big step to give users truly full control of their own tax data, since there's a lot of regulation around security policy of the service providers (vs. the users). Further, how does dynamic introduction work when the user wants to switch AMs? Eve hopes we eventually have a vibrant enough ecosystem to allow for this!

Refresh tokens issue

Paul proposed on the list that we should simply silently reuse the refresh token flow whenever the parties choose to use it. The refresh token is analogous to the persistent relationship that the requester has with the AM. The thing that needs to persist (and be well-protected) is the refresh token, if it was issued. If any claims associated with that refresh token are still good, then great.

What happens in the case where one of a dozen claims that backed up a token expires? The AM could invalidate the refresh token and make the requester come back to supply that one claim, or all the others in addition, etc. In this case, what's easiest for the requester? Maybe just to supply them all again. Or maybe any use case with a dozen claims required is already not in the Internet-scale set of use cases.

It sounds like we're happy with keeping the claims-required flow where it is, prior to initial access token/refresh token issuance.

Motion to accept Paul's recommendation on protocol issue on refresh tokens APPROVED.

Signing issue

Eve floated an idea she'd heard where (describing it in OAuth terms) a singular authorization/resource server issues credentials to a client, good for use only at that server, that must be used to sign the access token (or, at least, sign something in the access-request message – doesn't have to be the whole message since it's not for integrity-in-transit purposes) when it's presented to the resource server. This seems to be somehow related to both (a) the OAuth redelegation proposals (Vrancken, Twitter OAuth Echo) that have been floating around and (b) the "third signing use case", where the point is to have more-specific identification of the client.

We're not currently clear on the exact value of this. Looks like those of us who care about this issue need to do more reading/homework.

Next Meeting: UMA telecon 2010-04-15

  • Day: Thursday, 8 Apr 2010
  • Time: 9:00am-10:30am PST | 12:00-1:30pm EST | 16:00-17:30 UTC (time chart)
  • Dial-In:
    • Skype: +9900827042954214
    • US: +1-201-793-9022 | Room Code: 295-4214 (other local country numbers available on request)