[WG-UMA] Thoughts on requirements for registering discovery metadata about resources

Eve Maler eve at xmlgrrl.com
Sat Nov 17 23:16:14 EST 2012


Here are some random thoughts on what UMA needs to do to enable discoverability of resources. These may be completely off, as I know the SMART team has already figured out some sort of answer from their perspective, but this is just to stimulate discussion...

Currently, the AM is expected to present an interface to authorizing user Alice that helps her configure access policies for protected resources. To this end, we built in some "resource set description" metadata that the host provisions to the AM to help it populate this interface: an icon URL and text labels for the resource set and for the various scopes of access that are enabled for it.

If the AM is also meant to play the role of a discovery service when requesters come looking for certain information of Alice's but don't know where it can be found, it needs to be provisioned with additional information, such as the resource type and location. Identity claims about Alice are a subset of Alice's resources; we should try to leverage existing claim catalogs for this.

Perhaps we should make resource set descriptions a formal extension point within UMA, similar to token profiles and claim profiles. There could be multiple "UMA resource description profiles" in the world, where we might define one or more in our own spec, possibly mandatory-to-implement or possibly not.

It should be noted that UMA's existing "claim profile" for OpenID Connect is a different purpose than this proposed extension point. UMA claim profiles specify what claims to gather from the *requesting party* for the purpose of authorization, matching against Alice's policy. "Resource description profiles" would be for enabling sharing and discovery of the *primary* resources being UMA-protected. Of course, in recursive/reciprocal fashion, Bob could UMA-protect his claims that end up getting used by Alice's AM in the process of authorizing Bob to get access to Alice's calendar...! This is exactly the reciprocal scenario Domenico has outlined from his earliest conception of "trusted claims"; see his UX vision for UMA-protected claims here:

http://kantarainitiative.org/confluence/download/attachments/41026357/UMAUX_Trusted_Claims_v08b.pdf

Here are some concrete code examples to make things clear. An existing UMA-specific resource set description for, say, a photo, looks something like this:

(taken from http://docs.kantarainitiative.org/uma/draft-uma-core.html#resource-reg-example)
{
  "name": "Steve the puppy!",
  "icon_uri": "http://www.example.com/icons/flower",
  "scopes": [
    "http://photoz.example.com/dev/scopes/view",
    "http://photoz.example.com/dev/scopes/all"
  ]
}

The name and icon URI were our best guesses about information the AM would need to display to Alice when she goes to set policy about how the photo should be protected/shared. But this JSON structure could contain other information, such as this:

{
  ...
  "resource_type": "http://claimcatalog.example.net/claim/jpg_photo"
  "resource_loc": "https//photoz.example.com/alice/photoz/steve.jpg"
  ]
}

If the AM knew this additional information, it could serve as a host for an intermediate UMA-protected resource whose content is the resource location field. If the requester wins authorization to retrieve this resource, they would then know where to go to try and access the actual resource on the actual host. OpenID Connect uses a mechanism similar to this for solving the "distributed claims" challenge. Ideally, UMA would work in a fashion very similar or identical to OpenID Connect in enabling requesters to bootstrap discovery of a resource's location. (But see our discussion to date on this topic here: https://github.com/xmlgrrl/UMA-Specifications/issues/20 )

As a side note, our current resource set descriptions require scope URIs, which point to machine-readable scope descriptions. This mechanism allows for standardized access scopes one-by-one, but doesn't go as far as enabling standardization of resource types. If you look at OpenID Connect, it has reserved claims, and also standardized OAuth scopes for them; it's possible for the associated scopes to be *implicit* if the resource type being mentioned already comes with standard scopes.

	Eve

Eve Maler                                  http://www.xmlgrrl.com/blog
+1 425 345 6756                         http://www.twitter.com/xmlgrrl


More information about the WG-UMA mailing list