UMA telecon 2017-01-19

Owned by Eve Maler
Last updated: Jan 19, 2017

UMA telecon 2017-01-19

Date and Time

Agenda

  • Roll call

  • Approve minutes of UMA telecon 2017-01-12 

  • Logistics:
    • Meeting countdown: Jan 19 (today – week 0), Jan 26 (next week – week 1), Feb 2 (the week after – week 2), Feb 9 (WG Draft and Public Review vote – week 4)
    • We should strive for issue burndown and substantially complete specs by Feb 2 if possible – I may be calling on specific people to help close nitsy but not-very-substantial issues
    • No meeting Feb 16 because of RSAC

  • 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 12 (updated) and RReg is up to 04 (no change)
      • Set math and UMA grant vs. authorization interface updates; figure 3 removed
    • 266: Set math
      • Critique new wording (Core Sec 1.4.2, Sec 9.4, and impacts on Sec 3.6) and ensure it's sufficiently specified – e.g., the AS knows about resource IDs but the client doesn't, and the permission ticket can refer to multiple resource IDs, so is everything clear from that perspective?
      • Decide whether we need to be specific about AS implementation details (George's email)
      • Account for "previous RPT" logic
    • 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?
      • How many use cases?
      • Which are in our scope for V2.0 or out (e.g., separate modular specs that a V2.x could call out as an optional or required endpoint as part of the protection API or something)?
      • AIs for next steps?
    • 260: Cascading authorization servers
      • Is this in scope for V2.0 or out (e.g., a third-party extension that we could consider for a V2.x), considering the additional detail provided in email?
      • AIs for next steps? (don't do heavy design today)
    • "Dipstick check" on the RReg issues:
    • Easy issues to close by Tue Jan 24 if no comment by then:
      • 256: Naming and concepts
        • Proposal: Define "claim token" in the spec
  • AOB

Minutes

Roll call

Quorum was reached.

Approve minutes

Approve minutes of UMA telecon 2017-01-12: APPROVED.

Logistics

  • Meeting countdown: Jan 19 (today – week 0), Jan 26 (next week – week 1), Feb 2 (the week after – week 2), Feb 9 (WG Draft and Public Review vote – week 4)
  • We should strive for issue burndown and substantially complete specs by Feb 2 if possible – I may be calling on specific people to help close nitsy but not-very-substantial issues
  • No meeting Feb 16 because of RSAC

We should schedule an RSAC no-host drinks BOF.

UMA V2.0 work

266: Set math: The "default-deny" paragraph is still relevant because it's all about policy conditions, which are OOS for UMA, and you could have default-permit policies, which are pernicious. Maybe this statement should use a lowercase "must" because it can't be made testable, and say "must use a best effort" or something. For certain use cases, like "crunchy-shell security", or even "policies inside a micro-domain of permissiveness", how does an AS even manage access control? In any case, this paragraph should travel with the set math logic paragraphs (which we think should go back into an Authorization Assessment sub-section in Sec 3.6, which disappeared in rev 12).

A client can request (and register for) scopes around a public/standard API based on anticipated RS behavior around requesting permissions. But then if it knows the RS is going to put something in the PermissionTicket, it need not do anything. And a clueless client can also not register for or request anything. So an RS implementing a public/standard API (like FHIR) could document its practices around resource/scope requesting, and the client is all taken care of. But it's more private/proprietary APIs where the client has to take more responsibility.

George's email is a great example of the two paragraphs that were removed from rev 11's Authorization Assessment section. In fact, the two paragraphs are about the same subject. If the AS determines that the non-null GrantedScopes value isn't useful for the client for whatever reason, then it shouldn't be forced to grant an RPT; it should be allowed to error, in the same spirit as our not forcing the RS to return success in its response to the client on sufficiency of authorization.

How to handle PreviousRPT in all this? The AS would have to find all the claims relevant to having met all the scopes in that RPT. The task in email now is to look at when the previous RPT a) did and b) didn't contain resource IDs that were in the current request for access.

Shoebox: 246 etc: Eve's and Adrian's discussion has been happening in email. George notes that it could be quite valuable for an AS to have audit logging functionality, as captured in several of the issues. Mike makes a plea for not making breaking changes. George also notes that the Security Events group at IETF is working on something relevant as well (see the Security Event Token spec). There's a fair amount of interest, though time is short. The work seems possible to parallelize; an extension that proposes an endpoint and formats as required (or multiple extensions specs proposing more than one?), and the right community of interest that requires to use UMA along with an AS that presents that endpoint, would allow for rapid experimentation. However, Adrian would like this not to be an extension.

We have consensus to proceed on this work as a separate modular activity.

260: Cascading authorization servers: Recall that the use case (from the FHIR world) is that the RS has "edge authorization" it needs to perform, which it has ensconced in enterprise policies in its own authorization server. This is a way to have the "Adrian clause" reified in RPTs, and the client/RqP meet multiple sets of policy conditions, all the way. This connects to the shoebox question if you can get the RS to report what they've done. In the swimlane, the "downstream AS" is Alice's and the "upstream AS" (and any further upstream ones) belongs to the RS. So, in a way, this has positives and negatives: the incentives change because on the one hand an RS gets a lot more formal and dynamic control of liability, but on the other, it can control much more strongly what Alice gets to share, possibly enabling "data blocking" (a phrase from the health world).

This has been done as an extension already, so it could remain an extension for now. It has "set math" implications, because it introduces another set. Eve's observations about the flow:

  • AS needs to know about the other AS because it's a client of the permission request endpoint
  • Client needs credentials for the upstream AS(s) too
  • Client needs to keep an "AS stack" and to hold multiple RPTs for "that resource" (whatever that means to the client)
  • (George added:) There's new set math that each downstream AS has to calculate

George wonders if you could do this without cascading. Could the RS just issue a request that's "out of band", redirecting to each AS as necessary, and then when each process completes, there's some kind of meta-RPT structure, like a JWT that aggregates RPTs?

We're inclined to suggest this stays an extension for now. We'll check in with each other and the proposers next week.

Editing instructions:

  • Put our conclusions into Core rev 13.
  • (From ad hoc:) Try some language to soften the requirement for the AS to resolve the scope description document URI (issue 269).
  • (From ad hoc:) Send emails about each of the RReg issues.

(The official meeting ended and we kept going ad hoc to discuss RReg issues.)

269: Resource Reg Section 2.1: "URI MUST resolve to a scope description document":  Resource description documents are "private" and specific, but scope description documents are public and meant to be possible to standardize (e.g. pointing to third-party scope description documents), and thus, things like internationalization and localization of strings could be tricky. So a MUST is a big problem. At best, we can say that it's all down to developer documentation, not anything run-time. And as Mike pointed out, a URN isn't run-time resolvable in practical terms.

Since we rely on dynamic registration of resources and scopes, how ideally should this work? Eve wonders if we should add a new option: the string-based scope in a resource description is fine, a URI-based one that doesn't resolve is fine, but the RS could also resolve the scope description and stuff it into the resource description by value during registration. George notes that OIDC's "claim request hash" mechanism for handling localization could work. Mike asks if we're overdesigning. (smile) We're generally not crazy about playing I18N and L10N games with scope strings, either.

At the very least, we have to qualify that if the scope is a URN they don't have to resolve. And at the very least, the AS has to be prepared for failure to access any required scope description information.

271, 272: Add description fields to resource description doc and scope description doc: We just discovered that, since the "name" properties are defined to be friendly names, we don't really have a separate machine-readable name. Do we need one of those separately? But these issues are about "description". Resource description docs don't need I18N/L10N, but scope description documents might, for both a friendly name field and a description field. If we added a description field to scopes, then, do we want to make a breaking change and make this an array? Or leave the name as a default name that never changes and add an intl_name field or something like that? Or not care at all about I18N/L10N, but then possibly break things in future?

 

270: Resource Registration Document: 'uri' should be an array / examples: Gluu had actually assumed this was already an array, and implemented it that way! And wildcards would be really handy. Especially with the ability to request permissions (get permission tickets) "in bulk" now, registering resources seems to be an obvious parallel task that should be done in bulk. Note that there are two theories about when to register resources: eager (when they are created at the RS/host), and lazy (when the resource owner wants to share them). The latter puts resource registration very close to the time of permission requesting. So they would seem to want to be aligned. (Also note that our current design of requesting multiple permissions (resource IDs) has us using an array, but requesting a single permission (resource ID) uses an object! Other instances of ability to "do multiple things with one thing as an edge case" in the spec, as designed natively in V1.0, are all done as arrays.

To be floated on the list, and only discussed if not resolved prior.

Attendees

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

  1. Domenico
  2. Sal
  3. Eve
  4. Mike
  5. Cigdem
  6. Sarah

Non-voting participants:

  • Adrian
  • George
  • François
  • Colin L.
  • Scott F.

Regrets:

  • James
  • JohnW
  • Andi
  • Maciej

 

Â