[Openid-specs-heart] An approach to data portability for the RO's policies

[Adrian Gropper]

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.

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.

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.

Adrian

On Tuesday, August 30, 2016, jim kragh <kragh65 at gmail.com> wrote:

> Thanks for sharing Eve.....  a tip of the hat to all three of you.
>
> Have a nice evening,
>
> Jim Kragh
>
> On Tue, Aug 30, 2016 at 8:44 PM, Eve Maler <eve.maler at forgerock.com
> <javascript:_e(%7B%7D,'cvml','eve.maler at forgerock.com');>> wrote:
>
>> 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 short slide deck
>> <https://www.dropbox.com/s/pjrno6mm9jencwv/Data%20portability%20for%20UMA.pdf?dl=0>
>> 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).
>>
>> ----
>>
>> (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.)
>>
>> ----
>>
>> (Of course, a policy API could also allow *writing* policies in to this
>> location from other authoritative sources. :-) )
>>
>>
>> *Eve Maler*ForgeRock Office of the CTO | VP Innovation & Emerging
>> Technology
>> Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl
>> *ForgeRock Summits and UnSummits* are coming to
>> <http://summits.forgerock.com/> *London and Paris!*
>>
>> _______________________________________________
>> Openid-specs-heart mailing list
>> Openid-specs-heart at lists.openid.net
>> <javascript:_e(%7B%7D,'cvml','Openid-specs-heart at lists.openid.net');>
>> http://lists.openid.net/mailman/listinfo/openid-specs-heart
>>
>>
>

-- 

Adrian Gropper MD

PROTECT YOUR FUTURE - RESTORE Health Privacy!
HELP us fight for the right to control personal health data.
DONATE: http://patientprivacyrights.org/donate-2/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20160830/f154521c/attachment.html>