Shibboleth Developers

["Scott Cantor" <>]

> I still think that descending into an authorization model for 
> managing ARPs will go too far, as there is no way to 
> generalize it to cover all situations and/or all models at 
> all institutions.

I don't think having no model at all is necessarily better. This is not
specified anywhere except as a "feature set", really. Nobody is
constrained to use it, but if there's a collective impression that the
design is reasonable for handling a variety of administrative
approaches, I think at least having it in the design if not the eventual
code is a good thing.

ACLs are not always the best way to do security, but they have the
advantage of being fairly easy to implement and being fairly well
understood too.

> I think planning for the concept of an 'owner' attribute, or something

> similar, as is discussed in the Groups best practices 
> document, is certainly worthwhile, as a general mechanism to 
> allow to identify who can modify a given ARP. And talking 
> about the hierarchy of what ARP specifications take 
> precedence over others, from some guidelines like (higher to lower):
> 
>  - my personal ones
>  - 'intermediate agent' managed ones
>  - 'centrally managed' ones  
>  
> Where the intermediate agent ones might need some sort of 
> priority code to indicate their precedence among each other, 
> if more than one applies.

Precedence seems like one of the aspects that will differ between sites
or possibly between resources. If anything, I'm more uncomfortable with
designing some of that in at this stage than I am about the
authorization/delegation ideas.

-- Scott

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

    http://archives.internet2.edu/

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