[Wg-uma] New Scenario "Distributed Social Networks" and a modular specification
cs at comlounge.net
Mon Aug 17 00:14:38 PDT 2009
> 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 scenarios.
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
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.
> 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.
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?).
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
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.
> BTW, I intend to throw a bunch of scenario and use-case suggestions
> into email, and I encourage others to do the same. For ease of
> finding champions to work on them later, how about we hashtag our
> email message content? Like this (for the scenario point made just
> #scenario: AM audits access without needing to authorize it
> And from the discussion in today's call:
> #scenario: Managing ACLs for service authz through integration with
> PoCo or a similar contact service
> #usecase: For Distributed Social Networks scenario, showing that the
> Consumer approaches a Discovery Agent first
> #issue: How an SP can convey a manifest of managed resource URIs and
> their descriptors to an AM
> #scenario: Showing "eager" AM contact with a Consumer to invoke some
> provision of a data-sharing condition, vs...
> #scenario: Showing need for infrequent (vs. every-time) requests by
> an SP for AM to grant access
> #scenario: A user selling access to data
> (Even if no one else finds this way of making our email more
> "machine-readable", I know I will; hopefully it doesn't look too
> On 13 Aug 2009, at 8:42 AM, Christian Scholz wrote:
>> Hi there!
>> Just to inform you: I added a new scenario to the list titled
>> "Distributed Social Networks":
>> This is mainly what my focus is on. If you have questions about it
>> or something is not clear please provide feedback.
>> Additionally I wanted to come back to the discussion point on the
>> last call about how to develop the specification.
>> I would like to suggest to try a quite modular approach where a
>> base spec would only contain very little functionality
>> but lots of extension points. E.g. I like that the XRD spec is
>> supposed to be very lightweight (I personally would remove
>> even more from it) but is extensible via XML namespaces. The same
>> for OAuth where the actual authorization mechanism and the
>> process of obtaining a token are now two separate specifications.
>> Thinking about my scenario I could imagine the following (not sure
>> it fits everything though):
>> - a base specification which enables distributed authorization
>> without any policies attached (just authorize the use of a certain
>> - additional specifications defining different policy mechanisms
>> I am not sure that fits but maybe we can come up with something
>> modular, even if we first start with only one and see later what
>> might be an extension and thus can be factored out.
>> Just some thoughts!
>> PS: I am not sure I can make it 1:30 today so I might have to drop
>> out after 1h.
> Eve Maler
> eve at xmlgrrl.com
Christian Scholz Homepage: http://comlounge.net
COM.lounge GmbH blog: http://mrtopf.de/blog
Hanbrucher Str. 33 Skype: HerrTopf
52064 Aachen Video Blog: http://comlounge.tv
Tel: +49 241 400 730 0 E-Mail cs at comlounge.net
Fax: +49 241 979 00 850 IRC: MrTopf, Tao_T
neuer Podcast: Der OpenWeb-Podcast (http://openwebpodcast.de)
new podcast: Data Without Borders (http://datawithoutborders.net)
More information about the Wg-uma