Versions Compared

Old Version 1

changes.mady.by.user Eve Maler

Saved on

compared with

New Version 2

changes.mady.by.user Eve Maler

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Minutes

Roll call

Quorum was not? reached.

Approve minutes

Approve minutes of UMA telecon 20162017-1201-01: tbs05: APPROVED by unanimous consent.

UMA V2.0 work

Set math: 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 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:

  1. 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.
  2. This is all part of the assessment process. Combine steps 2, 3, and 4 because they're all in this general area.
  3. 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?
  4. 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.
  5. This would change to be error.
  6. 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: tbswith 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 (smile) 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)

  1. tbsDomenico
  2. Sal
  3. Eve
  4. Mike
  5. Maciej
  6. Sarah

Non-voting participants:

...

  • George
  • Justin
  • JohnW
  • James
  • Colin

Regrets:

  • tbs