[Wg-uma] Draft minutes of UMA telecon 2009-10-29

Eve Maler eve at xmlgrrl.com
Thu Oct 29 15:42:18 EDT 2009


NOTE: The "summertime skew" disappears as of next week! All time zones  
will have switched onto/off of their seasonal schedules by the next  
time we have a telecon.

The draft minutes are here; please let me know if you see any  
inaccuracies:

http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2009-10-29

The action item and resolution summary is here:

http://kantarainitiative.org/confluence/display/uma/Meetings+and+Minutes

The minutes are also pasted below, for your convenience.

	Eve



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:

Adams, Trent
Akram, Hasan
Bryan, Paul
Catalano, Domenico
Davis, Peter
Fletcher, George
Hanson, Michael
Henderson, Iain
Machulak, Maciej
Maler, Eve
Smith, Bill
Stollman, Jeff
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:

2009-10-29-1	Eve	Open	Find an IMI expert to advise us at the F2F on  
whether it can help us with terms/policy/claims satisfaction.	
2009-10-29-2	Hasan	Open	Share research on IMI/information card  
approaches for the F2F.	
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.


Eve Maler
eve at xmlgrrl.com
http://www.xmlgrrl.com/blog

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://kantarainitiative.org/pipermail/wg-uma/attachments/20091029/bd2af751/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smile.gif
Type: image/gif
Size: 699 bytes
Desc: not available
Url : http://kantarainitiative.org/pipermail/wg-uma/attachments/20091029/bd2af751/attachment-0001.gif 


More information about the Wg-uma mailing list