[Wg-uma] New Scenario "Distributed Social Networks" and a modular specification
eve at xmlgrrl.com
Tue Sep 1 17:30:36 PDT 2009
On 31 Aug 2009, at 3:07 PM, Christian Scholz wrote:
> Eve Maler schrieb:
>> First observation: I'm not sure I understand the authorization/
>> parties "key concepts" list below. I'd say, rather, that there is
>> a single act of authorization happening, with the opportunity for
>> two kinds of constraints to be imposed on the authz decision --
>> both of them derived directly from the user's wishes. The first
>> kind of constraint is "policy" that can be imposed unilaterally,
>> without the Consumer/Client even knowing about it. The second kind
>> is "terms/conditions" that the Client must meet before gaining
> It might be good to have examples for that. For me as non native
> speaker it's not always clear what's meant.
> So I think what we might have is:
> - The Service Provider having some sort of TOS which are fixed. They
> can have things like:
> - I do not give out your data to third parties without your consent
> - All you upload belongs to us
> - We can terminate your account on every third tuesday of a month
> but only until 11am
> - The user can tell the Authorization Manager under which conditions
> a Service Provider should give access to a Consumer or which parts
> of the data are given out. Examples:
> - Only give out day and month of my birthday but not the year
> - Only give out free/busy information of my events etc.
> - I am not sure about an example for conditions.. maybe "give out
> my profile to user with id X but not with ID y"? (assuming the
> Consumer will tell the SP which user is going to have access to it
> but this might be solvable with some kind of tag system. The AM then
> might need to tell the Consumer which users are allowed. But for
> this some use case might be handy)
> So I guess the first one are terms and the second policy.
Your guesses, I would say, are correct. To a first approximation, I
would define policy as something can be executed unilaterally, and
terms as something that require the other party to act in some
fashion. (They do sort of "meet in the middle", though.)
You gave great examples of user-driven policy. To give a fuller idea
of user-driven policy and also some terms we've had in mind, below is
a portion of the most recent wireframe I had developed for the
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 323129 bytes
Desc: not available
-------------- next part --------------
Warning: This is all absolutely hypothetical, and doesn't perfectly
reflect my current preference for terminology etc.! However, it may
be useful nonetheless. In this wireframe:
- "Choose how long to allow access" is about policy because the AM can
execute the user's wishes unilaterally.
- "Select a default resource-sharing contract" is about terms because
the user is requiring (per the ProtectServe flow) that the client
service *meet* the terms (either by agreeing to the hypothetical set
of terms called NoSelling-NoCaching-NoIndemnity-V1.0, or by supplying
a receipt proving they paid some required amount, or whatever).
- "Choose automatic vs. manual sharing" is largely about policy, since
the authz service manages the process of pinging the user all by
itself -- BUT it may have implications for the exact terms offered to
the client service, because the terms may have to state that the user
reserves the right of refusal.
>> (We can imagine a policy/term hybrid that conditions the Client's
>> access on merely being informed: "Access this resource at your own
>> risk; here are my policies..." Do we need to consider a #scenario
>> for this? Something like "Informing a Consumer/Client of the
>> user's terms without requiring positive confirmation of meeting/
>> accepting them.")
>> Second observation: I think it would be useful for at least
>> Christian and me, and likely others, to do a closer examination of
>> the proposed flow in ProtectServe, and maybe compare/contrast with
>> expectations and other models. I dimly recall Christian's earlier
>> experimentation with "4-legged OAuth" flows being a kind of mirror
>> image of the PS proposal. Perhaps we can see if there's general
>> interest for this in tomorrow's call.
> Now that we did it I am still confused but I might harrass you again
> with my questions. In the meanwhile I wrote down some additional
> attempt at doing a protocol but without much thinking if this would
> work security-wise. It's similar to PS in that it has an AM and an
> initialization phase etc. but it's different in some points. The
> main idea is that it replaces the redirect-flow of OAuth for
> retrieving the OAuth token by the AM which sort of proxies the token
> exchange and has the client and server preregistered:
> Comments are welcome but as I said, not much thought about or read
> over it again (maybe it is even the same as PS ;-) ).
I think it's not the same as the sketch of ProtectServe today, but it
adds the discovery service in the same way as the "distributed social
network" scenario you had already written up, so it's a great revision
of that scenario. The distinctive aspects aren't that it's social;
- Discovery service is approached before any SP (Server / Hosting
Service / entity #3 / etc. :-) is
- Location of the discovery service has to be bootstrapped/discovered
somehow during authn
I'll try and do some quick responses "for the record" on your thoughts
below, but we probably want to work through some of these on the phone
if we can...
>> Towwards the goal of syncing up, please forgive me for any
>> repetition, but here's a quick-reference summary of the
>> ProtectServe flow (detailed view here: http://www.xmlgrrl.com/blog/archives/2009/06/02/protocol-peep-show/
>> 0. User mediates the introduction of service provider to
>> authorization manager. This is almost entirely straight OAuth,
>> allowing the SP to to make authorization requests of the AM later
>> on when Consumers/Clients request access to something at the SP.
> Sounds like my phase 1.
>> 1. Client tries to access a resource and gets sent by SP over to
>> the AM to "register". (The resulting token, which we called an
>> "access token" a la OAuth, doesn't actually guarantee access, just
>> gives a unique correlation handle to the Client for all future use.)
> So this is different in that the client knows the AM and not the SP.
> Here the user needs to enter the address of the AM he wishes to use
> and the client will remember this (or this information can come via
> discovery which is more userfriendly). In my case this simply means
> that the client retrieves an OAuth token (formerly called access
> token in the OAuth spec) for accessing the AM client API.
> The AM client API is simply meant for retrieving an OAuth token from
> the SP.
> Here I would also see the point where the user can for the first
> time set policies for the new pair (client,server) which are then
> stored in the AM.
I think your first description isn't quite right. The SP, by now,
knows enough information about the AM to bounce the Client over there;
the user doesn't need to tell the Client where to find the AM.
In the ProtectServe sketch so far, the Client gets a token from the AM
because it's the AM that is globally controlling and auditing access
to all the various SPs and is tracking terms met by Clients. If there
are efficiencies we an gain by a different flow, without impacting
this major goal, we should definitely examine it.
>> 2. Client retrieves the terms and conditions for this type of
>> access to this resource and meets them to the AM's satisfaction.
>> The user can exercise her opportunity to demand real-time approval
>> here, which would happen in some out-of-band way.
> I left this out for now in my flow to make it easier and see how
> this can be later added by an extension. The main idea in my
> proposal is that it's an additioal function of the AM client API or
> it could be an extension to the function which retrieves the OAuth
> token. Some policies are sent with the request and passed on to the
> SP. It depends though who is responsible for e.g. filtering that
> data. If it's the client then the responce of the AM client API call
> could not only contain the OAuth token but the policy stored by the
> user earlier in the previous step as well.
This definitely deserves careful attention going forward. Hopefully
we can defer the discussion till next week when Paul is back, though.
>> 3. Client attempts access again; SP asks AM for policy decision and
>> lets the Client in if the AM says it's okay.
> So in my case the SP is not asking anybody anymore. It got accessed
> by the AM in the previous step for retrieving an OAuth token and
> migth have got any policy information needed in this case. So the
> policy is then already attached to that OAuth token.
Discussed a bit above...
> I guess this was wildly confusing but I might try to explain it
> better when I have some more time.
Actually, I'm starting (ever so slightly) to grok the differences in
approach! So it's good you wrote it up.
eve at xmlgrrl.com
More information about the Wg-uma