MACE-Dir WG call
August 28, 2006

*Participants*
Keith Hazelton, U. Wisconsin - Madison (chair)
R.L. "Bob" Morgan, U. Washington
Paul Hill, MIT
Tom Barton, U. Chicago
Scott Cantor, Ohio State U.
Brendan Bellina, USC
Von Welch, U. Chicago South
Tom Scavo, NCSA
David Wasley, Retired, UC, Office of the President
Ann West, EDUCAUSE/Internet2
Nate Klingenstein, Internet2
Renee Frost, Internet2
Steve Olshansky, Internet2
Jessica Bibbee, Internet2 (scribe)

New *Action Items*
[AI] {Von} will prepare a summary of the upcoming TeraGrid meeting and share on the mailing list.
[AI] {Nate} will send a link to his attribute aggregation developmental work.

Carry-over *Action Items*
[AI] {Keith and Jessica} will draft a use-case template regarding support for multiple levels of assurance and will schedule a call with {Tom}. Those who would like to volunteer ideas/content for a use case should email the MACE-Dir mailing list. (14-Aug-06)
[AI] {Group} will draft a proposal for InCommon to clarify MACE-Dir efforts. (31-Jul-06)
[AI] {Keith] will raise discussion on the next InCommon Technical Advisory Committee call about the role of MACE-Dir efforts in the Information Model. (31-Jul-06)
[AI] {Keith} will revisit the mailing list archives to mine for possible uses cases. (31-Jul-06)
[AI] {Keith} will begin work on eduPerson (2007??). (31-Jul-06)
[AI] Group will review the work on eduCourse and give feedback on how to proceed similarly or otherwise. (31-Jul-06)
[AI] Keith will email the list with a summary of recent developments in the eduPersonEntitlement space.
[AI] {Keith} will work on simplifying the URN MACE and OID registry page. (27-Mar-06)
[AI] {Keith} will contact (Walter Hoehn and Jon} about contributing towards requirements. (27-Mar-06)
[AI] {Bob} will email the list with an informative sentence regarding an additional spec. (13-Mar-06)

Future *Agenda Topic*
– MACE -Dir & EDUCAUSE – how might/should they work together on IdM issues?

*Agenda*
1) Subject mapping from X.509 certificate to attribute authority. For background, see the MACE-Dir
thread, "eduPersonSubjectDN" over the last week. Issues to discuss (in suggested order):
      a) Need for an operational link between the Certificate Authority and the Attribute Authority and/or
Enterprise Directory:
            . Does everyone agree this is essential?
            . Is it clear what the relationship needs to be?
NOTE: The possible role of VOs is set aside for later discussion under g).
      b) Are there more than two basic models?
            1) Identifier in certificate passed from service provider to attribute authority with
request for additional subject attributes
            2) Certificate as presented contains the attributes needed by the service provider
NOTE: Most of the subsequent questions drill down on 1.b.2 above.
      c) Required characteristics of whatever subject identifier in the certificate is decided on for purposes
of mapping subject identity back at the AA and/or Enterprise Directory
      d) Requirements governing selection of proper field(s) in the certificate for carrying the chosen identifier
      e) Requirements on the relationship between CA and Enterprise Directory
      f) Requirements on usage of mapping ability (privacy protection, others)
      g) VO role
      ?) Other issues that surface during the call

2) Draft of clarification of MACE-Dir role with the InCommon Federation

*Discussion*
The Group continued discussion on Subject mapping from X.509 certificate to attribute authority. {Keith} asked if there was a reordering or rejection of scoping to be done. {Scott} questioned its relevance, and cautioned its sliding into Shibboleth architecture. A GridShib interaction might serve as a standard use case, working with certs or processes at the Identity site.

{Von} emailed a URL to the list for the Scaling TeraGrid Access Paper: <http://gridshib.globus.org/tg-paper.html>. He asked the group how they would use certificates in a federated identity infrastructure, and how it would be of impact. While campus Identity Management has reasonable knowledge of which physical persons have access to resources, and which resources need to know about that person, TG looks at the passing of these trusted packets of information (X.509 object), i.e., for later forensics. The question now is how to query for these packets. {Keith} said the concern is not how these packets get assembled, but where the information comes from. What information in a cert would be most useful for learning more about the subject? There are other issues including knowing who the asking resource provider is. What is the larger model that the Group wants to advocate?

[AI] {Von} will prepare a summary of the upcoming TeraGrid meeting and share on the mailing list.

The Group agreed that there needs to be an operational link between the Certificate Authority and the Attribute Authority and/or Enterprise Directory, though there are multiple possibilities for defining this relationship. {Bob} suggested designing around a ‘push’ - not ‘pull’ - approach. {Von} said Europe is using X.509 as a push model, without problems. Are there use cases for assembling information in multiple places?

What are the privacy requirements around Grid resource access? The architecture and following certs should not preclude privacy. A short-lived cert model may be able to carry different information, as it is typically less than eight hours and there is little concern about revocations.

A lightweight model is of interest for specialized resources, compiling code. An example of a PI who requests more access or hours to this resource leads to more of an attribute authorization case. For the sake of security, any problems would necessitate a system of logs to be in place and also a mechanism to close the ticket. Depending on the resource and campus, the length of backlogs would vary.

{Von} suggested there be two levels of service – one that gives a persistent ID, and one that does not. The TeraGrid provides incentive for wanting to move to a better model. Ideally, campuses ought to run CAs that bundle attributes in a way that spans issues across authorization and security. {Bob} said the issue is more than just improvements to data management, it is about who is managing policies for access.

[AI] {Nate} will send a link to his attribute aggregation developmental work.

The next MACE-Dir Working Group call will be on Monday, September 11, 2006 at 4:30pm EDT.