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

...

• 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.

...

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.

...

Tom had originally wanted to work on a payroll scenario, "which is like tax, but much worse." 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.

...

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.

...

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.

...