UMA telecon 2014-12-04

Date and Time

Thu Dec 4 (ad hoc meeting 8-9am PT followed by) quorate meeting 9-10am PT: two hours total!
- Voice: Skype: +99051000000481 or US +1-805-309-2350 (international dial-in lines), room code 178-2540#
- Screen sharing: http://join.me/findthomas

Agenda

Roll call
Minutes approval if quorum
- Sample motion: Approve the minutes of UMA telecon 2014-11-20 and read into today's minutes the notes of ad hoc WG meetings held since 2014-11-20.
Interop testing status and meeting schedule review
- Eve meeting with Roland this Friday to discuss refactoring FTs; anyone else want to join?
- Meet next Monday without Eve?
- Only two more Thursdays in this calendar year!!
Review of new editors' drafts (core 13a and claim profiles 01a) and FT-impacting issues on V1.0 docket
- 92: trust elevation: can we close this issue now?
- 100: need_claims cleanup: can we close this issue now?
- 114: reabsorbing "redirect claim profile": can we close this issue now?
- 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: shall we add this?
- 116: mentioning OIDC dyn reg too: shall we add this?
- 115: syncing token introspection profiling to the latest draft: who is willing to take on this analysis?
- 95: multiple AS protection over one resource set: okay to drop this for consideration in 1.0?
- 51: JWT profile for local introspection: high enough interest to do an RPT profile for this in Core 1.0?
AOB

Minutes

Roll call

Quorum was reached.

Minutes approval if quorum

Deferred.

Interop testing status and meeting schedule review

Eve wonders if, after "issue burndown", we need more "spec burn-in" time past December 18. Andi speaks in favor of not waiting a huge amount of time, given that we've been discussing – and floating spec text for – the most invasive of the changes. Indeed, some of the outstanding issues are a result of implementers proposing additions that they've already implemented in extensions anyway. Perhaps we can just get to Dec 18 and see how it goes!

All voting participants should expect to attend the Dec 18 call for sure!

No meeting next Monday. We'll pick things up again next Thursday, with new published drafts to review.

Requesting party claims endpoint migration to Core 1.4

Thomas and Eve proposed that this be an optional piece of config data. The thinking is that, if the AS offers RqP interaction, then this is the only way to advertise the endpoint; if it doesn't offer this, then the config data property can be missing.

JSON extension opportunity in Core 1.1 (from 1.4 and elsewhere)

Eve tried moving the config data/JSON extension property text to 1.1. We like this, but want to clean up the text a bit: "JSON data structures defined by this specification MAY contain extension properties that are not defined in this specification. Extension names that are unprotected from collisions are outside the scope of this specification." Do we want to discuss when non-understood properties should be ignored? This would be a good open issue.

General 3.4.1 discussion

AI: Eve: Create an issue around "ignoring semantics" for extensions.

AI: Mark: Survey spec solutions for "ignoring semantics" for extensions.

AI: Eve: Fix the "nonexclussive" typo in 3.4.1. Remove the final comma in the error_details example. Add to "The client then has the opportunity to engage in follow-on flows to continue seeking authorization." as follows: "The client then has the opportunity to engage in follow-on flows to continue seeking authorization, in a process sometimes referred as "trust elevation"." Change redirect_user definition to "A string, "yes" or "no", indicating whether the requesting party's presence at the authorization server is required for the process of claims gathering. For example, the authorization server may require the requesting party to fill out a CAPTCHA to help prove humanness. The default is "no" if this parameter is not present. See Section 1.4 for how the authorization server declares the requesting party claims endpoint to which the client has the opportunity to redirect the requesting party, if it wishes to continue seeking authorization." Change the name of permission_ticket to just "ticket". Change its definition to "The permission ticket. If the authorization server provides the "redirect_user" property, it MUST also provide the "ticket" property. This helps the client avoid maintaining this state information after completing its request."

AI: Eve: Ask Maciej whether the permission ticket that the AS hands back to the C needs to be there even in all need_info cases, as a kind of session handle, given that the authorization data-seeking attempt isn't done yet.

The "claim_format" is really the token format! Should we call these "claim tokens", to distinguish them from the other three kinds of tokens we already deal with? We like that.

The "name" property seems okay. The "value_type" could be called "claim_type" with no mental distress. Our EMail example isn't so great all by itself because name and claim_type are equal, but we could provide a second claim object that distinguishes them.

3.4.1.2.1 discussion

Break up the "If the client has a trust relationship..." sentence to shorten the sentences.

Make this all about "claim tokens", and change the property names accordingly.

Avoid mentioning "trust" by just talking about OOB provisioning of required claim token details.

For "can accept client-delivered claims", cross-refer to the hint about redirect_user.

Fix the broken array brackets in the example.

3.4.1.2.2 discussion

AI: Eve: Talk to Maciej about how the client passes the required callback URL or other state to the AS, so that the user can be passed back successfully. We need an example in this section as well.

A claims-unaware client can't redirect the RqP if the AS hasn't declared the relevant endpoint! So we need to make this clear.

Claim Token Profiling spec discussion

AI: Mark: Investigate an ID token and/or JWT claim token profile, with audience challenges and examples.

Issue status

92: Close! Worked out.

100: Close! OBE.

114: Close! Claim token profiles are all about pushing now.

110: Location URI: There's some reluctance to mix authorization and discovery, and location and other discovery metadata. But there's also a recognition of value of helping to solve the discovery problem. We don't mean the RO's physical location (like GPS), we mean the web location of a protected resource. Call it a "resource URI" then ("location" is dangerous!). Or "URL", then, since we know that is truly resolvable! The OpenID Connect distributed claims pattern looks like this.

Attendees

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

Eve
Andi
Mark
Domenico
Thomas
Sal
Robert

Non-voting participants:

Katie
Adrian
Zhanna

Next Meetings

We will hold all-hands meetings (calling the roll) through the fall and early winter as much as possible; voting participants please attend! We are now also holding ad hoc meetings on Mondays (not listed below). You can subscribe to the UMA calendar (and ask the chair to send you an event invitation) to see the times in your local time zone. Keep in mind that when the clocks change, we experience "summertime skew"; our home time zone is Pacific so non-US meeting times may shift.

Thu Dec 11 (ad hoc meeting 8-9am PT followed by) quorate meeting 9-10am PT
Thu Dec 18 (ad hoc meeting 8-9am PT followed by) quorate meeting 9-10am PT: possible to approve V1.0 drafts on this date?
No meeting Thu Dec 25 because of Christmas holiday
No meeting Thu Jan 1 because of New Year's Day holiday

Browser not supported