Shibboleth Developers

["Scott Cantor" <>]

> That's the use case I have in mind.  Consider LionShare, for example
> (although GridShib will most likely propose something similar).

No, that's not push, not in this context. I mean sending attributes with the
SSO assertion. If you're not using a SSO profile, push isn't involved. You
may be pushing, but that's not the IdP's perspective. If you're querying,
that's pull.

> Well, that's the problem, I think.  In the attribute push case, the
> user is requesting attributes about itself.  So what happens when no
> specific attributes are requested?

See above, that's not push. Who is asking and about whom is not the issue.
Specifying no attributes means only send me whatever I can get about the
subject. How the AA decides "whatever you can get" is up to it, and is not
specified. A profile can't change that, it's defined in core. I just re-read
2.0, and it's quite clearly stated, all attributes allowed by policy.

> That's what I thought you'd say.  Some of us (GridShib) would rather
> not formulate specific attribute queries.  We are looking for
> alternatives.  (I wonder what LionShare is doing?)

The only possible reason I can even imagine for not spelling it out is that
1.1 doesn't handle value filtering. This is especially true for LionShare,
since the ARP is probably being short-circuited and asking for everything
doesn't seem very efficient. For a Grid Service, the ARP has to be created
in advance anyway, so in the end it doesn't really matter all that much
what's in the query or the metadata. But "select foo" is almost always
better and faster than "select *".

-- Scott