Hmm. I think the duty may be different. E.g., I was just talking to my colleagues about a scenario where it might be desirable within the virtual walls of a company to constrain the kinds of policy that an employee-Alice could set, even if the AS could technically handle them, so that an accountant going on vacation couldn’t share the books with someone outside the company or something. Eve
On 9 Sep 2015, at 6:11 PM, Neiditz, Jon <JNeiditz@kilpatricktownsend.com> wrote:
Thanks. It may come down to the following question: Once the picking of the AS is done, is the duty of the AS to the RO (Alice or AliceCorp) the same or different in the below scenarios? (Unfortunately, I may need to drop out of sight until Friday morning.)
Jon Neiditz Kilpatrick Townsend & Stockton LLP Suite 2800 | 1100 Peachtree Street NE | Atlanta, GA 30309-4528 office 404 815 6004 | cell 678-427-7809 | fax 770 234 6341 jneiditz@kilpatricktownsend.com | www.kilpatricktownsend.com
-----Original Message----- From: Eve Maler [mailto:eve@xmlgrrl.com] Sent: Wednesday, September 09, 2015 8:50 PM To: Neiditz, Jon Cc: wg-uma@kantarainitiative.org UMA Subject: Re: [WG-UMA] New [legal] wiki pages with mappings to Agency law etc.
I’ll explain by way of examples. ‘Course, I might still be wrong!
In federated single sign-on, we have a “user”, a “service provider”, and an “identity provider” to which the service provider is somehow willing to outsource authentication (becoming a “relying party”).
There is (or used to be) a totally-empowered-Alice use case of federated SSO, where Alice could build or run her own identity provider using the OpenID protocol, and some service providers out there would accept it.
There’s a social login use case, where a social Alice gets to pick her identity provider (say, Facebook, or Twitter) from a set pre-chosen by the service provider.
There’s a consumer-but-hidden (sometimes “internal federation”) use case, where Alice gets a login at a consumer-facing company like Amazon, and that company uses technology to enable Alice to use that login among all the web properties owned by that company.
There’s an enterprise use case, where Alice gets an employee login that comes with assurance that she’s still employed, and the "service providers” are actually all the on-premises and web applications she needs to use to do her job.
In these cases, I could imagine using an agency lens to pick various different parties as the primary mover, on a continuum from Alice to (probably) the identity provider.
Analogously, in federated access (I just made that up), we have all the UMA-ish parties.
We can anticipate a use case of federated access where a totally-empowered-Alice can build or run her own authorization server... and a use case where a social Alice gets to pick her authorization server from among popular social offerings... and a use case where a consumer-facing company manages a tighter circle of services and centralizes their management for Alice’s convenience only among those... and even a use case where a company-run authorization server represents not Alice but AliceCorp, and manages access on its behalf.
There’s still the same number of parties in UMA, but the use case can change up the power dynamic a lot.
??
Eve
Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl@gmail.com