UMA telecon 2015-02-19
UMA telecon 2015-02-19
Date and Time
- Thu Feb 19 9-10am PT
- Voice: Skype: +99051000000481 or US +1-805-309-2350 (international dial-in lines), room code 178-2540#
- Screen sharing: http://join.me/findthomas
- UMA calendar: http://kantara.atlassian.net/wiki/display/uma/Calendar
Agenda
- Roll call
- Minutes approval
- Sample motion: Approve the minutes of UMA telecon 2015-02-12.
- Upcoming meeting schedule
- Reminder of special meeting Mon Feb 23
- Field public review comments
- Report on other outstanding AIs
- AOB
Minutes
Roll call
Quorum was reached.
Minutes approval
MOTION: Andi moves: Approve the minutes of UMA telecon 2015-02-12. APPROVED by unanimous consent.
Upcoming meeting schedule
The Monday meeting is on!
Field public review comments
All issues in the public review timeframe are listed here. (The following analysis was created on 15 Feb 2015; check if new issues were added in the meantime.)
- Non-editorial: 137, 134, 129, 125
- Editorial: 136 (needs formal response because it came from an external commenter), 135, 131, 130, 128
Issue 137: Consensus to add the policy_uri to Read and Update along with Create.
Issue 134: The sentence in the spec could be: "Note that the word "user" implies a human requesting party; if the requesting party is not an end-user, then no client action would be possible on receiving the hint." Consensus to add this to the spec.
Issue 129: The mention of If-Match is indeed incorrect and should be removed.
Issue 125:
- Relationship of RPTs and types of clients: We think our Core Section 8.1 has it covered.
- Icon URI (for resource sets and scopes) threats: The RS itself has a trust relationship with the AS in question, and it registers resources in the context of a particular RO. If an RS is malicious, it would have to get a user to authorize it to (a) dynamically register and (b) outsource protection to the AS. Perhaps a mitigation is that an AS may not want to display scope or resource set icons of a dynamically-registered-client-as-RS until such time as it establishes sufficient trust. A choice on the RS side that increases the likelihood of the AS displaying its icons even if the RS is less trusted, could be to choose icons that are well-known and standardized by third parties. Do we have to worry about the threat of retrieving the scope description from the scope URI, similarly to an icon URI? No, because the endpoint should just contain a hunk of JSON, and we already say something about that in an abundance of caution; JSON should not be unthinkingly executed. Consensus to add new discussion of threats/mitigations.
Outstanding AIs related to the specs:
- AI: Sal, George: Do a close reading of UMA Core Sec 8.1 against the OAuth Security Cheat Sheet and see where we can improve the former.
- Did any comments come in from Hannes? (Eve closed her AI to ask him.)
We'll see if any further comments come in before Monday. If not, then not.
Zhanna asks: If nbf is set to the future, and everything else is “fine”, should be active==true or false? Is the reply still “200 OK”? Also, how would clock skew play in here? We expect that the correct semantic is that the token is properly "active" (good), but just because a token is active doesn't mean that the access attempt is supposed to succeed. The time may not be right, or the type of access attempted might not match the authorization data associated with it. In the case of the default RPT profile, the AS both generated the RPT and is validating the RPT, so any clock skew is "its own fault". Clock skew becomes more relevant in cases where, say, the RS locally introspects an RPT away from the AS that generated it. It would be good to add the nbf information in the response, perhaps, to indicate that the token or permission hasn't "timed in" yet.
Eve and Thomas are scheduled to edit the specs on Sun 22 Feb 2015 for review and voting on the Mon 23 Feb 2015 WG call.
Report on other outstanding AIs
- AI: Mike: Write the section on "Organizations as Resource Owners and Requesting Parties".
- Mike has sent Eve a link to his Google Doc.
- AI: Maciej: Write as many sections for the UIG as he can. (smile)
- Pending.
- AI: Andi: Write the section on "Handling Ignored Parameters" and share with Zhanna for comment.
- Their text is ready for Eve to incorporate. At Eve's discretion, she could use one or both halves.
- AI: Eve: Send suggested updates to Will at Gluu for English page updating, and to Domenico for Italian page updating, and to Rainer for hoped-for German page updating, and to Riccardo Abeti for the Spanish page, and to Mark for a Dutch translation.
- Pending.
- AI: Ishan: Review the FAQ for needed updates (http://tinyurl.com/umafaq).
- Will send FAQ suggestions later today.
- AI: Eve, Colin, Mike, Sal: Email discussion about possible crowdsourced track submission.
- Coming to a conclusion. The "OpenID Connect vs. UMA" theme is a contender, but Mike is also thinking of doing his "API Security".
- AI: Robert: Noodle on the kitten metaphor.
- Pending.
AI: Eve: Edit UIG!
Attendees
As of 14 Jan 2015, quorum is 7 of 12. (Dom, Sal, Mark, Thomas, Andrew, Robert, Maciej, Eve, Mike, Jin, Ishan, Ravi)
- Eve
- Ishan
- Maciej
- Domenico
- Andi
- Sal
- Mike
- Jin
- Thomas
Non-voting participants:
- Marcelo
- Zhanna
- George