...
Managed vs. unmanaged: We came up with some new terminology and assumptions to help us figure out the connection between protocol features and desirable user experiences. We believe it's likely that a host will want to offer to protect some or all of a user's resources there with the same AM, rather than offering to split the protection of resources among multiple AMs.
[(After the meeting, Joseph later observed that migration to outsourced authorization could be a reason why a host would offer to protect only some resources with that single AM.])
Any resources that a host ends up not registering with an AM are what we decided to call unmanaged. An unmanaged resource could be totally public or totally private, for example, and in both cases its existence is entirely unknown to the AM. It's expected that whatever a host does when access is attempted to such a resource, it does not engage in the step-2 "UMA dance" of issuing a 401 and sending the requester to the AM for an access token.
...
(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 suspect Paul Bryan would approve. 
! Maciej intends to take this idea forward.)
Proposal draft issues: We collected the following comments and issues on the proposal draft (in addition to the RESTful idea above, which may supersede some of these):
- Should it be possible to "boxcar" the registration of multiple resources? The current "uri" parameter could have a comma-separated list as its value, as long as the same available scopes applied to all of them.
- Is it okay not to explicitly label scopes in the request message (e.g. with a "scopes" parameter)? Maciej and Lukasz felt that it would be possible to accommodate extension parameters by requiring them to be named "x-something".
- Is it okay to only have single-language display names for the scopes? We felt yes, since the host would already know the user's preferred language (if it even offered its interface in multiple languages) and so would have the opportunity to pick the most suitable display names for that user.
- Can we solve a use case where the user just indicates to "protect" (manage) resources at the host without going through all the steps of actually selectively sharing them? (For example, this might come into play when the user wants to ensure that some or all of their resources are "non-public", as you can do when uploading a bunch of photos to Flickr in batch.) We believe so, since the resource registration piece involves only host-AM communication and doesn't have to have the redirect-the-user-to-the-AM piece on the end.
Next Meetings
- WG telecon on Thursday, 11 Nov 2010, at 9-10:30am PT (time chart) - Maciej to chair