Quorum was reached.
MOTION: Moved by Andi: Approve the minutes of UMA telecon 2014-11-13 and read into today's minutes the notes of ad hoc WG meetings held since 2014-11-13. APPROVED by unanimous consent.
When to discuss new feature tests? Should we take a Monday if Roland can confirm availability? He's been learning from the OpenID Connect experience, and can apply these to our interops. Mike points out that nuances come out in interop testing that aren't obvious in spec writing.
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.
Any update from Marcelo on scope mapping best practices?
Update from Eve on https for scope identifiers: Joni has asked Oliver to look into this. Barring any unforeseen issues, we should be able to switch our scope URIs and other identifiers to https by V1.0. (Only our scope identifiers actually resolve; the others don't.)
The logic goes something like this: Interop would take a hit if a nonstandard scope keyword were used in favor of OAuth ecosystem friendliness – unless we do build in a scope keyword mapping mechanism. Is Eve's reluctance around a scope keyword mapping mechanism misplaced? Then again, do we want to invent a mapping infrastructure now, on the basis of fairly theoretical evidence?
The proposed wording was:
Incorporate scope keyword wording into Core:
"It is RECOMMENDED that an AS use the scope keyword "http://docs.kantarainitiative.org/uma/scopes/prot.json" to represent protection API access. A rationale to use a different scope keyword would be that the AS has existing infrastructure surrounding a different OAuth scope keyword that is too difficult to change. An access token with at least a scope that includes protection API access is called a protection API token (PAT) and an entity with this scope is definitionally a resource server."
"It is RECOMMENDED that an AS use the scope keyword "http://docs.kantarainitiative.org/uma/scopes/authz.json" to represent authorization API access. A rationale to use a different scope keyword would be that the AS has existing infrastructure surrounding a different OAuth scope keyword that is too difficult to change. An access token with at least a scope that includes authorization API access is called an authorhization API token (AAT) and an entity with this scope is definitionally a client."
Our existing deployment experience, which admittedly is limited to closed and enterprise-related ecosystems, shows that the scope keywords are being used. Mike anticipates talking to Chuck Mortimore about this sometime soon. Can we find the candidate API publishers that might want to wrap an UMA-standardized API?
AI: Eve: Ask Marcelo to investigate the question of candidate API publishers wrapping UMA APIs.
AI: Eve: Update issue #108.
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.
Robert notes that "need reauthentication" is not quite right semantically. Eve suggests a brute-force reworking: "authentication context unacceptable"! What's the right naming scheme across the buckets? Should they be a single bucket? Eve argues that it's consistent to have them be two buckets:
AAT issuance and claims assertion/authz data issuance are distinct, not only in the protocol, but in the binding obligations. Then Andi asks: Is it inconsistent for the AS to return both? Maybe they have an order: you have to do reauth first, then claims.
Do we want to include a hint for this one that says the RqP's authentication context was too old/stale/expired and needs to be redone? And what about need_redirect? Here are things the AS might reasonably want next:
{
"error":"elevate_trust",
"error_description":"Some description.",
"error_uri":"<URI here that provides detail information of the error>",
"error_details":{
"authentication_context":{
"force_authentication":"yes",
"required_acr":[acrs]
}
"claims":{
"required_claims":[
{
"name":"name",
"format":"[format]",
"issuer":"[issuer]",
"issued_after":"timestamp"
}],
"redirect_user":"yes",
"redirect_state":"string"
}
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.
As of 17 Nov 2014, quorum is 7 of 12.
Non-voting participants:
Regrets:
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.