Comment with regards to point 2) and 3). Should the host have all access management systems listed within a single XRD and rely on requester to follow each one (possibly using disparate protocols)? Or should the Host reveal an access management system one by one (i.e. give the XRD to requester, eventually decision is obtained, give the XRD to requester, ...and so forth). The motivation for this question is related to boolean expressions. Should those be exposed to the Requester? Should the Requester know the logic behind access control decision making on the Host side (i.e. which AMs are "more important" than others).
Cheers,
Maciej
________________________________
From: wg-uma-...@kantarainitiative.org [wg-uma-...@kantarainitiative.org] On Behalf Of Paul C. Bryan [em...@pbryan.net]
Sent: 04 February 2010 07:54
To: WG UMA
Subject: [WG-UMA] How multiple protections on a resource could work
Hi UMAians:
I have addressed my UMA action item 2010-01-28-3 (propose in email how multiple protections on a resource could work) in the following page:
How multiple protections on a resource could work<http://kantarainitiative.org/confluence/display/~pbryan/How+multiple+protections+on+a+resource+could+work>
Discussion welcome.
Paul
_______________________________________________
WG-UMA mailing list
WG-...@kantarainitiative.org
http://kantarainitiative.org/mailman/listinfo/wg-uma
I think this has to be left up to the host, and be largely subject to
the threats and risks associated with providing access to resources.
The host may want hoops it wants requesters to jump-through (e.g. its
own mandatory access control systems) before it will considers the
condition secure enough to even reveal how to obtain discretionary
authorization from the user. Other hosts may simply not care and expose
them all.
> The motivation for this question is related to boolean expressions.
I'm pretty sure that doling-out authorization prerequisites one-by-one
will not achieve the equivalent of logical expressions, especially in
the case of OR.
> Should those be exposed to the Requester?
I don't think we can prevent multiple protections, but I'm also thinking
there's no strong driver for us to explicitly support it. With the
loose-coupling of resource descriptors, there's a lot of latitude, so I
don't think we're painting ourselves in any corner.
If/when there is a strong case to be made for multiple protections, I
think that's the appropriate time for us to get more rigorous.
> Should the Requester know the logic behind access control decision
> making on the Host side (i.e. which AMs are "more important" than
> others).
I'd say no. Or at least I think it goes too far for us to try to address
such expressions at this time.
Paul
Eve
Eve Maler
e...@xmlgrrl.com
http://www.xmlgrrl.com/blog
Just one more comment/clarification - what I meant by revealing an access management system one by one (calling it 'one by one' was actually not proper) is that the requester only gets to know all the necessary AM systems (either one after another or all listed within a single descriptor). However, the Requester never gets to know the rules behind satisfying all AM related requirements - it may obtain authorization from all AMs but the Host would still use only one (in case of OR expression) to derive the ultimate decision. This particular configuration would lack efficiency but I can imagine that there are scenarios where it could be applicable. The Requester would follow the same pattern for obtaining authz and the Host could change its config as necessary without revealing it.
Cheers,
Maciej
________________________________________
From: wg-uma-...@kantarainitiative.org [wg-uma-...@kantarainitiative.org] On Behalf Of Paul C. Bryan [em...@pbryan.net]
Sent: 04 February 2010 16:03
To: WG UMA
Subject: Re: [WG-UMA] How multiple protections on a resource could work
I certainly think this is possible, and should be supported by the
resource discovery scheme we're proposing. So, this remains at the
discretion of the host to decide when and how to expose AMs, to be
determined on a case-by-case basis.
Paul