[Wg-uma] Comments on today's conversation
Diego R. Lopez
diego.lopez at rediris.es
Fri Aug 28 13:39:28 PDT 2009
On 28 Aug 2009, at 02:30, Eve Maler wrote:
> On 27 Aug 2009, at 11:24 AM, Maciej Machulak wrote:
>> Eve raised a question about a user delegating access control to
>> multiple AM (part of resources protected by AM #1, part of
>> resources protected by AM #2). I wanted to fully agree with Paul
>> that the ProtectServe protocol does not restrict that. As
>> discussed, this may be a not-so-popular deployment scenario. It is
>> purely implementation specific and depends on how the SP adopts
>> UMA. It will definitely result in much more complex application code.
Agreed, though I don't see why application code can become so complex,
though I can imagine that both
popular application providers and well-established AM operators would
try to make exclusive agreements (OpenID
is facing this risk of partition, though some argue that it is a
>> I do think that there are certain scenarios which will require an
>> application to be able to use decisions from multiple AM as
>> multiple entities may be interested in controlling access to the
>> same set of resources. This, however, may be achieved through an
>> application delegating access to a single AM which will be
>> controlled by multiple entities or by an application delegating
>> access control to multiple AM. In both cases, I think that this may
>> be of interest in certain cases.
> It would be good for us to highlight the most reasonable/likely real-
> world circumstances here in one or more scenarios. I worry about
> inherent complexities (I believe you point these out in your paper),
> like: If you get a YES and a NO from two different AMs, what do you
> do? We'd have to have a really strong motivation in order to solve
> for a several-AMs-per-resource scenario!
My take is that is not only about complexity but about trust issues as
well... If you define an aggregator,
both parties have to trust it even more than each of the individual
AMs. And transitive trust evaluation is
not only complex but full of loopholes.
> I do remain just a little worried that we'll open up a can of worms
> in trying to let SPs teach AMs about policies with deep application-
> specific (content-type-specific?) semantics. Does it make sense to
> think of this as an *optional* part of our eventual protocol? I'm
> not a fan of having lots of options (it complicates Internet-wide
> adoption!), but this may be a sufficiently heavy branch that
> different populations might strongly want or not want to deal with.
I do think this will open a can of worms and will add a lot of
complexity. Detailed application access semantics
should be applied by the applications themselves if required,
otherwise we will end requiring a set of
ontologies and mappings between them...
>> 3) I would like to fully agree with Paul on the issue of users vs
>> services being consumers of resources. It is always an application
>> accessing a resource, be it a service or a user agent (e.g. a Web
>> browser) and there should be a strong separation between our access
>> control approach and authentication.
> +1! :)
"Esta vez no fallaremos, Doctor Infierno"
Dr Diego R. Lopez
Red.es - RedIRIS
The Spanish NREN
e-mail: diego.lopez at rediris.es
jid: diego.lopez at rediris.es
Tel: +34 955 056 621
Mobile: +34 669 898 094
More information about the Wg-uma