[Wg-uma] New Scenario "Distributed Social Networks" and a modular specification
eve at xmlgrrl.com
Tue Aug 18 09:27:22 PDT 2009
Ugh, this has to be one of the more incomprehensible emails I've ever
written. Sorry about that. I'll try to get proper time to re-think
and re-explain later...
On 18 Aug 2009, at 7:15 AM, Eve Maler wrote:
> On 17 Aug 2009, at 12:14 AM, Christian Scholz wrote:
>>> Christian-- Thanks very much, for many things! The new scenario,
>>> the modularity suggestions, and your very active participation in
>>> today's call.
>> You are very welcome :-) And also thanks for explaining your
>> The key concepts I see in those scenarios for now are:
>> - authorization between two parties (three with user)
>> - authorization between more than two parties (plus user)
>> - policy negotiations between all those parties
> I *think this is right. The way I'd put it is: The basic template
> is to let the AM impose the user's chosen authorization policies
> through decisions it makes when the SP asks if it can grant the
> Consumer access, and to give the Consumer choice around meeting the
> user's terms into the Consumer's hands at the point of authorized
> access. Policies can be imposed unilaterally; terms require someone
> to agree to/meet them.
> The calendar scenario is very basic, allowing its use case to
> explain the bare bones of how we came up with the user/AM/SP/
> Consumer flow for data sharing. The photo set scenario adds the
> wrinkles of complex service access and an explicit requirement for
> OAuth integration.
>> There might also be a similar scenario btw with virtual worlds
>> based on Linden Lab's OGP approach which also is valid for an
>> approach around a service catalogue. The main concepts are the same
>> as virtual worlds are also social networks but one key difference
>> might be that it's annoying to get asked any
>> question in case you move from one simulator to another (e.g. by
>> walking over a border). Here some means needs to be found to make
>> this authorization/policy step more automatic maybe limited to a
>> certain domain or by some means of a web of trust approach. But I
>> can write more details about that in a different mail.
> That would be great. Infinity Linden and I have managed to spend a
> little time together, reviewing her needs and the ProtectServe
> proposition, but I'd love to get virtual-world scenario into the doc
> that focuses on the special characteristics needed.
>>> I agree with an approach of small modular specs with extension
>>> points/"interfaces" to other specs -- which may be our own, may
>>> come from elsewhere, or in some cases may not even exist yet (as
>>> long as we have a temporary workaround or a default).
>>> We'll have to try your specific extension point suggestion and see
>>> if it will work. If we approve a scenario that involves, say,
>>> just auditing access without imposing terms/policies (this is
>>> something I've thought about!), then it would make this
>>> demarcation point even more obviously necessary.
>> Well, policy negotiations could always happen in the same step in
>> which a service (OAuth now calls them clients IIRC, btw) wants to
>> access a server and again needs to retrieve a token. This could be
>> basically a reissueing of a token which also might include policy
>> information. I don't know all OAuth extensions but in case we need
>> to create one ourselves we can also choose an extensible format
>> (e.g. XML, maybe XRD would even work in case we express policies as
>> <Rel> elements) and either policy information is around or it isn't.
> Yikes, I need to catch up on the OAuth changes. So what was a
> Consumer is now a client? Not bad; an overall improvement. It sort
> of mirrors the terminology in the Liberty identity web services
> framework: "web service client" or WSC, vs. "web service provider"
> or WSP. :-)
> The essential thing that we are trying to add with UMA is an
> externalized authorization function, which can not only track but
> control access on the user's behalf, even when the user deals with
> many different services and clients (hopefully I have that right).
> I've heard of a notion of "sticky policies" that travel with the
> content they're supposed to apply to, but I worry a lot about how
> closely this skates to DRM, and how many technical problems it buys.
> The most popular policy format in the enterprise world is XACML, an
> XML-based format expressly designed for authz. And there are
> starting to be interesting XACML profiles, like "Policy
> Constraints", which may be directly relevant to us and which don't
> look scary, even if ordinary users happen upon it:
>> But I haven't thought about the actual flows needed yet and if they
>> actually go into the right direction. But if policies are stored in
>> the AM (or at least the set of granted policiy elements) the AM
>> needs to ask the server for a new token anyway and can also pass
>> policy information in case they have changed since the last time
>> (and how long would a server need to cache that information?).
> We probably do need to do some technical sync-up, as the AM is in a
> position of granting tokens, not asking for them... This is where I
> think your original sketch of a 4-legged flow and the ProtectServe
> flow were sort of mirror images of each other. Figuring this out
> would be very useful for us (and everyone) to get the bigger
> picture, I suspect.
>> But as I have no clear picture of the technical flow right now I
>> guess this can be discussed later in detail (as long as we know we
>> need to discuss it).
>> PS: As told on the call I won't be available for this week's call
>> as I am on the road. Will be back next week.
> We'll miss you! I've added your name under the Regrets header on
> our fledgling page for the 2009-08-20 meeting.
> We should think about scheduling an extra hour -- perhaps the hour
> before the next call that Christian can attend -- to review the
> current flows on the table and compare technical notes...
> Eve Maler
> eve at xmlgrrl.com
> Wg-uma mailing list
> Wg-uma at kantarainitiative.org
eve at xmlgrrl.com
More information about the Wg-uma