Quorum was reached.
Deferred.
Proceeding!
Done.
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.
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?
As of 2 Oct 2014, quorum is 8 of 14.
Non-voting participants:
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.