UMA telecon 2009-10-29

Date and Time

NOTE: Please check your local time carefully! It may have temporarily changed due to differential application of seasonal time changes. The U.S. Pacific time zone is "normative".

• Day: Thursday, 29 Oct 2009
• Time: 9:00-10:30am PDT | 12:00-1:30pm EDT | 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)

Attendees

Voting participants:

1. Adams, Trent
2. Akram, Hasan
3. Bryan, Paul
4. Catalano, Domenico
5. Davis, Peter
6. Fletcher, George
7. Hanson, Michael
8. Henderson, Iain
9. Machulak, Maciej
10. Maler, Eve
11. Smith, Bill
12. Stollman, Jeff
13. Urban, Joseph

Guests:

• Joni Brennan

Regrets

• Christian Scholz
• Jonas Hogberg
• Gerald Beuchelt
• Joe Andrieu

Agenda

• Roll call
• Approve minutes of UMA telecon 2009-10-15 and UMA telecon 2009-10-22
• Action item review
• Spec progress and review
  • Latest flow example was sent in email
• Scenario review (docket)
  • Formally accept/reject aspects of the requester delegate scenario
• UMA F2F 2009-11-02 planning
  • Hold a telecon on 2009-11-05, or forego it due to the F2F, IIW, etc.?
• AOB

Minutes

Roll call

Quorum was reached.

Joe Urban is based in SF. He consults for Cisco Systems. He's been involved in developing their access control capabilities, and more recently business intelligence. He has been developing some technologies that seem relevant to the UMA mix.

Approve minutes of UMA telecon 2009-10-15 and UMA telecon 2009-10-22

Motion to approve both sets of meeting minutes APPROVED.

Action item review

• 2009-10-08-2 Eve Pending Check with Nat to see if we can start an every-fourth-week meeting time change on Oct 15. (Checked again with no response.)
• 2009-10-15-2 Eve Open Write a "Hey, Sailor" scenario to illuminate the needs around Requesters that ask for resource access without the User expecting them. (Still open.)
• 2009-10-15-3 Gerry Open Write an hData scenario for the Scenario document. (Still open.)
• 2009-10-22-1 Eve Closed Follow up with George on understanding the ongoing token-issuer discussions and contributing to them in the IIW timeframe.
• 2009-10-22-2 Paul Closed Provide a breadth-first fledgling "example appendix" for 2009-10-29.
• 2009-10-22-3 Christian Open Write up a proposal as discussed on his previous call with Paul and Eve. (Still open.)

Spec progress and review

• Latest flow example was sent in email

Now the proposal fleshes out some of the steps after the host registers with the AM. The requester is now in the picture (though not fully yet).

Originally, our protocol sketch had the requester hitting the resource, realizing it's UMA-protected, and then going over to the AM (by virtue of metadata it was given) to register, get terms, etc. When approaching the host again, the requester would have credentials signed by the AM, which the host could check. A problem with this was its inherent deviation from OAuth. We were reinventing the whole digital signature method that OAuth had invented already. This troubled Paul greatly.

So Paul reworked things to "get out of the authentication business" entirely, and just stick to authorization. And given our discussion of last week about preferring but not mandating OAuth, this suggested a thinner approach anyway – sequestering the means of authentication for the various parties.

So, e.g., the requester can authenticate with the host in any manner, and as long as the requester's identity at the host can be correlated at the AM (through an identifier provided by the host to the AM), we've got enough for a solution. The requester and host can use two-legged OAuth, and the requester and AM can also use two-legged OAuth.

The order of steps has changed a bit. It's up to the requester to establish a connection to the host ahead of time now, whereas before the host was relying on an identifier assigned by the AM (in what could be called our old "UMA signature protocol"). Now the host is expected to know how to authenticate its own requesters.

There are costs as well as benefits to this more OAuth-compliant approach. Let's understand them by walking through Paul's email. Even though this loosely coupled approach has more protocol steps, none of them impact the "done every time" steps; we think they can all be considered part of setup.

Step 1 hasn't changed much from last time. The authorization resource in section 1.4 has changed, and will likely change again. Paul had at first wanted to add protection by ensuring that the host's authorization resource (which requesters will use) doesn't contain the host identifier, but is wavering on whether that's important to protect.

Step 2 first involves the requester getting some token with the host. It could be acquired in any form (e.g. a cookie), and tokens could expire and have to be reissued according to whatever the host's needs are. But the example uses straight two-legged OAuth. It also invents an XRD for two-legged OAuth. (Does anyone know if such a thing has already been officially invented/proposed?)

George: Does it make sense to discuss "access tokens" as part of two-legged OAuth, since they don't really exist in this form of OAuth? Only the consumer key and secret are needed. Paul: There are two ways of doing two-legged OAuth: every consumer has a different consumer key, or every consumer has a different access token. George: How can the requester fit all the information that's necessary for UMA into a normal OAuth call? Paul: The authorization decision by the AM need only be correlated with a requester identity at the host.

We delved into the question of what happens when fifteen different "requesting parties" at the requester app. The requester could be acting on behalf of: the same person as the authorizing user; a different person; or the company that controls the app as a whole.

SPEC NOTE: The protocol needs to specify that the requester must distinguish these parties somehow in representing itself to the host and AM.

The example provided in step 2 happens to use the access token that the host provided to the requester as the requester correlation handle that the host provides to the AM. This is convenient, but the value of that handle could be anything the host desires.

George: In the case where the authorizing user has specified a policy that says "Ask me for real-time consent", how will the AM let the user know who the requester is? Paul: The claims provided by the requester could be displayed to the user, and it's possible that the user has mandated that the requester have a certificate signed with a certain strength etc., which would identify it with pretty high quality.

Step 3 needs major revision, but here's how it looks right now. The requester is authenticated, but not authorized yet. The host could even be smarter than shown here, and turn down the requester unilaterally with a "deny". The requester can then look at the protected resource's descriptor to figure out what's required for authorization. This descriptor tacks on a requester-specific value to the authorization resource that the AM originally gave to the host. The requester can then "build" its authorization on top of that resource.

George: Must every request be signed with an access token? Paul: Yes, and the host even needs to do a POST to create an authorization resource in the first place (a GET isn't good enough; to preserve RESTfulness it must be created with something other than a GET first). These extra steps are partly a consequence of being more OAuth-y.

Eve: In addition to being more OAuth-y, this is also way more XRD-ish and LRDD-ish. This sits well with her because it's more "declarative" and should be easy to experiment with.

George: Should we be more heavily HTTP-based and rely more heavily on redirects? Paul: Feels that we should answer Yes to the first but No to the second. George: Would the response to a requester's authenticated request be name-value pairs? (Praveen at AOL had written some OAuth extensions allowing other response formats.) Paul: Yes to the question. We can probably leverage the header field rather than the name-value pairs if we want to. George: Prefers name-value pairs over headers at the moment.

George: Notes that the responses are not currently signed.

Eve: Notes that the OAuth term "access token" is perhaps especially inapt in our usage of OAuth, since it's more about authentication than true authorization.

George: Notes that our "two-legged" OAuth approach is more like full three-legged OAuth, only bypassing the user interaction portion. We're using the full "authentication" spec (as conceived by OAuth V1.0a produced in the IETF), and not the "web delegation" spec.

Mike: This direction is feeling good. There's a lot of state to maintain, which brings up the question of how big the tables would get at scale, but maybe a lot of the state would be short-lived.

George: From a user experience perspective, if the access token that iGoogle (representing one particular user there) is good for an hour, and the authorizing user later looks at his logs, how will he know who that really was? The requester-AM-authzuser relationship wants to be quite long-lived from the perspective of audit logs. Eve: Could an IMI-like approach of "display tokens" be used? George: We'll probably have to go there.

Paul: The host could have a way of issuing access tokens that involves a requester/requesting party having pre-registered with the host. George: In this case, we could use true two-legged OAuth, where the requester can provide a unique consumer key in the original request to the host. (The process of the requester getting a consumer key and secret from the host would be out of band with respect to both OAuth and UMA.) This would also allow for short-lived access tokens. Eve: This would be a great optimization that doesn't rely on an entirely dynamic requester-to-host approach, and we don't have to be "in charge" of managing it in our spec. Paul: Since all we require is for the host to generate an identifier to represent the requester, it can use any sort of identifier it wishes. OAuth with whatever number of legs, cookies, or whatever – each authentication method suggests its own strategy for assigning the identifier.

Paul: We need to be prepared for a new access token to be issued (say, because the old one expired), and an existing authorization (still in effect) to be attached to that new access token. This will be the trick.

The host has no knowledge about the relationship that a requester has with the AM. It's just passing along an identifier and asking for an authorization decision. If that identifier doesn't have authorization, there are two ways to get it. Either the host and requester have to jump through the hoops of getting one in the usual fashion, or the host has to reattach a new identifier (assigned to the "same" requester) to an existing authorization. With a significant consumer key in the picture (that significantly represents the real requesting party standing behind the requester), then the access token doesn't have to bear this entire burden.

It's possible for an AM to have hundreds or thousands of authorization resources for the same protected resource, so it's possible for the requester to use this fact to reacquire state after its access token with the host expires.

Scenario review (docket)

• Formally accept/reject aspects of the requester delegate scenario

Motion to accept the Requester Delegate scenario, accept its impersonation use case, and reject its separate network endpoint use case APPROVED.

UMA F2F 2009-11-02 planning

• Hold a telecon on 2009-11-05, or forego it due to the F2F, IIW, etc.?

Let's definitely cancel the 2009-11-05 telecon.

Should we concentrate next week on scenarios that deal with terms/policy/claims, or with multiple resources on the same or multiple hosts? Paul vouches for the former, and suggests that we could look to IMI for ways to handle this. Hasan has also done some research in this area.

AIs:

Next Meeting: UMA F2F 2009-11-02

1-5pm, Computer History Museum, Mountain View, CA (directions)

As far as we know, telecon services will not be provided during this meeting. Free wifi and a projector will be available.