[security-services] RE: SAML/Shibboleth Context in attribute queries

[Scott Cantor <cantor.2@osu.edu>]

Hal wrote:
>My concerns are more about how Shib intends to use this, which I
>suppose is none of my business. As I understand the intention, there is
>a single entity making requests on behalf of sub-entities, which need
>to be distinguished from each other for the purposes of releasing
>attribute information. The proposed method is to include the full URL
>of the user request to which this information will be applied.

The requester makes requests on behalf of itself and on behalf of
resource managers behind it. Those RMs protect resources, and the
resource involved determines (maybe) what the query response should be.

>In my opinion, it would make more sense to identify these sub-entities
>by a meaningful name such as their ordinary name, e.g. "National
>Multiple Sclerosis Society" or top level dns domain, e.g. nmss.org.  A
>text name could remain stable as organizations merge or reorganize and
>in the face of technical restructuring of the network. A top level dns
>name would be a little less stable, but at least would allow the
>privacy policy to set in a suitably granular way.

Actually, this was discussed a little bit. We might go that way at some
point. We're just trying to start simply without having to invent a new
namespace or nomenclature right off the bat, and deal with URLs for the
time being.

>Certainly this would be much easier for the user who wants to set up
>their privacy policy as described in the example. In fact, I don't
>really see how this scheme can be made practical without using some
>kind of wildcarding in the privacy policy specification. You don't
>really plan to have Mary enter all the URLs she might access and enter
>a privacy policy for each do you?

No, and there's an implied wildcard on every one anyway. If I setup a
release to SHAR foo.edu for URL http://foo.edu/MS, it applies to
everything beneath that point.

The point of this small addition is to allow a different policy for
http://foo.edu/ALS and everything under it.

>Another objection to the URL scheme is based on privacy. It leaks
>information about the usage patterns of end users. I do not know if
>this is a problem in any particular case, but it would seem in the
>interests of privacy to distribute just the information needed to do
>the job and no more.

If you mean, I presume, that it leaks this to the origin site, I should
note that there is no goal in Shib that I know of to protect the user's
privacy *at the origin site*. The alternative to leaking this
information to the AA is to disallow the option of multiple release
policies per requester, so it's merely a trade off. One doesn't,
obviously, have to make the trade.

>Since the proposal to SAML is just a text field, individual depolyments
>are free to use it in a sensible way or not.

My original suggestion was merely to generalize the Resource attribute,
which is admittedly a URI, and allow it on both types of queries, which
is a quite obvious (to me anyway) use of an existing data item in the
schema, but if people are happier with Marlena's suggestion of a more
abstract addition, I'm equally happy.

-- Scott