Versions Compared

Key

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

...

Ultimately we gained rough consensus not to target a solution for problem B in UMA 1.0. Although reducing friction is nice, it felt like premature optimization, which perhaps lots of other efforts (such as various "identity in the browser" efforts) would be trying to solve in a more elegant fashion. Also, this would add a lot of protocol overhead and state management and give hosts lots more responsibility for authorization jobs than we had intended to give them.

Problem C: The SMART project folks had assumed that it would be possible for a user, while visiting the AM, to "delete" a resource there (or, more accurately stated, canceling the AM's management of that resource's protection). Since the SMART host sample apps have found it useful to display to the user whether a resource is currently under protection management, the host would have to have a way to "pull" the current state of registrations from the AM in order to offer an accurate display.

(If the registration state also included some notion of which policies were mapped to which resources, then we'd partly be back in problem B territory, but we concluded that only resource registration information could be played back to the host if we were to decide to solve problem C.)

Other reasons why it would be useful for a host to pull resource registration state include various kinds of failure recovery where the host and AM have gotten out of sync. There are actually other, admittedly more clunky, ways to solve for the use case of letting users cancel protection "while visiting the AM", such as having the AM offer to open a new window to let the user visit the host and cancel protection management from there.

(After the meeting, in further discussions over beers, Eve suggested a more RESTful approach that could kill more birds with one stone, since we do have a design principle for RESTfulness and resource orientation. The host could POST a new resource registration construct at the AM representing the managed resources of a particular user, could add to it with PATCH, could GET its state at any time, and so on. We suspected Paul Bryan would approve. (smile) Maciej intends to take this idea forward.)