UMA telecon 2010-07-08

Date and Time

WG telecon on Thursday, 8 Jul 2010, at 9-10:30am PT (time chart)
- Skype line "C": +9900827042954214
- US: +1-201-793-9022 | Room Code: 295-4214

Agenda

Administrative
- Roll call
- Approve minutes of 2010-07-01 meeting
- Action item review
SMART project update
Focus group report and review of new RRAPI push/pull model
- Hold another focus meeting next week?
Dynamic registration I-D progress
AOB

Attendees

As of 3 Jun 2010 (post-meeting), quorum is 6 of 10.

Adams, Trent
Catalano, Domenico
Hardjono, Thomas
Machulak, Maciej
Maler, Eve
Moren, Lukasz
Scholz, Christian

Non-voting participants:

Mark Lizar
Aaron Titus
Nat Sakimura

Regrets:

Randall Gamby

Minutes

New AI summary

2010-07-08-1	Maciej, Eve	Open	Figure out strategy for announcing opportunity to sign up to become SMART UX testers.
2010-07-08-2	Christian	Open	Automate the process of generating viewable HTML and TXT from the xml2rfc files and put them in a consistent place.

Roll call

Quorum was achieved.

Reminder of IRC channel: #umawg on irc.freenode.net (web interface)

Approve minutes of 2010-07-01 meeting

Minutes of 2010-07-01 meeting APPROVED.

Upcoming meeting opportunities

Focus meeting next Wednesday?

We agreed that it's better to spend the time on spec-writing.

Interest in UMA meeting or BOF (with possible dial-in) at October Kantara meeting in Paris?

We are interested in a 1-3pm slot, if one is still available. Eve will let Dervla know. Maciej and Lukasz can attend, and Maciej can run the meeting as necessary. NOTE: It turns out that flights within the UK and Europe seem to make a morning meeting a better bet, so we'll request a morning slot if possible.

Action item review

009-12-03-4 Eve Open Add terms-negotiation scenarios to Scenarios document. How long before people realize Eve is sort of ignoring this one?
2010-05-27-4 Eve Pending Ask Dave Crocker for help with Step 1 user stories.
2010-06-17-1 Christian, Eve Open Work on the conversion of the core spec and the dynamic registration spec to xml2rfc. In progress; hopefully to be largely completed by the weekend.
2010-7-01-1 Christian Open Sketch a new version of push+pull RRAPI, taking into account the 2010-07-01 discussion, the Artifact Binding, and the SMART resource registration writeup. In progress; hopefully to be largely completed by the weekend.
2010-7-01-3 Eve Open Send Domenico's draft trust model writeup to the list for comment. Eve will do this right away.

SMART project update

The Devoxx conference in November will have a couple of appearances of the SMART work. The SMART project is now affiliated with the Centre for Cybecrime and Computer Security at Newcastle University. And (if that weren't impressive enough) the UX has been fully designed and implemented and there's a working version people can try. They are doing some user research now. Send him an email if you're interested in being a tester – there may even be money involved! The team has been pushing forward on some resource registration ideas which can impact the AM interface. Maciej presented at a Security and Privacy for Cloud Computing workshop recently; he will send around some links to related papers that should be of interest to us. The SMART blog has more.

Relatedly, Eve has been doing a series of webinars; interest seems high among enterprises and "Enterprise 2.0" types. Maciej has been finding similar interest.

Focus group report and review of dynamic registration I-D progress

Thomas comments that the introduction needs work. Christian welcomes precise comments on how to edit the text.

Also, should we call this "registration" vs. "binding"? We agreed to switch it, based on previous telecon discussions.

Requirement 2.1 is "The client needs to be uniquely identifiable by the authorization server." We agreed that the sense is clear and it's a sensible requirement.

Requirement 2.2 is "The authorization server must be able to retrieve metadata about a client for later user interaction." Thomas points out that some OAuth clients don't ever need to involve a human end-user in later interaction. Is it also the case that metadata might be needed for other purposes in addition? Do we need to clarify the non-user-interaction use cases of dynamic client binding?

Proposed revision: "The authorization server must be able to retrieve metadata about a client for later interaction. For example, in order for the authorization server to describe a client to a human end-user in a user authorization step, it needs information about the client. This can be the client name at a minimum but today servers usually request at least a description, a homepage URL and an icon when doing manual registration."

Requirement 2.3 is "The authorization server must have the option of strongly authenticating the client and its metadata." This seems good.

Requirement 2.4 is "Automatic client binding must also be possible from applications running on mobile devices." This seems good.

Requirement 2.5 is "Data integrity must be ensured in large deployments where data propagation can be an issue." Christian has included a question about this in the draft: How would a pull look like here as it's always the client which needs to start the process? If a user starts an interaction using their browser, it uses a single particular server in a cluster, and then everything is okay. But if the client approaches the server independently, without any users needing the connection yet, them maybe it's also okay since presumably the necessary client credentials and metadata can be synced throughout the server ecosystem before the first user ever shows up (a la the static association model of today's OAuth). Nat thinks the user-introduction scenario is true across a single pull; is there a problem if you have to do multiple pulls in a single user session? or if the pull is followed by normal OAuth pushes? The source of the problem in, e.g., the web server flow is that the client and the user agent are living on different machines.

Discussing the registration flows: Christian listed the three expansive possibilities:

For completeness, Christian listed flow option 3.1, "Providing client information on every request and not using client credentials at all." This one violates the first requirement, but has been discussed on the OAuth list. It's almost kind of a "guest account" approach. Let's leave it in for now, to clarify the options and requirements.

Flow option 3.2 is push: "The client pushes client information to the authorization server which returns client credentials." This seems fine. Christian is hoping for comment on his remarks around authorization and PKI in this section. Eve suggests making the push option as simple as possible, since the pull option is the one that should support any complexity.

Flow option 3.3 is pull: "The authorization server pulls information from the client and returns client credentials." See the 2.5 discussion above for discussion of Christian's issues. We want to let nature take its course on the availability of the two flow options, and not try to decide it here ourselves; it's should be decided by the OAuth community.

Christian poses the question: Why recommend two options, if pull would solve all of the requirements? There is cost in recommending two options. Maciej's dynamic registration draft makes the case that servers should support both, but any one client might only support one. In this way, error codes could be rationalized as well.

Nat observes the with the pull model, a client can cheaply sign the metadata in static fashion.

Do we need a new requirement to answer this question? Maybe this will emerge in the OAuth discussion. A requirement around simplicity might argue for a single method, or for having both methods, depending on whose development and deployment process is being optimized for.

RRAPI progress

Maciej has been continuing to work on the SMART project's version of the RRAPI. Based on their experience, they want to revise their recommendation; he thinks they can get a new draft out by next Thursday (we hope) for consideration in our call.

Christian and Eve may find some time to meet and compare his and Maciej's RRAPI proposals. It would be very useful to go through the same requirements exercise for that (and each spec chunk in its turn) that we did for the dynamic registration piece.

Next Meetings

Legal subteam meeting on Monday, 12 Jul 2010, at 1-2pm PT (time chart)
WG telecon on Thursday, 15 Jul 2010, at 9-10:30am PT (time chart)

Browser not supported