<div dir="ltr">Hmm, I don't buy this reasoning. If Alice has a reason to switch AS's, that's <i>her</i> reason, and if there are someday many consumer-facing AS choices, market-sensitive AS's might want to make it easy to at least import and export such data smoothly (though admittedly an API approach is more necessary for ongoing access than one-time transfer).<div><br></div><div>But I don't see why there couldn't (<i>eventually</i>) be reasons to send policies elsewhere or ingest policies from elsewhere, maybe not to and from other AS's, but for other purposes -- interacting with apps that run analytics over policies, adopting standard helpful policy packages that work with standard APIs in order to set up default sharing profiles, running IFTTT recipes to check for common oversharing patterns, and the like. Once you see policies as "just more data available through just more APIs and protectable through UMA like everything else", the sky's the limit for use cases that could be beneficial to the RO.<div><br></div><div>(Note that, if you consider authorization policy to contain personal data, Article 18 of the <a href="http://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A52012PC0011">GDPR</a> would mandate the right to data portability over it...)</div></div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr">
<p><b>Eve Maler<br></b>ForgeRock Office of the CTO | VP Innovation & Emerging Technology<br>Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl<br><b>ForgeRock Summits and UnSummits</b> <a href="http://summits.forgerock.com/" target="_blank">are coming to</a> <b>London and Paris!</b></p></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div>
<br><div class="gmail_quote">On Tue, Aug 30, 2016 at 6:51 PM, Adrian Gropper <span dir="ltr"><<a href="mailto:agropper@healthurl.com" target="_blank">agropper@healthurl.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Another reason not to export policies is because it trashes the ability for the RO to centralize their control. With the current model, RSs and Clients can be asked to come to Aiice's AS for authorization and Alice has a convenient single place for management. As soon as we allow policy export, we end up back in the multiple portals problem. The switching cost for Alice to substitute one RS for another also goes up.<span class="HOEnZb"><font color="#888888"><div><br></div></font></span><div><span class="HOEnZb"><font color="#888888">Adrian</font></span><div><div class="h5"><br><div><br>On Tuesday, August 30, 2016, Adrian Gropper <<a href="mailto:agropper@healthurl.com" target="_blank">agropper@healthurl.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Once we put the RO's policies on the wire we're down the road of deprecating the user-centric design of UMA and back to an institutional focus. Instead of a Resource Server offering to register the AS specified by the RO, the RS will force users to use their AS and simply "share" policies with it. This takes a huge amount of power away from the RO for absolutely no reason that I can see.<div><br></div><div>This is totally equivalent to saying that I should share my password with every service as a way to do single sign-on. Yes, I works and yes it seems simple, but the tight binding across service providers that results is oppressive and does no scale.<br><div><br></div><div>If UMA does not allow me to specify my authorization server then I'm not sure why we're bothering at all. We don't have to compromise user-centered design. </div><div><br></div><div>Adrian<br><br>On Tuesday, August 30, 2016, jim kragh <<a>kragh65@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Thanks for sharing Eve..... a tip of the hat to all three of you.<div><br></div><div>Have a nice evening,</div><div><br></div><div>Jim Kragh</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Aug 30, 2016 at 8:44 PM, Eve Maler <span dir="ltr"><<a>eve.maler@forgerock.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">In a conversation today with Debbie, Ken, and Nancy, an old idea came to mind that I thought I'd capture in a diagram. Here's a <a href="https://www.dropbox.com/s/pjrno6mm9jencwv/Data%20portability%20for%20UMA.pdf?dl=0" target="_blank">short slide deck</a> illustrating the idea: The AS would present an UMA-protected API enabling Alice to share her policies out of the AS where she configured them in the first place to other places (say, other AS's that she wants to use instead, or for backup or federated policy management purposes).<div><br></div><div>----<br><div><br></div><div>(Keep in mind that an AS isn't actually required to store policies at all; they don't appear on the UMA wire. However, this service is the common facade where tokens do get issued after authorization assessment, and it's natural to build an AS on top of existing access management components that actually do policy handling and evaluation.)</div><div><br></div><div>----</div><div><br></div><div>(Of course, a policy API could also allow <i>writing</i> policies in to this location from other authoritative sources. :-) )<span><font color="#888888"><br clear="all"><div><div data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr">
<p><b>Eve Maler<br></b>ForgeRock Office of the CTO | VP Innovation & Emerging Technology<br>Cell <a href="tel:%2B1%20425.345.6756" value="+14253456756" target="_blank">+1 425.345.6756</a> | Skype: xmlgrrl | Twitter: @xmlgrrl<br><b>ForgeRock Summits and UnSummits</b> <a href="http://summits.forgerock.com/" target="_blank">are coming to</a> <b>London and Paris!</b></p></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div>
</font></span></div></div></div>
<br>______________________________<wbr>_________________<br>
Openid-specs-heart mailing list<br>
<a>Openid-specs-heart@lists.openi<wbr>d.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-heart" rel="noreferrer" target="_blank">http://lists.openid.net/mailma<wbr>n/listinfo/openid-specs-heart</a><br>
<br></blockquote></div><br></div>
</blockquote></div></div><br><br>-- <br><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><br><div dir="ltr">Adrian Gropper MD<span style="font-size:11pt"></span><br><br><span style="font-family:"Arial",sans-serif;color:#1f497d">PROTECT YOUR FUTURE - RESTORE Health Privacy!</span><span style="font-family:"Arial",sans-serif;color:#1f497d"><br>HELP us fight for the right to control personal health data.</span><span style="font-family:"Arial",sans-serif;color:#1f497d"></span><span style="font-family:"Arial",sans-serif;color:#1f497d"><br>DONATE:
<a href="http://patientprivacyrights.org/donate-2/" target="_blank"><span style="color:#0563c1">http://patientprivacyrights.or<wbr>g/donate-2/</span></a></span><span style="color:#1f497d"></span>
</div></div></div></div></div></div></div><br>
</blockquote></div></div></div></div><div class="HOEnZb"><div class="h5"><br><br>-- <br><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><br><div dir="ltr">Adrian Gropper MD<span style="font-size:11pt"></span><br><br><span style="font-family:"Arial",sans-serif;color:#1f497d">PROTECT YOUR FUTURE - RESTORE Health Privacy!</span><span style="font-family:"Arial",sans-serif;color:#1f497d"><br>HELP us fight for the right to control personal health data.</span><span style="font-family:"Arial",sans-serif;color:#1f497d"></span><span style="font-family:"Arial",sans-serif;color:#1f497d"><br>DONATE:
<a href="http://patientprivacyrights.org/donate-2/" target="_blank"><span style="color:#0563c1">http://patientprivacyrights.<wbr>org/donate-2/</span></a></span><span style="color:#1f497d"></span>
</div></div></div></div></div></div></div><br>
</div></div></blockquote></div><br></div>