Minutes

Roll call

Quorum was not reached.

Logistics

Next week: no meeting because of IIW! Have a great time if you're going. Please don't forget to send George comments on his deck, and soon.

Approve minutes

Approve minutes of UMA telecon 2016-10-13: Deferred.

Work on UMA.next issues

Requesting party claims endpoint: Eve's proposal for the AS declaring a requesting party claims endpoint to the client was that we should pick option 2: both static (in the config data) and dynamic (in the response to the client) methods, with MAY, and with dynamic overriding static if it's present, providing the rationale that static pattern enables the RqP to authorize client pushing of claims and the dynamic pattern enables variable URLs according to the AS's management of its API.

Mike notes that OIDC just had a thread about a similar matter, regarding scopes. Eve guesses that this specific thread may not be related because it's about a required registration and the interaction between two specs. Is there another thread? Eve proposes spec'ing the text, and if anyone can identify a concern that seems more related, do it by the time rev 06 is out.

Eve proposes that the definition of "authorization process" should require that "request_submitted" be more formally defined to have the AS emit a 403, and say that "The authorization server responds with the HTTP 403 (Forbidden) status code.", and the client is free to start another authorization process at a later time. Similarly the other 400s require starting new authorization processes. This makes clear what "persistence" means for a PCT. Mike and Cigdem are supportive.

Authorization interface and UMA grant: We looked at Dom's first diagram. We requested:

• Adding "natural person" and "legal person" icons to both the RO and RqP blocks
• Some way of ensuring that inside the AS block:
  • The protection API concept is associated with the RO-RS-AS tuple
  • The authorization interface concept is associated with the C-RqP-AS tuple
  • The UMA grant concept is associated with the C-AS tuple
• The PCT is shown as being optional in a nice-looking way
• The second canvas with the life cycle should use initial capitals in the text
  • Attempt resource access
  • Register requested permission
  • Authorization process
  • Authorization assessment
• It should also have a small "start" arrow to show that the client attempts access to the resource
• The life cycle circle should be a bit smaller to make sure all the outer text shows
• Overlay the RPT so that it shows "through" the life cycle (maybe make the circle translucent?)
• Keep up the flowcharts according to the swimlane; do as you wish with the life cycle color coding

Instructions:

• Spec requesting party claims endpoint declaration as indicated above
• Spec authorization process definition as indicated above
• Create a draft ASCII diagram for the first canvas
• Update swimlane

Bearer RPT and PoP tokens: We didn't get to this, so please weigh in on the list. Eve is happy to try out spec text (and also removing spec text!) in 06 if we hurry on that.

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. Eve
3. Mike
4. Cigdem

Non-voting participants:

• John

Regrets:

• James