PartnerID format

["Mishra, Prateek" <pmishra@netegrity.com>]

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