UMA telecon 2014-11-20

...

• Roll call
• Minutes approval if quorum
  • Sample motion: Approve the minutes of UMA telecon 2014-1011-13 and read into today's minutes the notes of ad hoc WG meetings held since 2014-1011-13.
• Interop testing status and meeting schedule review
• Review of FT-impacting issues on V1.0 docket
  • 108: make "protection" and "authorization" scopes able to be implicit: does our Monday conclusion still sit well?
  • 92: trust elevation: can we come to a conclusion based on progress from Friday and Monday?
  • 110: RSR location URI for registration of discovery info? 
  • 84: UMA endpoint names vs. OAuth endpoint names: do we have to change user_endpoint to authorization_endpoint, and then do we have to change our authorization_request_endpoint to something else?
  • 94: start_at for permission validity
  • Review issues newly added
• AOB

...

MOTION: Moved by Andi: Approve the minutes of UMA telecon 2014-1011-13 and read into today's minutes the notes of ad hoc WG meetings held since 2014-1011-13. APPROVED by unanimous consent.

...

AI: Eve: Ask Roland which Monday he might be available for the next interop planning session.

In 2014, we have three more (long) Thursday meetings after today, plus Mondays and any other ad hoc meetings.

108: scope implicitness

Any update from Marcelo on scope mapping best practices?

...

AI: Eve: Update issue #108.

92: trust el

Our status to date is that our rough consensus has moved us beyond a mere need_claims response from the AS to an elevate_trust response, where its embedded error_details has the option to provide hints to the client about what's required next, and where our own specs have the option to standardize hint options and third parties can provide their own above and beyond those. Our standardized options of interest are need_claims and need_reauthentication.

...

The thinking with arrays that use OR-logic is that their names are singular. For arrays with AND-logic, their names are plural. Since these are extensible JSON structures, we want to be sure to let third parties tell us where our design should go next; let's not over-design now without good reason.

The "yes" values are there to illustrate cases where the default of "no" is not taken.

Hints are always possible to leave off when the AS and the C have a prenegotiated understanding. This is where access federations come in. (We might want to point to the Binding Obligations spec in non-normative fashion for this.)

Should we then consider transplanting some Claim Profiles redirect stuff back under Core? We think the Requesting Party Claims Endpoint does need to be added back because it provides support for the redirect_user property above. It's not part of the authorization API, but rather an endpoint akin to the OAuth user endpoint, meant only for RqP interaction.

AI: Maciej: Write up proposal for integrating the requesting party claims endpoint back into the core spec and figuring out the impact on the claim profiles spec.

AI: Eve, Maciej, Thomas: Do an editing session on Saturday.

Attendees

As of 17 Nov 2014, quorum is 7 of 12.

...