MACE-Dir Call March 10, 2008

*Attending*
Brendan Bellina, USC (chair)
Etan Weintraub, Johns Hopkins
Michael Gettes, MIT
Scott Cantor, OSU
Paul Hill, MIT
Tom Barton, U. Chicago
RL “Bob” Morgan, U. Washington
Steve Olshansky, Internet2 (scribe)

**New Action Items**
[AI] (Brendan) will contact Tim Crouch about interest in following up on eduCourse section usage.

[AI] (Brendan) will send the attribute profiles document draft to MACE for final approval.

[AI] (Etan) will create a wiki topic for interoperation with a typical commercial SAML Service Providers in the Shibboleth wiki space with appropriate references

[AI] (Etan) will follow up with NIH on the use of LoA attributes and report back.

[AI] (Brendan) will post a note about the use of LoA attributes to the list in search of broader feedback.

**Carry-over Action Items**
[AI] {Bill Weems} will share a whitepaper addressing global Identity Management.

[AI] {Keith} will craft a survey question to understand what is going on within the eduCourse space in the real world, as it pertains to Section, and share with relevant mailing lists. (22-Oct-07)

**Discussion**

*Finalization of Scott Cantor's attribute profiles document*
- See <http://middleware.internet2.edu/dir/docs/draft-internet2-mace-dir-saml-attributes-20071202.pdf>
- With revisions marked http://middleware.internet2.edu/dir/docs/draft-internet2-mace-dir-saml-attributes-20071202-diff.pdf

[AI] (Brendan) will send the links to the attribute profiles document draft to MACE for final approval.

*Discussion of initial draft documentation on interoperation with a typical commercial SAML Service Provider*
(distributed to MACE-Dir by Etan Weintraub 9-Jan-2008 "RE: Action Items: MACE-Dir WG call, 4-Dec-07")

The intended audience for this is primarily InCommon participants interoperating with commercial SAML products. In effect it is really more of a configuration how-to guide for the Shibboleth documentation collection.

[AI] (Etan) will create a wiki topic for this in the Shibboleth wiki space with appropriate references.

*Continue discussion from March 3 call on Identity Assurance Profiles (was LOA) in SAML assertions; Establishing Conventions for URI-based representations*

- See <https://spaces.internet2.edu/x/Jhc> for a draft document on this topic
- See also the extensive discussion on the MACE-Dir thread, "RE: how to express a LoA/IAP"
- Attendees at the 5-Nov meeting recommended limiting these recommendations to apply only to InCommon, specifically for the Bronze and Silver Identity Assurance Profiles. The draft above reflects that recommendation.
- Subtopics suggested by Keith in MACE-Dir November 19 "Re: MACE-Dir agenda, Monday, Nov. 19, 2007, 4:30 pm EDT" and same day responses by Brendan Bellina and David Wasley
- InCommon “Bronze” and “Silver” LoA levels, which very roughly correspond to NIST 800-63 levels one and two. http://csrc.nist.gov/publications/nistpubs/800-63/SP800-63V1_0_2.pdf

One approach considered by the InCommon TAC (technical advisory committee) is to produce a separate metadata file containing participants operating at the Silver level. Another approach would be to create an attribute(s) (TBD) for LoA, which would be most portable across SAML versions and products. It is not clear whether this attribute might be like the authLOA attribute used in the usPerson schema.

It would seem that the appropriate place to define this attribute would be in MACE-Dir under the edu* umbrella, although Liberty may be working on something along this line as well.

Does specifying LOA “Silver” also imply that it is in effect a superset of and includes Bronze, or does LOA “Bronze” need to be explicitly stated as well? It would seem that in practical use Silver is indeed a superset of Bronze, and thus a RP who only requires Bronze should accept either Bronze or Silver…

There do not seem to be any potential problems associated with this approach, but we will be interested to hear about experiences in use.

Universities currently working with NIH are encouraged to try this approach and report back to us. The burden for carrying this forward lies with InCommon, not with MACE-Dir.

At a minimum, eduPersonEntitlement seems to be the existing attribute most appropriate to carry this value, at least in the near term pending definition of a dedicated attribute, but this may need to be revisited. InCommon is working on this and we will follow its progress in that forum.

Once this is worked out, the likely first application would be by organizations testing interoperability with NIH. Since Johns Hopkins is working with NIH, Etan is a good candidate to work with them about their requirements and probably future direction in this context.

Q: Should this include attribute usage and authentication characteristics?
A: This would depend upon the profile being referred to and thus it ought to be explicitly declared out of scope for us, for now...

[AI] (Etan) will follow up with NIH and report back.
[AI] (Brendan) will post a note about this to the list in search of broader feedback.

*Continue discussion from March 3 call on attributes/schema/etc for support of VOs*
(see MACE-Dir email thread "SAML V2.0 Attribute Profile for VOs")

Is isMemberOf the appropriate attribute to store group information related to VOs?

It was noted that Sun created their own isMemberOf operational attribute for their Java Enterprise (LDAP) Server, with different semantics. Given that their directory server is widely used, we need to take this into account going forward.

Q: Do we need another attribute serving this purpose with a unique name?
A: Short of taking it through the ITU for inclusion in X.520 there is not a lot of value in that effort.

Organizations using the Sun Java Enterprise Server who also want to use our isMemberOf attribute may need to find a work-around, but since the Object Classes and OIDs are different this may not be a real problem operationally. More research into this is required to fully understand the issues.

As a practical matter driving this discussion, how can VOMS be integrated into a Shibboleth-based federation? The OGSA AuthZ list was discussing this at one point, but not recently.

The next call will be Monday 24-March 4:30 EDT
Note: Etan has volunteered to chair the next call in Brendan’s absence.