Don't forget that this week's WG call is Friday instead of Thursday, after the Legal call; please see the calendar http://kantarainitiative.org/confluence/display/uma/Calendar if in doubt. ==== In other news, I've managed to publish a new version of the RReg (used to be RSR) spec, rev 01 https://docs.kantarainitiative.org/uma/ed/oauth-resource-reg-2.0-01.html, a mere three months after rev 00. The main edits were squished into one big commit https://github.com/KantaraInitiative/wg-uma/commit/81814413b7ccb39576bc7a5cd.... Nothing all that huge changed and it's not that deep or philosophical a spec, but I'll list some food-for-thought topics here that I plan to add to the agenda for Friday: 1. Is this really and truly a spec that's independent of UMA ("OAuth" RReg)? Does it need an extension grant or token introspection extension of some kind to function properly? 2. We currently force scope URIs (vs. plain strings) to resolve to a scope description document, though we impose no testable-assertion penalty if this is violated. Do we want to keep this a MUST? 3. The Core spec allows RS's to manage protection of any resources it likes at the "edge", away from UMA. Should we say something explicitly in RReg as well about this option, sanctioning the option of letting an RS leave out any resources, and scopes of resources, that it wants? 4. Do we need to say something about resource registration taking place in the context of a resource owner or at least in the context of the trust relationship of an AS and RS? For UMA, it's all about the PAT context. This comes back to question 1... *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl