UMA telecon 2017-01-12

Date and Time

Thursdays, special meeting times through Feb 9: 8:30-10am PT
- Skype: +99051000000481 / US +1-805-309-2350 / international lines / web calling interface / code 1782540
- Screen sharing: http://join.me/findthomas - NOTE: do not use the join.me dial-in line
- UMA calendar: http://kantara.atlassian.net/wiki/display/uma/Calendar

Agenda

Roll call
Approve minutes of UMA telecon 2017-01-05
UMA V2.0 work
- 2016 roadmap / GitHub issues for V2.0 (all issues to be kept here for the duration!) / dynamic swimlane
- Core is up to 11 and RReg is up to 04
  - Issues closed: 108, 234, 249, 261, 262, 268
  - Also tried out Justin's wording for how the AS and client handle invalidating/revoking an old RPT when the AS hands back a new RPT – see Core rev 11 Sec 3.6.6
- Please see new issues! We'll discuss as necessary next week; please comment online:
  - 271: Add 'description' to scope document
  - 270: Resource Registration Document: 'uri' should be an array / examples
  - 269: Resource Reg Section 2.1: "URI MUST resolve to a scope description document"
- Issues to discuss and close on this call:
  - 264: Authentication-related error details (quick)
  - 254: Hashed claims discovery (quick)
  - 266: Set math (hopefully we'll have some spec-like wording to guide us further by tomorrow)
  - 256: Naming and concepts, specifically authorization interface vs. UMA grant concept
- Issues to discuss and hand out assignments for:
  - 256: Naming and concepts, specifically a definition for and handling of the access token/claim token situation
  - 263: Claim token profiling / 119: Create an IANA registry for URIs that stand for claim token formats
  - Shoebox: 246: Endpoint for collection of "receipts" and notifications of RS action in case of extraordinary behavior / 245: Location Constraints / 224: RS Notifies AS or RO of Access / 63: Audit logs to support legal enforceability / 24: Possible to audit host's compliance in giving access based on a legitimate active permission from the AM?
  - 260: Cascading authorization servers
- Easy issues to close by Tue Jan 17 if no comment by then:
  - 256: Naming and concepts, specifically whether to rename PCTs
AOB

Minutes

Roll call

Quorum was reached.

Approve minutes

Approve minutes of UMA telecon 2017-01-05: APPROVED by unanimous consent.

UMA V2.0 work

Set math: In his Set Math Discussion email, Justin intended for ROPolicy to stand for the result of AS postprocessing of any policy conditions with which it has been configured. George intended for ROPolicy to stand for policy conditions prior to any AS processing. This may be moot for the math. Justin considered the math to be contextual to the resource set because of his implementation outlook, but George wants to ensure that, if the ROPolicy isn't sufficient to meet the requested policy, need_info (or "worse", definitive failure) is produced.

Eve notes that "RO" policy is really a set of policy conditions that could have come from a collaboration between the RO and the AS; see, e.g., the TTL section.

In George's "attempt at a simple example", Alice has policies that should result in Bob not getting access to download because he's not a family member. Let's think of ROPolicy instead as PolicyResults, (or even AuthorizationProcessResults?) and the value should be just (view, share).

Given Justin's interpretation that we're accepting, George's example set math stays the same, and the "determine which scopes are in play" section changes like this (download got removed, with no net change to the bottom line), and it should say "...based on claims collected and the authorization assessment performed":

Scopes = intersection(Requested, ROPolicy)
Scopes = intersection((view,share,print),(view,share))
Scopes = (view,share)

James proposed ClientRegisteredDefaults vs. the original OAuth ClientReg as a convenience/clarification. George thinks we don't need this because it's more of a burden on the client. The client knows it's dealing with whatever API and its scopes. Registering ahead of time lets it reduce its interactions at access attempt time. If we drop ClientRegisteredDefaults, it's incumbent on the client to register ahead of time.

Looking at the steps:

This now becomes: Requested = union(intersection(ClientRegistered,ClientRequested), RSTicket) If ClientRegistered OR ClientRequested is null, then RSTicket becomes all-important because the others won't get the client anywhere. If ClientRequested contains anything not previously in ClientRegistered, it gets dropped on the floor.
This is all part of the assessment process. Combine steps 2, 3, and 4 because they're all in this general area.
The pseudo-spec-text would change to say "...scopes for which RqP (and client) has satisfied authorization requirements" or something like that – with claims? figure out wording. We need a phrase that stands for the RqP-and-client. Would "requesting side" do?
This is the part of authorization assessment the AS would do if it's preparing to give a need_info error or maybe a request_submitted error (?). If it's preparing to give one of the other errors, it can dump out to those.
This would change to be error.
This would change to be success. This will need, in addition, the math that says what to do in the case that a previous RPT was supplied and was returned upgraded.

We have consensus on all the set math modulo previous-RPT handling.

Editing instructions:

Think up a phrase for "requesting side" and apply where necessary
Add spec text for everything but previous-RPT set math.
Implement the #264 decision where applicable.
Add to the extension grant type registry

AI: Everyone: Read the new set math spec text carefully ASAP when it's available, and implement if you can.

264: Authentication-related error details: Justin ran through the swimlanes he provided in the issue thread: with a local user and with a remote IdP, using OIDC's auth code as example. George asked about registration. If the RqP doesn't yet have an account, they'd have to do that step, right? Yes. Mike's question in the thread had been about login. There's a distinction between the (UMA) client and the AS as a claims client/RP. Eve insists on getting it on the record that pushed claims with secondary audience fields using pre-established trust are a legitimate, on-label use of ID tokens. No disagreement, but also noted that doing a lot of hinting around what other claims to push is not likely to be used in such ecosystems. Using redirect_user immediately on failing a plain request for an RPT is likely for the case where the AS intends to handle all the claims collection.

We have the UMA Implementers' Guide, where we could discuss things like achieving strong authentication. Or we could provide an example in the spec of profiling down to ACR values.

AI: Eve: Ask Mike Pegman if he has the strong authentication use case.

(The official call ended and we continued for a short while.)

Authorization interface and UMA grant: The spec is currently schizophrenic. The whole authorization process is the UMA grant, not just the client's interaction with the token endpoint. This means Figure 1 is wrong and Sec 3.6 is right. The preconditions for starting with redirection are that the client needs a ticket and the AS has to have statically declared the claims interaction endpoint (plus all the other stuff for entering Sec 3.6, which is the generic stuff for starting with approaching the token endpoint).

AI: Eve: Seek stylesheet help from Maciej/Oliver (and/or the xml2rfc list?).

254: Hashed claims discovery: Eve is wondering whether, in certain ecosystems where pushed claims have been pre-negotiated a la SSO with attributes, hinting specifically about needed claims is being used/going to be used. We should ask around about whether this is being used. This bears on the question of hashed claims discovery as a feature for consideration, since it could be added as an extension or in a V2.1. As an in-band hint, it's there to be useful to wider ecosystems. And if the AS were to say redirect_user on failing client-provided hints, that would suggest that a really colossal closed-ecosystem failure could be mitigated by something kind of surprising on the AS's part.

AI: Eve: Ask for instances of required_claims usage.

AI: Eve: Send out some new cascading authorization server information from VA.

AI: Eve: Send emails for the next issues to discuss.

Attendees

As of 22 Dec 2016 (post-meeting), quorum is 5 of 9. (Domenico, Sal, Nagesh, Andi, Maciej, Eve, Mike, Cigdem, Sarah)

Domenico
Sal
Eve
Mike
Maciej
Sarah

Non-voting participants:

George
Justin
JohnW
James
Colin

Browser not supported