UMA telecon 2016-10-13

Owned by Eve Maler
Last updated: Oct 13, 2016
3 min read

UMA telecon 2016-10-13

Date and Time

Agenda

  • Roll call
  • Logistics for upcoming meetings
    • Next week: moved to Friday
    • Week after: should we move to Friday given that it's IIW week?
  • Approve minutes of UMA telecon 2016-10-06 
  • Work on UMA.next issues
    • See last week's notes
    • Core should be up to 04 shortly
      • Review Domenico's diagrams and the UMA grant flow options
        • See Core Sec 3.5.4 for possible error responses from the AS
    • RSR is up to 00
      • New input simplification of the protection API
  • FB page care and feeding ideas (if time)
  • AOB

Minutes

Roll call

Quorum was reached.

Logistics

REMINDER: The call for NEXT WEEK will be held Fri Oct 21 instead of Thu Oct 20, just after the Legal subgroup call.

IIW WEEK: Move to Friday? NO: We will cancel the Thu Oct 27 call that would have been during IIW.

Approve minutes

Approve minutes of UMA telecon 2016-10-06 : APPROVED by acclamation.

Work on UMA.next issues

Sec Considerations: 7.1 and 7.3 do seem somewhat related, and could usefully be put closer together and conceptually brought closer together somehow. Also, there's a typo in 7.3: Needs to be "authentication and user mapping capabilities".

Sec Considerations: 7.2 talks about two different OIDC topics. The first paragraph is about one topic ("RECOMMENDED for the authorization server to use OpenID Connect, and to use its mechanisms for stronger client authentication at the token endpoint, in order to strengthen the authentication of OAuth clients."). The second paragraph is about end-user identification; we should break it out.

In error_details, Justin's MPD work doesn't have a redirect_user Boolean; rather it has a dynamically provided URL for where the client should redirect the RqP to. Putting this information in the response could mitigate a discovery document attack, according to some in the OIDC – this attack is the basis for the AS mixup attack. On the other hand, a client registering a callback is a case of using static-ness on the other side to mitigate attacks. Another (potential?) benefit is that the AS could bind state to the URL, making it different every time.

The static declaration does make it possible to proactive send the end-user RqP to an interaction with the AS, though the spec doesn't explicitly remind people that it's possible the way it explicitly reminds people that it's possible to proactively push claims to the RPT (now token) endpoint.

Options:

  1. Keep static declaration of requesting party claims endpoint in config data document and don't add to AS need_info response to client (status quo)
  2. Keep static declaration and ADD to AS response
  3. DROP static declaration and ADD to AS response

Decide next time on which option to choose.

Regarding 3.2.4: What is the expectation about the AS providing more information about the exact resource set IDs or scopes that were at fault? Would it be a good idea to provide more guidance around error descriptions that could accompany UMA errors? Development time and deployment time are different things; would end-users see these errors?

Instructions:

  • Address Sec 7.1 and 7.3 comments above. Will take some thought.
  • Address Sec 7.2 comments above.
  • Make an ISSUE around analyzing the spec for what its effective "operational modes" are. Look for all MAYs and natural dividing lines, and be sure to document a rationale for every MAY if possible.
  • Change title that has "Consent" in it to "Authorization"
  • Sec 3.2.4: Should be "Any one of the provided resource set identifiers".

Attendees

As of 3 Oct 2016, quorum is 6 of 11. (Domenico, Sal, Nagesh, Andi, Robert, Maciej, Eve, Jeffrey, Mike, Cigdem, Sarah)

  1. Domenico
  2. Sal
  3. Robert
  4. Eve
  5. Cigdem - researcher - new to the call!
  6. Sarah

Non-voting participants:

  • Adrian
  • Andrew
  • George
  • James
  • Scott F
  • Jin
  • Justin
  • Ishan

Regrets:

  • Andi
  • Mike