Shibboleth Developers

["RL 'Bob' Morgan" <>]

> Ok, great. I'm in process of writing all this up in the arch doc for
> final review. The AA section is getting the most attention, which I hope
> is good news. If there are any outstanding issues, we'll pick them up
> then.

I am sorry to be a bad guy on this, but I really don't see how this level
of policy detail can qualify as being part of the Shib architecture.  
Surely you can have an AA that implements the method you're proposing, and
I can have an AA that implements something completely different, like
"find all expressions that match the request and take the union of them,
with explicit-deny expressions supported, and longest-match determining
precedence" and you can be happy with yours and I can be happy with mine
and we can both call them "implementations of a Shib-conformant AA".  I
certainly think the approach that we take to implement this AA is
important to document, but I really don't think the arch doc is the place 
to do this.

And yes, this comment applies to existing text in shib-arch-04,
specifically the last sentence of section 5.6.4, which I suppose is more
or less the same as the result of today's debate.  I think I recall saying
this a few months ago, though of course I probably also volunteered to
write new text regarding this which of course I haven't.

But as we get closer to reality with this stuff I think this distinction 
is very important.  I don't think any of us can claim to know what's the 
most manageable and understandable way of representing these policies, and 
I wouldn't want potential implementors thinking that they're more 
constrained than they really are.

 - RL "Bob"

------------------------------------------------------mace-shib-design-+
For list utilities, archives, subscribe, unsubscribe, etc. please visit the
ListProc web interface at 

    http://archives.internet2.edu/

------------------------------------------------------mace-shib-design--