UMA telecon 2014-11-20

Owned by Eve Maler
Last updated: Dec 02, 2014
5 min read

UMA telecon 2014-11-20

Date and Time

Agenda

  • Roll call
  • Minutes approval if quorum
    • Sample motion: 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.
  • 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

Minutes

Roll call

Quorum was reached.

Minutes approval if quorum

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.

Interop testing status and meeting schedule review

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.

108: scope implicitness

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.

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.

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:

  • auth context = RqP/C/AS -> AAT context ->    OAuth (or protocol based on OAuth)
  • claims = RqP features independent of client (tho' possibly conveyed by client if it is claims-aware)

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:

  • Fresh authentication by the RqP ("need reauthentication")
  • Stronger authentication by the RqP ("need stronger authentication/assurance")
  • Claims about the RqP ("need claims")
  • Claims about the RqP directly from the RqP ("need user interaction for claims-gathering")
  • Fresh claim by the RqP ("need claim again")
  • Sourced claim by the RqP ("need claim from issuer")
  • Other environmental attributes ("need geography" etc.) left for third parties to extend/profile

{
"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.

 

 


Attendees

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

  1. Mark
  2. Eve
  3. Robert Lapes - spoke at the IRM Summit in Dublin recently - had done EU Guide research on consent architecture
  4. Andi
  5. Mike
  6. Sal
  7. Yuriy
  8. Thomas
  9. Domenico
  10. Maciej

Non-voting participants:

  • Zhanna

Regrets:

  • tbs

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.

  • No meeting Thu Nov 27 because of Thanksgiving holiday in the US
  • Thu Dec 4 (ad hoc meeting 8-9am PT followed by) quorate meeting 9-10am PT
  • 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