MACE-Dir Call 7-April-2008

**Attending**
Brendan Bellina, USC (chair)
Etan Weintraub, Johns Hopkins U.
Paul Caskey, U. Texas System
Ann West, Internet2/Educause
RL "Bob" Morgan, U. Washington
Bill Weems, U. Texas Health Sciences Center - Houston
Nate Klingenstein, Internet2
Steve Olshansky, Internet2 (scribe)

**New Action Items**
[AI] (Paul) will incorporate feedback and draft proposed text for meaning and usage, update the draft in the wiki, and forward the wiki link to the list.

[AI] (All) discuss potential discussion topics via the mailing list.

*Carryover Action Items*
[AI] {Bill Weems} will share a whitepaper addressing global Identity Management. [19-Nov-07]
[AI] {Tim Crouch} Craft a survey on eduCourse adoption and usage. [11-Mar-08]

**Discussion**
- FederationSoup
There will be a workshop tentatively called "FederationSoup" in Seattle in early June, addressing inter-federation policy issues. More to come as information becomes available.

- Attempt to bring Identity Assurance Profiles (LoA) attribute discussion to some points we can vote on.
- attribute name - based on March 24 call, eduPersonAssurance seems to be preferred over usPerson-like eduPersonAuthNLOA since this is not AuthN only.

The group discussed this, following up on the recent active thread on the MACE-Dir list. It was noted that usPerson is defunct for all practical purposes, thus there is no benefit in us trying to leverage any practice that would have been associated with it.

Q: Should this new attribute be part of the eduPerson schema?
A: While we do not want to give them impression that it should only be used in the context of educational institutions, adding it to eduPerson seems to be the right thing to do…

Q: Is the term "assurance" appropriate? Is it suitably vague?
A: Since we will say that it could include any assurance level, and the various levels would in turn dictate AuthN/Z, then assurance would seem to be the right way to refer to it. We would not be defining the levels of assurance (LoAs) per se (this is out of our scope), but just defining an attribute to convey the information. It is really up to the relevant communities of interest to define LoAs.

Q: Do we want to be able to say there is a specific LoA that corresponds to a method of AuthN? There could be a number of namespaces defined by various communities of interest, but each would have in common the need to know how a user was authenticated ("credential LoA")
A: This would seem to be out of our scope, and not practical for us to maintain in a registry, thus logically not up to us to define.

Another way of looking at this question is what can an assurance say v. what attribute(s) ought we define to convey this information? There may be LoAs that incorporate more than the AuthN method, but ultimately it would be best for us to define a single attribute for this purpose. The definition of a particular LoA, and/or specifying the AuthN method used, would be out of our scope.

- syntax - URIs are generally agreed to, and URLs are a subset of URIs so they should be allowable as well. Restriction seems to be preferred rather than open.
- OID - it seems that an eduPerson OID is adequate.
- single or multi-valued - preference seems to be multi-valued as multiple values might be used simultaneously to indicate multiple assurance facts.
- meaning and usage

Ref Paul Caskey's proposal on the list and ensuing discussion… It would seem appropriate to keep is short and simple, and omit usage details as much as possible. Given that there is not yet any practical usage to refer to, this seems to be the right approach.

[AI] (Paul) will incorporate feedback and draft proposed text for meaning and usage, update the draft in the wiki, and forward the wiki link to the list.

*Internet2 Spring Member Meeting MACE-Dir working group session*
April 21, 2008, 8:30 AM - 10:00 AM
http://events.internet2.edu/2008/spring-mm/sessionDetails.cfm?session=3738&event=280

[AI] (All) discuss potential discussion topics via the mailing list.

*Next Call*
Due to the upcoming Internet2 Spring Member Meeting we will not hold the call 21-April. Thus the next call will be Monday 7-May 4:40 EDT.