Richard Barnes wrote:
>
> 1. Conveying SAML assertions via a URI in the Identity-Info header
> contradicts Section 9 of RFC 4474, which says that the resource
> indicated MUST be of type "application/pkix-cert". ISTM there are at
> least a couple of ways to fix this:
>
> 1.a. Normatively update RFC 4474 to allow the resource to be of either type
>
> 1.b. Normatively update RFC 4474 to allow for a "multipart/mixed" with
> one part of each type
>
> 1.c. Add a separate header to carry the SAML assertion
>
> In the interest of backward-compatibility, I don't think you can get rid
> of application/pkix-cert altogether.
thanks, yes this is definitely an issue. We'd noticied it soon after RFC4474's
publication. There was a 3-message thread at the end of Oct-2006 discussing it.
Hannes' final message..
Re: [Sip] Re: wrt RFC4474 'absoluteURI' in Identity-Info header field and
SIP-SAML implications
http://www1.ietf.org/mail-archive/web/sip/current/msg17101.html
..summarizes it well, and proposes essentially Richard's proposed 1.c. solution
(note that the ostensible new header would convey a URI rather than a SAML
assertion by-value (conveyance of complex objects by-value in SIP header fields
being a higher-level (contentious) issue).
Also note that this is issue12 in the sip-saml tracker..
http://www.tschofenig.com:8080/saml-sip/issue12
In his message of Tue, 31 Oct 2006 03:54:02 -0400, Hannes was thinking that the
equivalent of option 1.c above would be the likely course of action.
However, option 1.{a,b} would be possible if draft-ietf-sip-saml-xx were to
appropriately normatively update RFC4474 wrt the specific language of the
second para of page 15 (in RFC4474).
What do folks think we should do here?
thanks,
=JeffH
_______________________________________________
Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
