Shibboleth Developers

[Scott Cantor <>]

Attached is a new draft of the architecture document, with some changes
to section 5.5 to account for recent discussions about ARPs.

After finding that Walter and I seemed to be in agreement on the basic
issues, and that what we have in CVS is really not too far off from
that, I think we just need to make a few minor adjustments to the
document to bring it in line.

What I think is that there's only one special case that we needed to
identify and account for, and that the focus on that one case was
distorting the rest. The true "default" ARP (or NULL ARP) is the only
special case, and that wasn't really clear in the document. The default
ARP is the one that is effectively '*' for both ARP and SHAR and applies
if nothing else does. That ARP can't have a URL specified.

The rest shouldn't need any real restrictions on how they're
constructed, and if this is appropriate (and we choose to support it):

        SHAR:   shar*.brittanica.com
         URL:   www*.brittanica.com

then I don't think there's any good reason to prevent it. So I changed
the arch doc to distinguish between wildcarded ARPs and the default ARP
which are very different.

Now, my understanding is that right now, the AA code doesn't support
wildcarded SHAR expressions at all. It does handle some wildcards in the
URL, which is different, even though there are some overlaps, especially
when SHAR=hostname.

What we have to do is to decide what we want to implement and scope the
work. Some of the things we have to decide:

- does the code properly handle the special default ARP?
- do we want to handle wildcarded SHARs or wait until post 1.0?
- what kinds of wildcards do we support for SHARs or URLs?
- do we enforce rules for format of SHAR names?
- do we enforce the fact that right now, only hostnames can delineate
policy because of the limitations on the target implementation that we
asked Derek to build?

Lastly, we need to make sure the deploy guide documents what we decide
to build and release, not what the architecture permits or describes.

Summing up, I believe we have something approximately within the bounds
of the arch doc. The fact that it doesn't implement every feature
*allowed* by that document doesn't mean it's wrong, obviously. It's a
subset.

I'll be in Atlanta speaking tomorrow, but I should be able to duck out
at 3:00 if there's a call, so I'll try to make it.

-- Scott

Attachment: Shib_v6.zip
Description: Zip compressed data