[WG-UMA] Draft minutes of UMA telecon 2014-10-16

Eve Maler eve at xmlgrrl.com
Thu Oct 16 12:01:57 CDT 2014


http://openid.net/specs/openid-connect-core-1_0.html#IDToken
Minutes
Roll call
Quorum was reached.
Minutes approval if quorum
Deferred.
Interop testing status
Proceeding!
Meeting schedule review
Done.
FT-impacting issues on V1.0 docket: close in today's call if possible!
FT-impacting issues on V1.0 docket
88/99: Eager permission registration
Is it in fact the case that there may be two RPTs floating around that may work, and do we care? Yes there may. Do we care? It seems not, as tokens might expire (or be revoked by the RO) at any moment.
Does it trouble us that the client might bring a "bad" RPT back to an AS over and over again, even if handed back a new one? What is the logical behavior for a client to implement? We're not sure. E.g., if a client handed in RPTa and got back RPTb, would it ever later hand in RPTa again, or would it switch to handing in RPTb in a "chain" to get RPTc etc.? We may not care. If this is purely in the realm of implementation, then it's best to be very loose with our prescriptions – it's not about interop.
So the wording choice we're considering is:
Once the authorization server issues the requested authorization data, it associates it with an RPT and responds to the client with an HTTP 200 status code and a response body containing that RPT. If the client didn't present an RPT in the request for authorization data, the authorization server creates a new RPT. If the client did present an RPT in the request, the authorization server returns the RPT with which it associated the authorization data, which may be either the RPT in the request or a new one. Note: It is entirely an implementation issue whether the returned RPT is the same one that appeared in the request or a new RPT, and it is also an implementation issue whether the AS chooses to invalidate or retain the validity of the original RPT in this case.
92: trust elevation/"need_reauthentication"
This is a proposed new fourth option for the AS response types when the client asks to add authorization data to an RPT. Currently, the core spec doesn't have the need_reauthentication response option to hook response hints off of, the way we have the need_claims response option that we hook the claims-gathering profiling off of.  Mike notes that in his profile, the domain_auth_level and domain_auth_mode are old and have been changed, but he thinks that the required_acr_uri and authentication_uri properties may be globally useful enough to consider adding. Without providing the authentication URI, you'd have to assume that the UMA AS and the authentication server are the same. Otherwise you have you inform the client what your IdP (or OP) is. An acr is an authentication context descriptor ("authentication context class reference").
We have consensus to add the response option. What do we think of the name of it? Eve likes "need_(something)" for parallelism. Is "...reauthentication" okay? Unless we hear something better, perhaps it is.
AI: Eve and Thomas: Draft text.
Do we have consensus to add a property to pass along a hint about the required authentication context, and if so, what should it be called and should it be part of the core spec? Mike's rationale is to help the client not waste time collecting a type of authentication that wouldn't be sufficient. Andi has a concern that putting this in may be too constraining. What if you want to pass multiple properties in a more complex structure, e.g. LOAs and such? This could be done in a separate profile much as for the claims-gathering profile spec.
AI: Eve: Revise trust elevation profile issue to limit the scope down to just the acr_uri issue now. Make sure to mention that this could be plural (an array).
AI: Eve: Add Marcelo's "implicit OAuth scope" issue to GitHub.
Do we have consensus to add a property to pass along a hint about the authentication URI endpoint, and if so, what should it be called and should it be part of the core spec? Isn't this already covered by the fact that the AAT is a regular OAuth token, issued from the AS as an OAuth as through the endpoints advertised in the UMA config data for this purpose?

105: status parameter in resource reg
94: start_at for permission validity
84: UMA endpoint names vs. OAuth endpoint names
Attendees
As of 2 Oct 2014, quorum is 8 of 14.
Eve
SteveO
Domenico
Andi
Jin
Maciej
Mike
Sal
Non-voting participants:
Zhanna
Adrian
Ryan
Marcelo
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! 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 Oct 23 9-10am PT
(Clocks change in Europe on Oct 26)
No meeting Thu Oct 30 because of IIW – we are holding an open UMA implementors' meeting on Oct 29 at IIW instead
(Clocks change in US and Canada Nov 2)
No meeting Nov 6 (Eve regrets)
Thu Nov 13 9-10am PT
Thu Nov 20 9-10am PT
No meeting Thu Nov 27 because of Thanksgiving holiday in the US
Thu Dec 4 9-10am PT (change from APAC-friendly time)
Thu Dec 11 9-10am PT
Thu Dec 18 9-10am PT: possible to approve V1.0 drafts for public review in January on this date?
No meeting Thu Dec 25 because of Christmas holiday
No meeting Thu Jan 1 because of New Year's Day holiday


Eve Maler                                  http://www.xmlgrrl.com/blog
+1 425 345 6756                         http://www.twitter.com/xmlgrrl

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://kantarainitiative.org/pipermail/wg-uma/attachments/20141016/1240055d/attachment.html>


More information about the WG-UMA mailing list