*MACE-Dir Conference Call* November 26, 2001 *Participants* Keith Hazelton -- Wisconsin(chair) Tom Barton -- Memphis Brendan Bellina -- Notre Dame Steven Carmody -- Brown Renee Frost -- Michigan/Internet2 Michael Gettes -- Georgetown Paul Hill -- MIT Ken Klingenstein -- Colorado/Internet2 Bob Morgan -- Washington Todd Piket -- MTU Ellen Vaughan -- Internet2 David Wasley -- UCOP Nate Klingenstein -- Internet2(scribe) *Discussion* The MACE-Dir group sojourned on a largely theoretical discussion of attribute scope during the call. This covered many questions, including who should assert attributes, who can assert which attributes for which principals, who decides whether this assertion is acceptable, and a host of other fundamental questions. An eventual answer for a version 1.5 implementation was arrived upon. The group used member of community as the persistent example through all the discussions. Trustworthiness of data itself was once suggested as a topic but the group considered that rathole to be unfathomably deep. Attribute Scope One of the most basic and challenging questions in attribute scope is what it precisely should tell you. Several options exist, such as the community or security domain on whose behalf the attribute assertion was asserted (e.g. hazelton@wisc.edu), the precise entity that has asserted these attributes (e.g. hazelton@madisonAA.wisc.edu), or the entity originally populating or officially recognizing the population of the fields in the directory itself (administrivia system at hazelton@wisc.edu). Michael tried to simplify the question by stating that in the theoretical sense, a CA speaks authoritatively for the community of certificates; it is representative of anything it chooses to sign, whether or not this maps precisely to an institution. This would suggest that the precise AA speaking is the important information to convey. The location and time at which the attributes should be signed was also contentious. This could be done when the attributes populated the directory, which would provide authoritative information on precisely who had asserted the attribute originally, potentially along with information on who asserted the information outside the zone. Michael suggested a means by which this would be possible, by including another attribute in each directory entry which would be responsible for containing attributes' signatures. Keith thought it was a complicating assumption to assume that attributes would be signed in the directory, and preferred instead to assume intra-realm attributes would rarely be signed and that these signatures should be "tacked on when [the attribute assertion] leaves home." It has also been a persistent question how the attribute scope should be formed. The general form has always been principal@securityDomain, but when there is a need for knowledge of both the asserter and the security domain in which the information is true, this form is insufficient. A makeshift for Shibboleth and EPPN to be able to assert both of these was a suggestion for use of the form principal@securityDomain@assertingAA, but this is somewhat messy both visually and in processing. This is further complicated when the security domain isn't necessarily clear; as Michael indicated, the means to word that a student is a member of the law school at Georgetown is unclear. He suggested student@law.georgetown.edu or lawstudent@georgetown.edu, but because of local campus politics Georgetown would be unable to assert lawstudent, making the first option necessary and leading to potential scalability problems with the number of fiefdoms in higher ed with students and resource providers needing to know which to accept, especially in situations less clear than law.georgetown.edu's affiliation with georgetown.edu, such as pomona.edu and claremont.edu. Third Parties An immediate problem with significant relevance to Shibboleth and other imminent inter-realm projects is the means by which MIT could assert that a principal was a visiting faculty member from Berkeley. This would be a statement about someone outside the security domain over which the AA would have any degree of jurisdiction. This is further complicated if the assertion is about a student at Pomona from the general Claremont Colleges AA. Even tougher is the question of trying to assert members of MACE at all, where the members are scattered across security domains. The group generally considered making assertions about principals outside the jurisdiction of the AA to be improper as an immediate simplifying move. Michael pointed out that there may be many instances in early dumb implementations where a resource provider may be expecting information signed by a certain AA, such that if the institution wanted to give the visiting professor access to the resource it might be forced to do sign a member of community assertion. Steven made a suggestion met with a degree of scepticism that there should be a knowledge of what the target expects and that the asserter should be able to discriminate between options based on this. One eventual solution to this problem was suggested by the group whereby Berkeley would be able to assert faculty@MIT with a pointer which would allow the relying party to verify both that Berkeley asserted this and that MIT asserted its truth as well. Handing a blob that suggests multiple affiliations/asserting parties like this to a target in today's world would be extremely difficult. The group initially suggested that this could be created in the form of x.509 bridge certificates which would allow Pomona to speak for Claremont but not for Harvey Mudd. This is implementationally very distant as well. It is still extremely unclear how assertions about rlbob@washington.edu being a member of MACE would be created in this model, and where this attribute would be stored and asserted even if it could be created. Another potential solution in the Pomona/Claremont example, at least, is simply to have more AA's. Adding an attribute authority for Pomona and Claremont each would largely solve the problem and free up the group to say unequivocally that no AA should ever be allowed to make assertions involving principles outside its security domain. This is not without its problems, too, however; in addition to the greater overhead of operating multiple AA's, students must be aware of precisely which AA to select when asked where they're from (especially in the Georgetown Law case where the student may be represented by multiple AA's). This does avoid what is perhaps the greatest challenge in teaching all potential targets about the political landscape at any origin sites. A patchwork model in the future where relying parties would be fairly intelligently aware of exceptions to the rule of who can speak for whom would be eventually desirable. 1.5 The group agreed that the sensible short-term decision was to disallow in the rules of any community of interest the assertion of attributes outside of an AA's jurisdiction. In instances where there is a political overlap or subgroup, the current sensible approach seems to be use of additional AA's which the target would need to understand as being authoritative and users would need to understand how to intelligently select origin from. No other immediate approach seems able to scale to the extent necessary for current implementations. Everything, including contracts and other objects, will need to be appropriately scoped (contract1234@berkeley.edu), meaning unscoped attributes (contract1234) are not valid for the time being. If there are special cases in which institutions mutually agree to break the rules, this is a policy decision which should be maintained externally and is not recommended.