...
Shall we do UMArtinis and UMArgaritas again this year at RSA? Let's! George put in a Peer2Peer talk on standards and the IoT. What if we were to concentrate our efforts on supporting an UMA-related talk in the crowdsourced track? The submission process opens on Jan 29. Topics that might be interesting: trust el, digital enrollment, why to kill the password, panel announcing UMA V1.0... Maybe straightforwardly announcing the news might be best. RSA likes "controversial" panels. Sal is thinking of submitting his "Embedded UMA" talk as well. Maybe the UMA aspect could be soft-pedaled, and the live demo aspect could be highlighted. Getting both in would be awesome.
No meeting next week! We are meeting the following week at the APAC-friendly time (that is, apparently Wednesday afternoon/evening for non-APAC-ers.)
Interop progress
Mike sees Roland making lots of commits to his test harness – it appears on OIDC parts.
...
If an UMA client is running in a browser, for example, then it can't hold a secret in a trustworthy fashion. What does this mean for holding RPTs? In the "public" space, you can't prove it's the client making the request. So when the client is "non-provable", what do you do? Does the PKCE spec come into play? Should we name-check the "PKCE" spec now that it's got a new name? That's a way, in browser-based redirects, to ensure that you send a token back to the same client. So there's still a problem in the picture.
AI: Sal, George: Do a close reading of UMA Core Sec 8.1 against the OAuth Security Cheat Sheet and see where we can improve the former.
...