Shibboleth Developers

["Alistair Young" <>]

What was the thinking behind the discovery service? other than a beefed up
WAYF, with more metadata to manage? Presumably the inital contact with the
service will be the same as the WAYF? You still have to work your way
through the hundreds/thousands of Identity Providers in a federation. I
can see how metadata can cut that down, using the SP's entityID but it
means even more metadata for a federation to manage.

Do you think the discovery service should use the same metadata file that
drives the federation? So it would be one discovery service per
federation.

> There was particular concern about products not working
> with Shib sites if we do this
How do you define "product"?

> multi-protocol sites, which of course all the products have to handle.
can you explain what you mean by this?

I've seen a lot of talk of IP address matching at WAYFs. Is this a viable
addition to the discovery service? i.e. if you're on campus, the discovery
service can be passive if the sp knows your IP address. i.e. SP tries a
passive query to the service and if nothing comes back it says to the user
"no idea, go find it yourself".

Once past the initial metadata check, the more the sp can give the service
to allow it to make a passive decision the better?

I can see semantic type decisions coming into play. i.e. SP tells the
service "I'm a medical records service and someone from uhi.ac.uk is
trying to access me. Where is their IdP likely to be?". A semantic
discovery service? It could drastically reduce the likely list of IdPs
from thousands to a handful. Given enough data it could match it. But the
metadata doesn't support that just now. Maybe it should in future.

Alistair


-- 
mov eax,1
mov ebx,0
int 80h

> I prepared an OASIS draft from Rod's initial document and uploaded it as
> shown:
> http://www.oasis-open.org/archives/security-services/200701/msg00037.html
>
> There was a bit of discussion today about it and they want to take it
> forward in OASIS. There was particular concern about products not working
> with Shib sites if we do this, and I did note that it was designed to help
> multi-protocol sites, which of course all the products have to handle.
>
> The draft I submitted includes a metadata extension that is designed to
> limit the delivery of IdP data to authorized endpoints. This isn't quite
> the
> same thing as the Shibboleth SessionInitiator, but it's likely that it
> will
> be used by us in that way.
>
> I have received some feedback already from one vendor that makes the
> protocol a little more complex, but it's worthwhile feedback and I'm
> working
> to keep the complexity to a minimum while still improving it.
>
> I have also verified that the "Home Realm Discovery" thing that MS/IBM
> published in WS-Federation 1.1 can be "spoofed" with this proposal such
> that
> you could drive a response to such a product (ADFS 2.0?) from this
> protocol,
> which is good, I guess. For due diligence, their proposal is not usable by
> itself for Shibboleth, not least because you can't communicate the
> identity
> of the SP and you can't include a passive flag.
>
> If there's feedback from anybody else on this, please submit it here or to
> the SSTC public comment site.
>
> A second draft is going to be done by me that includes more expository
> text,
> this was just a bare bones version to get the protocol in front of the TC.
>
> -- Scott
>
>
>