UMA telecon 2010-12-02

Date and Time

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

Agenda

Roll call
Approve minutes of 2010-11-18 meeting
Action item review
Status on user stories and test plan efforts
Latest resource registration work (etherpad)
- Review focus team progress
Review latest trusted claims proposal
- See also further explanation/links
Line up next set of spec issue priorities
- Claims 2.0 (plus other bootstrap claims definitions?)
- Dynamic registration
- Other?
AOB

Attendees

As of 15 Nov 2010, quorum is 8 of 14.

Adams, Trent
Alam, Mohammed
Bryan, Paul
Catalano, Domenico
D'Agostino, Salvatore
Hardjono, Thomas
Machulak, Maciej
Maler, Eve
Scholz, Christian

Non-voting participants:

Kevin Cox
Anna Ticktin (staff)

Regrets:

Susan Morrow
Lukasz Moren
Cordny Nederkoorn
George Fletcher
Tom Holodnik

Minutes

New AI summary

2010-12-02-1

Eve

Open

Create fresh resource registration spec draft and capture issues.

Roll call

Quorum was reached.

Approve minutes of 2010-11-18 meeting

Minutes of 2010-11-18 meeting APPROVED.

Action item review

2010-09-02-1 Thomas Open Categorize all existing scenarios by their distinctive aspects. Let's close this and pick up specific AIs later.
2010-11-01-2 George Closed Write up "problem B" as a user experience description that can be turned into a user story.
2010-11-01-2 Eve Open Put the public-private continuum language and diagram into the Lexicon. Still open.
2010-11-18-3 Domenico, Sal Open Explore turning the trusted claims UX and writeup into draft spec text. No new news.
2010-11-18-4 Eve Open Capture new user stories in the wiki. In progress. Lots of edits made; more to come.

Status on user stories and test plan efforts

Eve has updated the user stories quite a bit, but still has more to cover, including Alan's submitted ones. Cordny has been making excellent progress on conformance test cases for UMA, which are starting to incorporate the OAuth conformance issues underneath.

Latest resource registration work (etherpad)

We walked through the proposed text, discussing both conceptual and technical details. (The etherpad has lots more detail than appears here.)

Should we allow for flexibility in the format of resource/action details? How far ahead do we need to think, in terms of alternatives to JSON? We agreed to lock down JSON but keep an eye out for people who want to use different formats in future.

Should we include resourceid and actionid parameters in-band in the details documents? We think not, since the URI for each registered document will have the ID.

How to solve the i18n problem? Let's first decide if it is a problem before debating particular ways of solving it.

How and when does the /host/{hostid} branch get created? We're not sure yet, but maybe the hostid could be its client ID at this host.

How and when does the /user/{userid} branch get created? We're not sure yet.

Should {resourceid} be the same value in the "resource_id" parameter and the /resource/{resourceid} URI? If they're supposed to be the same, it's ideal not to include the ID in-band when registering the resource to reduce mistakes. If there is value in making them different, we should say what it is. Paul notes that tools like couchDB treat such identifiers as having special semantics, so that it can help you avoid errors that involve getting them out of sync. E.g., if you POST to create a new doc and ask it to assign an ID, it would ignore any ID you assign in-band.

Do we need to allow boxcarring of POSTs or DELETES or whatever to create resources/actions? It would be easy to delete all resources/actions at once, but currently it's not possible to selectively delete multiple ones at once. You'd have to do it one by one. We're not sure yet if we should be building in selective boxcarring. Similarly, how could you do bulk inserts of new docs? There are some popular patterns solving this, but you start to drift away from REST pretty quickly. We'll just keep a watchful eye on use cases for bulk inserts, selective deletion, etc.

Should we provide the server-assigned vs. host-assigned identifier option? If we had to pick one, you could make an argument keep just the host-assigned identifier (what Paul called "client-identifer" in the etherpad) since they may have a key they can already use. Today, OAuth servers use scopes in roughly the same way you might use action IDs, so maybe this is the right way to go. Let's do that.

Review latest trusted claims proposal

See also further explanation/links

Let's do some work in the trusted claims etherpad.

Line up next set of spec issue priorities

Claims 2.0 (plus other bootstrap claims definitions?)
- The current OAuth-related work on JSON tokens is highly relevant here. We're looking for someone to summarize the state of play on this at the next meeting.
Dynamic registration
- No news on this.
Conformance section
- Needed to help the conformance test plan.
Security considerations section
Other?

Next Meetings

WG telecon on Thursday, 9 Dec 2010, at 9-10:30am PT (time chart)
WG telecon on Thursday, 16 Dec 2010, at 9-10:30am PT (time chart)
WG telecon on Wednesday, 22 Dec 2010, at 9-10:30am PT (time chart)

Browser not supported