Versions Compared

Old Version 3

changes.mady.by.user Eve Maler

Saved on

compared with

New Version Current

changes.mady.by.user Eve Maler

Saved on

Key

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

UMA telecon 2013-10-24

Thanks to DomCat for our seasonal UMAnitarian!

Date and Time

...

We reviewed Roland's proposal, and realized that it's more about resource sets that have resource subsets (all referring to the same scopes), rather than being about scopes with sub-scopes. Maciej observes that there's a lot of repetition in the example given, which could be factored out and made into a pointer somehowSo, in OpenID Connect-speak, it's akin to the phone scope resolving to explicit (vs. implicit) phone_number and phone_number_verified claims, so that you can create policies that let Bob access just one and not the other, or that let him access the whole set.

Eve was thinking that there are opportunities for "virtual" or "complex" layers for both resource sets (as Roland has demonstrated) and scopes, e.g., "read" and "write" could combine into "all". If we need resource sub/supersets, here's one design question we need to answer: Is there a need to have multiple overlapping sets of resources (attributes/claims in Roland's case)? Or is a hierarchy completely sufficient?

Thomas ask about the ability to do queries on resources before fetching them. Our resource set "type" property (see the RSR spec) does give the ability to query about the types of available resources, without mandating that the AS support this use case.

A resource set like "photo album" probably has available scopes that are different from a resource set like (individual) "photo" that it contains. So what would it mean to gather together a bunch of protected photo resources under a single protected photo album resource, and what scopes should/would apply to both? A "download" scope could apply to both. But a "resize" scope could only apply to a photo, not a photo album. What's the ideal resource set/scope description mechanism to account for these use cases?

(Eve notes that her email in response to Roland was technically incorrect, as his putative example is about not scope descriptions, but resource set descriptions.) However, her point about JSON Pointer still applies. The owner of an API (or the owner of a standard that the API leverages) could maintain a single scope description document and JSON Pointer could be used in scope URI references in resource set descriptions to "point into" the desired specific scope.

Roland is representing the "I Have A Customer" voice right now (smile), so we want to hear his answers so that we can design the appropriate solution.

Updating the spec and planning for the interop

Eve will set up a meeting for all interop participants around early December, to work on virtual interop plans for the beginning of 2014.

Eve and Thomas will get together soon to work on new spec updates. Maciej notes that the dynamic client registration spec has split into multiple specs, so we need to reference the new stuff, and also be sure that our feature tests are up to date. Also, Eve notes that OpenID Connect has new spec versions, and this involved a consolidation of multiple specs into fewer. And Josh Mandel actually went into GitHub and made a few improvements to our spec!

Thomas has been working with Josh and folks, e.g., at Mass General, and is doing some UMA explication in these forums. There seems to be a keen need to enable patients to share data from medical studies with their primary care physician (which might be entirely outside the Mass General "ecosystem" and even in a totally different geolocation). This makes Eve think we should prioritize the PHealthCloud video highly in December!

Attendees

  • Eve
  • Domenico
  • Thomas
  • Maciej

...