Shibboleth Developers

I added shib-dev to the distribution.... so a larger audience can see 
the discussion

At 1:11 PM -0400 7/9/04, Scott Cantor wrote:
>  Just self-select using a simple best-practices guideline and the
> admins can just sanity check it. For IQ it doesn't matter anyway, for
> InCommon they would need to check the domain name with dig and just make
> sure it's owned by who is claiming it.
>
> A simple best practice is https://<domain>/shibboleth
>
> It's simple, it can be resolved easily later into metadata, it will be
> usable by just about any federation they enter into, etc.


At 11:39 AM -0400 7/15/04, Scott Cantor wrote:
> I'd like to note regarding these SP providerId values that putting in
> hostnames is ok for testing, but you need to think more seriously about it
> for real services.
>
> The providerId is not something you should ever change, unless a real domain
> change for the organization or service takes place. It's a much higher level
> consideration than, say, where a service runs. If you put the hostname into
> it and then feel like that's a problem when you rehost the service somewhere
> else, you've defeated the whole purpose, which is to keep deployment
> specific stuff out of policy, such as the ARPs.
>
> Just something to keep in mind. If people are more comfortable in some cases
> with a URN, perhaps one delegated out of a campus namespace
> (urn:mace:osu.edu) that's ok too.
>
> -- Scott

I had requested

    <DestinationSite Name="https://cooke.services.brown.edu/shibboleth";>

but I can certainly see Scott's  point...... and I now interpret 
these two notes as recommending

https://brown.edu/shibboleth

That seems fine.... except that the metadata links that providerId 
value with a specific SHIRE and cert subject field...... so there's 
no possibility of multiple hosts on the target campus being able  to 
reuse that providerId value and thus (perhaps) simplify ARP 
maintenance at the origins. So those values have to be associated 
with a specific instance of an application  on a specific host (or 
perhaps a collection of applications on that specific host). 
Collection would work if  you had several apps  on one host that 
could all share the same ARP (even if some apps only used a subset of 
the attr values).

So I'm wondering where the middle ground here is..... embedding the 
host name into the providerId value leads to the problems Scott cites 
above. Using something like

https://<application  identifier><domain>/shibboleth

would make target configuration more work, since Application elements 
would now have to be created for each new providerId........

thoughts?