*Attendees*

Jill Gemmill, UAB
Tom Barton Memphis
Samir Chatterjee, CGU
Nadim El-Khoury, UNC
Ken Klingenstein, Internet2
Steve Olshansky, Internet2
Jeanette Fielden, Internet2

*Discussion*
There is an article in InfoWorld by Jon Udell that talks about HIPAA implementing PKI in bite-size pieces. Ken will forward it to Steve for HIPAA distribution to the list.

Samir introduced the idea of writing a document for Internet2 to summarize ideas that have been introduced but not documented for credit to Internet2. With the introduction of the document library at the fall member meeting there is both space and promotional opportunities to talk about these sorts of ideas, where they fit together and where they haven't yet been explored. Details for ViDE.net could be documented as well. Samir will write a draft that will cover SIP directory integration and SAML in a federated approach. Jill can create a similar document for the H.323 approach.

In the ViDE.net group there has been considerable discussion around the fact that in the local authentication domain there are quite a few options today. LDAP, Radius, Kerberos, and some PKI. Many are doing LDAP, which also the choice for directory services so can we integrate the idea of SSO and the directory with LDAP? Yes, but we don't want to create the appearance that LDAP is the unifying force. We want to be careful about wrapping the local authentication with the inter-realm uses of LDAP for commObject. While H.323 relies on LDAP now and the only improved strategy relies on mostly unused end-user certificates, will this always be the case? Can the authentication service in the H.323 client be philosophically abstracted so it leaves open future development in non-LDAP areas?

Jill emphasized that one's authentication needs to somehow relate to the attribute. When you make use of the attribute authority that 's your authorization step. In the Shibboleth model your handle represents the link between the fact you authenticated and using the handle to discover attributes and make authorization decisions. The handle as implemented depends on web services. Whatever your authentication system was, if it happened not to be web services based what would be the equivalent of a handle that could be used? The attributes have to be associated with right person.

Based on the SAML document flows, whenever a policy decision point is approached a SAML token is handed and that token contains enough information to point to the reference so is there a concern if system has been SAMLized?

The key is what is the identifier in the SAML assertion? Is it a handle or a unique identifier that is transparent in some sense? Answer may lie in the privacy space. All agree a SAML assertion may contain information that may be sufficient to make a decision and if not, then contains an identifier that allows you to go back and ask for more information. The question is what kind of identifier is in there and will it point back opaquely or transparently? An important question to work through in the next few weeks is: Where and how do you plug into the information and decisions points that are now in this space? Is the assertion a push or pull model?

What are the constraints with the H.323 authentication? Where can an artifact be generated that might be passed along that the gatekeeper on the relying side might finally have in possession? There a gap that's not well understood there.

The problem of tying a handle that can be used to refer to is a necessary thing to understand in some detail, and involve the SAML experts in discussing so that it gets incorporated in the specifications as things progress. Jill and Ken will set up an informal discussion at the Internet2 fall member meeting to talk about these issues.

In looking at the H.235 Annexes (D, E and K), it might be possible to use other attributes, such as those in the commObject spec, H.323 identity dialed digits, identity URL id etc. as conveyances for information. The fact that the gatekeeper or endpoint used that information to do something different would be outside the current standard but that could be useful in driving development.

Jill explained that Annex D talks about handling certificates in H.323. Annex D does a hop-to-hop password, which gives you a secure channel so you can encrypt your media. If you have certificates you don't need to do hop-to-hop. You can pass each other your public keys and you're done. One of the nice things about using LDAP is: if you happen to have certificates you can reference the enterprise to get the enterprise public key. The certificates can be tied to an enterprise system. This is why PolyCom wanted to be its own certificate authority so it can distribute certificates for secure videoconferencing as an alternative to Annex D.

The whole security thing is to secure the conversation, for which there is a large interest in the market. People don't want to do open video conferencing for a number of reasons.

Radvision's preference is to develop software strictly inside the standard in the time frame of the grant. This is why there is not currently a gatekeeper that can interact with the AA. Since commObject is on it's way to becoming an ITU standard code can now be written using it. They have code in their stack today that is ready to do Annex D even though they haven't implemented anywhere. They have on their timeline to develop the port in their stack for certificates, which is Annex E, but it will be a year before it's available to be used for anything.

There is some soliciting for developers for gatekeepers to see if any of them can be recruited to developing some of the open source H.323. Those developers would need a fairly detailed architecture presented not a "here sit down with us and help figure this out from scratch" approach.

The next Authn/Z call will be scheduled via the e-mail list.