...
- Roll call
- Approve minutes of 2011-08-25 meeting
- Action item review
- Planning for upcoming gatherings
- Core protocol issues in GitHub
- AOB
Attendees
- TBS
Minutes
...
As of 22 Aug 2011, quorum is 6 of 10.
- Catalano, Domenico
- D'Agostino, Salvatore
- Hardjono, Thomas
- Machulak, Maciej
- Maler, Eve
- Moren, Lukasz
- Morrow, Susan
- Szpot, Jacek
Regrets:
- Wray, Frank (for this and next two meetings)
Minutes
Roll call
Quorum was reached.
Approve minutes of 2011-08-25 meeting
Minutes of 2011-08-25 meeting APPROVED.
Action item review
- 2010-11-18-4 Eve Open Capture new user stories in the wiki.
- 2011-04-14-1 Maciej, Alam, Eve Open Build list of FAQs (both questions and candidate answers) on the wiki. Eve has written a few new answers. Sal may take on a few too. The SMART team still has to write a special SMARTAM Q&A.
- 2011-08-18-4 Susan, Eve, Sal Open Draft a Waterford Institute contest entry.
Planning for upcoming gatherings
Make sure to register early to get good rates. Thomas will be attending IIW but not the UMA F2F meeting.
Core protocol issues in GitHub
Thomas has worked on a rev 16 of the spec, to incorporate some closed issue text. He has updated his GitHub thardjono repository. What is the right way to incorporate his work back to Eve's xmlgrrl repository? He needs to request Eve to "pull" his changes into it, and merge any conflicting changes.
Spec editor report on status of closed issues: #1, #3
Thomas has addressed issue #1 in rev 16 (rev 15 was the version we submitted to IETF). He added some lines in Section 3.4, explaining that the ticket is an opaque structure that's under the control and responsibility of the AM.
In Section 3.5, he noticed there was no mention of ticket-related errors, so he added Sections 3.5.1 and 3.5.2 as placeholders for anticipated error types. We'll ask Lukasz to take a look.
Thomas will work next on incorporating closed issue #3.
Try to close #4, #5, #6, #7 in short order
#4: Let's get away from talking about "claims-requested responses" because it's confusing to us.
We think we understand the second half of Lukasz's proposal, but not the first half.
What are all the things that could be wrong with the Requester's UMA/HTTP request message in Section 3.5? Note that this is related to issue #1.
- The token is wrong/broken/expired (Thomas thought of this for #1). This is OAuth-level.
- Invalid request (message is irretrievably broken and can't be parsed). This is UMA-level.
- Ticket has expired (Thomas thought of this for #1). This is UMA-level and the requester should go back to the host and start again with the thing they did to get the ticket.
- Claims not supported (they're of unsupported claim types). This is UMA-claims-level, and should be accompanied by a repeat of the claims still needed.
- Claims needed. This is UMA-claims-level, and should be accompanied by a list of the claims needed.
- Claims insufficient for authorization (claim values or issuers don't match policy). This is basically a "you are not authorized" error.
Do we have to worry about expired tickets during long and involved claims-exchange sessions? Can the ticket be a nonce that is only ever used once, and then the session can be tracked and secured by other means? This is an open question.
The issue is still open; Lukasz will try to map his two error suggestions to these six.
#5: We are fine with the way the resource set registration API is now. The Create version of PUT doesn't require If-No-Match and the Update version of PUT already requires ETag matching. So we can close this with no action.
#6, #7, #2: Still open.
Prioritize next issues to be discussed
Next week, let's focus on lining up OpenID Connect-related issues for Maciej to present the following week at the OpenID Summit.
Next Meetings
Note: Meetings are now 60 minutes in length.
...