Shibboleth Developers

["Scott Cantor" <>]

> Scott suggested that the grid client consume the grid service
> metadata, which is what I meant when I said the grid client would have
> to talk to the grid service initially.

Why? Consuming metadata != talking to service. I would guess dynamic
metadata is going to be a very rare case, for a good long while. We have
metadata all over the system and nowhere do we ever communicate ahead of
time across a network to get it. Doesn't mean we couldn't, of course, and in
this case, I don't think it would be a big deal at all. Of course, I'm not
sure I wouldn't stick with pull anyway.

There are some serious firewall implications for clients talking to an AA, I
would guess. Lionshare is fine and all, but it's hardly going to drive open
access to AAs anytime soon. I don't personally have mine firewalled off, but
I could easily imagine other people might and would be upset about having to
open access to the entire Internet instead of specific SPs.

> Essentially, what we'd like to do is communicate attribute
> requirements to the AA by reference (not by value).  Since the AA
> already knows the attribute requirements of the grid service (via
> ARP), we were hoping to capitalize on that in some way.  Any ideas?

Well, in 1.1, you could use Resource for this, assuming you identify the
requester some other way (I'm so glad there was no "use case" for Request
Issuer when I argued for it three years ago. sigh).

In 2.0, it's kind of impossible without an extension. This particular use
case wasn't on the table, and Resource didn't have a well-defined purpose
once Issuer was added.

-- Scott