Shibboleth Developers

David,

Now that Shibboleth has entered the design/ coding phase, I'd be 
interested in exploring the overlaps between your ideas and proposals 
and Shibboleth. It seems to me that some interesting possibilities 
might have opened up once Shibboleth expanded its list of allowable 
attributes beyond the eduperson core.

In the initial implementation, Shibboleth will NOT be implementing 
any sort of complex policy evaluation model with the AA. Which your 
model would need. However, as Shib concepts and ideas get cast into 
design and code, I think this might be a useful conversation. We 
might be able to structure the AA code so that you could extend one 
of our classes, and thus obtain the functionality you desire.

Let me start with a simplistic description of your scenario. 
Actually, let me start by apologizing for probably butchering much of 
the nuance of your ideas with my oversimplification. As I understand 
it, you'd like to see support for a scenario where a remote entity 
(which might be a content provider or a resource provider, in your 
model) could ask the origin site a simple question (for authorization 
purposes) and the origin site would do the appropriate policy 
evaluation, and then return the simple answer.

One way of approaching this in Shib terms would be for the sites to 
agree on a private attribute (let's call it Contract1234). And they 
would agree on the URL which represented the resource. The ARP at the 
origin site would reference this URL, and specify that attribute 
Contract1234 would be released. If a particular requesting user 
accessed this resource, and were eligible to access it, then their 
origin site AA would return "Contract1234=YES". In some vague sense, 
the URL is comparable to what you refer to as a namespace.

One suggestion that has surfaced during the design discussions about 
the AA has been to structure it so that there's an abstract class, 
representing the processing needed for an attribute. The class for a 
particular attribute should extend this class. So far, our discussion 
has talked about this being a way to provide sites with some 
generality in choosing how to store a particular attribute. Course 
membership often gets mentioned as an example of an attribute that 
gets treated very differently by different sites.

I've begun wondering, tho, whether this proposed structure might also 
suit your scenario. You could write a class that supported the 
attribute "Contract1234 ", and included the specialized algorithms 
needed to determine whether this particular browser user was 
authorized to access this resource. If the answer was yes, your class 
would have the attribute "Contract1234=YES" sent to to the target.

There's some additional complexity, I think, because you're proposing 
a hierarchy of entities that might have the ability to define 
namespaces and their associated policies (and algorithms).

Let me stop there, and ask if you think there's any value in 
exploring the relevance of this approach to your scenario.

-- I don't think you're currently able to post to 
; I'll make sure to forward your 
posting to that group, tho.

For those not familiar with David's work and ideas, here are some url's:

http://129.11.152.25/xlm4he/namespace.html

and more generally,
http://www.personal.leeds.ac.uk/~ecldh/xlm4he/

--

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

   http://archives.internet2.edu/

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