*Attendees*
Tom Barton, Memphis
Scott Cantor, OSU
Jill Gemmill, UAB
Jon Peterson, NeuStar
Samir Chatterjee, CGU
Tarun Abhichandani, CGU
Steve Olshansky, Internet2
Ken Klingenstein, Internet2
Nadim El-Khoury, U. North Carolina - Chapel Hill
Mudassir Fajandar, U. Colorado - Boulder
Jeanette Fielden, Internet2

*Discussion of by reference versus by value for assertions in SIP*
Is there some value to carrying around the assertion within the request or just a reference to the assertion? If just a reference to an assertion is being carried intermediaries may be uncertain if they need to resolve it. Whoever handles the call can attempt to view the assertion. How much information the assertion actually has is a separate matter. You don't necessarily need to block intermediaries from seeing it. If it refers to a MIME body then end-to-end security restrictions apply. You can also authenticate the actual retrieval of the assertion as well.

One possibility is content indirection: a proposal in the SIP working group for an extension to SIP. There is some body for a SIP request that you want to be able to refer to, as opposed to carry by value in a request. Content indirection is a way to carry around a URL that refers to a mime body in SIP. There are two drafts: a requirements document and a mechanism draft. The mechanism draft refers to the URL mime-type and how you control various properties of the URL, such as how long it's valid for, etc. The drafts are available at:
http://www.ietf.org/internet-drafts/draft-ietf-sipping-content-indirect-01.txt
http://www.ietf.org/internet-drafts/draft-ietf-sip-content-indirect-mech-00.txt

Content indirection moves beyond SAML artifacts to the Web security notion of security token references. The artifact is really intended as a one-time use piece of data that would immediately be used to resolve the full piece of data and has to be used in a very controlled very specific fashion. This instance talks more about: "I don't want to put the whole message in, I just want to put a reference in so the person that wants to can resolve it and I will deal with questions about integrity etc. in a separate way." Content indirection models more against WS-Security. Information on Ws-Security is available at: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnglobspec/html/ws-security.asp
Another consideration in crafting a solution is that some choices may be easier to implement in H.323 than others, without constraining options for SIP. Jill is gathering summaries of possible approaches in H.323 and will distribute them for evaluation. One possible approach is the use of digital certificates. Gateways using signaling could push a digital certificate through. In SIP there is the concept for end-to-end security, in H.323 this exists only for digital certificates. Are there other possible approaches?

Recommendation: carry by reference is indicated for the majority of cases since an assertion can be large.

Do any of these approaches have implications for a point and click resource discovery process for initiating calls. I.e. a directory page of links to people you might want to call, where you click on a name and a call is initiated? In SIP, it would be a URI you click on and that SIP URI would be consistent for a person regardless of their location. SIP associates devices with addresses of record through registration so the back end reconciliation of the URI to their current location is a solved problem by SIP. It is also feasible to use an existing credential to be the authenticating mechanism for the registration process All SIP user agents must support digest, but you are not restricted from using other mechanisms.

What form would a single sign-on architecture take for SIP? What information does your SIP client really need to have in order for it to be single sign-on? Perhaps it has one pre-loaded route header that is single sign-on because there is one place through which all requests will be sent and that place will provide the assertion for the request. This would allow you to register through an authentication service. The way in which you learn the URI of the authentication service through which you're going to send calls has to be part of whatever your single sign-on procedure is. It's possible to construct a SIP URI that tells you to add route headers. Example: click on a web page link, which is a SIP URI to send this kind of request through this server to get to a particular place. Just making a call is not going to install the preloaded route header into the client. It needs to be figured out how to make that part of the single sign-on process.

Which leads to questions such as: How does a SIP client have a concept of single sign-on? What needs to be passed to the client?