Shibboleth Developers

["Scott Cantor" <>]

> Our clients don't have a UI where the user in real-time can decide about 
> their release policy for a certain SP.
> 
> Our clients are agents that work independently from the user, which 
> requires a user to make up its mind about the attribute release policy 
> for SPs before it kicks off any jobs.

Alright. That's not really that different. The difference is in who's
asking, not the fact that the ARP has to be created ahead of time.

> I hope you agree that an ARP is needed in those cases, and that it has 
> to be maintained "somewhere", where it has to be found, downloaded, 
> enforced, and be kept in sync with the ARP on the Shib-AA for those 
> cases where the SP can pull the attributes directly.

Well, I don't think I quite agree fully. The ARP doesn't exactly move to the
client here, not in the sense that I think of the concept. Clearly, the pull
case is the same, you set up the ARP so the SP can get what you want it to.

In the push case, I think you need to grant the client the same Lionshare
notion of full access to the AA's attributes about that user (presumably
reasonable if there's a proxy cert used by the client to authenticate to the
AA). I think it's still up to the client (through user-supplied information)
to ask for what the SP wants because if you want the AA to sign the
assertion, he has to build the right set. You can't filter the set at the
client without breaking the signature. I grant that I was mistaken about the
UI thing.

Now, I guess you could argue that's an ARP, but the mere fact that the same
input ("the set of attributes the SP wants") feeds both processes doesn't
make them exactly the same thing or mean that they need to be a common
technology/format/whatever.

I realize that you'd prefer to just say "give me the attributes for SP foo",
but your options there are fairly limited at the moment if you try and
remain interoperable. I'm not saying you can't choose to go that route, but
it does have some downside.

I guess there's a possibility we could push the TC to adopt and bless your
profile/extension. The current profile that BAH is proposing, while similar,
isn't exactly lining up. It doesn't support push, and it also uses
holder-of-key subject confirmation, although I suppose you could adopt that
part without really breaking anything you're doing.

-- Scott