[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: PartnerID format
Discussions at the f2f#4 and at the bindings con-call on September 6, 2001 raised several issues concerning the "PartnerID" component of a SAML artifact (Section 4.1.3, draft-sstc-bindings-model-05). I have split the discussion into several sub-parts, so that folks can separately agree or disagree with each sub-part. Please respond with a set of choices and rationale (if appropriate). (1) As currently written, PartnerID's are constructed in the context of a relationship between a Source Site and Destination Site. This suggests a single site may have multiple PartnerID's, each for use with a different a destination site. A number of folks at the f2f#4 argued that this was an administrative nightmare and that sites should be associated with a single unique PartnerID drawn from some "managed namespace". This would ensure that a source site could utilize a single PartnerID for all of its relationships with Destination sites. YOUR CHOICES: Agree OR Disagree (2) If we accept the change that a managed namespace is required for PartnerIDs, what should this namespace be? Please keep in mind that a bounded size SAML artifact requirement requires a bounded size PartnerID. (a) An IP address (4 bytes) (b) A DNS domain name (restricted to 30 bytes?) (c) arbitrary 4 byte string (d) a new namespace proposal YOUR CHOICES: One of a/b/c/d, for (d) please explain your namespace proposal and its strengths relative to (a) thru (c). (3) The assumption in (1) and (2) above is that sites continue to maintain a mapping table of the form: PartnerID X (Complete) URL for artifact-to-assertion lookup service Such a table would be maintained at each destination site and would consist of a list of pairs as shown above. It has further been suggested that we could eliminate this table by providing the (complete) URL for artifact-to-assertion lookup service AS the PartnerID within the SAML artifact. The destination site simply uses the PartnerID as the URL for the artifact-to-assertion lookup service. YOUR CHOICES: Support this suggestion/Oppose this suggestion. (4) If we accept the change suggested in (3), we are left with the difficulty that PartnerID is no longer of bounded size. How can we meet the bounded size requirement for PartnerID's? (a) arbitrarily restrict PartnerID to some maximum size (e.g., 75 bytes). Note that this not as onerous a restriction as it may seem, as the source site can employ various mapping techniques to bind an actual ASP/JSP/Servlet to this address. (b) Support two types of PartnerID's: (i) size restricted URL (e.g., 75 bytes) (ii) SHA-1 digest of URL (8 bytes). Further, utilize the SAML artifact TypeCode and assign different type codes to each choice (e.g., 0x0001 and 0x0002). (c) I do not support the suggestion in (3), so I have no proposal in this space. YOUR CHOICES: One of a/b/c
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC