Shibboleth Developers

[Scott Cantor <>]

> Why not put the AA pointer in the SIA field?  It is clearly "subject 
> information" after all...

As I mentioned on the call, what we want is most likely an Attribute
ProviderID that will point to SAML metadata here, not a literal location. I
have no opinion about where it goes in the cert though (not knowing any
better).

> Isn't this a security problem, as we've discussed in the past?  I.e. 
> "tell me the requester's SSN, mother's maiden name, student ID# and 
> I'll let him/her in".  Since most people won't ever set their own 
> ARP, the default release to this sort of resource must be carefully 
> managed.

I think (and I always thought this, going back to the original Shib calls)
this was a red herring. Requesting attributes is not a privacy issue,
releasing them is. You can't get it if the AA doesn't release it, and if you
don't ask for what you need, nobody can make a rational decision about what
to give you. People don't like 403 errors, so increasing their frequency
doesn't make sense to me if we want people to use this stuff.

If you lie, then you're a liar, but I don't see what I can do about that
before the fact. But it should be possible to include attribute requirements
in metadata and have the fed sign them after checking their reasonableness.
I don't think that works in a P2P situation as well, where people are by
definition making their own judgements.

> Isn't the issue how the requester will verify the signature? 
> Validity period would seem irrelevant if I can't trust the signing 
> key.  I'm assuming that some targets won't be local to the 
> requester...

I would expect that most or all of the validation will be handled by code
from our library, which brokers the validation using SAML authorities and/or
metadata. The roots are based on the parameters of the transaction such as
the relying party and the service.

> Are you assuming an arbitrarily large number of targets? E.g. 
> students wanting to share files with each other.  In which case, a 
> "default" better apply...

Seems like real-time release is more likely here, which I think somebody
mentioned today.

-- Scott